As bug 142186 showed, classpath that ant uses for itself can affect the stuff being compiled too. Look at this - http://ant.apache.org/manual/running.html Especially: Note that the CLASSPATH environment variable is passed to Ant using a -lib option. Ant itself is started with a very minimalistic classpath. Ant should work perfectly well with an empty CLASSPATH environment variable, something the the -noclasspath option actually enforces. We get many more support calls related to classpath problems (especially quoting problems) than we like. the current ant startup script doesn't do that, it's passing the CLASSPATH for ant's libs to the VM directly, so they are affecting the javac compiling stuff... This should be fixed.
Created attachment 93262 [details, diff] attempt to fix the ant startup script attempt to fix that. the classpath for stuff needed by optional ant tasks isn't appended to the JVM classpath but passed to ant with -lib. Seems to work here but I don't guarantee it's proper :)
Hm no that wasn't it. It behaves the same, providing anything passed by the -lib to the compiled stuff too. But still the patch could be applied if it doesn't break anything, as upstream suggests -lib usage. What makes the difference is using -Dbuild.sysclasspath=ignore. See http://ant.apache.org/manual/sysclasspath.html. Maybe this should be added to the eant in eclass?
We should probably get an overlay setup to test this, and then would need to test _all_ java packages. This is an issue I've wanted to address for some time, but it'll take a bit of time to fully address...
Ok, here's what I can do... There's a java-strict FEATURE that is used a few times. So in eant, I do: if is-java-strict; then einfo "Disabling system classpath for ant" antflags="${antflags} -Dbuild.sysclasspath=ignore" fi This will let us be able to test it by having FEATURES=java-strict, and let other users be able to test it too. Once we're sure it'll work everywhere, we can make it the default behavior.
Great. On a related note, I was thinking about ant-tasks. Trying to test if package needs full ant with ant-tasks or if ant-core is enough isn't the easiest. I need to quickpkg ant-tasks, unmerge it, test and later merge it back from package. If it was possible to determine if ant-tasks are used with some envvar, it would be easier. Currently ant-tasks symlink their libs to $ANT_HOME/libs so it's kinda unseparable. This dir is passed as -Dant.library.dir. If it wasn't symlinked, maybe we could pass the dirs separated, allowing to leave the ant-tasks one if wanted. But I guess -Dant.library.dir can be only one dir... in that case there would have to be new dir that would get symlinks from both ant-core and ant-tasks, and the env flag could determine if the full dir is used or just ant-core/lib dir...
Created attachment 93304 [details, diff] improved ant startup script patch, allowing to disable ant-tasks and their deps if they are not installed or overrided by JAVA_PKG_FORCE_NOANTTASKS=yes
Created attachment 93305 [details, diff] patch for ant-core ebuild to create needed dir to work with the startup script patch The idea of this is that it will create /usr/share/ant-core/lib-core in addition to /usr/share/lib. ant-tasks ebuild puts symlinks to the .../lib so .../lib-core stays clean and can be used to invoke ant without ant-tasks and their classpath deps even if they are installed, by setting JAVA_PKG_FORCE_NOANTTASKS=yes. The eclass could then set this variable in eant based on FEATURES="java-strict" and DEPENDS containing only ant-core, not full ant or ant-core + ant-tasks. It would be then easier to determine what is needed when creating+testing the ebuild. This is the basic idea, not the most elegant, on IRC nichoj came up with even more complicated way of having each of ant-tasks in separate ebuild and precisely defining which ones to load...
Actually this lib-core dir and symlink voodoo isn't needed. And it would be impossible to implement the idea of separated ant tasks (+ their deps) like that, imagine one libdir with symlinks for each of possible combinations of enabled tasks... Luckily, it's equivalent to pass just the minimalist ant-core/lib (without symlinked jars from ant-tasks) as ant.library.dir and pass any desired task jars and their deps as -lib $TASKSCLASSPATH.
Ignore comments 5-8 because split-ant is handled elsewhere :) (In reply to comment #4) > This will let us be able to test it by having FEATURES=java-strict, and let > other users be able to test it too. Once we're sure it'll work everywhere, we > can make it the default behavior. How bout we make it the default behaviour already? I don't think many bugs should pop up at this point.
(In reply to comment #9) > > How bout we make it the default behaviour already? I don't think many bugs > should pop up at this point. > In ~arch this is safe. Someone should run a script on a stable machine to emerge everything with this on before we always turn it on.
Well seems now we have the script, so time to toss it on arch teams (with eclass patch that makes sysclasspath-ignore passed always), like in the sun-jdk-1.6 case? And then apply the patch.
(In reply to comment #11) > Well seems now we have the script, so time to toss it on arch teams (with > eclass patch that makes sysclasspath-ignore passed always), like in the > sun-jdk-1.6 case? And then apply the patch. > Indeed. We could have done them both at the same time :)
Created attachment 135729 [details, diff] patch for java-utils-2.eclass to make build.sysclasspath ignored by default
Created attachment 135776 [details] list of x86 stable packages OK time to make the build.sysclasspath setting default and not only JAVA_PKG_STRICT. But because it affects stable ebuilds, it should be tested first. I'll be attaching lists for arches to test, please apply the eclass patch locally and report results.
Created attachment 135796 [details] amd64 list
Created attachment 135820 [details] ppc list
Created attachment 135822 [details] ppc64 list
portagemaster is masked for removal, so no need to test it.
(In reply to comment #18) > portagemaster is masked for removal, so no need to test it. Yeah it's possible that the script for creating the list doesn't take p.mask into account, so just skip such packages, thanks.
(In reply to comment #19) > (In reply to comment #18) > > portagemaster is masked for removal, so no need to test it. > > Yeah it's possible that the script for creating the list doesn't take p.mask > into account, so just skip such packages, thanks. > http://overlays.gentoo.org/proj/java/browser/scripts/find-stable-java-ebuilds Script updated to now show package.masked stuff.
Filtered jikes and ecj-3.2 on dev-java/commons-logging. Filtered jikes on games-util/searchtool (When I noticed that I did not apply the patch nearly all packages were already tested...thumbs up for wasted calculation cycles), will come back in some hours with results for x86.
Created attachment 135886 [details] build.log for dev-java/xom-1.0-r2 dev-java/xom fails, succeeds without patch filtered jikes on dev-java/jakarta-jstl, app-editors/jedit, dev-java/relaxngcc, dev-java/spin, dev-java/xstream and dev-db/octopus >>> Install mx4j-3.0.1-r2 into /var/tmp/portage/dev-java/mx4j-3.0.1-r2/image/ category dev-java java-pkg_dosrc called without app-arch/zip in DEPEND
x86 out of here, only one package failing
(In reply to comment #22) > Created an attachment (id=135886) [edit] > build.log for dev-java/xom-1.0-r2 > > dev-java/xom fails, succeeds without patch > Please post the error. > > > >>> Install mx4j-3.0.1-r2 into /var/tmp/portage/dev-java/mx4j-3.0.1-r2/image/ category dev-java > java-pkg_dosrc called without app-arch/zip in DEPEND > Fixed.
(In reply to comment #24) > (In reply to comment #22) > > Created an attachment (id=135886) [edit] > > build.log for dev-java/xom-1.0-r2 > > > > dev-java/xom fails, succeeds without patch > > > > Please post the error. > lol there is the log
+*xom-1.0-r3 (13 Nov 2007) + + 13 Nov 2007; Petteri Räty <betelgeuse@gentoo.org> +xom-1.0-r3.ebuild: + dev-java/servletapi is only needed to build the examples to add examples use + flag. Also now it does not get picked automatically from ant classpath. + Reported in bug #142538. + Ok so let's get this stable.
x86 stable
xom stable on ppc, I'm compiling packages from the list now, will report back when it finishes.
All ok on ppc.
(In reply to comment #26) > +*xom-1.0-r3 (13 Nov 2007) > Ok so let's get this stable. Not this one anymore but -r4 in the blocker bug 199673.
from amd64 list here, emerge: there are no ebuilds to satisfy "dev-java/jgoodies-looks:1.3". emerge: there are no ebuilds to satisfy "dev-java/xerces:2.6". Calculating dependencies... done! [ebuild N ] www-servers/tomcat-6.0.14-r1 USE="test -doc -examples -source" [ebuild N ] dev-java/commons-dbcp-1.2.2 USE="test -doc -source" !!! Error: circular dependencies: ('ebuild', '/', 'dev-java/commons-dbcp-1.2.2', 'merge') depends on ('ebuild', '/', 'www-servers/tomcat-6.0.14-r1', 'merge') (hard) ('ebuild', '/', 'www-servers/tomcat-6.0.14-r1', 'merge') depends on ('ebuild', '/', 'dev-java/commons-dbcp-1.2.2', 'merge') (hard) !!! Note that circular dependencies can often be avoided by temporarily !!! disabling USE flags that trigger optional dependencies.
Removed ebuilds and I guess the circular dep. can't be avoided with test? Anyway, giving a shot to the list now.
xom-1.0-r4 stable on ppc64. all other packages compile/install.
amd64 is good, I've emerged everything from list posted here w/ patch applied. However, these fail test suite: joda-time, bug 187616 pmd, bug 200220
Eclass patch commited. Thanks everyone.
