Hi Adrian,
Adrian Brock wrote:
My critisms of using the JSR277 repositories to do the integration
included:
I want to better understand your concerns around developing
repositories, since I believe some of your concerns have already been
addressed in the draft API.
* There are already lots of orthogonal reasons for swapping
repository implementations
On Mon, 2007-02-26 at 12:26 +0100, Adrian wrote:
So besides the peer/hierarchy argument there
is also the problem that the repository is dealing
with too many concerns.
1) ModuleDefinition construction
The draft API provides a Modules.newJamModuleDefinition() method to
construct a ModuleDefinition from JAM's metadata and ModuleContent. The
ModuleContent abstraction enables a module archive to be stored in the
repository in any form under the cover. This should make it easier for a
repository implementation to construct ModuleDefinitions from JAM files,
or from other archive formats (as long as the metadata information of a
module can be expressed as JAM's metadata, and the content of the module
can be exposed through the ModuleContent abstraction).
In your original use case in JavaEE, the appserver wants to use the
module system for "plain old module" wiring but also wants to define its
own "modules" for wars, ears, etc., and some of which looks nothing like
jars/jams in structure. Do you think the draft API and the ModuleContent
abstraction are sufficient to address the ModuleDefinition construction
issue you were concerned with?
2) Model - parent/child or peer
I think you meant the module system inteorp model, not the repository
delegation model. Right?
3) QoS - what tools are available for the repository
The Java Module System implementation will come with a standard tool to
manage module archives in the repository, e.g. install/uninstall, etc.
Is there any particular aspect of the tools support that you are
concerned with but currently not possible in the draft API?
4) Location - file system/url based, etc.
This is handled by the ModuleContent abstraction described above.
* Developing a full repository just to define a different archive
format is too much (e.g. legacy javaee deployments)
I would like to know what you think about the draft API to see if it is
still too much to develop a repository.
- Stanley
