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

[Stanley M. Ho]

Adrian Brock wrote:
> I see a number of possible use cases here 
> (I'll continue with appserver example):
> 
> 1) Fully JSR 277
> 
> The appserver and JavaEE specs are updated to fully understand
> JSR277/294. In this case, the JavaEE deployment process would 
> probably make use of a JSR 277 repository.
> 
> 2) Partial JSR 277
> 
> The appserver knows about JSR277/294 but the JavaEE specs
> haven't been updated (or they are legacy deployments).
> 
> In this case the appserver could try to adapt the deployments
> to conform to the ModuleDefinition/Content.
> 
> In this case, there probably wouldn't be a real repository
> implementation, instead the "repository" would be dummy.
> It would just be serving as an adapter from the old deployment packaging
> and metadata to the new one at runtime.
> 
> 3) Mixed
> 
> Similar to 2, but the opposite. 
> The appserver knows about JSR277/294 and wants to support
> .jam files as well as .jar files in JavaEE deployments.
> i.e. .jam files would be unpacked from a .jar EAR deployment
> and then added to the module system runtime.
> 
> Conclusion:
> 
> I expect there are other possible uses.
> 
> The question is whether Repository is the best api
> for cases (2) and (3). i.e. we implement a dummy
> repository with a dummy "URL" for the source
> or whether there should be a more abstract parent
> class (I called it ModuleSource) that doesn't
> assume a physical repository behind the scenes.
> 
> At least for cases (2) and (3) all we really want
> to do is to PUSH a ModuleDefinition/Content to the
> jsr 277 module system such that we can get back
> a Module/Classloader with the imports resolved.

In your example, if you want to create ModuleDefinitions from the .jar 
files, there are two ways to achieve it:

1. a. Create a ModuleContent based on the content of the .jar file.
    b. Generate the JAM's metadata based on information in the .jar file.
    c. Construct a JAM's ModuleDefinition with the ModuleContent using
       Modules.newJamModuleDefinition(). The ModuleDefinition would be
       associated with the JAM module system.

2. a. Create a ModuleContent based on the content of the .jar file.
    b. Create your own ModuleDefinition with the ModuleContent and use
       the JAM module system as the associated module system. As long as
       your ModuleDefinition exposes the appropriate metadata information
       reflectively, the JAM module system would treat it like other
       JAM's ModuleDefinitions.

In either case, the JAM module system could be used to instantiate and 
initialize Module/ClassLoader from the ModuleDefinition.


Creating a repository implementation is a different story. In the 
current draft API, you do need to override a number of methods in 
Repository in order to have a functional repository implementation. I 
still think Repository is the api for module systems to find 
ModuleDefinitions. The question is how we could change the API to make 
it much easier for developers to create custom repository implementation.

Perhaps we should provide more useful default implementation in the 
Repository's methods so developers only need to override very small 
number of methods. Or perhaps what we really need is a repository 
builder which allows developers to provide a set of ModuleDefinitions 
and get back a basic repository implementation to use.

I'll look into the draft API to see if further simplifications can be made.

- Stanley