maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Maven and JigSaw thoughts
Date Sat, 22 Oct 2011 09:00:54 GMT
Hi!

Yesterday I had the chance to attend the jigsaw [1] team meeting.
Since I'm still a bit blasted and overwhelmed with information, I try to summarize what I
think of it.
Since I'm a complete n00b to jigsaw, please correct me if I got something wrong.

JigSaw is a modularization proposal for the JDK itself. Thus instead of having a fully blown
jarmageddon in an app you ship, you can declare 'dependencies' very similar to what you can
do with Maven, p4, ivy or graddle. They are also discussing about taking some ideas from binary
package managers like yum, rpm and apt, which would allow installation scripts.
Those dependencies will then get fetched at RUNTIME (first big difference to maven which does
all that at buildtime) and stored in a local 'jigsaw-repo' (whatever this will get called
finally).

The JigSaw spec is heavily talking about 'Module' which is similar to our 'artifacts'. BUT
there is atm a strict 1:1 between a Modul and a ClassLoader. Thus modules which need multiple
classloaders (like EARs) or a specific deployment task (like WARs) are not supported if I
understood this right.
> Module = "A collection of classes, resources, and metadata, which are packaged together
and 
> accessed as a unit at build-time, distribution-time, and run-time" 

Modules also have a few runtime specifics which are OSGi influenced, like the ability to export
and filter class and package visibility. But this is nothing which concerns us really (except
if we like to provide this info in our index).

What Modules are missing imo is the complete concept of having different artifact types. A
Module is a JAR. As far as I understood the don't support other artifact types. 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(). Of course as a separate
module. So no nice myproject-sql-scripts.zip which automatically gets deployed as part of
your backend project build anymore.


How does this fit into the Maven world?
--------------------------------------

Well, as mentioned a few times already, I'm fairly new to jigsaw, thus I might have misunderstood
something. So take all this with a fine grain of salt and correct me if you know more ...

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.
As the dependency resolution is built into the java runtime, we don't need to do anything
for resolving jigsaw modules.
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.

I bet there are lots of other things we can do. If we do it well, then we may even extend
the local maven repo (or even upstream maven repos) to serve as a jigsaw modules repo directly?

LieGrue,
strub


[1] http://openjdk.java.net/projects/jigsaw/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message