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 WARs)
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/module-info.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 module-info.java is out of synch with
pom.xml, and force the user to maintain both. Yuck.
2. Create target/generated-sources/jigsaw/module-info.java 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
module-info.java. 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.
[later]
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 app.
(*) 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: [email protected]
For additional commands, e-mail: [email protected]
