You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jörg Hohwiller <jo...@j-hohwiller.de> on 2013/05/16 23:42:34 UTC
Strategy for jmod (Jigsaw)?
Dear Maven developers,
is there already some slight inital draft or idea for a strategy how
maven x.y could deal with jigsaw?
How could this be harmonized and go together?
Or will this create an entirely new universe?
The concepts seem to be quite similar. Some features should be
compatible but various things are not.
Do you have your crystal balls ready and can give a little insight?
For those that have no idea what I am talking about.
Jigsaw is a JSR project aiming to modularize the JDK.
Initially it was planned only as a technology to be used internally by
the JDK
but it is now the be the new module system for java.
The successor of the good old JAR is the JMOD file.
The analogon for pom.xml is module-info.java that gets bundeled diretly
into the JMOD
but can be read uncompressed from the head of the file.
module-info.java only addresses identification (module name and version
- instead of groudId, artifactId and version)
as well as dependencies. But does not other aspects addressed by pom.xml.
Project Jigsaw also defines repositories and stuff like that so there is
some sort of compatition with maven, gradle, buildr, OSGi, etc.
I am quite unsure where this journey is going to.
Jigsaw was planned for Java6, 7, and also failed to make it into Java8.
However, it will surely make it into Java9.
Thanks
Jörg
Re: Strategy for jmod (Jigsaw)?
Posted by Hervé BOUTEMY <he...@free.fr>.
I haven't really looked at it myself. I don't know for others.
AFAIK, there is no shared strategy, I don't remember even of sharing opinions
on this: busy on other topics
But yes, we'll need to have a strategy about it.
Did you try to see how things could be harmonized?
Regards,
Hervé
Le jeudi 16 mai 2013 23:42:34 Jörg Hohwiller a écrit :
> Dear Maven developers,
>
> is there already some slight inital draft or idea for a strategy how
> maven x.y could deal with jigsaw?
> How could this be harmonized and go together?
> Or will this create an entirely new universe?
> The concepts seem to be quite similar. Some features should be
> compatible but various things are not.
> Do you have your crystal balls ready and can give a little insight?
>
> For those that have no idea what I am talking about.
> Jigsaw is a JSR project aiming to modularize the JDK.
> Initially it was planned only as a technology to be used internally by
> the JDK
> but it is now the be the new module system for java.
> The successor of the good old JAR is the JMOD file.
> The analogon for pom.xml is module-info.java that gets bundeled diretly
> into the JMOD
> but can be read uncompressed from the head of the file.
> module-info.java only addresses identification (module name and version
> - instead of groudId, artifactId and version)
> as well as dependencies. But does not other aspects addressed by pom.xml.
>
> Project Jigsaw also defines repositories and stuff like that so there is
> some sort of compatition with maven, gradle, buildr, OSGi, etc.
> I am quite unsure where this journey is going to.
>
> Jigsaw was planned for Java6, 7, and also failed to make it into Java8.
> However, it will surely make it into Java9.
>
> Thanks
> Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Strategy for jmod (Jigsaw)?
Posted by Jörg Hohwiller <jo...@j-hohwiller.de>.
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...
>
> 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.
I agree that is not the best approach and would not recommend to go in
this direction...
>
> (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.
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.
>
>
> [1] https://bitbucket.org/jglick/jigsawmaven
>
Cheers
Jörg
Re: Strategy for jmod (Jigsaw)?
Posted by Jesse Glick <jg...@cloudbees.com>.
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.
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.
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.
(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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org