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

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(a)oracle.com >>>>> To: jigsaw-dev(a)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... >>>>> >>>> >>>> >>> >> >