On Mon, 2008-04-28 at 20:16 -0700, Stanley M. Ho wrote: > 2. Requirements > 1. It shall be possible for an OSGi container to implement the > Java Module System. > 2. It shall be possible for a JAM module to express an import > dependency on any Module Definition in any Java Module System.
These goals appear to have changed from the ones we agreed? I am misreading it or is this document only expressing one side of the equation? On Fri, 2007-02-16 at 13:08 -0800, Stanley M. Ho wrote: > Goals: > > 1. It shall be possible for JSR-277 modules to make use of modules from > other module systems (e.g. JSR-291) (i.e. if other module systems expose > their modules as JSR-277 modules through a repository implementation.) > > 2. It shall be possible for other module systems (e.g. JSR-291) to be > implemented on top of the JSR-277 APIs such that the modules from other > module system can make use of JSR-277 modules. > I originally read (2) as a rewording of Glynn's original definition where the goal is to create a more peer orientated delegation. > On Fri, 2007-01-12 at 09:49 +0000, Glyn Normington wrote: > > Michal Cierniak <[EMAIL PROTECTED]> wrote on 09/01/2007 20:20:12: > > Co[u]ld you write a one-paragraph outline of what "first class > > interoperation with JSR 291" would mean? > > First class interoperation with JSR 291 means that JSR 291 > implementations > should be implementable on top of Java 7 APIs such that JSR 291 > bundles can > make effective use of JSR 277 modules and vice versa. > > (I guess JSR 291 modules residing in JSR 277 repositories would be > helpful > too, especially if anyone needs to create a hybrid application > containing > modules of both sorts.) My critisms of using the JSR277 repositories to do the integration included: * 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 > 2) Model - parent/child or peer > 3) QoS - what tools are available for the repository > 4) Location - file system/url based, etc. > 5) Delegation - links to standard repositories > etc. * Developing a full repository just to define a different archive format is too much (e.g. legacy javaee deployments) On Wed, 2007-02-28 at 17:12 +0100, Adrian wrote: On Mon, 2007-02-26 at 18:05 -0800, Stanley M. Ho wrote: > > If I understand you correctly, your primary concern is around > requiring > > other module systems which support 277 modules that are stored > > differently (e.g. war, ear, etc.) to implement the classloading and > > other functionalities from scratch. Is this accurate? > > Not just that, anybody that wants to integrate their own > packaging format and construct module definition (wrappers) > should be able to plugin without dictating > or developing a full repository. > > The examples so far discussed are: > OSGi modules > JavaEE deployment packages * The concern about hierarchical integration On Wed, 2007-02-28 at 17:18 +0100, Adrian wrote: > On Mon, 2007-02-26 at 18:05 -0800, Stanley M. Ho wrote: > > Hi Adrian, > > > > > The hierarchical assumption of repositories makes it difficult > > > to plugin peer modules, unless we are going to define > > > a composite repository for this purpose. > > > > Can you give me an example of peer modules that you are concerned with? > > > > It is really peer module systems. > > e.g. My repository is made up of modules from > > 1) a local JSR77 repository > 2) an OSGi repository handled by my OSGi "module system" > 3) Some JavaEE deployments handled by the appserver's "module system" > 4) a link to a repository on the internet > > I want my JavaEE modules to be able to use OSGi modules > and vice versa OSGi modules should be able to use my JavaEE modules > (e.g. an appclient or a resource adapter) > > This requires a peer integration at the classloader and security > level. -- xxxxxxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Chief Scientist JBoss, a division of Red Hat xxxxxxxxxxxxxxxxxxxxxxxxxxxx
