dev-utils/groovy could use a version bump Improvements that could be done to the ebuild: * check the deps. project.xml seems that all is not needed and some are optional * improve the wrapper script. Could probably be done by dolauncher for example
Created attachment 95196 [details] Some work done This ebuild is NOT compleat.. but it will compile the jar for the latest version.. im still fitteling to get the cli to work.. but others are welcome to join..
Created attachment 95198 [details] The autogenerated build.xml This build.xml is needed in files..
How do we handle all these optional features?? Do we 1) Include none 2) Include the ones "we" like 3) Include each and every one 4) Use ALOT of useflags.. This is not only a question for this package but for java packages in gereral.. A lot a java packages has support for alot of optional stuff.. it seems to me that the current approach is "3". => emerge <some java package> => install alot of crap that no sane perseon uses. Unlike with c packages the java packages can be linked (with supplid jars) to no remerging of a package is needed to make optional feetures work...
Created attachment 95200 [details] Almost there Ok.. most of the cli tools seems to work out of the box with standard launchers.. the onlything missing is the groovyConsole.. it needs groovyc to compile.. but groovc is first avail in the install fase... is there some way to create a temp launcher??
While a lot of things are 'optional', they are almost always optional at runtime, ie you simply don't provide the appropriate classpath that the optional parts need. But... you still need them at build time, because source would import classes from said dependency. This is because most packages don't sanely support building optional support, and so we usually end up deleting source code for the optional features.
(In reply to comment #5) > While a lot of things are 'optional', they are almost always optional at > runtime, ie you simply don't provide the appropriate classpath that the > optional parts need. > > But... you still need them at build time, because source would import classes > from said dependency. This is because most packages don't sanely support > building optional support, and so we usually end up deleting source code for > the optional features. > I get that.. but how do we deside what 'optional' things to include... eg. in this project what optional feetures do we include?
Created attachment 95416 [details] groovy-1.0.6.ebuild I have found all optional feetures that can be toggeled by simply removing files.. and made them enableble via useflags... please give me some feetback..
The ebuild looks pretty good overall. * USE flag dependencies should always be in parentheses. ie test? ( >=dev-java/junit-3.8.1 ) note: there should be space after start ( and before end ) * I'm not sure about calling it 1.0.6. It's versioned as 1.0-jsr-6, whatever that is. I think it might be better to call it _rc6, so we don't have to worry about doing a downgrade if a real 1.0.x release comes out. * Typo in use flag in dep, sommandlinetools :) * IUSE=source, but you don't do anything with it. * >=dev-java/asm-2.2 isn't a valid dependency (not in main tree) * >=dev-java/xstream-1.1.1 isn't a valid dependency (not in main tree) I think it may be better to, at least initially, include most of the kitchen sink by default without USE flags. If there are things with really big dep trees or something, we can consider USE flag. The idea here, is that we end up with groovy having most/all of the libraries that someone using groovy would expect.
Right, there's bugs open for those two depends :)
After some tweaking, I've added it to our overlay: https://overlays.gentoo.org/svn/proj/java/migrated-java-experimental-overlay/dev-java/groovy Still needs a little work though. In particular, groovyConsole gets an exception, probably because I'm using asm-2.0.x.
Added as groovy-1.0.06. Thanks for the contribution :)
