First it was failing with: checking for x86_64-pc-linux-gnu-zip... no checking for zip... /usr/bin/zip checking for a JDK home directory... configure: error: "A JDK home directory could not be found." !!! Please attach the following file when seeking support: !!! /tmp/tmpwork/portage/dev-java/netx-1.1.2/work/icedtea-web-1.1.2/config.log * ERROR: dev-java/netx-1.1.2 failed (configure phase): * econf failed * * Call stack: * ebuild.sh, line 56: Called src_configure * environment, line 4085: Called econf '--with-rhino' '/usr/share/rhino-1.6/lib/js.jar' * ebuild.sh, line 561: Called die * The specific snippet of code: * die "econf failed" * * If you need support, post the output of 'emerge --info =dev-java/netx-1.1.2', * the complete build log and the output of 'emerge -pqv =dev-java/netx-1.1.2'. !!! When you file a bug report, please include the following information: GENTOO_VM=sun-jdk-1.6 CLASSPATH="" JAVA_HOME="/opt/sun-jdk-1.6.0.27" JAVACFLAGS="-source 1.6 -target 1.6" COMPILER="" and of course, the output of emerge --info * The complete build log is located at '/tmp/tmpwork/portage/dev-java/netx-1.1.2/temp/build.log'. * The ebuild environment file is located at '/tmp/tmpwork/portage/dev-java/netx-1.1.2/temp/environment'. * S: '/tmp/tmpwork/portage/dev-java/netx-1.1.2/work/icedtea-web-1.1.2/' So I've tried to add --with-jdk-home=$(java-config -O) to econf in .ebuild, but it fails only a bit later checking for x86_64-pc-linux-gnu-zip... no checking for zip... /usr/bin/zip checking for a JDK home directory... /opt/sun-jdk-1.6.0.27 checking for javac... /opt/sun-jdk-1.6.0.27/bin/javac checking for ecj... /usr/bin/ecj checking if we are using ecj as javac... no checking for jar... /opt/sun-jdk-1.6.0.27/bin/jar checking whether jar supports @<file> argument... yes checking whether jar supports stdin file arguments... no checking whether jar supports -J options at the end... yes checking for an ecj JAR file... /usr/share/eclipse-ecj-3.5/lib/ecj.jar checking for javadoc... /opt/sun-jdk-1.6.0.27/bin/javadoc checking whether javadoc supports -J options... yes checking for x86_64-pc-linux-gnu-hg... /usr/bin/hg checking for IcedTea Mercurial revision ID... none checking for distribution package version... none checking what version string to use... 1.1.2 checking whether to build the browser plugin... yes checking for x86_64-pc-linux-gnu-pkg-config... no checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for GTK... yes checking for GLIB... yes checking for MOZILLA... yes checking for xulrunner version... 2000100 checking for main in -lz... yes checking for X11... yes checking for a JRE home directory... /opt/sun-jdk-1.6.0.27/jre checking for a Java virtual machine... /opt/sun-jdk-1.6.0.27/jre/bin/java checking if java.util.jar.Pack200 is available... yes checking if java.net.CookieManager is available... yes checking if java.net.HttpCookie is available... yes checking if java.net.CookieHandler is available... yes checking if sun.security.provider.X509Factory is available... yes checking if sun.security.util.SecurityConstants is available... yes checking if sun.security.util.HostnameChecker is available... yes checking if sun.security.x509.X500Name is available... yes checking if sun.misc.BASE64Encoder is available... yes checking if sun.misc.HexDumpEncoder is available... yes checking if sun.security.validator.ValidatorException is available... yes checking if com.sun.net.ssl.internal.ssl.X509ExtendedTrustManager is available... yes checking if sun.awt.X11.XEmbeddedFrame is available... yes checking if sun.misc.Ref is available... yes checking if com.sun.jndi.toolkit.url.UrlUtil is available... yes checking if sun.applet.AppletImageRef is available... yes checking if sun.applet.AppletViewerPanel is available and public... 2 configure: error: sun.applet.AppletViewerPanel is not public. !!! Please attach the following file when seeking support: !!! /tmp/tmpwork/portage/dev-java/netx-1.1.2/work/icedtea-web-1.1.2/config.log * ERROR: dev-java/netx-1.1.2 failed (configure phase): * econf failed * * Call stack: * ebuild.sh, line 56: Called src_configure * environment, line 4085: Called econf '--with-jdk-home=/opt/sun-jdk-1.6.0.27' '--with-rhino' '/usr/share/rhino-1.6/lib/js.jar' * ebuild.sh, line 561: Called die * The specific snippet of code: * die "econf failed" * * If you need support, post the output of 'emerge --info =dev-java/netx-1.1.2', * the complete build log and the output of 'emerge -pqv =dev-java/netx-1.1.2'. !!! When you file a bug report, please include the following information: GENTOO_VM=sun-jdk-1.6 CLASSPATH="" JAVA_HOME="/opt/sun-jdk-1.6.0.27" JAVACFLAGS="-source 1.6 -target 1.6" COMPILER="" and of course, the output of emerge --info * The complete build log is located at '/tmp/tmpwork/portage/dev-java/netx-1.1.2/temp/build.log'. * The ebuild environment file is located at '/tmp/tmpwork/portage/dev-java/netx-1.1.2/temp/environment'. So I guess that sun-jdk is not supported to build it and DEPENDS should be updated to force icedtee or other VM which is supported for netx. Reproducible: Always
*** Bug 382357 has been marked as a duplicate of this bug. ***
Fixed by compiling just netx.jar instead of everything, using java-pkg-simple eclass and not the included build system.
Uh well, it didn't help the actual build problem...
fordfrog: regarding appframework, I've found this on http://java.net/projects/appframework/sources/svn/show/trunk/AppFramework?rev=151 === The build also depends on javaws.jar, the JNLP API, at compile time. This file is distributed with the JDK, it's ${java.home}/lib/javaws.jar The javaws.jar file isn't needed at run-time and is included automatically by the Java Web Start launcher. === What I thus suggest is adding the following to the netx ebuild: src_unpack() { default rm -rf "${S}"/netx/net } AND then commiting the result as dev-java/jnlp-api (it will contain just the javax/jnlp API classes and no JDK-specific implementation), and try if appframework will build with this as DEPEND (not RDEPEND, see above). Then you can remove the netx package again, as it's apparently icedtea-specific even in the pure java part. Please try this and test properly this time...
caster: there are some problems with this suggested solution: 1) jnlp is not put automatically on classpath during compilation 2) there are jdks that do not provide jnlp classes 3) there is package media-gfx/sweethome3d in our svn repo (cannot move it to main tree because of jnlp issue) that needs jnlp (probably just api) for compilation and complete jnlp for runtime. the problem is it is not started using javaws but it uses standard java command instead so jnlp is not put on classpath for runtime and running fails. and again, not every jre/jdk provides jnlp classes, so depending on used jdk/jre application might fail to start. and there is no standard way to put jnlp classes on classpath for runtime. and if we have one application that works this way, there might be more. i did tests with netx package on classpath for runtime with sweethome3d using sun-jdk-1.6 for running the app and it worked fine, so when talking about runtime, the solution with netx package seems to work perfectly and is probably the only solution that should work no matter what jdk/jre is being used. the only problem is the compilation of netx. if compilation of netx is really bound to icedtea, maybe we could register netx.jar from icedtea-web and from applications that need jnlp we would use direct dependency on icedtea-web (so we do not duplicate the complexity of the ebuild) and we would just include netx.jar on classpath. what do you think?
I think that if the solution is working fine for appframework/netbeans, then we should do it and stabilize ASAP. Also for jnlp-api the rhino dep won't be needed anyway afterwards. Also maybe create a separate distfile for the sources instead of downloading whole icedtea-web. And the version should match version of the API, which I'm not sure if it's still 1.2 or higher. As for sweethome3d, we should look into what exactly it needs from jnlp and why the API is not enough. Since jnlp implementation is AFAIK supposed to read a .jnlp descriptor and start an app, I don't see why any app would need it for anything once it's started.
Also let me reply on this: (In reply to comment #5) > i did tests with netx package on classpath for runtime with sweethome3d using > sun-jdk-1.6 for running the app and it worked fine, so when talking about > runtime, the solution with netx package seems to work perfectly and is probably > the only solution that should work no matter what jdk/jre is being used. the > only problem is the compilation of netx. If netx is failing to compile without an internal icedtea class, it will be also missing this class on runtime, when used with a different jdk/jre. The fact that sweethome3d doesn't trigger this particular missing class is just luck, and such solution wouldn't be clean anyway.
(In reply to comment #6) > As for sweethome3d, we should look into what exactly it needs from jnlp and why > the API is not enough. Since jnlp implementation is AFAIK supposed to read a > .jnlp descriptor and start an app, I don't see why any app would need it for > anything once it's started. the application is coded so that it works both as standalone application and jws application. so when started from upstream website, jnlp is used. when started locally, the same jnlp classes are called aswell. the difference is that in standalone mode jnlp classes are not available by default, that's why upstream distributes the application with jre and their startup script puts jnlp on classpath. (In reply to comment #7) > If netx is failing to compile without an internal icedtea class, it will be > also missing this class on runtime, when used with a different jdk/jre. The > fact that sweethome3d doesn't trigger this particular missing class is just > luck, and such solution wouldn't be clean anyway. if we would depend directly on icedtea-web, the internal icedtea class would be available, or am i wrong? i guess that is why running sweethome3d worked even when using sun-jdk-1.6 for running it, as netx was able to use the icedtea class. i also noticed when compiling icedtea-web manually, that even though i have user-vm set to sun-jdk-1.6, configure script found icedtea6 installation and (probably) even used that for building as the compilation did not fail. so it seems the only case when it fails is when there is no icedtea installed at all.
(In reply to comment #8) > > the application is coded so that it works both as standalone application and > jws application. so when started from upstream website, jnlp is used. when > started locally, the same jnlp classes are called aswell. the difference is > that in standalone mode jnlp classes are not available by default, that's why > upstream distributes the application with jre and their startup script puts > jnlp on classpath. So how bout we either work around the jnlp code path and call the real main class directly from our launcher, OR use javaws command instead of java command to load its .jnlp file (which I assume exists, then?). > (In reply to comment #7) > > if we would depend directly on icedtea-web, the internal icedtea class would be > available, or am i wrong? i guess that is why running sweethome3d worked even No, it won't. It has no path to it. > when using sun-jdk-1.6 for running it, as netx was able to use the icedtea > class. I think it wasn't but the particular class that depends on it wasn't used in this case (I think it's some class related to applets). > i also noticed when compiling icedtea-web manually, that even though i have > user-vm set to sun-jdk-1.6, configure script found icedtea6 installation and > (probably) even used that for building as the compilation did not fail. so it > seems the only case when it fails is when there is no icedtea installed at all. That's because icedtea-web ebuild forces the VM selection to select icedtea6.
(In reply to comment #9) > So how bout we either work around the jnlp code path and call the real main > class directly from our launcher, OR use javaws command instead of java command > to load its .jnlp file (which I assume exists, then?). So anyway, I was curious and tried running sweethome3d with netx reduced per comment 4 and it started just fine (but indeed crashed, when the dep was removed). So in this case jnlp-api is also a RDEPEND (for some weird reason), but no actual implementation is needed, just the javax/jnlp API classes. I think there's no obstacle to the jnlp-api solution then.
(In reply to comment #9) > > i also noticed when compiling icedtea-web manually, that even though i have > > user-vm set to sun-jdk-1.6, configure script found icedtea6 installation and > > (probably) even used that for building as the compilation did not fail. so it > > seems the only case when it fails is when there is no icedtea installed at all. > > That's because icedtea-web ebuild forces the VM selection to select icedtea6. no, i mean unpacking the tarball and issuing ./configure(In reply to comment #10) > (In reply to comment #9) > So anyway, I was curious and tried running sweethome3d with netx reduced per > comment 4 and it started just fine (but indeed crashed, when the dep was > removed). So in this case jnlp-api is also a RDEPEND (for some weird reason), > but no actual implementation is needed, just the javax/jnlp API classes. I > think there's no obstacle to the jnlp-api solution then. if it's really just about the api then your solution should be fine. idk when i would get to it so if you have some time, feel free to package the api. then we need to drop that netx package and update appframework and webcdwriter (and sweethome3d in overlay) to use the api. then we can schedule jnlp-bin and openjnlp for removal.
Ok added jnlp-api and revbumped appframework, webcdwriter, sweethome3d to use it.
masked for removal. replaced by dev-java/jnlp-api
