Hi Jesse, Am 20.05.2013 17:28, schrieb Jesse Glick:
On 05/16/2013 05:42 PM, Jörg Hohwiller wrote:is there already some slight inital draft or idea for a strategy how maven x.y could deal with jigsaw?I wrote up a very preliminary sketch about a year ago [1] but have not worked on it since then, and whatever worked then may or may not work with current drafts of Jigsaw. Feel free to fork it and develop it, if the approach matches your expectations.
Wow. Great. I am about to dig into...
The idea was to generate target/generated-sources/jmod/module-info.java from pom.xml, reusing standard Maven elements to the greatest extent possible, introducing plugin-specific configuration only for Jigsaw-specific metadata; and attach target/*.jmod as secondary artifacts. Then the generated module-info.java is just used as an input to javac, but you would not normally see it; you would continue to work in a traditional Maven way, just with a better runtime, and stronger compile-time validation of things like internal packages. You could even activate Jigsaw conditionally in a profile, so that the same source project could be built by a premodular JDK.
That makes sense to me from the build/development point of view. Still the question is what will hapen to the repository worlds on the long run...
I agree that is not the best approach and would not recommend to go in this direction...There are other possible approaches, of course. You could treat Jigsaw metadata as primary (versioned) sources, and install a Maven extension that would read src/main/java/module-info.java early in the lifecycle and generate synthetic dependencies in the Maven model so that pom.xml is used only for other metadata. My fear was that this (a) would be too “magical”, (b) would fail to work comfortably with other Maven features such as dependencyManagement and the release plugin.
Thanks for sharing your thoughts. Actually you are true that unless life becomes into jigsaw repositories we can never know where they journey is going to. Your approaches will help to bridge the gaps for some time. On the long run I wonder if a "cut" would be better like it was done from m1 to m2. With m2 repositories I still think that there is way to much clutter in POMs that would actually not be needed in a repo. And that was always preventing the maven world from making improvements on POMs (remember the dicussions about attribute based POM, etc.). IMHO development information should not be published to a repo and could therefore be seperated from the other stuff. And except for lincense and maybe a link to the homepage the module info already contains all essentials. Development infos could come from other sources such as SCM.(The comparison between Tycho and the Felix bundle plugin is instructive.)Interoperability between Maven repositories and Jigsaw repositories is another topic, which I did not explore. You could imagine creating a unidirectional or bidirectional mirror between the two types of repository, either static (a batch translation) or dynamic (e.g. a Nexus plugin). Or you could imagine creating a Maven <extension> which adds a new kind of repository to Aether, so that Maven projects could declare direct Jigsaw repository additions. If and when there are some live, realistic Jigsaw repositories, this will be more interesting to experiment with.
[1] https://bitbucket.org/jglick/jigsawmaven
Cheers Jörg
smime.p7s
Description: S/MIME Kryptografische Unterschrift
