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