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.

Bug 133901 - I18N : Build JNLP App/ZIP Distribution will not include localized jar files
Summary: I18N : Build JNLP App/ZIP Distribution will not include localized jar files
Status: VERIFIED FIXED
Alias: None
Product: www
Classification: Unclassified
Component: Builds & Repositories (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker with 25 votes (vote)
Assignee: pgebauer
URL:
Keywords: I18N
: 138056 157027 169522 187872 199496 (view as bug list)
Depends on: 205206 205207
Blocks: 157031
  Show dependency tree
 
Reported: 2008-04-25 08:03 UTC by Masaki Katakai
Modified: 2011-11-16 15:01 UTC (History)
14 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Masaki Katakai 2008-04-25 08:03:07 UTC
Try the ml daily build e.g. builds/netbeans/6.1/fcs/latest/ml/.
It includes Japanese localization.

It seems that localized platform jar files will not be built and
copied into the binary when Run JNLP apps.

1. Start IDE
2. New Project
3. Samples > NetBeans Modules > Paint Application
4. Run JNLP Application

Localized jar files of NB platform should be signed and copied into
the dist folder - <project>/dist/jnlp/local/netbeans/.
Comment 1 Jesse Glick 2008-04-25 15:59:43 UTC
I don't know where to get an "ML daily build". Give me a URL if you want me to reproduce anything, and instructions for
reproducing on an English-language computer.

To test, I downloaded 6.0.1 ML from the public website and installed it. In a plain NB dev build, using JDK 6, I
configured a NetBeans Platform with that installation (using the default mode "Harness Supplied with IDE", i.e. testing
the same JNLP building code you claim does not work). I created an application suite using the new platform, then ran
Run JNLP. The app appeared in English as expected. Then from a command line I ran

javaws -J-Duser.language=pt -J-Duser.country=BR $thesuite/dist/jnlp/local/master.jnlp

and the app appeared in Portuguese as expected.

I do know that localization JARs will not be included if they are not enumerated in */update_tracking/*.xml in the
platform. If these files indeed fail to mention the ML JARs, please reassign to mzlamal in nbbuild/code as this would be
a production build issue.
Comment 2 Ken Frank 2008-04-25 17:44:59 UTC
http://smetiste.czech.sun.com/builds/netbeans/6.1/fcs/2008-04-21_18-33-08/ml/zip/
for internal location of recent ml bld.

ken.frank@sun.com
Comment 3 Jesse Glick 2008-04-25 20:38:03 UTC
Indeed the build you point to does not have localized JARs correctly listed in update_tracking/*.xml.
Comment 4 Jesse Glick 2008-06-27 03:27:38 UTC
*** Issue 138056 has been marked as a duplicate of this issue. ***
Comment 5 puce 2009-01-19 13:56:40 UTC
*** Issue 157027 has been marked as a duplicate of this issue. ***
Comment 6 puce 2009-01-19 14:17:28 UTC
I have the same issue with NetBeans v6.5 and German locale.
(See: http://www.netbeans.org/issues/show_bug.cgi?id=157027 )

Here is what I did to get a NetBeans Platform with German l10n files:
- Download the NetBeans Platform src.zip and build it
- Download the German NetBeans IDE and install it
- Exctract the German i18n files from the German NetBeans IDE installation and merge them into the directory of the
NetBeans Platform binaries
- Uninstall the German NetBeans IDE (I think I also had to uninstall and reinstall the English NetBeans IDE)
- Configure the application to use this built platform

After this the German texts showed up when starting the application with the German locale - but only if I start the
application "normally" from within the IDE.

"Build ZIP Distribution" and "Build JNLP Application" do not include the localized platform jars!

I tried now to manipulate one of the update_trackin/*.xml and the according jar was included in the war and the jnlp had
the according resources entry.

Is there an easy way to create all those files with the correct crc attributes in the file elements? (Though the crc
attributes don't seem to be needed.) Or do I have to manipulate all these xml-files manually???

Neither the German nor the standard (default, ja, pt_BR, zh_CN) installation of the NetBeans IDE v6.5 do include any
file elements for localized jars -> this should be fixed.

I found almost no documentation about update_tracking -> this should be fixed

It really should be simpler to internationalize a NetBeans Platform based application:
http://www.netbeans.org/issues/show_bug.cgi?id=157031


Comment 7 dlipin 2010-05-07 11:14:20 UTC
I'll look into that.
Comment 8 dlipin 2010-05-07 12:15:26 UTC
Looking at nbbuild/newbuild/build-all-components.sh I see that ML artifacts are build in a special step (line 302):

ant -Dbuildnum=$BUILDNUM -Dbuildnumber=$BUILDNUMBER -f build.xml -Dlocales=$LOCALES -Ddist.dir=$NB_ALL/nbbuild/netbeans-ml -Dnbms.dir=${DIST}/uc -Dnbms.dist.dir=${DIST}/ml/uc -Dkeystore=$KEYSTORE -Dstorepass=$STOREPASS build

This step produces a number of locale jar files and does not create any update_tracking files nor modifies existing ones.

Later in the build process, English artifacts are *copied* to the ml directory (line 247):
cp -r $NB_ALL/nbbuild/netbeans/* $NB_ALL/nbbuild/netbeans-ml/
That also copies update_tracking/* files. Those files correspond to English-only files and does not update tracking information for localized files.

One of the possible solutions is to re-generate update_tracking/* files after that. Hard to say whether we already have a specific ant target for that (probably that is netbeans-ml in projectized.xml) or should yet create another one. Reassigning to nbbuild owner.
Comment 9 dlipin 2010-05-08 07:22:46 UTC
BTW, this issue also happens with zips which are created in pack-all-components.sh using zip-cluster-config target.
Comment 10 dlipin 2010-06-02 14:27:07 UTC
Why is it 6.9_WAIVER_APPROVED? I haven't seen any requests about this issue on nb-bug-waiver-council.
Comment 11 dlipin 2010-06-02 14:46:54 UTC
A-ha, just saw "Automatic waiving of P2s which are not stoppers" in p-team minutes.
Comment 12 Jesse Glick 2010-06-21 15:02:29 UTC
*** Bug 187872 has been marked as a duplicate of this bug. ***
Comment 13 Jesse Glick 2010-08-22 21:29:15 UTC
simpatico - Version fields may be moved backward (if a bug is found to be reproducible in an earlier release than previously thought), but not forward; an open bug is assumed to apply to all later versions.
Comment 14 tkellerer 2011-02-20 08:53:31 UTC
Why is this marked with "www" instead of platform?
Comment 15 Jesse Glick 2011-02-22 15:46:09 UTC
(In reply to comment #14)
> Why is this marked with "www" instead of platform?

Because the problem is with build scripts, not the platform per se.
Comment 16 alied 2011-03-22 00:01:01 UTC
Perhaps related (if not, I'll file a new issue):
directory "release" in a suite is not included in zip distribution.
Comment 17 Jesse Glick 2011-03-22 13:38:58 UTC
(In reply to comment #16)
> Perhaps related

Not related.
Comment 18 Marian Mirilovic 2011-03-24 08:57:34 UTC
pgebauer, 
did you send request for waiver as specified in http://wiki.netbeans.org/WaiverProcess ? If not, please do so ASAP. Thanks in advance.
Comment 19 pgebauer 2011-03-24 09:18:35 UTC
(In reply to comment #18)
> pgebauer, 
> did you send request for waiver as specified in
> http://wiki.netbeans.org/WaiverProcess ? If not, please do so ASAP. Thanks in
> advance.

Yes, I did on Tuesday 22-Mar. The issue should be marked as waived today, in case of no objections.
Comment 20 Marian Mirilovic 2011-03-27 07:17:16 UTC
agreed with waiver
Comment 21 pzajac 2011-03-27 07:29:21 UTC
3 years old, P2, 20 votes, 3 duplicates and still waiver :-)
Comment 22 Jesse Glick 2011-06-23 19:47:04 UTC
*** Bug 199496 has been marked as a duplicate of this bug. ***
Comment 23 Petr Jiricka 2011-06-28 14:43:38 UTC
A comment on the waiver request for 7.0.1 from Jesse Glick:
-----
> The fix is not likely to be trivial.

I see this issue being repeatedly waived, with no real evaluation.

> Users which uses JNLP with non-EN locales will be impacted.

Also affects anyone creating plain ZIP distributions of NB-based applications.

-----
Unfortunately, the time is running out for 7.0.1, and with Petr G on vacation, we have no option but to waive this for 7.0.1 as well.
Comment 24 benjamin.ihle 2011-07-27 12:38:09 UTC
We also had a problem in building a localized netbeans rcp app based on netbeans platform 7.0 that shall be distributed via Java Web Start.

That is what we did:
http://netbeans.org/projects/platform/lists/dev/archive/2011-07/message/246

The localized jars are not added to the generated *.war file. But the created ZIP distribution includes the localized jar files. Maybe because we added the localized jar-files to the netbeans platform directories manually before.

Does anybody knows how to integrate all the localized jar files into the "build-jnlp" target?
Comment 25 Marian Mirilovic 2011-08-02 05:33:56 UTC
>20 dups + votes -> P1 based on http://wiki.netbeans.org/BugPriorityGuidelines
Comment 26 Jesse Glick 2011-09-02 18:12:28 UTC
*** Bug 169522 has been marked as a duplicate of this bug. ***
Comment 27 Marian Mirilovic 2011-09-22 09:24:49 UTC
not a stopper for NB 7.1 Beta - but must be fixed for 7.1 FCS
Comment 28 pgebauer 2011-10-04 22:43:29 UTC
The update_tracking/*.xml files are generate by the build-nozip target but the target generates only English bits. The multi lingual version isn't generated from java source but only locales are created from l10n repository and they are just copied into English bits. A re-generation of update tracking files ( proposed in http://netbeans.org/bugzilla/show_bug.cgi?id=133901#c8 ) isn't possible because all jar files from all modules are mixed in one place however update tracking files have to be generated for jar files per every single module. 

Does anybody have an idea how to generate update tracking files without complete rewriting of multi lingual build script?
Comment 29 Jesse Glick 2011-10-25 22:04:25 UTC
(In reply to comment #28)
> re-generation of update tracking files isn't
> possible because all jar files from all modules are mixed in one place

Should not be a problem; you can infer by its path that platform/modules/locale/org-netbeans-core-io-ui_ru.jar is supposed to be a variant of platform/modules/org-netbeans-core-io-ui.jar, thus owned by update_tracking/org-netbeans-core-io-ui.xml.

Anyway that is only relevant if you want locale JARs to be associated with the individual module. This would not work if unlocalized updates were offered, which is quite likely given that translations are not even kept in the main source repository. A better approach might be to create one pseudomodule NBM for all localizations, or one per locale, or one per cluster, or one per locale x cluster, etc.; these could appear as regular plugins in Plugin Manager, or be invisible modules "recommended" by plugins. This technique would anyway be required by unofficial community translations.

(There is a special <l10n> element permitted by the Auto Update DTDs - somewhat akin to OSGi bundle fragments - but I doubt this feature was ever fully implemented or tested, and is unlikely to work properly with either Ant- or Maven-based builds.)

Whichever policy is adopted, the Maven repository and JNLP builds must be considered as well.

I expect this issue will get waived for 7.1 once again. As a nontrivial change with possibly wide ramifications it needs to be planned for and addressed during the regular development cycle, not as a bug fix during stabilization.
Comment 30 Petr Jiricka 2011-10-26 07:21:56 UTC
> I expect this issue will get waived for 7.1 once again.

I'd hope it will be addressed for 7.1.
Comment 31 ulim 2011-10-29 20:02:06 UTC
Perhaps there could at least be a workaround documented somewhere. Someone developing a NB Platform based application will eventually want to distribute localised versions of his app. I am not aware of any documentation on how to do that. After a lot of searching I found someone describing how to hack the update_tracking files manually and download the localised jars seperately and put them in the right place. This is a very time-consuming and error-prone procedure that has to be repeated with every new version of the IDE being installed. It would be nice to have an official HOWTO for that. Even better would be a "pre-hacked" multilingual distribution to download that works right out of the box.
Comment 32 Quality Engineering 2011-11-04 15:01:20 UTC
Integrated into 'main-golden'
Changeset: http://hg.netbeans.org/main-golden/rev/428a24a0c939
User: PGebauer <pgebauer@netbeans.org>
Log: #133901 I18N: Build JNLP App/ZIP Distribution will not include localized jar files
Comment 33 Quality Engineering 2011-11-05 02:59:30 UTC
Integrated into 'main-golden'
Changeset: http://hg.netbeans.org/main-golden/rev/076bb8610593
User: PGebauer <pgebauer@netbeans.org>
Log: #133901 I18N: Build JNLP App/ZIP Distribution will not include localized jar files
Comment 34 pgebauer 2011-11-07 10:05:44 UTC
The issue should be fixed. Could somebody verify it? Bits are at http://bits.netbeans.org/trunk/nightly/latest/zip/
Comment 35 Masaki Katakai 2011-11-07 16:16:12 UTC
Thank you for working on it, it's great to include the fix into 7.1!

I'm now trying 201111060600 build on Japanese Windows and here are the quick results:

1. create a NetBeans Platform Application project
2. create a sub module under it, added a empty Windows to the module
3. Start it on NetBeans
  message on splash screen and menus are localized : OK

4. Try JNLP
  message on splash screen e.g. Initializing, Staring Modules... are still English
  menus are localized

5. Try ZIP distribution
  message on splash screen e.g. Initializing, Staring Modules... are still English
  menus are localized
Comment 36 pgebauer 2011-11-08 00:14:00 UTC
Masaki, could you please attache screenshots? BTW do you know a place in source tree where messages from splash screen (Initializing, Staring Modules...)  reside?
Comment 37 ulim 2011-11-08 00:20:11 UTC
Ran my existing NB platform app from within the IDE with --locale pt:BR, since that locale is apparently always shipped with the IDE. Result was that the splash screen was localised in Portuguese.

Then I built a Mac OS X application and ran it outside the IDE: splash screen again in English.

Ulrich
Comment 38 Masaki Katakai 2011-11-08 02:04:54 UTC
(In reply to comment #36)
> Masaki, could you please attache screenshots? BTW do you know a place in source
> tree where messages from splash screen (Initializing, Staring Modules...) 
> reside?

I can see the message in

   platform/core/core.jar

org/netbeans/core/startup/Bundle.properties:MSG_restore=Starting modules...

When I checked ZIP distribution,

   platform/core/locale/core_<lang>.jar

is not provided.
Comment 39 sidlo 2011-11-08 07:12:29 UTC
I take nb 7.0.1 with Czech jar files. Next I copy netbeans-trunk-nightly-201111060600-ml-javase over it. Start IDE under Linux with Czech localization. Menu in IDE are Czech. Build application and package as zip distribution. New application I run outside IDE. Menu are English.
Comment 40 pgebauer 2011-11-09 13:17:31 UTC
(In reply to comment #39)
> I take nb 7.0.1 with Czech jar files. Next I copy
> netbeans-trunk-nightly-201111060600-ml-javase over it. Start IDE under Linux
> with Czech localization. Menu in IDE are Czech. Build application and package
> as zip distribution. New application I run outside IDE. Menu are English.

The standard ML NetBeans IDE doesn't contain Czech locales. Only ja, pt_BR, ru and zh_CN are supported. Czech locales are handled by community builds.
Comment 42 Quality Engineering 2011-11-10 15:55:43 UTC
Integrated into 'main-golden'
Changeset: http://hg.netbeans.org/main-golden/rev/ec687ba12277
User: PGebauer <pgebauer@netbeans.org>
Log: #133901 I18N: Build JNLP App/ZIP Distribution will not include localized jar files
Comment 43 Quality Engineering 2011-11-11 15:35:32 UTC
Integrated into 'main-golden'
Changeset: http://hg.netbeans.org/main-golden/rev/daf7b1d2c905
User: PGebauer <pgebauer@netbeans.org>
Log: #133901 I18N: Build JNLP App/ZIP Distribution will not include localized jar files
Comment 44 pgebauer 2011-11-14 09:55:26 UTC
(In reply to comment #38)
> When I checked ZIP distribution,
> 
>    platform/core/locale/core_<lang>.jar
> 
> is not provided.

It should be fixed. Masaki, could you please verify the result as you did in http://netbeans.org/bugzilla/show_bug.cgi?id=133901#c35  ?

Thank you.
Comment 45 Jesse Glick 2011-11-16 02:52:18 UTC
Checking netbeans-trunk-nightly-201111150600-ml-javase.zip. */update_tracking/*.xml look right.


Make new NetBeans Modules > NetBeans Platform Application. Add to project.properties:

run.args.extra=--locale ru

and Run Project. Appears in Russian as expected.


Package as > ZIP Distribution. Unzipped result, ran with --locale ru. Again appeared in Russian as expected.


JNLP > Run. build/jnlp/netbeans/*.jnlp created with e.g.

  <resources locale='ru'>
    <jar href='org-openide-filesystems/locale-org-openide-filesystems_ru.jar'/>
  </resources>

as expected. App appeared in English as expected. Ran

javaws -J-Duser.language=ru dist/jnlp/local/master.jnlp

and app appeared in Russian as expected.

After excluding "JUnit 4" from the app (Libraries tab), and adding

jnlp.platform.codebase=http://deadlock.netbeans.org/hudson/job/ide-jnlp/lastStableBuild/artifact/nbbuild/build/jnlp/

to project.properties, running Clean, then repeating the JNLP build, Russian locale is not available, since this job does not currently build locales out of the l10n repo.

Whether this will work with http://bits.netbeans.org/7.1/fcs/jnlp/ (or whatever the final URL is) depends on what process builds those files - Petr is there some preview available of JNLP files? I guess that would be http://bits.netbeans.org/trunk/nightly/latest/jnlp/ but this does not currently contain locales. http://bits.netbeans.org/dev/jnlp/ (the same??) does not either.


Cannot fully test Mac applications, but can observe that the result contains the expected locale JARs, so see no reason why it should not work as well.


http://bits.netbeans.org/trunk/nightly/latest/uc/ contains locale JARs.


NBMs in http://bits.netbeans.org/netbeans/trunk/maven-snapshot/ do not contain locale JARs.


Petr - not sure if I should leave this FIXED and open separate blocking issues for the Maven repo and (prebuilt) JNLP, or if you will be fixing those as well?
Comment 46 pgebauer 2011-11-16 13:54:21 UTC
(In reply to comment #45)
> Whether this will work with http://bits.netbeans.org/7.1/fcs/jnlp/ (or whatever
> the final URL is) depends on what process builds those files - Petr is there
> some preview available of JNLP files? 

The following link http://bits.netbeans.org/netbeans/7.1/jnlp/ could be used as preview. It contains 7.1-beta bits.
BTW Do I understand correctly that jar-files from the mentioned link should contain locales? (They do not contain any now)
 
> Petr - not sure if I should leave this FIXED and open separate blocking issues
> for the Maven repo and (prebuilt) JNLP, or if you will be fixing those as well?

Could you please open a new issue? Thank you.
Comment 47 Jesse Glick 2011-11-16 14:49:48 UTC
OK, I will open blocking issues.