Goals was: Re: Supporting OSGi Bundles in the Java Module System
abrock at REDHAT.COM
Tue Jun 10 04:28:12 PDT 2008
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
On Fri, 2007-02-16 at 13:08 -0800, Stanley M. Ho wrote:
> 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
> On Fri, 2007-01-12 at 09:49 +0000, Glyn Normington wrote:
> > Michal Cierniak <cierniak at GOOGLE.COM> 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
> 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
> too, especially if anyone needs to create a hybrid application
> modules of both sorts.)
My critisms of using the JSR277 repositories to do the integration
* There are already lots of orthogonal reasons for swapping
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
* 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
> > 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
JBoss, a division of Red Hat
More information about the jsr277-eg-observer