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.
The current way is to make the generated source code files become secondary entries in a MultiDataObject, and then have them appear as child nodes of the grammar file in the explorer. This creates some problems including poor performance since currently every java/c++/c# source code file has to be parsed to look for a header comment indicating whether or not the file was generated from a *.g file. Also, Holger reported that the scheme used to support this mechanism can lead to infinite loops in the dataloader. Due to the problems with the current system, I am planning to remove the mechanism that makes the generated source code files be secondary entries of the DataObject for the grammar file, so that the generated files will appear just like regular source code files. That is obviously not ideal, but it will help to get the module into working and supportable shape. Holger Krug has a private implementation of an ANTLR module that places the all the generated code in guarded blocks. I am not sure if I want to integrate that kind of change in since guarded blocks are troublesome if there is a need to edit the *.java files during debugging or some other reason. It seems that the NetBeans 4.0 Projects designs will better address the issues related to the user interface regarding how to handle the generated source code that is produced when a ANTLR grammar (*.g) file is "compiled" into Java (or C++ or C#) source code. So, after this task is completed, I will file another issue regarding the implementation of a NB4.0-Projects-compatible way of handling the ANTLR module's build process, which should hopefully also address the UI issues presented here. I would like to do that work on a branch so that we can also maintain a NB3.4 compatible ANTLR module at least through the initial release of NB4.0.
I agree - grouping all of these files as secondary entries is an poor use of Datasystems. I think it is possible to do this in a reasonable way that would work even in 3.4. 1. Treat all files generated from the grammar as disposable build products, to be placed in a separated area from the sources, and normally not visible to users at all. Perhaps dump them into a hidden filesystem, as JSP support does when generating servlets. 2. The compiler type for .g files should first run ANTLR, then additionally invoke the default compilation (as per CompilerCookie) for each generated file. 3. Optionally, have the DataNode for a .g file display subnodes which are clones of the node delegates for the generated files. This would permit a user to browse and sanity-check the generated files easily. Don't bother making them guarded text; just document that they are generated and any edits may be discarded. If you want to be fancy, it is possible to filter their nodes in such a way that the editor supports are treated as read-only. 4. When the 4.0 projects architecture is stable enough, refit the UI to match it. The basic design will not have to change much, I think.
Obsolete milestone, please reevaluate