[jboss-as7-dev] Fwd: Late for the train

[Thomas Diesler]

 > a 1 to 1 mapping from a jar (which is the unit of release) to a 
"module identification" (which is the unit of reuse)

Yes, if you use a system of "module identification" to build a wiring 
graph this is important. I claim that this approach is flawed for 
complex systems where the provider of moduleA does not know about 
moduleB. Perhaps you like to show a solution to the simple problem that 
I mentioned?

Here it is again: pluginA has a requirement on libraryX-1.0.0 and 
pluginB has a requirement on libraryX-1.1.0. How do you propose that 
libraryX is distributed in the target system?

On 07/27/2012 11:48 AM, Geoffrey De Smet wrote:
> Op 27-07-12 11:22, Thomas Diesler schreef:
>> Geoffrey,
>>
>> > unlike OSGi - the unit of reuse is the unit of release
> Let me clarify that concept, as you're interpreting it very 
> differently than me.
>
> It just means: We are releasing "jars", so there must be a 1 to 1 
> mapping from a jar (which is the unit of release) to a "module 
> identification" (which is the unit of reuse).
> Unlike OSGi, a single jar, for example "foo.jar", can not export 2 or 
> more module identifications, such as "org.foo:bar1" and "org.foo:bar2".
> Instead, it exports only 1 module identification, for example 
> "org.foo:foo".
> (For simplicity I am ignoring versions in the example above).
>
> This is important, because client-modules declare their dependencies 
> using module identifications.
> In your example:
> pluginA depends on libraryX 1.0.0
> pluginB depends on libraryX 1.1.0
> That means there should be exactly 1 libraryX-1.0.0.jar and exactly 1 
> libraryX-1.1.0.jar.
> In OSGi, libraryX-1.0.0 could as well be in the pluto-5.0.0.jar, 
> intermingled with the modules libraryY-2.0.0 and libraryZ-1.2.0.
> And libraryX-1.1.0 could be in the saturn-0.1.0.jar, intermingled with 
> the module libraryZ-1.0.0.
>
> More info here:
>   libraryX-1.0.0 could as well be in the pluto-5.0.0.jar, intermingled 
> with the modules libraryY-2.0.0 and libraryZ-1.2.0.
>>
>> in an ecosystem of distributed module providers, how can one provider 
>> reason about the requirements of another provider such that their 
>> requirements converge? Any complex system that has the notion of 
>> plugin would face this problem. For example, pluginA has a 
>> requirement on libraryX-1.0.0 and pluginB has a requirement on 
>> libraryX-1.1.0. How do you propose that libraryX is distributed in 
>> the target system?
>>
>> Here some options:
>>
>> #1 libraryX is available in both versions. pluginA/B bind to their 
>> respective versions
>> #2 libraryX is available in the highest compatible version (i.e. 
>> libraryX-1.1.0). pluginA/B bind to that
>>
>> The problem with #1 is that it fails (is inconsistent) as soon as 
>> pluginA/B exchange a type from libraryX - you get a CCE
>> The problem with #2 is that you have to touch pluginA's wiring 
>> metadata - which contradicts "unit of reuse is the unit of release".
> No, it doesn't: the "unit of reuse is the unit of release" restriction 
> states nothing when dependencies should be resolved and whether or not 
> it can be overwritten at runtime.
>> pluginA must know that pluginB exists, which it cannot because A/B 
>> may be installed independently on user request.
>>
>> ...
>>
>> In a nutshell: "unit of reuse is the unit of release" is too 
>> simplistic for complex modularity systems
> No, see clarification of this principle above.
>
> With kind regards,
> Geoffrey De Smet
>>
>> cheers
>> -thomas
>>
>>
>> On 07/18/2012 09:07 AM, Geoffrey De Smet wrote:
>>> From what I 've read so far about Jigsaw, I like it.
>>> It would have consistent resolution (unlike OSGi - the unit of reuse 
>>> is the unit of release),
>>> it would be straightforward (unlike Maven -  there would be no 
>>> "Maven dependency puzzlers").
>>> And it would allow for runtime optimization.
>>> So basically, it would be JBoss modules ;)
>>>
>>> Anything particular why it would be a train wreck?
>>>
>>> With kind regards,
>>> Geoffrey De Smet
>>>
>>> Op 17-07-12 18:11, David M. Lloyd schreef:
>>>> This is actually great news for us... Jigsaw is a train wreck.  
>>>> Maybe we'll have a chance to get in this game after all.
>>>>
>>>> -------- Original Message --------
>>>> Subject: Late for the train
>>>> Date: Tue, 17 Jul 2012 08:57:39 -0700
>>>> From: mark.reinhold at oracle.com
>>>> To: jigsaw-dev at openjdk.java.net
>>>>
>>>> As some of you are already aware, I've concluded with regret that 
>>>> Project
>>>> Jigsaw isn't going to make Java 8 as planned.  I've set out my 
>>>> reasoning
>>>> in a blog entry [1], and I've asked the Java SE 8 EG to consider 
>>>> dropping
>>>> the module system and modularization from the release [2].
>>>>
>>>> Slipping Jigsaw to Java 9 isn't an easy decision, but I think it's the
>>>> best of a set of unpleasant options.  We've made a lot of progress 
>>>> over
>>>> the past year, and I'm determined that we do our best to maintain our
>>>> momentum from here to Java 9.  I thank those who've contributed to 
>>>> this
>>>> effort so far, in ways both large and small, and I hope you'll all be
>>>> able to stay aboard for the rest of the journey.
>>>>
>>>> - Mark
>>>>
>>>>
>>>> [1] http://mreinhold.org/blog/late-for-the-train
>>>> [2] 
>>>> http://mail.openjdk.java.net/pipermail/java-se-8-spec-observers/2012-July/000001.html
>>>>
>>>
>>>
>>
>

-- 
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx