My system VM is by default Sun JDK: paddy ~ # java-config -L The following VMs are available for generation-2: 1) Blackdown JDK 1.4.2.03 [blackdown-jdk-1.4.2] 2) Blackdown JRE 1.4.2.03 [blackdown-jre-1.4.2] 3) IBM JDK 1.4.2.5 [ibm-jdk-bin-1.4] 4) IBM JDK 1.5.0.3 [ibm-jdk-bin-1.5] 5) WebLogic JRockit 1.4.2.11 [jrockit-jdk-bin-1.4] 6) WebLogic JRockit 1.5.0.06 [jrockit-jdk-bin-1.5] 7) Sun JDK 1.3.1.18 [sun-jdk-1.3] *) Sun JDK 1.4.2.12 [sun-jdk-1.4] 9) Sun JDK 1.5.0.09 [sun-jdk-1.5] I'd like to emerge Tomcat 5.5 with the "java5" use flag, but it breaks, since Tomcat makes usage of Sun internal classes and the ebuild selects for whatever reason the IBM JDK as virtual Java 5 SDK :-/ So the java5 flag may not trigger an arbitrary Java 5 JDK, it's dependent on Sun's JDK only.
reopen with some errors, thanks.
As said, IBM JDK does not have the com.sun.* classes ... I switched manually now to sun-jdk in /etc/java-config-2/build/jdk.conf, but the dependency with a virtual jdk 5 is not valid. ============= %< =================== build-tomcatutil: [echo] ========== Building: tomcat-util to /volatile/portage/tomcat-5.5.20-r2/work/apache-tomcat-5.5.20-src/build/build detect: build-prepare: tomcat-util.jar: [echo] ----- Java-utils ----- [echo] -- puretls.present = ${puretls.present} [echo] -- jsse.present = true /volatile/portage/tomcat-5.5.20-r2/temp/jsse-1.0.3/lib/jsse.jar [echo] -- commons-logging = true [echo] -- jmx = ${jmx.present} /volatile/portage/tomcat-5.5.20-r2/temp/mx4j-3.0.1/lib/mx4j.jar [echo] -- modeler = true /usr/share/commons-modeler/lib/commons-modeler.jar [echo] -- skip.digester = ${skip.digester} [echo] -- JDK14 = true [echo] -- JDK15 = true [javac] Compiling 94 source files to /volatile/portage/tomcat-5.5.20-r2/work/apache-tomcat-5.5.20-src/build/build/classes [javac] /volatile/portage/tomcat-5.5.20-r2/work/apache-tomcat-5.5.20-src/connectors/util/java/org/apache/tomcat/util/net/jsse/JSSE13SocketFactory.java:76: package com.sun.net.ssl.internal.ssl does not exist [javac] Security.addProvider (new com.sun.net.ssl.internal.ssl.Provider()); [javac] ^ [javac] /volatile/portage/tomcat-5.5.20-r2/work/apache-tomcat-5.5.20-src/connectors/util/java/org/apache/tomcat/util/net/jsse/JSSE13SocketFactory.java:94: package com.sun.net.ssl does not exist [javac] com.sun.net.ssl.KeyManagerFactory kmf = [javac] ^ [javac] /volatile/portage/tomcat-5.5.20-r2/work/apache-tomcat-5.5.20-src/connectors/util/java/org/apache/tomcat/util/net/jsse/JSSE13SocketFactory.java:95: package com.sun.net.ssl does not exist [javac] com.sun.net.ssl.KeyManagerFactory.getInstance(algorithm); [javac] ^ [javac] /volatile/portage/tomcat-5.5.20-r2/work/apache-tomcat-5.5.20-src/connectors/util/java/org/apache/tomcat/util/net/jsse/JSSE13SocketFactory.java:105: package com.sun.net.ssl does not exist [javac] com.sun.net.ssl.TrustManager[] tm = null; [javac] ^ [javac] /volatile/portage/tomcat-5.5.20-r2/work/apache-tomcat-5.5.20-src/connectors/util/java/org/apache/tomcat/util/net/jsse/JSSE13SocketFactory.java:112: package com.sun.net.ssl does not exist [javac] com.sun.net.ssl.TrustManagerFactory tmf = [javac] ^ [javac] /volatile/portage/tomcat-5.5.20-r2/work/apache-tomcat-5.5.20-src/connectors/util/java/org/apache/tomcat/util/net/jsse/JSSE13SocketFactory.java:113: package com.sun.net.ssl does not exist [javac] com.sun.net.ssl.TrustManagerFactory.getInstance("SunX509"); [javac] ^ [javac] /volatile/portage/tomcat-5.5.20-r2/work/apache-tomcat-5.5.20-src/connectors/util/java/org/apache/tomcat/util/net/jsse/JSSE13SocketFactory.java:119: package com.sun.net.ssl does not exist [javac] com.sun.net.ssl.SSLContext context = [javac] ^ [javac] /volatile/portage/tomcat-5.5.20-r2/work/apache-tomcat-5.5.20-src/connectors/util/java/org/apache/tomcat/util/net/jsse/JSSE13SocketFactory.java:120: package com.sun.net.ssl does not exist [javac] com.sun.net.ssl.SSLContext.getInstance(protocol); [javac] ^ [javac] Note: * uses or overrides a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. [javac] 8 errors BUILD FAILED /volatile/portage/tomcat-5.5.20-r2/work/apache-tomcat-5.5.20-src/build.xml:42: The following error occurred while executing this line: /volatile/portage/tomcat-5.5.20-r2/work/apache-tomcat-5.5.20-src/build/build.xml:517: The following error occurred while executing this line: /volatile/portage/tomcat-5.5.20-r2/work/apache-tomcat-5.5.20-src/build/build.xml:172: The following error occurred while executing this line: /volatile/portage/tomcat-5.5.20-r2/work/apache-tomcat-5.5.20-src/connectors/util/build.xml:69: Compile failed; see the compiler error output for details. Total time: 40 seconds !!! ERROR: www-servers/tomcat-5.5.20-r2 failed. Call stack: ebuild.sh, line 1546: Called dyn_compile ebuild.sh, line 937: Called src_compile tomcat-5.5.20-r2.ebuild, line 167: Called eant '-Dbase.path=/volatile/portage/tomcat-5.5.20-r2/temp' '-Dcommons-collections.jar=/usr/share/commons-collections/lib/commons-collections.jar' '-Dcommons-daemon.jar=/usr/share/commons-daemon/lib/commons-daemon.jar' '-Dcommons-digester.jar=/usr/share/commons-digester/lib/commons-digester.jar' '-Dcommons-dbcp.jar=/usr/share/commons-dbcp/lib/commons-dbcp.jar' '-Dcommons-el.jar=/usr/share/commons-el/lib/commons-el.jar' '-Dcommons-pool.jar=/usr/share/commons-pool/lib/commons-pool.jar' '-Dcommons-fileupload.jar=/usr/share/commons-fileupload/lib/commons-fileupload.jar' '-Dcommons-launcher.jar=/usr/share/commons-launcher/lib/commons-launcher.jar' '-Dcommons-modeler.jar=/usr/share/commons-modeler/lib/commons-modeler.jar' '-Djunit.jar=/usr/share/junit/lib/junit.jar' '-Djdt.jar=/usr/share/eclipse-ecj-3.1/lib/ecj.jar' '-Dlog4j.jar=/usr/share/log4j/lib/log4j.jar' '-Dcommons-beanutils.jar=/usr/share/commons-beanutils-1.7/lib/commons-beanutils.jar' '-Dcommons-logging.jar=/usr/share/commons-logging/lib/commons-logging.jar' '-Dcommons-logging-api.jar=/usr/share/commons-logging/lib/commons-logging-api.jar' '-Dmail.jar=/usr/share/sun-javamail/lib/mail.jar' '-Dstruts.jar=/usr/share/struts-1.2/lib/struts.jar' '-Dstruts.home=/usr/share/struts' '-Dexamples.precompile.notrequired=true' '-Djasper.home=/volatile/portage/tomcat-5.5.20-r2/work/apache-tomcat-5.5.20-src/jasper' java-utils-2.eclass, line 1361: Called die !!! eant failed !!! If you need support, post the topmost build error, and the call stack if relevant. !!! When you file a bug report, please include the following information: GENTOO_VM=ibm-jdk-bin-1.5 CLASSPATH="" JAVA_HOME="/opt/ibm-jdk-bin-1.5.0.3" JAVACFLAGS="-source 1.5 -target 1.5" COMPILER="javac"
Woe now, let's back up here a second. From original bug post. <!-- Snippet My system VM is by default Sun JDK: paddy ~ # java-config -L *) Sun JDK 1.4.2.12 [sun-jdk-1.4] 9) Sun JDK 1.5.0.09 [sun-jdk-1.5] I'd like to emerge Tomcat 5.5 with the "java5" use flag, but it breaks --> Yeah no wonder you have problems. You have a 1.4 jdk selected as the default, and are using the java5 USE flag. I will see about adding conditions or etc for that, but seems some common sense there might help. :) Meant politely. Presently I believe the new java system lacks the ability to filter vms via the virtuals. So I don't really have any way to control if a user tries to compile with IBM jdk or etc. This has been brought up with upstream. We might package jsse, and provide it when a IBM jdk is used to correct. However I don't believe this is a problem with Tomcat 6.0.x which hopefully will be released soon. Beyond that as a resolution. I would suggest the following java-config -S sun-jdk-1.5 and/or edit /etc/java-config-2/build/jdk.conf There are some examples but you might do something like *=sun-jdk or *=sun-jdk-1.5 Otherwise having a 1.4 jdk selected and enabling a java5 USE flag is kinda weird, and should not be done. Really for the most part 1.5 should be used, it's the current stable jdk/jre from upstream. 1.4 is a previous release that still supported for bugs and etc. But 1.6 will be out soon as well.
Ok this actually is caused by the order of the default jdk's in /usr/share/java-config-2/config/jdk-defaults.conf Which will get updated. In the mean time you need to do two things. One for building the other for runtime. Edit /etc/java-config-2/build/jdk.conf add *=sun-jdk-1.5 Then you will need to set your system vm to 1.5, otherwise you will be running a 1.5 bytecode Tomcat against a 1.4 jre and will get errors about class versions. java-config -s sun-jdk-1.5
(In reply to comment #4) > Ok this actually is caused by the order of the default jdk's in > /usr/share/java-config-2/config/jdk-defaults.conf > > Which will get updated. In the mean time you need to do two things. One for Updating jdk-defaults.conf is less than ideal solution. What if somebody specifies ibm-jdk-bin in jdk.conf? The defaults won't count there. What's possible to do now is this: --- tomcat-5.5.20-r2.ebuild 5 Dec 2006 00:07:04 -0000 1.5 +++ tomcat-5.5.20-r2.ebuild 6 Dec 2006 00:16:17 -0000 @@ -43,7 +43,10 @@ >=dev-java/xerces-2.7.1 =dev-java/xml-commons-external-1.3* )" -DEPEND="java5? ( >=virtual/jdk-1.5 ) +DEPEND="java5? ( + >=virtual/jdk-1.5 + =dev-java/sun-jdk-1.5* + ) !java5? ( =virtual/jdk-1.4* ) ${RDEPEND} dev-java/ant" @@ -52,6 +55,7 @@ JAVA_PKG_NV_DEPEND="=virtual/jdk-1.4*" else JAVA_PKG_NV_DEPEND="=virtual/jdk-1.5*" + JAVA_PKG_FORCE_VM="sun-jdk-1.5" fi S=${WORKDIR}/${MY_P} But ideally we should have a more elegant way to force/filter VM's from ebuilds, like we have with compilers. And should also ensure that tomcat will run with sun-jre/jdk 1.5 regardless of system/user vm.
depend-java-query does not know how to handle use flag based dependencies yet. I already have working code for this. This should probably be committed to the next version of java-config.
To answer for some comments here in general: 1/ Yes, I know now about /etc/java-config-2/build/jdk.conf and - as I already pointed out in #3 and as it was affirmed by Vlastimil in #5 - a dependency to an arbitrary JDK 5 is simply wrong. Tomcat is obviously dependend on the *Sun* JDK. 2/ It is my intention to have a JDK 1.4.2 as system JDK. Nevertheless, I want Tomcat to support JDK 5. If I must have a JDK 5 as system JDK, why is there a java5 use flag then? This makes no sense. Having Tomcat compiled with JDK 5 only is an absolutely valid use case. Tomcat is not a framework but a runtime environment. Any webapp compiled with an older JDK will happily run - including my own ones and others available as binary distribution.
Tomcat does not dep on just Sun jdks. However other things are needed when not using a Sun jdk. Like jsse for SSL which has not been packaged. Or mx4j as a jmx implementation replacement. So a simple fix would be to just make it dep on Sun jdk 1.5. But I doubt that would make all happy, much less provide an option to those platforms that lack a Sun 1.5 jdk like ppc. The java5 use flag produces a 1.5 bytecode Tomcat. Which will not run at all on older vms. Without you get a 1.4 bytecode Tomcat that can run on 1.4 vm. Sure old binaries can run on new jvms, but not the same for new binaries and old jvms. Tomcat by default is set to use the system vm. This is a variable that users can change(mentioned in Tomcat guide). So by having 1.4 as a system VM would not allow Tomcat to start by default without user intervention. Either way you don't have to have 1.5 set as system. But you will have to edit /etc/conf.d/tomcat-5.5. Things will not work out of the box with a 1.4 system vm when java5 USE flag is set.
1/ OK. So the state is, that the current ebuild of Tomcat 5.5 depends on Sun JDK 5 when the java5 flag is used, at least unless the separate packages are also available for the other JDKs. I just wonder, how those dependencies can be expressed in the ebuild, since virtual/jdk-1.5 is obviously not enough. 2/ Well, if I set the java5 flag, I know what I get, and yes, my Java 5 Tomcat runs perfectly setting JAVA_HOME to the appropriate value (/usr/lib/jvm/sun-jdk-1.5) in conf.d/tomcat-5.5. Thanks for that hint.
The conditional dependencies are handled correctly this is actually a dupe of bug 146946. wltjr said that Tomcat 6.0 would not depend on com.sun.* stuff any more. Let's hope that is truly the case. *** This bug has been marked as a duplicate of 146946 ***
Here is a link to the bug I filed with upstream about the SSL stuff/dependency. http://issues.apache.org/bugzilla/show_bug.cgi?id=39562
