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
