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

[Thomas Diesler]

 > it could run both X-1.0.0 and X-1.1.0 simultaneously

Well said. It (the resolver) could! It is not the responsibility or 
either pluginA nor pluginB to provide the wiring metadata. Nor can this 
decision (based on module identity) be made at build time.

On 07/27/2012 12:21 PM, Geoffrey De Smet wrote:
> Op 27-07-12 12:04, Thomas Diesler schreef:
>> > 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?
> I am sorry, I don't see the distribution problem.
>
> The distribution system could use the same principle of RPM's and 
> Maven (which both follow the release/reuse principle):
> Grab the artifact from a repository and put it into a local cache of 
> that repository (which might be zipped into the release zip of pluginA).
> Both libraryX-1.0.0.jar and libraryX-1.1.0.jar are in that local cache 
> of that repository.
> The advantage of "reuse/release" principle is, based on a moduleId, 
> the jar can easily and unambiguously found in a repository.
>
> It's up to the "conflict resolution" and "classpath/modulepath" specs 
> to decide how to deal with the obvious version conflict in your example.
> In a modulepath world (= a graph of dependencies, just like Maven and 
> OSGi), it could run both X-1.0.0 and X-1.1.0 simultaneously (if 
> pluginA and pluginB don't communicate to each other with X).
>
> With kind regards,
> Geoffrey De Smet
>>
>> 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