This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Webstart is a technology that significantly improves the out of box experience as with single click (and a bit of patience) one can get a full featured application running in few minutes without any need for downloading, installing, etc. NetBeans (at least in its limited version) are not far from being able to start and run using webstart. This issue is created to track the problems and possible progress in webstarting NetBeans lite.
Created attachment 29436 [details] Diff with jnlp.verify.excludes showing where are the current blockers that prevent JNLP descriptors for ide cluster to be built
IMHO modules/lib/* should be handled generically by <makejnlp>. I'm not sure why we ship sources for AbsoluteLayout - seems it could be published on the website somewhere, with a link from release notes and a note inside AbsoluteLayout.jar. Handling org-netbeans-modules-java-j2seplatform-probe.jar requires a change in java/j2seplatform/src/ to check for this JAR on the classpath, and if so use it via CodeSource.getLocation(). Probably ditto for org-netbeans-modules-java-j2seproject-copylibstask.jar. modules/ext/gjast.jar means javacore has to load this stuff using a custom masking class loader, I think. Maybe it already does and no big change is needed other than finding the JAR location. It would be OK to load this JAR directly only if the JDK's tools.jar is *not* in the JNLP classpath, which I think we cannot rely on. modules/ext/junit-3.8.1.jar can be put on classpath but the ExtraClasspathProvider will need to find it via CodeSource.getLocation. BTW I am seeing a bit of a pattern here. junit-3.8.1-api.zip is harder to deal with. It is referred to only via nbinst URL protocol, meaning for JNLP mode we either have to ship a different lib definition (undesirable, e.g. because it could prevent sharing of userdir between JNLP and regular IDE mode if the user associates sources with this lib); or fix InstalledFileLocator to behave better in JNLP mode, as I have suggested in the past. Probably there are two cases for JNLP IFL: JARs and ZIPs, where we can at <makejnlp> time look for a unique JAR entry path in the file, then add the file to the CP and have IFL use ClassLoader.getResource to infer the location of the JAR; or other files, which have to be unpacked to some temp dir on demand or at startup. I can imagine writing an override of the 'jnlp' target to do something like <makejnlp ...> <installed-jar path="docs/junit-3.8.1-api.zip" uniqueentry="junit/framework/Assert.html"/> </> or <makejnlp ...> <installed-file path="ant/etc/log.xsl" unpack="eager"/> </> either of which would make IFL.locate(path) work in JNLP mode with no further effort or source code changes.
Reassigning to "javawebstart".
No, 'javawebstart' is for the user feature of creating JNLP-aware projects. This is completely unrelated.
*** Issue 156342 has been marked as a duplicate of this issue. ***
Does this really date back to 2006? That's shocking.
The platform, ide, and java clusters can supposedly be run via JNLP - building this is verified by nbms-and-javadoc. Not sure whether it really works well, and other clusters are not handled. https://bitbucket.org/jglick/jnlpide/ is a completely different approach; the usual NB installation structure is used and JNLP is just used as a way to easily download and start the IDE.
Just want to add that the main advantage would be to ensure that all users are on the same version. This alone eliminates many issues, which is why this bug gets my vote.
WebStart is not as popular as it used to be.