Libraries API

Svata Dedic <[email protected]> Wed, 21 May 2003 21:57:44 +0200
Newsgroups gmane.comp.java.netbeans.modules.projects.devel
Message-ID <[email protected]>
Hello,

I have several questions/comments for Libraries API, present in 
projects/libraries [in no particular order].

* What are the use cases for "library" defined locally within a project ?

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

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

* 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.

* 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.

* 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.

* Functionality required for uniform presentation could be easily 
achieved by some enumerator interface on VolumeProviders.

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 ?

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.

Hardcoded to UI spec:

Thanks,
-Svata