Relationship to JSR 291 [was: Re: Bryan's comments]

[Bryan Atsatt]

Let me try to focus this discussion. What I am aiming for here is
conceptually simple:

Don't force a specific interpretation of the import String in the 277 *API*.

So, for example, change:

    String ImportDependency.getModuleName()

to

    String ImportDependency.getImportName();

Each ModuleSystem is then free to interpret that name as appropriate.

Sure, this leaves room for *mis*interpretation. So let's figure out a
way to avoid that (e.g. define a syntax such that the string is
self-describing).

(I'm off for till Tuesday, so I'll tune back in then :^)

// Bryan

Richard S. Hall wrote:
> Stanley M. Ho wrote:
>> Hi Bryan,
>>
>> Bryan Atsatt wrote:
>>> Let me clarify. It is my assumption that 277 will provide both an
>>> API/framework *and* a specific ModuleSystem implementation. And that
>>> OSGi will be able to supply another ModuleSystem implementation:
>>>
>>>        277 API/Framework
>>>         /           \
>>>        /             \
>>>   277ModuleSystem   OSGiModuleSystem
>>
>> Right. There are also other module systems that can be plugged into this
>> framework, e.g. NetBeans.
>>
>>> Therefore, the API's must *support* "import package", or it will not be
>>> usable by the OSGiModuleSystem.
>>>
>>> I agree that the 277ModuleSystem implementation does not need to support
>>> "import package" semantics. Which means that the 277 APIs must support
>>> *both* semantics.
>>>
>>> Otherwise, OSGi will not be able to operate as a first-class citizen in
>>> the 277 world.
>>>
>>> And, if 294 adds support for "import", it should at least do the natural
>>> thing of "import package". And it should also support "import module",
>>> but supporting both at the language level may be awkward.
>>>
>>> // Bryan
>>
>> I think we all agreed that the module system defined by JSR 277 does not
>> need to support import package. As far as I am aware (correct me if I'm
>> wrong), all the existing systems support import at the module level, and
>> OSGi is the only one that supports import at the package level. Thus,
>> import by package should be a feature specific to the OSGi specific
>> module system implementation (e.g. OSGiModuleDefinition), and I don't
>> think it is necessary to push it into the base classes in JSR 277.
>
> Well, I must at least say that this is flawed logic at best. The fact
> that only the OSGi framework supports importing packages does not say
> anything about whether or not it should be supported by 277 or not.
> There any many valid arguments why the import package model is better
> due to the fact the is declares "what" is needed, not "who" contains
> what is needed.
>
> Using "who" instead of "what" generally leads to terrible dependency
> fanout due to coarse-grained module definitions and brittleness. I am
> fairly certain that I could conjure up some people who could tell you
> stories about the horrors of the brittleness of the module dependency
> approach when trying to re-use modules for different purposes. However,
> I guess this is beside the point...
>
> I think the real argument that should be made for not necessarily
> including import package support is along the lines of what I was saying
> in my other message, which is that we should keep 277 as simple as
> possible.
>
>> This doesn't mean supporting the notion of import by package is
>> impossible. What OSGi will expose from its repository is simply module
>> definitions, and module definition is basically an abstraction.
>> Therefore, it should be possible to treat an OSGi bundle as a module
>> definition, as well as to treat each exported package in an OSGi bundle
>> a module definition as well. The dependency supported in JSR 277 is
>> import-by-module. In the JSR 277 module system, this is mapped to
>> import-by-superpackage. In the OSGi module system, this can be mapped to
>> import-by-OSGi-bundle or import-by-package. If other module systems want
>> to support different import granularity or if OSGi evolves to add new
>> import granularity in the future, this model should still work.
>>
>> Honestly, interoperability between multiple module systems with "import
>> module" alone is already a hard enough problem for us to solve. I am
>> concerned that we're making this problem towards insolvable if we keep
>> adding complexity. ;)
>
> Agreed, but I think part of the reason that there is an urge to push
> such features into the core is because there is already feature creep in
> the core that gives people the impression that we are redefining OSGi
> modularity, NetBeans modularity, etc. Thus, everyone wants to make sure
> their pet feature is added. If 277 could make a stand and declare that
> it is at a layer beneath all of that (and live up to that declaration),
> then there would likely be less push down.
>
> -> richard
>