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.
Summary: | ${jnlp.indirect.jars} and META-INF/exists/* | ||
---|---|---|---|
Product: | apisupport | Reporter: | Jesse Glick <jglick> |
Component: | Harness | Assignee: | apireviews <apireviews> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | jtulach |
Priority: | P2 | Keywords: | API_REVIEW_FAST |
Version: | 5.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | 94385, 96630, 154471 | ||
Bug Blocks: | 70477 | ||
Attachments: |
Working patch
An opensource impl of JDI Commit log |
Description
Jesse Glick
2006-12-03 21:54:21 UTC
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. *** |