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.
Mentioned in issue #69078. Consider patching build of apisupport/harness to collect jnlp.verify.excludes properties from all modules in config.modules.jnlp, and write the result somewhere in the built harness - e.g. a .properties file loaded by jnlp.xml. This would avoid maintaining two copies of the same info.
I guess the fix for this issue highly depends on resolution of issue 90498
Is there still anything needed to be done? I have not faced a problem with wrong imports in a long time...
I think it's still valid. jnlp.xml still contains verifyexcludes="lib/nbexec.cmd,lib/nbexec,lib/nbexec.exe,core/ide.ks,LICENSE.txt,DISTRIBUTION.txt,THIRDPARTYLICENSEREADME.txt,docs/swing-layout-1.0-doc.zip,docs/swing-layout-1.0.1-doc.zip,docs/html40.zip,core/org-netbeans-modules-utilities-cli.jar,docs/org/netbeans/modules/usersguide/ide.css,docs/swing-layout-1.0.2-doc.zip,docs/swing-layout-1.0.2-src.zip,docs/swing-layout-1.0.3-doc.zip,docs/swing-layout-1.0.3-src.zip" which mentions a number of long-obsolete files. (The swing-layout files in particular may need updating with each release of the library, meaning extra work and possible version skew if the library is newer than the harness.) And this hardcoded list will not work if your target platform includes more than the platform cluster. All in all I think the jnlp-generate-platform-repository target has to be either rewritten or killed. The design is fundamentally flawed: while a module source project's build.xml and project.properties are able to specify idiosyncratic ways to run the 'jnlp' target when creating a JNLP platform distribution, the code in this target is missing the information it needs to create the platform JNLP fragments correctly. Richard, since it is not at all obvious from the outside what is going on here: if you build a JNLP version of your platform app using the property ${jnlp.platform.codebase}, you can point to a prebuilt binary collection of JNLP fragments for the platform modules. This works reasonably well; the JNLP distribution of the platform can be created by nbbuild/build.xml#build-jnlp, which runs a 'jnlp' target in each module. Most modules don't do anything special in this target, but some customize it heavily (e.g. Ant), and a bunch specify ${jnlp.indirect.jars} and/or ${jnlp.verify.excludes}. On the other hand, if you do not set ${jnlp.platform.codebase}, jnlp.xml in the harness makes an attempt to create working JNLP fragments for the platform modules (since we do not currently build JNLP descriptors in the platform by default). Unfortunately this target cannot work for arbitrary modules in the platform. Among other problems, it has to hardcode a list of files present in the platform which are known to not be needed in JNLP mode.
Integrated into 'main-golden', will be available in build *201205040400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/b55a08de8a71 User: Jesse Glick <jglick@netbeans.org> Log: #70477 workaround: cannot specify verify=true since verifyexcludes must be manually enumerated from all of platform.