Bugzilla Bug 142538

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 an attachment (id=93262) [details]
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 an attachment (id=93304) [details]
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 an attachment (id=93305) [details]
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 an attachment (id=135729) [details]
patch for java-utils-2.eclass to make build.sysclasspath ignored by default

Created an attachment (id=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 an attachment (id=135796) [details]
amd64 list

Created an attachment (id=135820) [details]
ppc list

Created an attachment (id=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 an attachment (id=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] [details]
> 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] [details]
> > 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.