Re: Libraries API

Svata Dedic 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.

> 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?

> When we are at setContent() :) -- could you please describe how the
> collaboration between the framework and individual providers is supposed
> to work in Library customizer ?

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

>>>* I wonder how would the API user describe, using e.g. a FileSet, the
>>>build output from a specific build configuration from a specific
>>>project. The API seems not expressive enough.
>> 
>> Is it use case for library? You can add remote build target
>> project resource directly.
>>  
> See above -- why shouldn't the user be able to add this resource type to
> a library, supposing other (less arcane) project resources can be added ?

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.

> 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? :-)

>> Content and Resource names are highly overloaded. Unique
>> name like Volume should simplify communication.
>>  
> Well, they did not seem to :)

That is sad. What meaning have you had linked with volume
name?
  
  Cc.