maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pontarelli <br...@pontarelli.com>
Subject Re: Maven and JigSaw thoughts
Date Sat, 22 Oct 2011 18:05:35 GMT
Mark,

A few things to clarify and some additional thoughts and points:

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

This meeting wasn't at all part of Jigsaw and I don't think any of the Jigsaw team was involved
(unfortunately). This was a meeting for the community that has ideas for making modules work
with for all our needs and we are hoping to provide feedback to Jigsaw so that we don't end
up with a set of tools that don't work for us.


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

Jigsaw isn't solely about runtime. The Jigsaw specification and JSRs also impact javac and
this is really where Maven, Ivy, Gradle, Savant and others should be concerned. It is essentially
moving the dependency management out of our tools and into javac, which could have dramatic
impacts.

Also, the Jigsaw specification and JSRs cover the concept of distribution of modules, which
is  something of a concern for projects like Maven, Ivy, Gradle and Savant, since these tools
have concepts for distribution (publishing, releasing, etc).



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

The Jigsaw spec doesn't define module at all really and that was the first order of business
for this meeting. We are hoping to define a Module so that it fits all of our needs and then
the specification will be much more clear about the requirements for each stage of development
with respect to a Module. This also implies the definition of stages (phases, etc.) and we
only briefly talked about that. The initial thoughts around stages are:

	1. Build (compile)
	2. Distribute
	3. Run

I think this is missing some key stages. My thoughts around the stages are:

	1. Build (compile)
	2. Package
	3. Test
	4. Release
	5. Distribute
	6. Run

We haven't quite gotten to the runtime and class loader issues yet, but I'm certain that EARs
will be a hot topic during that debate. It should work though with the our definition of a
Module because an EAR would specify each of its WAR and JAR dependencies in the meta-data
and that would allow for multiple class loaders and the correct runtime dependencies.

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

I don't think Modules have to be JARs. They only have to be packages. This is something that
you should bring up at the next meeting to ensure that the document we are creating contains
the correct definition of the Module. I think we ended the meeting yesterday with this definition:

 "A collection of classes, resources, and metadata, which are packaged together and accessed
as a unit at build-time, distribution-time, and run-time"

You examples seem to be fine with the concept of a Module thus far. 

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

I think the discussion around build and distribution will reveal how Maven and others fit
into Jigsaw. My largest concern right now is the dependency management system that Jigsaw
wants to take over. I also have some concerns about javac trying to do too much. Ideally,
build tools will fit in easily to the landscape and will be capable of doing dependency resolution
themselves and calling javac using a module path or a local module cache that they built.

Something else we need to start talking about is compile-time, distribution-time, and run-time
meta-data. This is where the dependency definitions will reside. From the Maven perspective,
a project defines the compile-time and distribution-time dependency information in a single
location, the POM. Other tools define these things separately. 

Jigsaw uses a module-info.java class for this information at compile-time and a module-info.class
file at distribution time. This can drastically change how all build tools work and can heavily
impact dependency management. Consider if you had to download the entire artifact to figure
out transitive dependencies. This could cause a lot of overhead.

Furthermore, it is my goal to help define a good standard for dependency meta-data definition
inside the repository (like the POM) that can be used across all projects. By creating a standard
that works well for Jigsaw, javac, Maven, etc. we all win. Even if the standard is not used
by Jigsaw, it will still help considerably for Maven, Ivy, Gradle, Savant and any other tools
that want to share repositories. This is why I wanted to specifically include Maven, Ivy,
Gradle and Savant developers in these meetings.

Hope that helps clear things up. Feel free to bounce questions and ideas off me. I'm planning
on attending all of the IRC meetings (if possible) and helping shape the plans as much as
possible so that build tools don't incur a lot of pain to support Jigsaw.

Also, anyone that is interested in this stuff, feel free to join the IRC discussions. I'm
also created a Google Group that anyone can join to continue the discussion about all this
stuff. The info for that group:

web: http://groups.google.com/group/java-modularity
email: java-modularity@googlegroups.com

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


Mime
View raw message