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.
Thus it is impossible to include them in an update description file - they could not be downloaded. And the validation of the update desc XML file fails too, as it should. <locmakenbm> needs to include this attr. Including suggested technique, but it could be refined as desired.
Created attachment 9579 [details] Suggested patch
Well, this bug shold have arised sooner or later. Actually, when we discussed the new-l10n-way, the only thing we missed was the distribution parameter. Please also remove the comment "Decide how to..." Thanks for help, Jesse, I'm real 0 (= dude) in NB AU quirks
Jesse, the suggested patch is in conflict with other modules NBM build. All the build scripts keep property dist.base defined w/o protocol and the "http://" protocol string is hardcoded in each <makenbm> task. I know, that hardocoded assumption of "http://" protocol is not good idea, but applying your patch would require to patch build infrastructure and build scripts of all modules on release35 branch. I would suggest to apply your patch only for LocMakeNBM with the change to hardcode the "http://" string just before dist.base property. After Tegal is in Final, the "http://" hardcoded string can be removed from trunk. The current build infrastructure (same for dev and 3.5) is not much flexible to allow different construction of dist.base property value for 3.5 and dev builds. New build infrastructure (not yet done) is separated by "codeline" so it's easy to have different build logic.
1. I have no idea what you mean by this conflicting with other modules. Only <locmakenbm> is patched. It is used only by translatedfiles AFAIK. And re. use of the (evil) automatic "http://" prefix, I am not sure what the problem is here. The patch does not do anything about this prefix. It just looks for ${dist.base} and if present, calls MakeNBM.setDistribution, which already applies the prefix when it is needed. The patch to LocMakeNBM.java is similar to just adding an attr: <locmakenbm distribution="${dist.base}/foo.nbm" .../> which is like how normal modules do <makenbm>. The only reason I did not do that directly is because <locmakenbm> generates several NBMs and the suffix (here "/foo.nbm") is going to be different for each one (e.g. "/foo_ru.nbm" vs. "/foo_ja.nbm"), so you cannot just set it to one value. It needs to be computed somehow (this is a little clumsy but should work until something better is available).
added i18n to synopsis to aid for netbeans_ro tracking.
Jesse, normal modules do <makenbm distribution="http://${dist.base}/foo.nbm" /> what is in conflict with the patch which turns that to say <makenbm distribution="${dist.base}/foo.nbm" /> For build of "daily-alpha-nbms" moduleconfig, the property dist.base is set on command line, because the nbm will not reside on default dist.base.
Fine, so just ignore the part of the patch affecting translatedfiles/build.xml (until prefix usage for dist.base is removed everywhere - in the trunk I suppose). It doesn't matter; <locmakenbm> with the patch should work with or without an explicit http:// prefix. Either way, MakeNBM.setDistribution is called, which adds the prefix as needed.
nbcvs ci -m "Issue 32437. I18N - Localized NBMs do not include distribution attr. Fixed by join of value in property dist.base and localized filename." nbbuild/antsrc/org/netbeans/nbbuild/LocMakeNBM.java Checking in nbbuild/antsrc/org/netbeans/nbbuild/LocMakeNBM.java; /cvs/nbbuild/antsrc/org/netbeans/nbbuild/LocMakeNBM.java,v <-- LocMakeNBM.java new revision: 1.3.22.6; previous revision: 1.3.22.5 done Processing log script arguments... Mailing the commit message to cvs@nbbuild.netbeans.org (from rbalada@netbeans.org)
Cool. Fixed in the trunk too?
Reopening for trunk.
nbbuild/antsrc/org/netbeans/nbbuild/LocMakeNBM.java revision 1.7 for sure contains these changes.
Reopening for two violations I spotted in www/www/updates/alpha/dev_1.6_.xml: <module codenamebase="org.netbeans.modules.apisupport.lite" license="japanese_l10n-nbm-license.txt" downloadsize="9118" > <l10n langcode="ja" module_major_version="1" module_spec_version="0.6" OpenIDE-Module-Name="新規モジュールウィザード" OpenIDE-Module-Long-Description="Open API を使用する初級ユーザーがIDE から IDE への簡単なモジュール拡張を開発できるようにする単一のウィザー ド。簡単にするため、最も一般的に使用されるモジュール機能だけが直接提供 されます。Open API を真剣に使用したいと考える開発者は、このモジュール にないあらゆる拡張機能を備え、すべての API ドキュメントも含んでいる、 完全な API サポートモジュールも入手する必要があります。" /> </module> and <module codenamebase="org.netbeans.modules.apisupport.lite" license="russian_l10n-nbm-license.txt" downloadsize="8032" > <l10n langcode="ru" module_major_version="1" module_spec_version="0.6" OpenIDE-Module-Name="Мастер создания модуля" OpenIDE-Module-Long-Description="Мастер, позволяющий новичкам освоить Open API для разработки простых модулей Среды в самой среде. Для простоты представлены лишь наиболее часто используемые возможности модулей. Те разработчики, которые хотят заниматься серьёзно использовать Open APIs должны также установить полный модуль поддержки Open API (API Support), который предоставляет всю расширенную функциональность, отсутствующую в данном модуле, а также содержит полную справку по Open API." /> </module> BTW there is no magic involved in finding these things. Try opening the update XML files in the NetBeans editor and running standard XML validation on them. You will see errors.
Is this still an issue? I don't see any L10N NBMs in actual catalog (dev_1.8_.xml). This issue is either already fixed or does not need any further fixes.