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.
create general module suite project, >>> >>>1. new -> project -> module suite >>>2. edit property to run module suite as a standalone application >>>3. Run >>> -> OK, it can start with Japanese messages >>>4. Select create "Build JNLP Applicatioin" >>> -> compile failed >>> >>>I tried >>>"netbeans-5_0-daily-bin-200512272030-ml_ja_zh_CN-27_Dec_2005_2030.zip" >>>nightly >>>on both "ja" and "zh" locales on Solaris. in output window is seen: >>>Created dir: /home/katakai/feedreader-suite/build/tmp/master-jnlp >>>jnlp-generate-keystore: >>>Going to create default keystore in >>>/home/katakai/feedreader-suite/build/default.keystore >>>Generating Key for jnlp >>>jnlp-generate-platform-repository: >>>Created dir: /home/katakai/feedreader-suite/build/jnlp/netbeans >>>/home/katakai/netbeans/harness/suite.xml:175: The following error >>>occurred while executing this line: >>>/home/katakai/netbeans/harness/jnlp.xml:95: Cannot build JNLP for module >>>/home/katakai/netbeans/platform6/core/core.jar as these files are in >>>module's NBM, but are not referenced from any path: >>>[core/locale/core_zh_CN.jar, core/locale/core_ja.jar] on windows it does not compile on solaris ja euc - it can be compiled, can run but cannot create jnlp file I realize these might need to be separate issues.
This happens in every module project, not specific to feedreader app.
org.netbeans.nbbuild.MakeJNLP fails to process I18N (or branding) variants of modules. http://installer.netbeans.org/docs/jnlpInstaller.html does not mention it, but it should probably have been case 1.5 or something like that. I wish this issue had been filed a few days ago when we still had time to fix it. Now it's too late, I think, unless someone considers this a showstopper. Fix is not likely to be difficult, though not trivial. 1. verifyExtensions should look in fileToOwningModule for locale variants of the main module ('name') as well as its class-path extensions ('r' in the loop). A locale variant of path/base.ext is any path matching path/locale/base(|_[a-zA-Z0-9_]+)\.ext Any such variants should be considered legal and be removed from fileToOwningModule. 2. generateFiles and processExtensions need to write out locale/branding variants of the main JAR and extensions (respectively). Most simply, just write an extra <jar href="..."/> for each variant. (Means that verifyExtensions probably has to return the original fileToOwningModule for use from these other methods.) Preferably locale (not branding) variants would be put into their own sections, thus: <resources> <jar href="core.jar"/> </resources> <resources locale="ja"> <jar href="core_ja.jar"/> </resources> <resources locale="zh_CN"> <jar href="core_zh_CN.jar"/> </resources> This would mean that the generated JNLP would avoid loading localized JARs unless they were really going to be used. But this is just a minor optimization; the behavior would be the same if you simply had <resources> <jar href="core.jar"/> <jar href="core_ja.jar"/> <jar href="core_zh_CN.jar"/> </resources> since all resources within the localized JARs use locale-specific paths that are simply ignored in the default locale. 3. apisupport/harness/release/jnlp.xml needs to copy the locale and branding variant JARs from the platform into the JNLP output directory, of course. Maybe it already does this.
Created attachment 28293 [details] Fix of the basic problem
Now the jnlp build understands locales for modules. Still two problems: p3 cannot build autoupdate as it localizes its updater also, not just main module p4 jnlp files contain description just in english - probably they should also get one from the localized module bundles I'll commit what I have and also attach ZIPed harness dir which can be put into existing multi language 5.0 build and verify the above statement.
Created attachment 28295 [details] Harness to try the fix in 5.0
"#71129: MakeJNLP should at least a bit understand locales" Checking in antsrc/org/netbeans/nbbuild/MakeJNLP.java; /cvs/nbbuild/antsrc/org/netbeans/nbbuild/MakeJNLP.java,v <-- MakeJNLP.java new revision: 1.13; previous revision: 1.12 done Checking in test/unit/src/org/netbeans/nbbuild/MakeJNLPTest.java; /cvs/nbbuild/test/unit/src/org/netbeans/nbbuild/MakeJNLPTest.java,v <-- MakeJNLPTest.java new revision: 1.9; previous revision: 1.8 Fix of the main problem. For the others a lower priority bugs shall be open, I guess.
Filed low-priority bugs for remaining problems.
Should this fix be merged or waived for 5.0?
"Backport of #71129 to 5.0 branch" Checking in antsrc/org/netbeans/nbbuild/MakeJNLP.java; /cvs/nbbuild/antsrc/org/netbeans/nbbuild/MakeJNLP.java,v <-- MakeJNLP.java new revision: 1.12.2.1; previous revision: 1.12 done Checking in test/unit/src/org/netbeans/nbbuild/MakeJNLPTest.java; /cvs/nbbuild/test/unit/src/org/netbeans/nbbuild/MakeJNLPTest.java,v <-- MakeJNLPTest.java new revision: 1.8.2.1; previous revision: 1.8
Verified (5.0fcs+ja pseudo) - there was no problem to invoke 'Build JNLP Application'