Bug 169522 - "Build ZIP Distribution" forgets locale-dependent JARs
"Build ZIP Distribution" forgets locale-dependent JARs
Status: RESOLVED DUPLICATE of bug 133901
Product: apisupport
Classification: Unclassified
Component: Harness
6.x
PC All
: P3 with 9 votes (vote)
: TBD
Assigned To: Jesse Glick
issues@apisupport
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-07-30 05:32 UTC by timekeeper
Modified: 2011-09-02 18:12 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description timekeeper 2009-07-30 05:32:52 UTC
The build script doesn't create folder platform10/core/locale and it also doesn't copy core_<locale>.jar into this folder.
As a result, splash screen messages, menu labels etc. are always displayed in English independent of the current locale.

Hint: My Rich Client Project was created with NB5.5.
Comment 1 rmichalsky 2009-08-03 12:24:34 UTC
Did it work for you in previous versions of platform? If so, which was the latest?

It seems to me that there has never been support for building platform app with arbitrary localization (i.e. without
update_tracking/*.xml entries), correct me if I am wrong. See
http://www.netbeans.org/issues/show_bug.cgi?id=133901
http://www.netbeans.org/issues/show_bug.cgi?id=157031

I agree that this should be changed, but it is rather an enhancement than a bug. As a workaround for now, you can add
your localization files into ZIP distribution e.g. in overriden 'build-zip' target in your suite.
Comment 2 timekeeper 2009-08-03 12:46:19 UTC
If you select language German when downloading NB 6.7 the german localization files are installed but they are not
registered in update_tracking/*.xml
And therefore they are not copied during "build zip distribution".

Sorry, this is not an enhancement, this is a real big bug! Billions of people all over the world have a non-english
mother tongue and the localization teams spend a lot of time in translating the bundles. If a NB user cannot create
a distribution with support for additional languages than NB is not usable for nearly 90% of the world!

The supposed workaround is very problematic because I would have to know which localization files I have to copy. I use
44 NB modules in my application and I really don't know which localization file I have to copy for which module. Is
there a way to find out which files I have to copy for a specific module to which location?
Comment 3 rmichalsky 2009-08-05 15:31:44 UTC
I understand your point, however this has never worked and there is no spec that this should work, so from my POW it is
an enhancement (even if it worked prior 6.0 as a side effect of more or less mistakenly listing 3 concrete localizations
in update_tracking).

Regarding the workaround:
I agree that it is not particularly simple to put together, so here it is for your convenience. Specify your desired
locale in your suite's nbproject/project.properties, e.g.:

    locales=de

And override 'build-zip' in your suite's build.xml, like this:

    <target name="build-zip" depends="suite.build-zip">
        <pathconvert property="l10n.files" pathsep="&#10;">
            <pathfileset>
                <path refid="cluster.path.id"/>
                <selector refid="zip.platform.included.files"/>
            </pathfileset>
            <mapper type="regexp" from="^.*[/\\](modules|core|lib)([/\\]ext)?[/\\]([^/\\]*)\.jar$"
to="**/\3_${locales}.jar"/>
        </pathconvert>

        <tempfile property="l10n.filter" destdir="${basedir}/build" deleteonexit="true"/>
        <echo file="${l10n.filter}">${l10n.files}</echo>

        <tempfile property="temp.dir" destdir="${basedir}/build" deleteonexit="true"/>
        <mkdir dir="${temp.dir}"/>
        <copy todir="${temp.dir}" failonerror="false">
            <pathfileset>
                <path refid="cluster.path.id"/>
            </pathfileset>
            <mapper type="regexp" from="^.*locale[/\\][^/\\]+_${locales}\.jar$" to="${app.name}/\0"/>
        </copy>

        <zip destfile="${dist.dir}/${app.name}.zip" update="true">
            <zipfileset dir="${temp.dir}" prefix="${app.name}">
                <includesfile name="${l10n.filter}"/>
            </zipfileset>
        </zip>
    </target>

I tested it and it seems to work, let me know if you encounter any problems. The target is a bit hacky and may break in
future versions of platform harness, but then hopefully RCP app localization will be more properly supported.
Comment 4 Michel Graciano 2009-08-31 18:29:24 UTC
As VOC meeting [1] will be necessary define some spec about how IDE should work in this scenario. When we have this spec 
probably we can implement this maybe by NetDEV or NetFIX program developer.

Regards
[1] http://qa.netbeans.org/processes/voc/chats/transcript_090821.html
Comment 5 Jesse Glick 2011-09-02 18:12:28 UTC

*** This bug has been marked as a duplicate of bug 133901 ***


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo