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.
I have a patch which lets all ide-cluster modules be built in JNLP mode. Of course some may not work correctly (debuggerjpda, Retouche, ...) but at least it is good to be able to build them all. The main change required is in the handling of JAR files which are bundled with a module but not included in its class path. One example is for JARs which are used only for a library descriptor. The existing JNLP build infrastructure rejects these. The patch permits the module author to request that these JARs be included in the JNLP classpath. Since generally they are referred to via InstalledFileLocator (incl. the nbinst URL protocol), rather than directly linked against, it is necessary to have some way of finding the JAR path on the client. For this purpose, the Ant task adds a marker file META-INF/exists/${relpath} where ${cluster}/${relpath} is the original JAR file. This can be found at runtime using ClassLoader.getResource. This should pose no compatibility issues; IFL will work iff the new harness is used for the launcher and the new harness was used to build the module JNLP. Existing JAR signatures need to be clobbered for these files since the marker cannot be signed with the same signature. The patch also - puts all module files other than its main .jnlp into a subdir of the JNLP dest dir named by the module CNB, to avoid clutter and possible filename conflicts - changes some other file naming rules to avoid conflicts (e.g. o-n-m-usersguide.jar vs. docs/o-n-m-usersguide.jar previously conflicted) - fixes extbrowser to bundle its DLLs properly - fixes a buglet that required workaround in the htmleditor sample
Created attachment 36446 [details] Working patch
Good. I am not sure if I understand how it work (it is not really written anywhere, is it?), but as far as I can tell: all the jnlp.indirect.jars are repackaged to include META-INF/exists/relname file so they can be later found by InstalledFileLocatorImpl. That is simple and clever. I am not fully sure about the "exists" name. Maybe META-INF/netbeans/relativepath/ would be more unique. You seem to have no tests. Why not write one at least for MakeJNLP? I am looking forward to see webstartable ide cluster.
Re. mechanism - yes, that is it. Will try to document it more clearly. Re. name "exists" - can make more distinctive. Re. tests - I know there are none yet, will try to add some. I just did not know what the behavior of <makejnlp> should be in advance; the current state is the result of tweaking it over and over until build-jnlp succeeded and running javaws on the result (i.e. an empty suite w/ platform + ide clusters enabled) did not result in any launch errors. (There are still runtime problems of various sorts - but the program at least starts.) Should probably also edit http://installer.netbeans.org/docs/jnlpInstaller.html to mention that #4 is done for ide cluster, as is #6 (though as yet untested). #5 is probably the major thing that has to be fixed to correct runtime errors.
Updating the jnlpInstaller is good idea. Re. test - I can understand the troubles of testing just pieces. I guess it would be valuable to have integration test that would create a JNLP application, tried to execute it and reported a success or failure. This test could be run after each upload to netbeans.org JNLP registry, so we would early catch possible regressions there. Re. #6: I guess you should use <nativelib href=""/> and not just <jar/>, as I found at http://lopica.sourceforge.net/ref.html#nativelib Re. #5: When Sun's tools.jar will be redistributable? Or maybe we could use some other opensource implementation...
Created attachment 36472 [details] An opensource impl of JDI
Re. test - would be nice but javaws interacts with the user using GUI dialogs if it fails (or if needs to accept a signature). Not sure how easy it would be to automate that. Re. #6 - sure. Re. #7 - well I don't think we should be using different software components just to run in JNLP mode. The user very likely has the JDK's tools.jar on their machine, we just need to link to it. The Ant module already does this, although no Ant module code links against tools.jar, unlike (I guess) debuggerjpda module code. Perhaps the launcher app can handle this, I don't know.
This bug also affect Javahelp and JNLP because of same name jar conflict. Step to recreate - Create A module component - Create JavaHelp HelpSet (using the wizard) inside that module component - Create / generate JNLP (webstart) using the provide ant task - Bang the bug occur because the same name problem eg: module-name.jar(Module) and docs/module-name.jar (JavaHelp), when the JNLP is generated the doc/module-name.jar will overwrite the module-name.jar because of same name on the jnlp destination directory Simple workaround is to create JavaHelp HelpSet into separate module so it will have different name jar
Fixed.
Created attachment 36856 [details] Commit log
*** Issue 97880 has been marked as a duplicate of this issue. ***