The eant function inside java-utils-2 is broken. In fact it prepares the classpath defining the gentoo.classpath property which is not used anywhere (is was used by functions of java-ant-2.eclass which has been removed from portage)
(In reply to Fabio Rossi from comment #0) > The eant function inside java-utils-2 is broken. In fact it prepares the > classpath defining the gentoo.classpath property which is not used anywhere > (is was used by functions of java-ant-2.eclass which has been removed from > portage) Could you please provide a pull request patching it out and also fixing the documentation which is presently looking weird on 1, lines 423-437. [1]https://devmanual.gentoo.org/eclass-reference/java-utils-2.eclass
that function was designed to be used with java-ant-2.eclass which has been phased out, do you mean to remove only the definition of gentoo.classpath, right? There are many packages using eant, I think an ant wrapper is convenient to have in portage. I don't know why you decided to remove java-ant-2.eclass. With complex libraries it is not just a matter of compiling together a bunch of java classes in a jar, reimplementing the build.xml logic without using ant is IMHO pretty the same as reinventing the wheel.
(In reply to Fabio Rossi from comment #2) > that function was designed to be used with java-ant-2.eclass which has been > phased out, do you mean to remove only the definition of gentoo.classpath, > right? Yes, exactly. Plus fixing/updating documentation tags. > There are many packages using eant, I think an ant wrapper is convenient to > have in portage. I don't know why you decided to remove java-ant-2.eclass. > With complex libraries it is not just a matter of compiling together a bunch > of java classes in a jar, reimplementing the build.xml logic without using > ant is IMHO pretty the same as reinventing the wheel. In fact, the eant() function and anything which is needed only for eant() should be moved to its own (new) eclass. Ant as build system is used only by a small number of packages while java-utils-2.eclass should provide only basic variables and functions which are needed by a majority of packages. We did not reimplement any build.xml logic at all. dev-java/ant is still there and eant() is being used in packages which for some reason need it like hsqldb, i2p, tomcat, ... The old java-ant-2.eclass was good for nothing but triggering the xml-rewriter of javatoolkit which has also finally been removed in bug #942810.
(In reply to Volkmar W. Pogatzki from comment #3) > > There are many packages using eant, I think an ant wrapper is convenient to > > have in portage. I don't know why you decided to remove java-ant-2.eclass. > > With complex libraries it is not just a matter of compiling together a bunch > > of java classes in a jar, reimplementing the build.xml logic without using > > ant is IMHO pretty the same as reinventing the wheel. > In fact, the eant() function and anything which is needed only for eant() > should be moved to its own (new) eclass. Ant as build system is used only by > a small number of packages while java-utils-2.eclass should provide only > basic variables and functions which are needed by a majority of packages. > > We did not reimplement any build.xml logic at all. dev-java/ant is still > there and eant() is being used in packages which for some reason need it > like hsqldb, i2p, tomcat, ... > > The old java-ant-2.eclass was good for nothing but triggering the > xml-rewriter of javatoolkit which has also finally been removed in bug > #942810. Ok, but you are suggesting to move eant to its own class, so creating back a new java-ant class. I have recently discovered what xml-rewriter was doing and I think the concept was right (maybe not implemented properly, I don't know which was the problem), in particular it was possible to amend build.xml files for custom classpath lookup. Now it is potentially needed some logic to add missing classpath in each ebuild individually, I think having some helper code in an eclass would be good as part of a framework offered to ebuild developers (and please consider also who write ebuilds in overlays outside portage). In spite of that the gentoo.classpath can be still useful, I would prefer to think more about a new design and what we want to achieve before patching the current code
(In reply to Fabio Rossi from comment #4) > (In reply to Volkmar W. Pogatzki from comment #3) > [...] > Ok, but you are suggesting to move eant to its own class, so creating back a > new java-ant class. [...] It is not about creating back anything. Just an idea to carve out what's not of general use. [...] > [...] > classpath lookup. Now it is potentially needed some logic to add missing > classpath in each ebuild individually, [...] Before adding anything new, please point us to a bug report or to an existing ebuild in ::gentoo which would need such.
(In reply to Volkmar W. Pogatzki from comment #5) > (In reply to Fabio Rossi from comment #4) > > (In reply to Volkmar W. Pogatzki from comment #3) > > [...] > > Ok, but you are suggesting to move eant to its own class, so creating back a > > new java-ant class. [...] > It is not about creating back anything. Just an idea to carve out what's not > of general use. [...] I would be in favour of adding a specific class > > [...] > > classpath lookup. Now it is potentially needed some logic to add missing > > classpath in each ebuild individually, [...] > Before adding anything new, please point us to a bug report or to an > existing ebuild in ::gentoo which would need such. Maybe I was not too clear, I stated that new feature is to improve the capabilities of the current framework available for java ebuild developers. As an example, I am currently maintaining my ebuilds for gluegen/jogl which unfortunately were phased out a long time ago from portage. The old ebuilds were using the java-ant-2 eclass with the xml-rewriter logic, the build system is based on ant. Now I am converting them using only eant and I had to patch the build file for the classpath issue. In the process I have discovered the gentoo.classpath property and opened this bug :-)
(In reply to Fabio Rossi from comment #6) > (In reply to Volkmar W. Pogatzki from comment #5) > [...] > As an example, I am currently maintaining my ebuilds for gluegen/jogl which > unfortunately were phased out a long time ago from portage. The old ebuilds > were using the java-ant-2 eclass with the xml-rewriter logic, the build > system is based on ant. Now I am converting them using only eant and I had > to patch the build file for the classpath issue. In the process I have > discovered the gentoo.classpath property and opened this bug :-) For classpath, if there are more dependencies, a 'build.properties' HERE file should be used as can be seen in tomcat ebuilds. For single dependencies it could even be done like in hsqldb-2.7.4. That way it won't need any eclass variable for classpath. Something potentially more helpful for packaging might be if an eclass provided ant.build.javac.source="$(java-pkg_get-source)" ant.build.javac.target="$(java-pkg_get-target)" But that's only two lines in the ebuild.
the her(In reply to Volkmar W. Pogatzki from comment #7) > (In reply to Fabio Rossi from comment #6) > > (In reply to Volkmar W. Pogatzki from comment #5) > > [...] > > As an example, I am currently maintaining my ebuilds for gluegen/jogl which > > unfortunately were phased out a long time ago from portage. The old ebuilds > > were using the java-ant-2 eclass with the xml-rewriter logic, the build > > system is based on ant. Now I am converting them using only eant and I had > > to patch the build file for the classpath issue. In the process I have > > discovered the gentoo.classpath property and opened this bug :-) > For classpath, if there are more dependencies, a 'build.properties' HERE > file should be used as can be seen in tomcat ebuilds. For single > dependencies it could even be done like in hsqldb-2.7.4. That way it won't > need any eclass variable for classpath. > > Something potentially more helpful for packaging might be if an eclass > provided > ant.build.javac.source="$(java-pkg_get-source)" > ant.build.javac.target="$(java-pkg_get-target)" > But that's only two lines in the ebuild. the build.properties solution is equivalent in defining the properties with -Dxxx on the command line, that is used to overwrite the values used in the build.xml. It is not always so easy unfortunately because the dependencies list may be wrong, for instance I had to patch the build.xml as --- ./make/build.xml 2025-03-04 22:43:47.547003953 +0100 +++ ./make/build.xml.new 2025-03-04 22:52:30.855954704 +0100 @@ -32,12 +32,14 @@ <path id="cc_gluegen.classpath"> <pathelement location="${antlr.jar}" /> <pathelement location="${semver.jar}" /> + <pathelement path="${env.GENTOO_CLASSPATH}" /> </path> <path id="javadoc_gluegen.classpath"> <pathelement location="${ant.jar}" /> <pathelement location="${antlr.jar}" /> <pathelement location="${semver.jar}" /> <pathelement location="${gluegen.jar}" /> + <pathelement path="${env.GENTOO_CLASSPATH}" /> </path> </target> where I use the env GENTOO_CLASSPATH in the ebuild to pass the missing jars (mimicking the old gentoo.classpath implementation). In that case jsr305 is missing from the needed jars. An helper function needed to patch the xml element (with the result equivalent to the patch above) would be very useful, for example java-ant-add-path cc_gluegen.classpath $(java-pkg_getjars jsr305)
(In reply to Fabio Rossi from comment #8) > the her(In reply to Volkmar W. Pogatzki from comment #7) > [...] > (mimicking the old gentoo.classpath implementation). In that case jsr305 is > missing from the needed jars. An helper function needed to patch the xml > element (with the result equivalent to the patch above) would be very > useful, for example > > java-ant-add-path cc_gluegen.classpath $(java-pkg_getjars jsr305) Guess it's not more than a handful of ebuilds which could use that? I still prefer the way we did it for tomcat in www-servers/tomcat/files/tomcat-9.0.87-gentoo-bnd.patch
