| Re: [platform-releng-dev] improved checking for internal references |
No, you got it right, I got it wrong. I had the impression every API type ought to be enumerated. Thanks for pointing it out. I thought Doug was concerned with failures being reported when new API types were created but the component.xml was not updated to reflect the addition (false positives). But, as you said, that does not cause violation errors. The actual issue would be that illegal usage might not be reported if the component.xml is not updated accordingly. Rafael February 17, 2005 2:36 PM To: platform-releng-dev@xxxxxxxxxxx cc: From: Steven Wasleski <wasleski@xxxxxxxxxx> Subject: Re: [platform-releng-dev] improved checking for internal references Rafael, perhaps I am misunderstanding your last sentence, but if you do not mention a type in the component.xml the api rules for the type depend on if its package name contains "internal". That is, leaving a type out of component.xml that is used by another component is not itself an error that will be flagged by the api scanner. For example, if you add an interface to an api package (non-internal) and intend for it to not be implemented but forget to put that in the component.xml file, a client that implements the interface will not see an error. Thanks, Steve Wasleski IES Technical Lead Rafael Chaves <Rafael_Chaves@xxxxxxxxxx> Rafael Chaves <Rafael_Chaves@xxxxxxxxxx> Sent by: platform-releng-dev-admin@xxxxxxxxxxx 02/17/2005 12:03 PM Please respond to platform-releng-dev To platform-releng-dev@xxxxxxxxxxx cc Subject Re: [platform-releng-dev] improved checking for internal references Personally, I don't think it is a big deal to go through the violation results file and make sure any valid cross-plugin references get properly addressed in the component.xml. This is only for classes used accross plug-ins, not every class in a plug-in. And if you forget to update the component.xml accordingly, no build will be broken, the violation will just be reported. But I agree with Peter - if the tool just obtained the information it needs from javadoc annotations in the Java source files, that would be more easily maintanable. Rafael February 17, 2005 11:51 AM To: platform-releng-dev@xxxxxxxxxxx cc: From: Peter Manahan/Toronto/IBM@IBMCA Subject: Re: [platform-releng-dev] improved checking for internal references I think the idea of the component.xml is great and something that has been needed for a long time. But the potential for it to get out of date is very likely. Perhaps if the component.xml was generated at build time. I assume the javadoc is built that way and since normally API is defined in javadoc perhaps something could be added as a tag that allowed the generation of the component.xml. Keeping all the information with the java files where hopefully the API javadoc is kept up to date. Thanks, ----------------------------------- Peter Manahan IBM Rational Tools Common Install ------------------------------------ manahan@xxxxxxxxxx platform-releng-dev-admin@xxxxxxxxxxx wrote on 17/02/2005 11:35:51 AM: > 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) > _______________________________________________ > platform-releng-dev mailing list > platform-releng-dev@xxxxxxxxxxx > http://dev.eclipse.org/mailman/listinfo/platform-releng-dev
Attachment:
graycol.gif
Description: GIF image
Attachment:
pic23413.gif
Description: GIF image
Attachment:
ecblank.gif
Description: GIF image
