WARNING: This server is unstable and will be retired in the next days.
If you want to keep this forum available, please request immediately a migration
on the Nabble Support forum.
Forums that don't receive any migration request will be deleted forever.
Adrian Brock wrote:
> My critisms of using the JSR277 repositories to do the integration
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.