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.sign.jars and jnlp.platform.codebase do not mix | ||
---|---|---|---|
Product: | apisupport | Reporter: | Jesse Glick <jglick> |
Component: | Harness | Assignee: | pgebauer <pgebauer> |
Status: | REOPENED --- | ||
Severity: | blocker | CC: | jtulach |
Priority: | P3 | ||
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 98371 |
Description
Jesse Glick
2007-10-06 22:26:57 UTC
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. |