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.

Bug 16555

Summary:	secondary file recognition
Product:	obsolete	Reporter:	_ derrick <derrick>
Component:	antlr	Assignee:	_ derrick <derrick>
Status:	STARTED ---
Severity:	blocker
Priority:	P3
Version:	3.x
Hardware:	All
OS:	All
URL:	http://www.antlr.org/doc/runtime.html#_bb3
Issue Type:	TASK	Exception Reporter:
Bug Depends on:
Bug Blocks:	17159, 17234

Description _ derrick 2001-10-15 01:18:32 UTC

The GDataObject class currently has a static list of created files, all based on
the primary file name, see findAssociatedFiles().
The GLoader class (a MultiFileLoader) then uses this list to identify secondary
files.

This should be modified to parse the primary (.g) file looking for 'class'
definitions, then based on whether the class is a parser, lexical analyzer or a
tree parser, and any package specification in the header section and
'exportVocab' in the options section, determine the list of files that will
actually be generated on a successful compile.

This will need to be done on startup and each time the primary (.g) file
changes.

Policies about orphaned files, i.e. where the output class name is changed after
a file of the original name has been produced, need to be addressed.

Comment 1 _ derrick 2001-11-11 01:04:01 UTC

The most recent submission adds the capability of clustering the
generated files under the reindeer node, correctly picking up existing
files, but fails to add files created after a compile. 

It also doesn't handle reparsing the .g file after an edit, so changes
to the generated file list aren't noticed.

A work-around is to disable the module and then re-enable it.
    -- working on it.

Comment 2 _ derrick 2001-11-14 04:43:30 UTC

The last submission adds FileChangeListener functionality to the
GDataObject.
There still remains one problem in that the nodes show up in two
places:
 1) under the reindeer
 2) under the directory node, even though they're registered as antlr
secondaries

Number 2 is a bug in the implementation for the 'thing handling
directory nodes'. You can tell it's a bug because if you have a couple
of nodes incorrectly shown under the directory, and you delete only
one using the command line of the OS, when the FileChangeListener
event is sent to the 'thing handling directory nodes' it (realizes the
error and) removes *all* the incorrect entries.

Code in GNode that populated the node with FileObject nodes has been
moved to GDataObject because (from the Node documentation):

The node has three purposes: 
    1.visually represent the object in the tree hierarchy (i.e.
Explorer) 
    2.provide sets of properties for that object (i.e. Component
Inspector, Property Sheet) 
    3.offer actions to perform on itself 

none of which mentions maintenance of contents. I'm open to discussion
about where this code should really go.

Downgrading to P3 since it's mostly done.

Comment 3 Jiri Prox 2007-09-17 21:48:22 UTC

Obsolete milestone, please reevaluate