maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Glick <>
Subject Re: Maven and JigSaw thoughts
Date Mon, 24 Oct 2011 19:40:11 GMT
On 10/22/2011 05:00 AM, Mark Struberg wrote:
> there is atm a strict 1:1 between a Modul and a ClassLoader.

This would not be true for the special case of JDK modules (what is now rt.jar + tools.jar);
probably TBD whether "user" modules will be permitted to share class loaders 
for ease of migration of legacy apps. But in general, yes, each module would be associated
with its own loader at runtime.

> modules which need multiple classloaders (like EARs) or a specific deployment task (like

As far as I know, Java EE is not supported by the current Jigsaw work.

> A Module is a JAR.

Actually a true Jigsaw module would be a *.jmod file - a new format capable of good compression
and other advantages. There is also support for creating "legacy" *.jar 
files for use in premodular JVMs (just as an OSGi bundle can be used in degraded form without
a container).

> Thus also the notion of an 'attached artifact' is completely missing. If you need such
a thing, you would need to stuff it into a jar and access it via
> getResource().

Probably true, though this is already more or less the case at runtime: a premodular app cannot
use attached artifacts at runtime (without embedding Maven code). At least 
the common case of System.loadLibrary would work more smoothly with a jmod (no need to extract
to a temporary file).

On a related topic, it seems unclear how creation of modules from a Maven project should work.
Suppose <packaging>jmod</packaging>. Should ${finalName}.jmod be the 
primary and only artifact? But then a "legacy" <packaging>jar</packaging> project
will not be able to consume this module's classes in flat classpath mode, which would be 
a huge obstacle to adoption. Should ${finalName}.jar be the primary artifact with ${finalName}.jmod
(*) a secondary artifact (**)? This would permit interoperability with 
jar-packaging projects but seems clumsy because the primary artifact would not be used at
runtime in a module-aware app.

And should dependency artifact(s) be resolved to ${basedir}/target/classes/ inside a reactor
build? Jigsaw should have support for "exploded modules" so this would be 
fine for compiling, and for running (e.g. in Surefire) most Java code; but not for testing
code using JNI, unless the Surefire plugin can be taught to set 
$LD_LIBRARY_PATH / %Path% (***) intelligently.

> What we could do is to populate the local jigsaw repo on mvn install. Or even provide
a mechanism to do a mvn jigsaw:deploy for upstream jigsaw module repos.

Jigsaw already has a (prototype) repository connector which can read Maven repositories, so
this might be unnecessary for most users.

> As the dependency resolution is built into the java runtime, we don't need to do anything
for resolving jigsaw modules.

This is actually the main problem as I see it: Jigsaw's javac expects src/main/java/
to have the exact list of Java dependencies (the -classpath argument 
is illegal in modular mode), which means that any part of Maven other than maven-compiler-plugin
which needs to know the list of dependencies is going to be out of luck. 
Possible solutions:

1. Signal an error at build time if is out of synch with pom.xml, and force
the user to maintain both. Yuck.

2. Create target/generated-sources/jigsaw/ from pom.xml before calling javac.
Not clear if this can work; and some module information (e.g. list of 
"exported" classes) would then have to be encoded somewhere in pom.xml (compare maven-bundle-plugin's
<configuration>), which is not great.

3. Force Maven core to load (at least some) dependency information from
I understand Tycho does something like this already.

> Of course we could provide something like resolving
> dependencies from an upstream jigsaw repo if those artifacts are not present in the local
maven repo.

And/or provide a batch tool to create a Maven 2-format mirror of a Jigsaw repo.

> the dependency matching (what happens if you have 2 transitive dependencies with different
versions, version ranges, etc) must not happen at runtime

Final version resolution would happen at install time. Note that Jigsaw's decisions would
not match Maven's in all scenarios; it might prefer the newest available version 
of a contentious dependency rather than the version "closest" to the top-level module of the

(*) Perhaps ${finalName}-something.jmod. It is not obvious from Maven's limited documentation
whether a secondary artifact must have a classifier. nbm-maven-plugin 
(analogous in many ways to Jigsaw) creates secondary ${finalName}.nbm artifacts with no classifier,
but this seems to cause subtle problems, especially in Maven Indexer.

(**) -Pdeployment could add *.deb and other native variants.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message