Re: Java Project API/SPI

Svatopluk Dedic wrote:
> Jan Pokorsky wrote:
> 
>> Java Project API refinements:
>>
>> In order to make the api classes less overcrowded with methods and to 
>> prevent future compatibility issues I would propose to split following 
>> classes to API and SPI part:
>>
>> 1. ProjectPath:
>> http://www.netbeans.org/download/prj40_prototype/javadoc/JavaProjectAPI/org/netbeans/api/java/project/ProjectPath.html 
>>
>>   API: the class should be final. Just static methods would remain.
>>   SPI: introduce
>> public abstract class AbstractProjectPath {
>>   public abstract PathResource handleCreateResource(FileObject filebase)
>>        throws IOException;
>>   public abstract ClassPath getPath(ProjectMember object, Object type);
>> }
> 
> 
> What is the "handleCreateResource" method for ? It is not obvious from 
> the javadoc at all; shouldn't be the fact, that PathResources are based 
> on FileObjects (indirectly through ProjectMembers) or included in some 
> fixed sets of Classpaths an implementation detail of each provider ?
> 
>>
>> 2. JavaProject:
>> http://www.netbeans.org/download/prj40_prototype/javadoc/JavaProjectAPI/org/netbeans/api/java/project/JavaProject.html 
>>
>>
>>   API: the class should be final. Remove needless support methods like 
>> fireXXX, listenerAttached.
>>   SPI: introduce public abstract class BasicJavaProject containing all 
>> support methods and those neccessary for proper functionality of the 
>> api.JavaProject.
>>
> What is the advantage of this design over implementing directly the API 
> method by the provider ? Is the number of abstract methods (the methods, 
> which in fact define the project's functionality) small enough so that 
> richer final API class can be built around a small set of SPI methods ?

First of all I do not think the main purpose of JavaProject is to be 
implemented by providers but to be consumed by clients. Actually there 
is just one provider. So why clutter the class with methods useful only 
for  providers. Maybe we could hide the spi part at all till some one 
really needs to plug own implementation in. Do you suppose to provide it 
in ide4dev?

I have not count the number of helpers using the abstract methods yet. 
At a glance there are assignSources, createCompilationUnit, findSourse, 
findSourceDescriptor, getCompilationUnit and probably others build 
around current abstract methods.

Jan