Updates on Interoperability

[Sam Pullara]

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