The jax-rpc ebuild has lib/mail.jar hardcoded into the ant call, but gnu-javamail-1.0 did provide a jar file with a different name. The gnu-javamail-1.0-r2 ebuild was changed to provide mail.jar instead. Suggested solution: provide a new ebuild for java-virtuals/javamail which changes its dependency on gnu-javamail to 1.0-r2 and therefore always provides a mail.jar. Then have jax-rpc depend on this new javamail virtual. This will ensure the correct update order. Quick workaround until this fix is in place: manually update gnu-javamail. Details from emerge: * Using all available ANT_TASKS Buildfile: build.xml init: [echo] -------- JAX-RPC RI 1.1.3_01-INTERNAL -------- [echo] java.mail=lib/mail.jar BUILD FAILED /var/tmp/portage/dev-java/jax-rpc-1.1.3.01-r1/work/jaxrpc-ri/build.xml:187: The java.mail property does not reference an existing file: lib/mail.jar Total time: 1 second * * ERROR: dev-java/jax-rpc-1.1.3.01-r1 failed. * Call stack: * ebuild.sh, line 1762: Called dyn_compile * ebuild.sh, line 891: Called qa_call 'src_compile' * ebuild.sh, line 35: Called src_compile * environment, line 3946: Called java-pkg-2_src_compile * environment, line 2145: Called eant 'image' 'javadocs' '-f' 'build.xml' '-Djava.mail=lib/mail.jar' * environment, line 920: Called die * The specific snippet of code: * ant ${antflags} "${@}" || diefunc "$FUNCNAME" "$LINENO" "$?" "eant failed" * The die message: * eant failed * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/log/portage/dev-java:jax-rpc-1.1.3.01-r1:20071128-092530.log'. * !!! When you file a bug report, please include the following information: GENTOO_VM=sun-jdk-1.5 CLASSPATH="" JAVA_HOME="/opt/sun-jdk-1.5.0.13" JAVACFLAGS="-source 1.5 -target 1.5" COMPILER="javac"
java-virtuals/javamail already depends on RDEPEND="|| ( dev-java/sun-javamail >=dev-java/gnu-javamail-1.0-r2 )" Did java-virtuals/javamail get pulled in before jax-rpc?
(In reply to comment #1) > java-virtuals/javamail already depends on > RDEPEND="|| ( dev-java/sun-javamail >=dev-java/gnu-javamail-1.0-r2 )" Indeed! And the installed ebuild contains this as well. I have both implementations present on my system. Could it be that gnu-javamail was not updated, because sun-javamail was present as well, and that with nothing but comments in /etc/java-config-2/virtuals java-config still chooses gnu over sun? > Did java-virtuals/javamail get pulled in before jax-rpc? I'm not sure if I understand you correctly, but according to my logs there was a successful emerge of java-virtuals/javamail immediately preceding the first jax-rpc update attempt.
(In reply to comment #2) > I have both implementations present on my system. Could it be that gnu-javamail > was not updated, because sun-javamail was present as well, and that with > nothing but comments in /etc/java-config-2/virtuals java-config still chooses > gnu over sun? > Yeah there is no need to update it as sun-javamail satisfies the virtual. This is why it's prudent to usually use --deep.
(In reply to comment #3) > Yeah there is no need to update it as sun-javamail satisfies the virtual. This > is why it's prudent to usually use --deep. The jax-rpc update itself was part of an "emerge -uavND world", so it was deep already. I'm not sure whether gnu-javamail was part of the world file at that time, because I remerged (updated) it without -1 later on.
(In reply to comment #4) > > The jax-rpc update itself was part of an "emerge -uavND world", so it was deep > already. I'm not sure whether gnu-javamail was part of the world file at that > time, because I remerged (updated) it without -1 later on. > Yeah I believe I have reproduced this and can only figure that as portage finds sun-javamail it fails to check the other options as well.
Bumped java-virtuals/javamail to explicitly blocker <dev-java/javamail-1.0-r2 Thanks for you help.
*** Bug 200609 has been marked as a duplicate of this bug. ***
