[In regards to original question, -0.0 (harmless, but pointless, since applications should not use lang as a jpms module. To be usable as a jpms module, EVERY release that has ANY api change must use new module and package names).[1] ]
Since all dependencies have to be shad(e|ow)ed (and not exported) when using jigsaw, it's not too much of a hassle to do a ½-assed job. The only thing that might take a bit more work is if you want to have extra support for services. I haven't checked if there's a non-beta release, but ASM 6 has had support for the new module-info class format stuff for a year or so (Remy Forax being on the jpms EG). For custom tooling there's no real win in using module-info.java as input (there was no real point in putting the metadata in .java and .class files in the first place 🤦♂️). JSON would be one good lazy mode; this could also be used to generate the .java file. Another possibility is to derive module-info data from bundles. The metadata can be extracted fairly easily using bndlib. This would be more complicated if there were imports, but since the only modules commons projects can safely import are the non-default jdk ones (and possibly not even all of those), it's essy to use a static map (which can be pretty much generated from jmod/jdep). Simon [1] A module can only appear in the modpath once. A package can only come from one module. If an application uses multiple third party dependencies, which use different versions of a fourth party module, "*Lasciate ogne speranza, voi ch'intrate".* On Oct 16, 2017 5:57 AM, "sebb" <seb...@gmail.com> wrote: > On 16 October 2017 at 10:34, Emmanuel Bourg <ebo...@apache.org> wrote: > > Le 14/10/2017 à 14:43, Benedikt Ritter a écrit : > > > >> I’d like to hear opinions on this change. > > > > I wonder if we could somehow write a module-info.java compiler that > > works with older version of Java. The syntax doesn't look terribly > > complicated after all. It could be invoked from a plugin hooked to the > > compile phase. > > Or skip the files if compiling with an older Java version? > > > Emmanuel Bourg > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
