Re: ClassPath API comments, questions

Vitezslav Stejskal wrote:
>>
>>Originally I thought that it would be useful to have a restricted 
>>interface for query clients, who need ClassPath to access/find resources 
>>and that PathContent/PathResource should be mainly used by clients 
>>interesting in configuration and project management.
>>
> Hmm, both PathContent & PathResource don't use anything from projects 
> API (nor the Java Project API), so why they shouldn't be used by anybody 
> intersted in Classpath management only? Or do you mean that we should 

Classpath management is (IMHO) a small portion of ClassPath usage. 
Locating, loading, listing resources is far more common. It's true that 
project-management code does classpath management too, but not "normal" 
clients.

It's the same as sending Enumerations instead o Collections if clients 
are not typically interested in add()ing. For locating a resource, you 
don't need add(), remove() or path structure provided by a PathContent 
at all.

> separate the classpath 'consumers' from classpath 'providers'? In such 
> case the PathContent and PathResource should be moved to SPI.
> 
No - some consumers (API clients) really _need_ to access configuration 
data. Other clients need only read them and don't bother with structure, 
validity, definitions and other stuff involved.

> Don't you think that classpath manipulation capability is interesting 
> even for clients who do not bother with projects at all?
> 
Possibly. To the contrary only a small portion of use cases lead to 
classpath manipulation even for project-aware client.

>>
>>>> ClassPath.Entry, these classes seem to be independent, but PathResource 
>>>> contains the same methods (not all, but many) as CP.Entry and in fact 
>>>> serves the same purpose IMO. It seems that there is no support for 
>>
>>Correct. 
>>
> Ehm, sorry then, but why PathResource doesn't extend the CP.Entry?
> 
Look at the CP.Entry interface :-( I admit that I had been stupid when I 
wrote it.
CP.Entry is (IMHO) not suitable as a base class for PathResource which 
are not leaves in the path structure. However if can subclass it somehow 
consistently, please do so!

>>
>>The PathResource does serve one additional purpose: it establishes an 
>>identity for the folder (other than the folder identity) so that other IDE
>>
> OK. It's the R-9 I guess. Properly translated URL should be enough for 
> the identification purposes.
> 
URL of the denoted folder / jar ? No, it is not. You don't get anything 
from a folder if you can't reach the URL. You can get more from 
PathResource. For example a presentation, which tells you "Project foo 
is not available" if the Resource is output from "foo".
> I do understand this pattern, but look at the code:
> 
> public class ProxyPathContent extends PathContentBase {
>    
>     public static final class Control {
>        
>         public void setDelegates(PathContent[] bases, PathContent 
> writable) {
>     }
> 
[...]
>     public final void setBases(PathContent[] bases, PathContent del) {
>         ...
setBases() was made public by accident, it was meant to be protected 
from the start (modelled after FilterSet).

Sorry for the confusion I made -- please make setBases protected, or 
remove .Control class. The solution IMHO depends on how much data 
protection we need.

>>
>>I would rather keep "find" in the name -- the path type may not be 
>>supported at the object.
>>
> I have no strong opinoin on "find" vs. "get", I just wanted to be 
> consistent with Open API (e.g. Looku.Provider.getLookup(), 
> Environment.Provider.getEnvironment(), 
> ExplorerManager.Provider.getExplorerManager(), ...).
> 
All these get() functions are document not to return null. find() 
methods are typically permitted to return null value.

> I still think it's useless and should be removed, see above explanation ;-).
> 
Oops :-)

-Svata