a 1 to 1 mapping from a jar (which is the unit of release) to a

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... >>> >> >> >