Updates on Interoperability

[Stanley M. Ho]

Hi experts,

As we discussed in the EG, we would like to make JSR 277 interoperable
with other module systems (e.g. OSGi, NetBeans, etc.). We have been
building prototypings to figure out how it should work and to also
validate the overall approach. Since there are many module systems out
there and they are all implemented very differently (there are also
multiple OSGi implementations), it requires us to build more than a few
prototypes and the whole process takes time.

The good news is that we now have a prototype that allows JSR 277
modules to interoperate with OSGi bundles in certain degrees, and
another prototype that enables interoperation with Maven. I'm in the
process of sorting out the details with the development team so we could
have a strawman for this EG to discuss soon.

- Stanley

[Sam Pullara-2]

Can you send out what our roadmap might look like so that we can  
understand what needs to be done to get this into JDK 7?

Sam

On Apr 2, 2008, at 10:27 PM, Stanley M. Ho wrote:

> Hi experts,
>
> As we discussed in the EG, we would like to make JSR 277  
> interoperable with other module systems (e.g. OSGi, NetBeans, etc.).  
> We have been building prototypings to figure out how it should work  
> and to also validate the overall approach. Since there are many  
> module systems out there and they are all implemented very  
> differently (there are also multiple OSGi implementations), it  
> requires us to build more than a few prototypes and the whole  
> process takes time.
>
> The good news is that we now have a prototype that allows JSR 277  
> modules to interoperate with OSGi bundles in certain degrees, and  
> another prototype that enables interoperation with Maven. I'm in the  
> process of sorting out the details with the development team so we  
> could have a strawman for this EG to discuss soon.
>
> - Stanley

[Daniel Leuck]

Hi Sam,

My two cents: It seems like OSGi and Maven would be enough.  I don't
think any other non-IDE system is widely used.  I assume Sun will have
NetBeans working with JSR-277 modules in short order.  I don't think
its important to spend a lot of time making JSR-277 interoperate with
a lot of other systems.  It should be the other way around.

Dan

On Wed, Apr 2, 2008 at 7:31 PM, Sam Pullara <sam@...> wrote:

> Can you send out what our roadmap might look like so that we can understand
> what needs to be done to get this into JDK 7?
>
> Sam
>
>
>
> On Apr 2, 2008, at 10:27 PM, Stanley M. Ho wrote:
>
> > Hi experts,
> >
> > As we discussed in the EG, we would like to make JSR 277 interoperable
> with other module systems (e.g. OSGi, NetBeans, etc.). We have been building
> prototypings to figure out how it should work and to also validate the
> overall approach. Since there are many module systems out there and they are
> all implemented very differently (there are also multiple OSGi
> implementations), it requires us to build more than a few prototypes and the
> whole process takes time.
> >
> > The good news is that we now have a prototype that allows JSR 277 modules
> to interoperate with OSGi bundles in certain degrees, and another prototype
> that enables interoperation with Maven. I'm in the process of sorting out
> the details with the development team so we could have a strawman for this
> EG to discuss soon.
> >
> > - Stanley
> >
>

--
Daniel Leuck
President
Ikayzo, inc.
[phone] (US Direct)
[phone] (Japan Direct)
[phone] (Mobile)
[phone] (Fax)
http://www.ikayzo.com
http://www.javaui.net

[Andy Piper]

Yes, my sentiments exactly. I wouldn't want a focus on a *breadth* of
systems to end up meaning that (a) nothing is done well or (b) this
slips out of Java 7.

As always OSGi is the most important to us and, I suspect, to the
majority also.
Its also the only one with an associated approved JCP standard, so it
would be interesting to know what platform specific issues have been
encountered.

andy

At 11:10 03/04/2008, Daniel Leuck wrote:

>Hi Sam,
>
>My two cents: It seems like OSGi and Maven would be enough.  I don't
>think any other non-IDE system is widely used.  I assume Sun will have
>NetBeans working with JSR-277 modules in short order.  I don't think
>its important to spend a lot of time making JSR-277 interoperate with
>a lot of other systems.  It should be the other way around.
>
>Dan
>
>On Wed, Apr 2, 2008 at 7:31 PM, Sam Pullara <sam@...> wrote:
> > Can you send out what our roadmap might look like so that we can understand
> > what needs to be done to get this into JDK 7?
> >
> > Sam
> >
> >
> >
> > On Apr 2, 2008, at 10:27 PM, Stanley M. Ho wrote:
> >
> > > Hi experts,
> > >
> > > As we discussed in the EG, we would like to make JSR 277 interoperable
> > with other module systems (e.g. OSGi, NetBeans, etc.). We have
> been building
> > prototypings to figure out how it should work and to also validate the
> > overall approach. Since there are many module systems out there
> and they are
> > all implemented very differently (there are also multiple OSGi
> > implementations), it requires us to build more than a few
> prototypes and the
> > whole process takes time.
> > >
> > > The good news is that we now have a prototype that allows JSR 277 modules
> > to interoperate with OSGi bundles in certain degrees, and another prototype
> > that enables interoperation with Maven. I'm in the process of sorting out
> > the details with the development team so we could have a strawman for this
> > EG to discuss soon.
> > >
> > > - Stanley
> > >
> >
>
>
>
>--
>Daniel Leuck
>President
>Ikayzo, inc.
>[phone] (US Direct)
>[phone] (Japan Direct)
>[phone] (Mobile)
>[phone] (Fax)
>http://www.ikayzo.com
>http://www.javaui.net

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

[Sam Pullara-2]

I meant so that JSR-277 would get into JDK 7 regardless of the  
decisions we make around interoperability. What I would like from  
Stanley is a list of things that the expert group needs to do and  
dates by when they need to be done to ensure that whatever choices are  
made actually make it into JSR-277.  There has been some question in  
the community as to whether or not JSR-277 would even make it into JDK  
7 based on the public schedule of the project.

Sorry about the confusion,
Sam

On Apr 3, 2008, at 3:28 AM, Andy Piper wrote:

> Yes, my sentiments exactly. I wouldn't want a focus on a *breadth* of
> systems to end up meaning that (a) nothing is done well or (b) this
> slips out of Java 7.
>
> As always OSGi is the most important to us and, I suspect, to the
> majority also.
> Its also the only one with an associated approved JCP standard, so it
> would be interesting to know what platform specific issues have been
> encountered.
>
> andy
>
> At 11:10 03/04/2008, Daniel Leuck wrote:
>> Hi Sam,
>>
>> My two cents: It seems like OSGi and Maven would be enough.  I don't
>> think any other non-IDE system is widely used.  I assume Sun will  
>> have
>> NetBeans working with JSR-277 modules in short order.  I don't think
>> its important to spend a lot of time making JSR-277 interoperate with
>> a lot of other systems.  It should be the other way around.
>>
>> Dan
>>
>> On Wed, Apr 2, 2008 at 7:31 PM, Sam Pullara <sam@...>  
>> wrote:
>>> Can you send out what our roadmap might look like so that we can  
>>> understand
>>> what needs to be done to get this into JDK 7?
>>>
>>> Sam
>>>
>>>
>>>
>>> On Apr 2, 2008, at 10:27 PM, Stanley M. Ho wrote:
>>>
>>>> Hi experts,
>>>>
>>>> As we discussed in the EG, we would like to make JSR 277  
>>>> interoperable
>>> with other module systems (e.g. OSGi, NetBeans, etc.). We have
>> been building
>>> prototypings to figure out how it should work and to also validate  
>>> the
>>> overall approach. Since there are many module systems out there
>> and they are
>>> all implemented very differently (there are also multiple OSGi
>>> implementations), it requires us to build more than a few
>> prototypes and the
>>> whole process takes time.
>>>>
>>>> The good news is that we now have a prototype that allows JSR 277  
>>>> modules
>>> to interoperate with OSGi bundles in certain degrees, and another  
>>> prototype
>>> that enables interoperation with Maven. I'm in the process of  
>>> sorting out
>>> the details with the development team so we could have a strawman  
>>> for this
>>> EG to discuss soon.
>>>>
>>>> - Stanley
>>>>
>>>
>>
>>
>>
>> --
>> Daniel Leuck
>> President
>> Ikayzo, inc.
>> [phone] (US Direct)
>> [phone] (Japan Direct)
>> [phone] (Mobile)
>> [phone] (Fax)
>> http://www.ikayzo.com
>> http://www.javaui.net
>
>
>
> Notice:  This email message, together with any attachments, may  
> contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  
> affiliated entities,  that may be confidential,  proprietary,  
> copyrighted  and/or legally privileged, and is intended solely for  
> the use of the individual or entity named in this message. If you  
> are not the intended recipient, and have received this message in  
> error, please immediately return this by email and then delete it.

[Stanley M. Ho]

Hi Sam,

I am in the process of writing the EDR2 spec and it should be ready for
the EG to review within the next few weeks. Once the spec is available,
I hope it will give the EG a clearer overall picture in terms of the
current JSR state. I will also provide a TODO list as you suggested.

- Stanley


Sam Pullara wrote:

> I meant so that JSR-277 would get into JDK 7 regardless of the decisions
> we make around interoperability. What I would like from Stanley is a
> list of things that the expert group needs to do and dates by when they
> need to be done to ensure that whatever choices are made actually make
> it into JSR-277.  There has been some question in the community as to
> whether or not JSR-277 would even make it into JDK 7 based on the public
> schedule of the project.
>
> Sorry about the confusion,
> Sam

[BJ Hargrave]

Java Community Process JSR #277 Expert List <JSR-277-EG@...> wrote on 2008/04/03 01:27:27 AM:

> [image removed]
>
> Updates on Interoperability
>
> Stanley M. Ho
>
> to:
>
> JSR-277-EG
>
> 2008/04/03 01:30 AM
>
> Sent by:
>
> Java Community Process JSR #277 Expert List <JSR-277-EG@...>
>
> Please respond to Java Community Process JSR #277 Expert List
> <JSR-277-EG@...>
>
> Hi experts,
>
> As we discussed in the EG, we would like to make JSR 277 interoperable
> with other module systems (e.g. OSGi, NetBeans, etc.). We have been
> building prototypings to figure out how it should work and to also
> validate the overall approach. Since there are many module systems out
> there and they are all implemented very differently (there are also
> multiple OSGi implementations), it requires us to build more than a few
> prototypes and the whole process takes time.

This is good news. I realize there are many OSGi implementations, but they all implement the OSGi spec. So the goal of OSGi interoperation must be aimed at the OSGi spec and not the various idiosyncrasies of the various implementations.
>
> The good news is that we now have a prototype that allows JSR 277
> modules to interoperate with OSGi bundles in certain degrees, and
> another prototype that enables interoperation with Maven. I'm in the
> process of sorting out the details with the development team so we could
> have a strawman for this EG to discuss soon.

Looking forward to it.

>
> - Stanley


--

BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance hargrave@...

office: [phone] mobile: [phone]

[brettporter]

On 03/04/2008, at 1:27 PM, Stanley M. Ho wrote:

> The good news is that we now have a prototype that allows JSR 277  
> modules to interoperate with OSGi bundles in certain degrees, and  
> another prototype that enables interoperation with Maven. I'm in the  
> process of sorting out the details with the development team so we  
> could have a strawman for this EG to discuss soon.

With my Maven hat on, this sounds quite interesting. Is there any  
update on the availability of this for discussion?

Thanks,
Brett

--
Brett Porter
brett@...
http://blogs.exist.com/bporter/

[Bryan Atsatt]

Nice to see some movement here Stanley! I've been thinking a bit about
this issue, and tried to summarize that here:

http://atsatt.blogspot.com/2008/04/jsr-277-interoperation.html

Do folks generally agree with this characterization? Does anyone think
I've grossly misstated the situation, or left out anything important?

// Bryan


Stanley M. Ho wrote:

> Hi experts,
>
> As we discussed in the EG, we would like to make JSR 277 interoperable
> with other module systems (e.g. OSGi, NetBeans, etc.). We have been
> building prototypings to figure out how it should work and to also
> validate the overall approach. Since there are many module systems out
> there and they are all implemented very differently (there are also
> multiple OSGi implementations), it requires us to build more than a
> few prototypes and the whole process takes time.
>
> The good news is that we now have a prototype that allows JSR 277
> modules to interoperate with OSGi bundles in certain degrees, and
> another prototype that enables interoperation with Maven. I'm in the
> process of sorting out the details with the development team so we
> could have a strawman for this EG to discuss soon.
>
> - Stanley
>

[Gordon Hirsch]

Bryan Atsatt wrote:
>  I've been thinking a bit about
> this issue, and tried to summarize that here:
>
> http://atsatt.blogspot.com/2008/04/jsr-277-interoperation.html
>
> Do folks generally agree with this characterization? Does anyone think
> I've grossly misstated the situation, or left out anything important?

Hi Bryan,

Great summary. I generally agree with your characterization of
interoperability. This degree of interoperability, at least with OSGi,
is necessary to make JSR 277 a success.

It's true, as you mention, that much of the "interoperability story is
already present in the spec". However, I think there's good reason to
wonder how achievable that story actually is. That's why it has been
disappointing to wait so long for something concrete. It's encouraging
to read that we'll see something soon.

You mention that resolution requires each implementation to:

> 1. Map its dependency declarations into a standard runtime representation.
> 2. Support a standard search model over its stored modules, using the runtime dependency expressions.
> 3. Map its stored module data into a standard runtime representation that can be returned by the search.

One challenge lies in defining the "standard runtime representations"
and "standard search model" in a universal enough way to encompass OSGi
and other module systems. This implies embracing concepts (in these
standard representations and search model) that were not universally
liked by the EG early on. (Split packages and package-level
import/export come to mind.)

[Richard S. Hall]

Gordon Hirsch wrote:

>> 1. Map its dependency declarations into a standard runtime
>> representation.
>> 2. Support a standard search model over its stored modules, using the
>> runtime dependency expressions.
>> 3. Map its stored module data into a standard runtime representation
>> that can be returned by the search.
>
> One challenge lies in defining the "standard runtime representations"
> and "standard search model" in a universal enough way to encompass
> OSGi and other module systems. This implies embracing concepts (in
> these standard representations and search model) that were not
> universally liked by the EG early on. (Split packages and
> package-level import/export come to mind.)

Package-level import/export seem like a must, but I still don't see
split packages as a necessity.

-> richard

[Bryan Atsatt]

Richard S. Hall wrote:

> Gordon Hirsch wrote:
>>> 1. Map its dependency declarations into a standard runtime
>>> representation.
>>> 2. Support a standard search model over its stored modules, using
>>> the runtime dependency expressions.
>>> 3. Map its stored module data into a standard runtime representation
>>> that can be returned by the search.
>>
>> One challenge lies in defining the "standard runtime representations"
>> and "standard search model" in a universal enough way to encompass
>> OSGi and other module systems. This implies embracing concepts (in
>> these standard representations and search model) that were not
>> universally liked by the EG early on. (Split packages and
>> package-level import/export come to mind.)
>
> Package-level import/export seem like a must, but I still don't see
> split packages as a necessity.

Strongly agreed on import-by-package, and that ModuleDefinition requires
a method to enumerate exported packages (and probably an
exportsPackage(String packageName) method to enable an efficient Query).

On the split package front, however, it seems a little fuzzy to me. If
an OSGi implementation of 277 is also going to remain OSGi Rx compliant,
it will still need to support split packages, right? If so, don't we
need to surface this fact at the 277 level? Perhaps that is as simple as
acknowledging that Module.getImportedModules() may return more than one
instance that exports a given package.

// Bryan

[Richard S. Hall]

Bryan Atsatt wrote:

> Richard S. Hall wrote:
>> Gordon Hirsch wrote:
>>>> 1. Map its dependency declarations into a standard runtime
>>>> representation.
>>>> 2. Support a standard search model over its stored modules, using
>>>> the runtime dependency expressions.
>>>> 3. Map its stored module data into a standard runtime
>>>> representation that can be returned by the search.
>>>
>>> One challenge lies in defining the "standard runtime
>>> representations" and "standard search model" in a universal enough
>>> way to encompass OSGi and other module systems. This implies
>>> embracing concepts (in these standard representations and search
>>> model) that were not universally liked by the EG early on. (Split
>>> packages and package-level import/export come to mind.)
>>
>> Package-level import/export seem like a must, but I still don't see
>> split packages as a necessity.
> Strongly agreed on import-by-package, and that ModuleDefinition
> requires a method to enumerate exported packages (and probably an
> exportsPackage(String packageName) method to enable an efficient Query).
> On the split package front, however, it seems a little fuzzy to me. If
> an OSGi implementation of 277 is also going to remain OSGi Rx
> compliant, it will still need to support split packages, right? If so,
> don't we need to surface this fact at the 277 level? Perhaps that is
> as simple as acknowledging that Module.getImportedModules() may return
> more than one instance that exports a given package.

That all depends on if the 277 API is a subset of OSGi functionality or
equal to it, I suppose.

-> richard
>
> // Bryan

[Gordon Hirsch]

Bryan Atsatt wrote:
>
> On the split package front, however, it seems a little fuzzy to me. If
> an OSGi implementation of 277 is also going to remain OSGi Rx compliant,
> it will still need to support split packages, right?

Yes, and, like it or not, split packages are common enough that it may
be hard to completely ignore them wrt to interoperability.

  If so, don't we
> need to surface this fact at the 277 level? Perhaps that is as simple as
> acknowledging that Module.getImportedModules() may return more than one
> instance that exports a given package.

This is the case I was thinking of.

Also, IIRC, OSGi allows the specification of additional attributes on
Import-Package statements which can be used to help disambiguate the
import in the presence of split packages. Does this facility get
surfaced to the standard search mechanism? If features at this level are
involved, this is where I begin to become concerned about the complexity
of our task :-).

[Sam Pullara-2]

Did we decide which way it will be compatible?  I'm a little concerned  
that implementing something that can use OSGi modules is a far bigger  
task that implementing something that OSGi can use.  If we are going  
for total compatibility it seems like we should just use OSGi.  
Personally I wanted something in Java that was simpler and cleaner  
that OSGi-users could leverage if they wanted.  But I'm coming at this  
from the we-need-something-like-maven/gem/ivy camp.

The vast majority of people that are going to use this system will  
have never heard of OSGI nor care about any of their more subtle  
features and just want an easy way to leverage the vast amount of  
libraries available (virtually all of them are not OSGi modules today  
but are jar files in maven repositories).  We shouldn't be specing out  
some sort of uber container but rather a simple way to tie code to its  
dependencies.

I strongly suggest KISS applies to our effort.  I write this knowing  
that the committee seems to be heavily in favor of this alternate view  
that we implement the kitchen sink.

Sam

On Apr 25, 2008, at 1:57 PM, Richard S. Hall wrote:

> Bryan Atsatt wrote:
>> Richard S. Hall wrote:
>>> Gordon Hirsch wrote:
>>>>> 1. Map its dependency declarations into a standard runtime  
>>>>> representation.
>>>>> 2. Support a standard search model over its stored modules,  
>>>>> using the runtime dependency expressions.
>>>>> 3. Map its stored module data into a standard runtime  
>>>>> representation that can be returned by the search.
>>>>
>>>> One challenge lies in defining the "standard runtime  
>>>> representations" and "standard search model" in a universal  
>>>> enough way to encompass OSGi and other module systems. This  
>>>> implies embracing concepts (in these standard representations and  
>>>> search model) that were not universally liked by the EG early on.  
>>>> (Split packages and package-level import/export come to mind.)
>>>
>>> Package-level import/export seem like a must, but I still don't  
>>> see split packages as a necessity.
>> Strongly agreed on import-by-package, and that ModuleDefinition  
>> requires a method to enumerate exported packages (and probably an  
>> exportsPackage(String packageName) method to enable an efficient  
>> Query).
>> On the split package front, however, it seems a little fuzzy to me.  
>> If an OSGi implementation of 277 is also going to remain OSGi Rx  
>> compliant, it will still need to support split packages, right? If  
>> so, don't we need to surface this fact at the 277 level? Perhaps  
>> that is as simple as acknowledging that Module.getImportedModules()  
>> may return more than one instance that exports a given package.
>
> That all depends on if the 277 API is a subset of OSGi functionality  
> or equal to it, I suppose.
>
> -> richard
>>
>> // Bryan

[Richard S. Hall]

Gordon Hirsch wrote:

> Bryan Atsatt wrote:
>>
>> On the split package front, however, it seems a little fuzzy to me. If
>> an OSGi implementation of 277 is also going to remain OSGi Rx compliant,
>> it will still need to support split packages, right?
>
> Yes, and, like it or not, split packages are common enough that it may
> be hard to completely ignore them wrt to interoperability.
>
>  If so, don't we
>> need to surface this fact at the 277 level? Perhaps that is as simple as
>> acknowledging that Module.getImportedModules() may return more than one
>> instance that exports a given package.
>
> This is the case I was thinking of.
>
> Also, IIRC, OSGi allows the specification of additional attributes on
> Import-Package statements which can be used to help disambiguate the
> import in the presence of split packages. Does this facility get
> surfaced to the standard search mechanism? If features at this level
> are involved, this is where I begin to become concerned about the
> complexity of our task :-).

Well, the attributes really have nothing to do with split packages,
although the recommendation is to use mandatory attributes on split
packages to avoid importers from accidentally getting wired to a partial
package.

We can go down this path, but I doubt it will be as simple as just
changing getImportedModules() to return an array...

-> richard

[Stanley M. Ho]

Hi Brett,

We are in the process of finalizing the document, and hopefully we could
provide more details to the EG next week.

- Stanley


Brett Porter wrote:

> On 03/04/2008, at 1:27 PM, Stanley M. Ho wrote:
>
>> The good news is that we now have a prototype that allows JSR 277
>> modules to interoperate with OSGi bundles in certain degrees, and
>> another prototype that enables interoperation with Maven. I'm in the
>> process of sorting out the details with the development team so we
>> could have a strawman for this EG to discuss soon.
>
> With my Maven hat on, this sounds quite interesting. Is there any update
> on the availability of this for discussion?
>
> Thanks,
> Brett
>
> --
> Brett Porter
> brett@...
> http://blogs.exist.com/bporter/

[Stanley M. Ho]

The current APis do not prohibit module definition to have split
packages. It is only when a Java module is instantiated from the module
definition, the implementation of the default module system would
perform shallow validation and consider split packages as an error.
Other module system implementations can continue to have their own
validation policies to resolve their modules.

I hope this will become more clear when the details are available next week.

- Stanley


Bryan Atsatt wrote:

> Richard S. Hall wrote:
>> Gordon Hirsch wrote:
>>>> 1. Map its dependency declarations into a standard runtime
>>>> representation.
>>>> 2. Support a standard search model over its stored modules, using
>>>> the runtime dependency expressions.
>>>> 3. Map its stored module data into a standard runtime representation
>>>> that can be returned by the search.
>>>
>>> One challenge lies in defining the "standard runtime representations"
>>> and "standard search model" in a universal enough way to encompass
>>> OSGi and other module systems. This implies embracing concepts (in
>>> these standard representations and search model) that were not
>>> universally liked by the EG early on. (Split packages and
>>> package-level import/export come to mind.)
>>
>> Package-level import/export seem like a must, but I still don't see
>> split packages as a necessity.
> Strongly agreed on import-by-package, and that ModuleDefinition requires
> a method to enumerate exported packages (and probably an
> exportsPackage(String packageName) method to enable an efficient Query).
> On the split package front, however, it seems a little fuzzy to me. If
> an OSGi implementation of 277 is also going to remain OSGi Rx compliant,
> it will still need to support split packages, right? If so, don't we
> need to surface this fact at the 277 level? Perhaps that is as simple as
> acknowledging that Module.getImportedModules() may return more than one
> instance that exports a given package.
>
> // Bryan

[Richard S. Hall]

Sam Pullara wrote:

> Did we decide which way it will be compatible?  I'm a little concerned
> that implementing something that can use OSGi modules is a far bigger
> task that implementing something that OSGi can use.  If we are going
> for total compatibility it seems like we should just use OSGi.  
> Personally I wanted something in Java that was simpler and cleaner
> that OSGi-users could leverage if they wanted.  But I'm coming at this
> from the we-need-something-like-maven/gem/ivy camp.
>
> The vast majority of people that are going to use this system will
> have never heard of OSGI nor care about any of their more subtle
> features and just want an easy way to leverage the vast amount of
> libraries available (virtually all of them are not OSGi modules today
> but are jar files in maven repositories).  We shouldn't be specing out
> some sort of uber container but rather a simple way to tie code to its
> dependencies.

If this is all that people wanted, then we could just define
repositories and associated metadata and forget about all runtime
modularity support, but I strongly disagree that this is all people want
or else there wouldn't be such an upsurge in OSGi interest and adoption.

> I strongly suggest KISS applies to our effort.  I write this knowing
> that the committee seems to be heavily in favor of this alternate view
> that we implement the kitchen sink.

I think our interest is similar, but perhaps our conclusions are
different. Initially, I think my comments were construed as an argument
against split packages in general, but I am really arguing the same as
you (I think) that we don't really need split packages to be a concept
in our "interoperability API", if that is how we are to view the 277
API. Of course, I am also willing to have the former argument too, but I
will leave that for another time. :-)

 From my point of view, I do not think it is wholly reasonable to assume
that we want to try to accomplish interoperability across module
systems, where that includes arbitrarily sharing split packages across
module systems.

Let me try to accurately conjure the peculiarities of split packages in
the OSGi module layer...

We support split packages in two ways, via required bundles (i.e.,
module dependencies) and via bundle fragments. In general, we recommend
that if you split your packages that you attach mandatory attributes on
them so that importers do not get them by mistake. By requiring a
bundle, you can ignore mandatory attributes and get everything a bundle
has to offer and combine it with other required bundles that might be
exporting other parts of the split packages. Given this, there is a
semi-reasonable chance* that we can tell you which bundles are
contributing to the "complete" packages, but we have no way of knowing
if/when combined split packages are complete. Further, we have to assume
that split package parts offered by different bundles do not overlap,
because if we allowed them to overlap then we would have shadowing and
ordering issues. Again we have no easy way to verify that they do not
overlap, so we just assume they don't.

Fragments on the other hand are a little trickier, since split packages
from them are loaded from the same class loader to provide package
private access (which is not afforded for split packages in the require
bundle approach). The "host" bundle doesn't really know about fragments
and it is possible for fragments to shadow or extend packages in the
"host" bundle. Since fragments provide their split packages in an
implicit way (i.e., they largely just become part of the host bundle's
class path), there is no easy way to determine if a fragment is
contributing to a given package or not. (* This feature of fragments
also makes it so it is not really possible to know who is contributing
classes to a split package in the require bundle case.)

I think that is fairly complete description of the situation, sorry if
it is somewhat terse. In summary, I wouldn't assume that we can get
reasonable interoperability at this level. If you need these types of
features, then you should stick to a single modularity
framework...preferably OSGi. ;-)

But my overall point is, I believe that if we can support
interoperability at module- and package-level dependencies across module
systems, then I think we would hit most use cases.

-> richard

>
> Sam
>
> On Apr 25, 2008, at 1:57 PM, Richard S. Hall wrote:
>
>> Bryan Atsatt wrote:
>>> Richard S. Hall wrote:
>>>> Gordon Hirsch wrote:
>>>>>> 1. Map its dependency declarations into a standard runtime
>>>>>> representation.
>>>>>> 2. Support a standard search model over its stored modules, using
>>>>>> the runtime dependency expressions.
>>>>>> 3. Map its stored module data into a standard runtime
>>>>>> representation that can be returned by the search.
>>>>>
>>>>> One challenge lies in defining the "standard runtime
>>>>> representations" and "standard search model" in a universal enough
>>>>> way to encompass OSGi and other module systems. This implies
>>>>> embracing concepts (in these standard representations and search
>>>>> model) that were not universally liked by the EG early on. (Split
>>>>> packages and package-level import/export come to mind.)
>>>>
>>>> Package-level import/export seem like a must, but I still don't see
>>>> split packages as a necessity.
>>> Strongly agreed on import-by-package, and that ModuleDefinition
>>> requires a method to enumerate exported packages (and probably an
>>> exportsPackage(String packageName) method to enable an efficient
>>> Query).
>>> On the split package front, however, it seems a little fuzzy to me.
>>> If an OSGi implementation of 277 is also going to remain OSGi Rx
>>> compliant, it will still need to support split packages, right? If
>>> so, don't we need to surface this fact at the 277 level? Perhaps
>>> that is as simple as acknowledging that Module.getImportedModules()
>>> may return more than one instance that exports a given package.
>>
>> That all depends on if the 277 API is a subset of OSGi functionality
>> or equal to it, I suppose.
>>
>> -> richard
>>>
>>> // Bryan

[Sam Pullara-2]

On Apr 25, 2008, at 4:46 PM, Richard S. Hall wrote:

> Sam Pullara wrote:
>> The vast majority of people that are going to use this system will  
>> have never heard of OSGI nor care about any of their more subtle  
>> features and just want an easy way to leverage the vast amount of  
>> libraries available (virtually all of them are not OSGi modules  
>> today but are jar files in maven repositories).  We shouldn't be  
>> specing out some sort of uber container but rather a simple way to  
>> tie code to its dependencies.
>
> If this is all that people wanted, then we could just define  
> repositories and associated metadata and forget about all runtime  
> modularity support, but I strongly disagree that this is all people  
> want or else there wouldn't be such an upsurge in OSGi interest and  
> adoption.

I guess that is what I am arguing for.  I don't see the critical need,  
outside the internals of application servers and a very few plugin  
based tools, for runtime modularity support.  And if OSGi can load a  
JSR-277 module then I feel like the interoperability job is done.

Sam