Re: Libraries API

Svata, thank you for the review, reply is in-lined.

> * 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.
 
> * Does the API return FileSet of resource definitions within the library
> or set of referenced files (e.g. set of .jar files) ? In the later case,
>   why is there a restriction that all resources must be file-based ?

These URLs are rendered by volumes to instances returned by
volume Lookup. I hope that URL allows to represent virtually
anything.
 
> * Library.create() -- where does that create the Library ? In some
> project, in "Personal" area or somewhere else ? Why the library is not
> given a human-readable name from the start ?

Nowhere, library itself does not know where it is stored.
I have not received requirement for programmatic library
definitions (except those final at module layer). Therefore
only implementation that provides UI is able to add
it to storage. The create() method serves for framework
purposes, it's not client method (until library storage
methods exposed). It needs to be better documented.
 
> * What is the use case to deliver an uninterpreted FileSet to the client
> ? How is the client supposed to handle such raw data ? If it knows the
> data type, presumably from some module API, it could directly access
> service exposed by a VolumeProvider and do not bother with getContent()
> at all.

It could be moved to implementation. See bellow.
 
> * I do not see a use case for setContent() method, which stores a random
> fileset into the Library. If the client and the "Volume provider" agree
> on some data type, they may agree on some protocol to alter/add to that
> data, too. Note that setContent is not sufficient for e.g. Classpath,
> where ordering counts.

Such method does not exist at API level.
 
> * 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.
 
> * Functionality required for uniform presentation could be easily
> achieved by some enumerator interface on VolumeProviders.

I cannot not get it.
 
> Naming:
> 
> Volume sounds much more like a measure than a content, could it be
> changed to "Content" and "VolumeProvider" to "ContentProvider", or even
> to "Resource" and "ResourceProvider", since libraries are all about
> resources ?

Content and Resource names are highly overloaded. Unique
name like Volume should simplify communication.
 
> FeatureDescriptor misuse:
> 
> Usage of FeatureDescriptor in the Library API seems rather strange:
> - it mixes presentation with data. The library can be visualized by a
> Look/Node.
> - Library or Libraries should derive from, rather than return
> FeatureDescriptor, if they have properties like "name", "displayName",
> "expert" etc. I do not think that FeatureDescriptor is well for
> description of a library, except delivering "UI hints" which are in turn
> left unspecified in the API.
> In fact, Library duplicates FeatureDescriptor's functionality since it
> has name attribute itself.

It could be moved to implementation. It finally simplifies library
class to getLookup(), isValid(), getName() methods.
 
> Hardcoded to UI spec:

[it looks like unterminated mail]

Summary:
I'll remove several methods from the API and move them to implementation.

  Cc.