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 just unpacked NB 4.0 beta (from .tar.bz2) and took a look at the module_tracking.xml file at top level. I'm not sure what exactly it's supposed to say, but clearly it is not very useful because the (absolute) file paths it refers to are not even close to any existing path, e.g.: <module name="editor/util" path="/tmp/netbeans/dev/nb40beta/nb_all/nbbuild/netbeans/ide4"> <file name="config/Modules/org-netbeans-modules-editor-util.xml"/> <file name="modules/org-netbeans-modules-editor-util.jar"/> <file name="update_tracking/org-netbeans-modules-editor-util.xml"/> </module> Should that path perhaps have been just "ide4"??
I remember that there was an agreement between xtest team and the buildmaster to have the file there to allow a standalone test suite to run over any build. At least I am not aware of any other reason for the file to be there. As user experience is likely more important, I believe that the release build should not include this file and xtest can keep its copy somewhere else.
Well there are a few issues I guess. 1. The file does not seem to serve any purpose to the user. 2. It duplicates information already available in */update_tracking/*.xml. 3. It incorrectly uses absolute paths, making the path information worthless. 4. It will probably fall out of synch with reality if you update NBMs, since AFAIK Auto Update does not touch it. So unless there is some compelling reason for it to be there, I would recommend it be deleted.
I (and no one from former testtools team) don't know this file have ever been used by xtest. It can be deleted.
Well, the file became important for localized builds (since nb40).
#3 no longer applies - now seems to use relative paths. #1, #2, and #4 still apply - a useless file is left in the IDE distribution which duplicates files managed by AU yet will fall out of date with them. If translators need some such information, they should get it from a separate source; it should not be present in a regular English build.
Jesse, #2 doesn't apply. The file module_tracking.xml now holds information about respective cvs module/submodule name, NB cluster dir and NBM file name. This information is not held in respective update_tracking files. I would be happy to put this information somewhere else (i.e. nbbuild/templates/modules.xml) so it could be used during build of localized build, but it's not there. With projectized build and update tracking file we need to somewhat register locale/*_${locale}* files in all those tracking files. The build of localized IDE takes English IDE bits as an input, and builds localized data for it. Then the localized data are merged with english bits into localized build/NBMs. This complicated merge is done to preserve file permissions in the zipfile so the files present in both english and localized builds have got the same permissions (i.e. executable permissions on launchers). To accomplish this task cvs module name and cluster name is required for IDE build, and cvs module, cluster dirname and NBM filename is required for localized NBM build. All these information is (unfortunatelly) available only during build of respective module. To eliminate module_tracking.xml file I need to be able to get cvs module/submodule name, cluster dirname and NBM filename on demand during build of translatedfiles/build.xml file.
"we need to somewhat register locale/*_${locale}* files in all those tracking files." - localizations should not be in the same update_tracking/*.xml files as the main modules, I guess, but the autoupdate owner should say where they *should* be listed. "the localized data are merged with english bits into localized build/NBMs" - merging into a localized *build* is OK, but *NBMs* should be kept in two pieces: main English NBM, plus separate localizing NBM with only foreign language resources. Do not use nbbuild/templates/modules.xml for any purposes relating to this please. I may delete this file without notice if ParseProjectXML and apisupport cease to require it (which I hope will be the case soon).
Jesse, L10N NBMs are unusable as present in NB 3.x - 4.1. Maybe Promo-F (NB 4.2) would change that. I agree with the idea, that localized resources should be separated, but this also means they should be properly versioned and bound to their parent modules, what's actually not the case. Missing versioning of localized resources causes Update Client to handle L10N NBMs incorrectly and thus unacceptable for providing through Update Center. Jirka Rechtacek already works on that, but I don't know actual plan and status. For NB 4.1 the module_tracking.xml file is precious information resource. The localized data must be registered in update_tracking files, because those update_tracking files are data source for MakeNBM task and combined code + EN resources + localized resources is actually the only way to provide working&usable localized NBMs. regarding modules.xml. I don't need to put the information into modules.xml file. I just need whatever viable way for getting information about the build and what modules it's built from.
Re. "L10N NBMs are unusable as present in NB 3.x - 4.1. Maybe Promo-F (NB 4.2) would change that." - well if you know more please talk to Jirka Rechtacek, as he is now owner of AU, and probably does not know yet what is missing. I think this should be resolved for 4.2 - we need to have L10N NBMs working correctly without hacks.
The reported version is still 4.0. (Generally the Version field should never be moved forward, only on occasion back.)
It is fixed in trunk
Is it fixed? I just did a clean build yesterday and the file is there. Have you fixed anything since then? If so, a CVS commit log is needed to close. ModuleTracking.TRACKING_FILE still mentions it. nbbuild/hudson/trunk still has to delete it.
Re-assigning to me
I've removed it during work on my not-yet-committed changes related to multilanguage build, thus this will be soon fixed.
Removing nbbuild/antsrc/org/netbeans/nbbuild/ModuleInfo.java; /cvs/nbbuild/antsrc/org/netbeans/nbbuild/ModuleInfo.java,v <-- ModuleInfo.java new revision: delete; previous revision: 1.3 done Removing nbbuild/antsrc/org/netbeans/nbbuild/ModuleTracking.java; /cvs/nbbuild/antsrc/org/netbeans/nbbuild/ModuleTracking.java,v <-- ModuleTracking.java new revision: delete; previous revision: 1.15 done Removing nbbuild/antsrc/org/netbeans/nbbuild/SetClusterPatternSet.java; /cvs/nbbuild/antsrc/org/netbeans/nbbuild/SetClusterPatternSet.java,v <-- SetClusterPatternSet.java new revision: delete; previous revision: 1.6 done
Removing the line to delete it: nbbuild/hudson/trunk 1.93