Re: Libraries API

Petr Kuzel wrote:
>>Petr Kuzel wrote:
>>
>>>>* What are the use cases for "library" defined locally within a project ?
>>>
>>>To be able to share it with project. It simplifies project
>>>configuration in team environment.
>>
>>Yes, but I still do not follow the use cases: project definition is
>>shared anyway, so what are the scenarios to group project resources, or
>>build targets (or other things ?) into libraries for sharing ?
> 
> The same as for local definitions. You can reuse them in multiple projects.
> And if project definition is shared it could be shareable including
> library definitions.
> 
The user can create "user library" for that purpose. With project local 
libs we may end up by sharing a project or linking to it in order just 
to share the libraries it defines.
The advantages seems to include implementation reuse of project 
reference points, which are not available in user libraries + 
possibility to package project's output (e.g. jar + generated javadoc + 
...).

I am really not convinced that a project-local libraries are a necessary 
concept -- what do others think ?

> 
>>Almost -- IMO it is good to use FileSet as the least common denominator
>>interface to query library contents, but not restrict the contents to be
>>file-based.
> 
> I do not see the restriction. Do think anything in particular?
> 
It seemed that any data must be expressed in form of URL or better: 
FileObject, FileSets add "broken" semantics to URLs. That does not work 
for resources like database connection -- the connection itself is not a 
file, its definition is. So the client could end up with a mix of "real" 
resources (jar, folder, file, ...) and resource definitions (database 
connection, ...) when querying the library.

A related question: in project resource system, a resource may be 
decorated by additional content types by independent modules (if they 
e.g. can convert the original type to their own). Is such data reuse 
supported in Libraries ?

> 
> By default library customizer can add/remove FileSet content.
> However if provider registers customizer searchable by
> beans.Introspector it's used instead.
> 
Aha, OK.

> Library's lookup content is propagated to project resource
> ProjectMember's lookup. There is no problem at API leval AFAIK.
> I see possible problem at UI side, currently library customizer
> shows all registered volume providers' customizers. Too many
> volume providers will mess all library customizers.
> 
Do you mean that the customizer lists all volume types in one list ?

> 
>>I initially thought that the narrow FileSet-based content interface is
>>there in order for the framework to present library contents.
>>When we have Looks, it is also possible for the provider to implement
>>some generic enumerator interface + register Looks to achieve the same
>>goal.
> 
> Do you maen the library lookup? :-)
> 
Possibly, what interfaces are supposed to be registered in the Lookup ?

>>
>>Well, they did not seem to :)
> 
> That is sad. What meaning have you had linked with volume
> name?
>   
I simply did not understand the naming :)

-Svata