On Wed, 2008-06-11 at 22:31 -0700, Stanley M. Ho wrote: > 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. >
The comments I included were from discussions (a year ago) before the current api changes, so some parts maybe out-of-date. > > * 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? 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. -- xxxxxxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Chief Scientist JBoss, a division of Red Hat xxxxxxxxxxxxxxxxxxxxxxxxxxxx
