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.
I need a way to build just one module (like core.startup) including all the L10N JARs. Current L10N build runs as a post build step (taken from build-all-components.sh): #ML_BUILD if [ $ML_BUILD == 1 ]; then cd $NB_ALL hg clone -r $L10N_BRANCH $ML_REPO $NB_ALL/l10n cd $NB_ALL/l10n 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 ERROR_CODE=$? create_test_result "build.ML.IDE" "Build ML IDE" $ERROR_CODE if [ $ERROR_CODE != 0 ]; then echo "ERROR: $ERROR_CODE - Can't build ML IDE" # exit $ERROR_CODE; fi env variables are: LOCALES = "ar_SA ,ca ,cs,de,es,fr,gl_ES,in_ID,it,ko,nl_NL,pl,pt_PT,ro,sq,sv,tr,zh_TW,bg_BG" L10N_BRANCH=release701
Good luck. The L10N build system is a huge mess, and there is no clear interaction with AU, Maven, JNLP, etc.; witness bug #133901. Probably we need to get rid of the separate main/l10n repo and put (official) localizations back in the standard build process. Community-contributed localizations could just be handled as regular plugins (one per locale x cluster?) which happen to consist only of a placeholder module JAR plus */locale/*.jar. Then we would drop support for the <l10n> element from AU (if it is even implemented yet). As a short-term workaround on your side, just build all the L10N JARs and then copy only the ones you actually need to the destination.
I am fine with main/l10n. I imagine it could work like main/contrib. If present it will be used otherwise ignored. Just ant netbeans would also look for main/l10n/${locales}/my-module/ and packaged necessary JARs as well. Details TBD.
Not for 7.1, planning to do it right after that.
I guess we have no "Next" version in this component.
Created attachment 120145 [details] Initial version of my changes Hi guys, I'd like to move this issue forward and integrate it into 7.2 or some update of 7.2. Here is the initial patch. Just make sure "releases/l10n" repository is under your main NetBeans repository (btw. is there any reason why main/l10n repository is completely empty?). And then you should be able to rebuild any module with specified locales: ant -f openide.util.lookup/build.xml -Dlocales=cs,ja,ru and that should produce JARs for all these languages. In case you don't specify "locales" property, the system default locale is used. That should give our developers the translation they run their system in (e.g. cs_CZ in my case). Jesse please add some general notes about this patch. I plan to create a branch in core-main repository and set a Hudson builder up so we can verify our new system is generating the same bits as current daily build.
(In reply to comment #5) > is there any reason why main/l10n repository is completely empty? It is not empty, but it seems to be disused. (There are just two outgoing changesets relative to releases/l10n: my febf6adf20a6, which someone seems to have transplanted to a040e2d7bc23; and masaki's ac7f55f07670, also apparently transplanted to c1360fa9e630.) > Jesse please add some general notes about this patch. [JG01] Rather than overriding the 'netbeans' target as you have, which forces projectized.xml to keep up with a long list of dependencies normally specified in common.xml, may be better to define <target name="jar" depends="projectized-common.jar,jar-ml"/> and define a placeholder property in common.xml#files-init which projectized.xml can define instead of module.l10n.files; <locfiles> should really be split into a prep task which defines this list (needs to be available also to the "clean" target), vs. a task to actually pack the loc JARs. [JG02] 'codenamebase' is a misleading attribute name when really you want the version with dashes. [JG03] Use ModuleListParser.abbreviate rather than findModuleDir.
Branch created: http://hg.netbeans.org/core-main/rev/L10NBuild201433 builder is started: http://deadlock.netbeans.org/hudson/job/prototypes-L10NBuild201433/ > [JG02] 'codenamebase' is a misleading attribute name when really you want the > version with dashes. I kept the codenamebase name and I am passing dot version of the name into it now. > [JG03] Use ModuleListParser.abbreviate rather than findModuleDir. The "shortening" logic used in l10n seems to be different than the one used in regular NetBeans repository. Until it is unified, I am afraid I have to keep my own findModuleDir version. > [JG01] Rather than overriding the 'netbeans' target as you have, which force "jar" target is often overriden, so it seems safer to override the "netbeans" target. To address your concern, I defined new "-netbeans" target in common.xml
(In reply to comment #7) > it seems safer to override the "netbeans" target Probably an improvement, but note that 'netbeans' is overridden in at least three cases in main as well. Unfortunately Ant has no equivalent to 'super.' - you need to prefix with the name of a concrete script, meaning currently 'projectized-common.netbeans' that will not run jar-ml. Also this does not address the second half of JG01, that a monolithic <locfiles> fails to properly set ${module.files}, which breaks at least the 'clean' target.
(In reply to comment #7) > http://deadlock.netbeans.org/hudson/job/prototypes-L10NBuild201433/ BTW you may prefer to set the job's SCM to "Multiple SCMs" and then configure core-main#L10NBuild201433 and releases/l10n#default as delegates. The main reason to do so would be to get a proper changelog from the l10n repo in case you are making coordinated fixes there.
(In reply to comment #8) > this does not address the second half of JG01, which breaks at least the > 'clean' target. Clean target fixed: http://hg.netbeans.org/core-main/rev/0377e5ac8ebe
I'd like to get the incremental support in for 7.2. Thus I've just merged the infrastructure hoping it remains disabled with no impact on 7.2 release: ergonomics#c878f97662cd To use it, make sure the releases/l10n repository in underneath your releases (or *-main) repository and then just invoke the build with: $ ant build -Dlocales=ja,ru,pt_BR,zh_CN and you should get all the bits needed for these locales. I am leaving this issue open until it this process is turned on for daily builds (which I try to arrange as soon as release72 is branched).
Here is a how-to page: http://wiki.netbeans.org/L10N
Petr, please turn this on in default branch.
Done or not? If so, mark as fixed.
Done. All ant commands have set -Dlocales=$LOCALES as a command line parameter.