Goals was: Re: Supporting OSGi Bundles in the Java Module System

[Stanley M. Ho]

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