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