maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <>
Subject Re: Maven and JigSaw thoughts
Date Sun, 23 Oct 2011 09:31:58 GMT
re my last sentence: forget it, they could use jarsigner
Almost forgot about that, used it the last time aprox 10 years ago when I shipped a few ME


----- Original Message -----
> From: Mark Struberg <>
> To: Maven Developers List <>
> Cc: 
> Sent: Sunday, October 23, 2011 11:27 AM
> Subject: Re: Maven and JigSaw thoughts
> Hi Brian!
> Txs 4 your clarifications!
>>  Jigsaw isn't solely about runtime. The Jigsaw 
>>  specification and JSRs also impact javac
> True, I should have said Maven is about the buildtime and JigSaw is _also_ about 
> runtime.
> If I understood it correctly then JigSaw will package the 'Module' 
> information into the JAR itself (most probably as a class file), right?
> This 'integrated' solution has the benefit that meta-information and 
> binary are always in sync (actually Maven also packages our pom.xml and 
> properties into META-INF already). The downside is that you need to download all 
> the fat jar to detect if you need anything. I hope that it will be defined that 
> the dependency matching (what happens if you have 2 transitive dependencies with 
> different versions, version ranges, etc) must not happen at runtime. Otherwise 
> the system will blow itself up quickly and tend to become unstable over time...
>>  this is really where Maven, Ivy, Gradle, 
>>  Savant and others should be concerned.
> Actually I don't see any problems. If JigSaw does something good, then we 
> will support it. 
> If it does something better than Maven, then we will use it instead of our old 
> mechanism (in a compatible way). 
> But as far as I've read, all the build process, attached artifacts, 
> different artifact types etc are still better solved via Maven though. So 
> I'm not afraid of JigSaw but rather happy to use the features it brings us. 
> Of course we need to make sure that they don't ship unusable crap like it 
> happened with java.util.logging.Logger...
> As far as I understood so far there is still alot functionality missing in 
> JigSaw. Thus I currently see the scenario with either having parallel 
> JigSaw-repo + Maven-repo or a Maven-repo which also contains JigSaw artifacts 
> and could directly act as JigSaw repo.
>>  The Jigsaw spec doesn't define module at all really
> Imo the JigSaw docu pretty prominently _mentions_ the word 'Module
> but I'm completely with you that it's by far not enough to make a well 
> specified terminus tecnicus.
>>  I don't think Modules have to be JARs ...
>>  "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. 
> A the meeting I asked about what 'accessed as a unit at ... run-time" 
> means and go the answer:
> "struberg, one module one CL". Please check your irc logs, maybe I got 
> this wrong (but 2 me it sounded pretty straight).
> We should elaborate on this on the next meeting.
> I'm still thinking about the rest of your mail (need to run now). But you 
> made some good points with the 'stages'. Imo every stage needs some 
> metadata. And if those metadata parts are well defined, then the very metadata 
> can get created in a 'portable way'. Means it doesn't matter if you 
> write the by hand or if Maven or Gradle generate it for you, 
> isn't?
> Of course I guess we will need to invest some brainwork to handle 
> 'Modules' which got created via another framework thus we only have the 
> JigSaw metadata available.
> Btw one big thing which is imo not covered by the JigSaw spec is the security 
> aspect. Maven contains a fairly straight set of md5 sha1 and even support 
> artifact signing. All this requires that the security information lives outside 
> the artifact/Module (jar) which should be verified. So I honestly cannot see how 
> this should work with only one jar. The only way I can see quickly would be to 
> just zip all the jar + metainfo together again..
> txs and LieGrue,
> strub
>> ________________________________
>> From: Brian Pontarelli <>
>> To: Maven Developers List <>
>> Sent: Saturday, October 22, 2011 8:05 PM
>> Subject: Re: Maven and JigSaw thoughts
>> 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 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 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:
>> email:
>> -bp
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

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

View raw message