Re: [platform-releng-dev] improved checking for internal references

[Douglas Pollock <douglas.pollock@xxxxxxxx>]

I have some concerns about what this tool will mean in terms of process.

It seems that every team will be expected to update this file as public 
classes are added to their plug-ins.  They will also need to update the file 
if private internal classes are added.  If they fail to do so, there also 
doesn't seem to be any real way for them to realize that they have forgotten 
to do something.  As such, I am concerned that this will eventually lead to 
"component.xml" files that are significantly out-of-date.

Also, the creation of this file is not an insubstantial task.  For example, 
Platform/UI maintains about 2400 classes.

I would like to recommend that the use of this tool be put on hold until it 
can address some of these issues.  Ideally, the "component.xml" file should 
be optional.  Sane defaults should be obtainable by: parsing the package 
name, parsing javadoc comments, and make some assumptions about the nature of 
fragments.


On Tuesday February 8 2005 05:52 pm, Jim des Rivieres wrote:
> The tool takes as input a set of component definition files
> (component.xml) that provides the following information for each
> component:
>
> - what plug-ins are to be treated as a unit for the purposes of drawing an
> API boundary; all references between the plug-ins are considered a private
> matter (even if to internal packages)
> - a list of packages that are to be considered API packages
> - a list of classes and interfaces within the API package that have
> additional constraints on them (e.g., clients are not supposed to
> implement an API interface, instantiate an API class, or instantiate an
> API class)