I have done this eclass for java-commons. It's really for all the commons in jakarta.apache.org. And in so doing, updated the necessary ebuilds for the commons stuff. Reproducible: Always Steps to Reproduce:
Created attachment 9281 [details] java-commons.eclass This is the java-commons.eclass. This is not as elegant as I would want it. So if you are a bash guru, just tune it up a little. The significant portions that are required by the packages are there.
Created attachment 9282 [details] commons-beanutils-1.6.1.ebuild Updated proof of concept for beanutils 1.6.1
Created attachment 9283 [details] commons-cli-1.0.ebuild *NEW* commons-cli
Created attachment 9284 [details] commons-collections-2.1-r2.ebuild *Updated* to use the java-commons.eclass
Created attachment 9285 [details] commons-dbcp-1.0-r2.ebuild *Updated* to use java-commons.eclass
Created attachment 9286 [details] commons-logging-1.0.2-r2.ebuild *Updated* to use java-commons.eclass
Created attachment 9287 [details] commons-digester-1.4.1.ebuild *Updated* to new version
Created attachment 9288 [details] commons-pool-1.0.1-r3.ebuild *Updated* to use java-commons
Created attachment 9289 [details] commons-validator-1.0.1-r1.ebuild *Updated* to use java-commons
Created attachment 9290 [details] commons-fileupload-1.0_beta.ebuild *NEW* Added this package.
Created attachment 9291 [details] commons-discovery-0.1.ebuild *NEW* Added
Created attachment 9292 [details] commons-httpclient-2.0_alpha3.ebuild *NEW* Add this now.
Created attachment 9293 [details] commons-lang-1.0.1-r1.ebuild *Updated* to use java-commons
Created attachment 9294 [details] commons-net-1.0.0.ebuild *NEW* Added this one.
Im getting this one since i made all the current jakarta-commons ebuilds available.
Is there anyway I can help to speed the process up a little to get this in the official portage tree??
FYI -- I just checked in dev-java/commons-cli for something else I was working on. Lim: This is great that these ebuilds have been submitted, but I have to ask: What is the reasoning behind making an eclass for commons? I didn't see any compelling case to make an eclass for either the commons or avalan classes. But maybe I'm missing something.
There is: a. If you do look at the ebuilds now, they are significantly reduced. b. It lowers the bar for someone to add yet another package for java-commons. c. Certainly, if you look at it, the class can be used for just about _any_ java package, since everything that is on jakarta now uses ant. d. And since all the src_compile are the same, you really want to flag this as a common installation code. e. It's just good programming practice. So that if all the installation process needs to be changed, since it's all in one file, you really want to just use the eclass. f. On the other hand, why don't you answer the question on why you do not need to make an eclass for the java classes, in and especially since they do share some amount of significant code. Ciao ST Lim
im testing all the ebuild and the eclass, so sooner it will be available on testing on portage.
Dylan, can you take care of commons-cli ebuild so it uses the eclass ? cause there's a patch you made and i dont have time now on checking it. im updating all others, and adding the new ones. Best Regards, Adrian
I fixed/hacked away at the eclass a little bit, and it's checked in. * added a 'makedoc' target so that USE=doc can be implemented for API docs * changed ${targetlist} --> ${ant_targetlist} because it was breaking the while loops from using the correct targets. Also checked in dev-java/commons-cli-1.0-r2 which makes use of this eclass... currently masked for testing. Have not looked at any of these other ebuilds (yet).
Created attachment 9544 [details] updated java-commons.eclass This is in CVS as well...
Cool. You might like to note that: a. for commons-cli, you can instead of using a patch file, use a command: echo "final.name=commons-cli-1.0" >> build.properties b. for the eclass that is currently in CVS, you might like to change the section for make to use either or dist-jar or jar instead of just using the "jar" target at the moment. I had used the "dist" target. c. You can remove the comment in the all build section. Ciao ST Lim
Oops. Sorry about the commons-cli. If you needed to change the name of the file, you do need to use a patch. Just tested, and build.properties does not work.
Created attachment 9546 [details] java-commons.eclass You'll probably find that the "dist" target will be more univerally known. Most of the projects have a dist target, and do not have a jar target. This eclass reflects this change.
Something better needs to be done in the make section. I'm thinking about it. Unfortunately, 'dist' is not a good target because it builds _everything_ and that's not what we want, so to avoid building docs/javadocs if the user doesn't want them. jar/dojar/dist-jar are all valid depending on which package we're talking about. It'd be nice if they picked one and standardized on it. That's one of the problems with the eclass method. If all commons-* distributables were packaged the same way and had the same build.xml conventions, it would be a no-brainer. I'll look at this some more tonight maybe and see if I can fix up the make target at least.
Comment on attachment 9546 [details] java-commons.eclass invalid
i think we should change the name of the eclass from java-commons to jakarta-commons, cause its only jakarta stuff so it should be better named. Any thoughs on renaming the eclass ?
Adrian: I agree. It's been done. eclass was renamed to jakarta-commons, functions were renamed to jakarta-commons, and the dev-java/commons-collections and dev-java/commons-cli ebuilds were corrected.
Created attachment 9574 [details] jakarta-commons.eclass Realize that all the other ebuilds attached to this bug will now need to be changed, and don't forget the function names too.
Fine, ill work on these ebuilds ASAP, thanks also for making the eclass change !
Alrighty. All the builds are checked in. Test them out, and open new bugs for whichever ebuilds you do happen to catch bugs in. On another note: We will need to do some improving of this eclass. A few of them don't build jars, just classes. I didn't expend much thought on this, and hacked around it inside the ebuilds for now. We'll need a better long-term solution. If you have any ideas, please send them on. Closing. Cheers
Hi, I've mentioned that there is no definite target in between packages to get jar files. The most common target/denominator in this case is really to use the dist target if you want jar files. :) And this is effective on the other apache based java projects. Someone will need to highlight this problem with target standards with either ant or the apache java groups. Ciao ST Lim
This is true, yet 'dist' isn't an acceptable target for us in the larger picture of what we want to achieve with Gentoo. The 'doc' USE flag, in particular should be active in all the Java builds, which rules out using the 'dist' target. I have temporarily worked around this by building jars out of the class files manually, but nothing has been integrated into the eclass as of yet. My basic requirement for any new ebuild (at least ones that I'm working on) is that it must be able to accept the 'doc' flag. Additionally, if compiling from source, it should be able to use 'jikes', unless there's some incompatibility that cannot be resolved through normal means. I am reasonably suspect of anything that doesn't compile successfully with Jikes.
