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 http://openjdk.java.net/projects/jigsaw/doc/draft-java-module-system-requirements-12 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 module-info.java 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 <[email protected]> >To: Maven Developers List <[email protected]> >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 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] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
