On Oct 23, 2011, at 3:27 AM, Mark Struberg wrote: > 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?
I hope not. This is one the things I want to try to avoid. > 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… Yeah, these are all things I have concerns about. Version ranges can be dangerous at build and runtime and single module transitive version compatibility is also something that needs to be ironed out. > > >> 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. I tend towards the more pragmatic and cynical approach. I'm not thrilled that Jigsaw is planning on diving head first into dependency management without any discussions with Maven, Ivy, Savant and Gradle dev teams. I think with a good EG and a solid JSR that has input from the community, it could provide some great benefits. We just aren't anywhere near that yet. > > >> 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. Hehe. Yeop. Using a term doesn't mean it is defined ;) > >> 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). Yeah, I saw that. This is a Redhat requirement, not a Jigsaw requirement right now (if I recall correctly). > > 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? Yeah, it doesn't matter that much, but it does impact every repository out there and all existing artifacts (to some degree). One of my main goals is to standardize the dependency meta-data format across all projects (Maven, Ivy, etc.) so that we can start sharing repositories. This includes Jigsaw. Then we can all generate the same information in the same way and start updating all the repositories to provide the new information (along with the old info to keep backwards compatibility). > > 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.. That is something that was brought up on the Jigsaw list as a major item to be covered. -bp --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
