Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 90498 - ${jnlp.indirect.jars} and META-INF/exists/*
${jnlp.indirect.jars} and META-INF/exists/*
Product: apisupport
Classification: Unclassified
Component: Harness
All All
: P2 (vote)
: 6.x
Assigned To: apireviews
: 97880 (view as bug list)
Depends on: 94385 96630 154471
Blocks: 70477
  Show dependency treegraph
Reported: 2006-12-03 21:54 UTC by Jesse Glick
Modified: 2008-12-03 15:20 UTC (History)
1 user (show)

See Also:

Working patch (30.82 KB, patch)
2006-12-03 21:55 UTC, Jesse Glick
Details | Diff
An opensource impl of JDI (349.99 KB, application/x-compressed)
2006-12-05 10:11 UTC, Jaroslav Tulach
Commit log (4.01 KB, text/plain)
2006-12-20 20:53 UTC, Jesse Glick

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2006-12-03 21:54:21 UTC
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
Comment 1 Jesse Glick 2006-12-03 21:55:09 UTC
Created attachment 36446 [details]
Working patch
Comment 2 Jaroslav Tulach 2006-12-04 15:43:14 UTC

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.
Comment 3 Jesse Glick 2006-12-04 17:15:39 UTC
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

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.
Comment 4 Jaroslav Tulach 2006-12-05 09:57:21 UTC
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 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 

Re. #5: When Sun's tools.jar will be redistributable? Or maybe we could use 
some other opensource implementation...

Comment 5 Jaroslav Tulach 2006-12-05 10:11:55 UTC
Created attachment 36472 [details]
An opensource impl of JDI
Comment 6 Jesse Glick 2006-12-05 16:13:21 UTC
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.
Comment 7 kiyut 2006-12-15 03:47:12 UTC
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
Comment 8 Jesse Glick 2006-12-20 20:53:18 UTC
Comment 9 Jesse Glick 2006-12-20 20:53:48 UTC
Created attachment 36856 [details]
Commit log
Comment 10 Jesse Glick 2007-03-22 19:52:21 UTC
*** Issue 97880 has been marked as a duplicate of this issue. ***

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo