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: [email protected]
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
