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.
Ahoj Petre a Jesse, I'm working on implementation of multilanguage build of NB 6.0. Current set of changes touches three files. nbbuild/templates/common.xml nbbuild/templates/projectized.xml nbbuild/antsrc/org/netbeans/nbbuild/MakeListOfNBM.java General idea of those changes is, that if property 'locales' has been set (i.e. by calling 'ant -Dlocales=foo'), then multilanguage build targets should be also executed. When I discussed this solution, Yarda pointed out that changes in common.xml appear in harness cluster of product, so any changes should be made carefully and get approval. I'll attach a patch. Would you please consider looking at the patch and approve/reject? In case of reject I would welcome suggestions for different solution.
Created attachment 50121 [details] Patch for build system to support multilanguage builds
I think before asking for review you should step back and create a description of what you are trying to accomplish, exactly, then enumerate details of what new properties you expect to be settable in module projects and exactly what they mean. All this information needs to be cleanly written up and present in harness/README if there is to be some effect on users of the harness. Right now it's not even obvious that any of this should go into the harness at all - perhaps it is all specific to nb.org modules and should stay out of the subset of code which is used in the harness (i.e. common.xml plus those Ant tasks listed in apisupport/harness/nbproject/project.properties#bundled.tasks). Better to redo the patch without gratuitous whitespace changes (here, changes in indentation, and additions of trailing spaces) which distract from the real changes. ${nb_all} should certainly not be used in common.xml, nor should there be any mention of translatedfiles which is a nb.org project. includes="**/*" is the same as includes="**"; both are no-ops. Do not use java.util.Vector (or Hashtable) in new code, and do not use raw types for collections etc. Testing for values beginning with "${" to see if a property is unset is poor form. Define a sensible default value for the property in the build script; the task should expect to see a legitimate evaluated value. Many uses of StringTokenizer can be replaced with a simpler call to String.split.
Redone the patch without touching common.xml