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.
In my experiments, jnlp.sign.jars=false does not work when using jnlp.platform.codebase (set to a local file: codebase, as generated by nbbuild/build.xml#build-jnlp). javaws complains that an unsigned JAR (e.g. swing-layout-*-src.zip, which is not even executable code) is requesting full access. startup.jar's Main does not seem to have been run yet (e.g. inserting a call to JOptionPane.showMessageDialog does nothing). Things work if the platform *.jnlp & *.jar are moved physically inside the codebase of master.jnlp (and their codebases rewritten accordingly), which I guess is why j.s.j=f works if j.p.c is not specified (since then the platform JNLPs/JARs are generated in a netbeans/ subdir). Should either be fixed, if possible (I have no idea if it is); or at least jnlp.xml should abort with a friendly message saying that the combination will not work.
Note: when using codebase http://deadlock.netbeans.org/hudson/job/javadoc-nbms/lastSuccessfulBuild/artifact/nbbuild/build/jnlp/, it works, I guess since these JARs are signed. (Though it is _slow_.) To reproduce, in a dev build make a suite with a simple module w/ one TopComponent. Set to app mode, accept default module excludes. Then run ant -f ..../nbbuild/build.xml build-jnlp -Djnlp.sign.jars=false ant -f ..../suite/build.xml clean build-jnlp run-jnlp -Djnlp.platform.codebase=file:..../nbbuild/build/jnlp/ -Djnlp.sign.jars=false
Just before I start looking at this can you please answer this: why do you call build-jnlp from the nbbuild at all? I was always using just the call from the suite's directory. It packaged the platform jnlp nicely in the suite's dist folder ...
suite.xml#build-jnlp (without jnlp.platform.codebase) is a minimal implementation which is hacked up just enough to work on the current platform cluster. It treats all target platform modules uniformly and has a special-cased excludes list for some ignorable files. It does not work at all on other clusters or with arbitrary modules which sometimes need special treatment. nbbuild/build.xml#build-jnlp calls the jnlp target in each module, which (1) can use special properties such as jnlp.verify.excludes and jnlp.indirect.jars which are defined by the module rather than the harness, or (2) even have custom implementation (as e.g. ant or extbrowser modules). If we shipped *.jnlp files as part of the binary platform then we would always use those and there would be no problem, but it is an unfortunate fact that we do not ship them; so Yarda made this system in which we actually have two, subtly different, ways of including the platform in a JNLP app.
Regarding last comment, see issue #70477 for more detail.
Not possible for 6.9.
Who needs this?
If it is not going to be fixed, the documentation should explain that.
What documentation and what should I put there?
harness/README documents jnlp.sign.jars; should be more emphatic that this option only works under special circumstances, and generally not when jnlp.platform.codebase is used. Not solvable until *.jnlp descriptors are treated as first-class binary artifacts.