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 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.