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 apps.
LieGrue, strub ----- Original Message ----- > From: Mark Struberg <[email protected]> > To: Maven Developers List <[email protected]> > 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 > > > 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]
