You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Paul Benedict <pb...@apache.org> on 2016/08/31 13:59:04 UTC
Re: Building jar targeting multiple Java versions, including 9
Robert, I'm responding to dev@maven so we can discuss Maven philosophies...
I believe the pattern should be based on a multi-module project. Each
module should target the expected JDK version. Then introduce a new "mrjar"
type for the parent that knows how to bind them all together into a
Multi-Release JAR.
Cheers,
Paul
On Wed, Aug 31, 2016 at 6:10 AM, Robert Scholte <rf...@apache.org>
wrote:
> I've been working on the implementation of this in the
> maven-compiler-plugin, but I'm not really pleased with the result.
> The problem is that in the worst case scenario we have to work with 3
> different versions of Java:
> - The Maven Runtime (set as JAVA_HOME)
> - JDK for the module-info.java
> - JDK for all other source files.
>
> The example below worked because all three were set to JDK9.
> But based on the source/target of 1.6 I cannot predict which JDK is used,
> only that it is at least JDK6. Should the plugin switch to another JDK?
> And if you want to compile with source/target 1.5 or less, you're in
> trouble. There's something called toolchain, where you can specify the
> JavaHome per version, but in case of maven-compiler-plugin it assumes that
> all java-related plugins and execution blocks want to use the same
> toolchain through the whole Maven project.
> The good news is that for the maven-jdeps-plugin I improved this part in
> Maven 3.3.1, since this plugin only works with Java8 and above, which
> doesn't have to be the same JDK to compile the sources with. Now you can
> simple say: I want the toolchain for version X. This feature needs to be
> added to the plugin.
>
> That said I think I will write a recipe for this. This is first of all an
> issue for library writers who want to have their jar compatible with
> multiple Java versions for their end users.
> Result: One javac call per execution block as it was meant to be.
>
> thanks,
> Robert
>
> On Fri, 26 Aug 2016 15:31:07 +0200, Oliver Gondža <og...@gmail.com>
> wrote:
>
> Thank you all for your suggestions. I managed to get the project to build
>> with following maven setup:
>>
>> ```
>> <!--
>> When using compiler from java 8 and older, ignore module files
>> altogether.
>> Otherwise, use 2 phase compilation to build
>> - all classes for target version and
>> - module-info.java with 9+ source and target level
>> -->
>> <build>
>> <plugins>
>> <plugin>
>> <groupId>org.apache.maven.plugins</groupId>
>> <artifactId>maven-compiler-plugin</artifactId>
>> <version>3.5.1</version>
>> <configuration>
>> <source>1.6</source>
>> <target>1.6</target>
>> </configuration>
>> <executions>
>> <execution>
>> <id>default-compile</id>
>> <configuration>
>> <excludes>
>> <exclude>**/module-info.java</exclude>
>> </excludes>
>> </configuration>
>> </execution>
>> </executions>
>> </plugin>
>> </plugins>
>> </build>
>>
>> <profiles>
>> <profile>
>> <id>jigsaw</id>
>> <activation>
>> <jdk>[1.9,)</jdk>
>> </activation>
>> <build>
>> <plugins>
>> <plugin>
>> <groupId>org.apache.maven.plugins</groupId>
>> <artifactId>maven-compiler-plugin</artifactId>
>> <version>3.5.1</version>
>> <configuration>
>> <source>1.9</source>
>> <target>1.9</target>
>> </configuration>
>> <executions>
>> <execution>
>> <id>module-infos</id>
>> <phase>compile</phase>
>> <goals>
>> <goal>compile</goal>
>> </goals>
>> <configuration>
>> <includes>
>> <include>**/module-info.java</include>
>> </includes>
>> </configuration>
>> </execution>
>> </executions>
>> </plugin>
>> </plugins>
>> </build>
>> </profile>
>> </profiles>
>> ```
>>
>> It does compile with older javac versions as a bonus. Given this is
>> nothing else than using `-source 9 -target 9` for module-info.java if
>> present, I dare to say maven-compiler-plugin can be adapted to figure this
>> out on its own.
>>
>
Re: Building jar targeting multiple Java versions, including 9
Posted by Tibor Digana <ti...@apache.org>.
Richart,
>>couple features of Java8 which I've avoided adding because of needing
backward compatibility.
If I have to decide where my time goes, then I would rather keep Java 6 in
source code and make s/w more stable improving architecture and features;
rather than Java 7 or 8 or 9 or 10 since I know the cost and benefit. I
would rather wait for time to come when Java 9 is out and Java 8 in Maven
project.
Some can be compromise, like in Surefire I can imaging Java 8 in source
code in one child module of multimodule project and the reason is that
JUNit 5 is built with Java 8 which makes sense to JUnit team from API point
of view and mine as well, but again only that particular module.
This is pragmatic and conservative approach.
>>Eclipse's maven support
Do you know that IDEA is free of charge in open source project like Maven?
I am mixing plenty of JDKs in one project. Separate for IDEA, another for
compiler, another for runtime, another for tests and another for Maven.
Cool...
On Wed, Aug 31, 2016 at 11:05 PM, Richard Sand [via Maven] <
ml-node+s40175n5879624h84@n5.nabble.com> wrote:
> Agree with Andreas, I can see MRJars usefulness too. APIs with lambdas
> come to mind as a good example, or interfaces with default
> implementations, are just a couple features of Java8 which I've avoided
> adding because of needing backward compatibility.
>
> Eclipse's maven support in general is very subpar... and it may be
> difficult to avoid having multiple projects for different runtimes - but
> I could envision a scenario where I'd simply have my project configured
> in Eclipse as Java9, but in my pom configured for other builds. Eclipse
> wouldn't be able to tell me if a particular piece of code was compatible
> with the other runtimes, but maven sure would, and maybe Eclipse will
> add the capability. In any event I wouldn't want the limitations of a
> particular IDE to drive the POM design and in particular require
> multi-projects when a single project could suffice. If I as the end user
> can live with the limitations of the IDE (e.g. not being multi-runtime
> aware) then I should be allowed to do so.
>
> Richard Sand | CEO
> IDF Connect, Inc.
> 2207 Concord Ave, #359
> Wilmington | Delaware 19803 | USA
> Office: +1 888 765 1611 | Fax: +1 866 765 7284
> Mobile: +1 267 984 3651
>
>
>
>
> ------ Original Message ------
> From: "Andreas Gudian" <[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=5879624&i=0>>
> To: "Maven Developers List" <[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=5879624&i=1>>
> Sent: 8/31/2016 4:52:16 PM
> Subject: Re: Building jar targeting multiple Java versions, including 9
>
> >2016-08-31 22:02 GMT+02:00 Tibor Digana <[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=5879624&i=2>>:
> >
> >> >>So, we can try to have different source folders for different
> >>runtimes.
> >> No. If you are developers you would not say this.
> >> No developer would develop and merge the same code multiple times!!!
> >> Look, now let the maven-compiler-plugin to download jars of the same
> >> artifact which was released for Version 1.7 and 1.8, and now let the
> >> compiler wrap those two versions with current version 1.9 which is
> >> ready to be released. Now you have fat jar MRjar.
> >> This means any Java version of the artifact can be chosen on the top
> >>of
> >> JDK9.
> >>
> >> >>Most other plugins would need to be executed for each version as
> >>well -
> >> javadoc, junit
> >> No. because the previous Versions were already tested and processed.
> >>
> >> >>Again if they *don't* need a separate execution, then why is MRJar
> >> needed?
> >> Exactly, and now I cannot imaging company which is going to
> >>complicate
> >> their project with a stupid MRJar and why so if they have WildFly
> >> 8.2.1 which supports Java 8 do you think they EE project would
> >> struggle with MRJar? Of course not. If they have WildFly 10.x
> >> supporting Java 9 then again no developer would build MRJar.
> >>
> >> I think MRJar is suitable only for JDK internals and it is only
> >> because of Oracle has problem with JCP because JCP does not let
> >>Oracle
> >> to break backwards compatibility and introduce dynamic language
> >> features. So Oracle is trying for compromise.
> >> Oracle is trying to let you build java.* JDK with javac, interchange
> >> internal modules, etc.
> >> Nothing for other non-JDK projects.
> >>
> >
> >That's a bit off-topic, as this thread is about the _how_ and not the
> >_why_, but I'd like to point out that I disagree with you here ;).
> >MRJars
> >would be great for a lot of frameworks and libraries that you would
> >_use_
> >in your end-product. Frameworks that offer different alternatives or
> >extended features requiring a newer JDK now have to build and maintain
> >artifacts either with different versions or with different artifactIds
> >(e.g. funky-annotations and funky-annotations-jdk8, where the -jdk8
> >variant
> >contains annotations with @Repeatable) -- there are a lot of examples
> >out
> >there. And that's not only cumbersome for maintainers, but also for
> >users
> >(which is the bad thing).
> >
> >So go MRjars! Making them easily consumable for users is the
> >top-prirority
> >and it looks like a solid approach.
> >
> >Making them easy to build for the maintainers is way less important (as
> >that's only a tiny percentage of the maven-users out there), but it
> >sure
> >needs to work with different IDEs and especially Eclipse would have
> >problems handling different target JDKs in the same project.
> >
> >So for me as an Eclipse user, I'd have to take the road with the
> >multi-module projects. But that's okay, as I'm just building a
> >framework
> >and separating the different variants for different JDKs has also a lot
> >of
> >benefits, as already described above: testing, generating javadocs, and
> >all
> >that other stuff is already there and can be used without having to
> >change
> >anything. For me, a project collecting the internally seperate
> >artifacts
> >and combining them into an MRjar would be totally fine.
> >
> >Andreas
> >
> >
> >
> >>
> >> --
> >> Cheers
> >> Tibor
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=5879624&i=3>
> >> For additional commands, e-mail: [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=5879624&i=4>
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=5879624&i=5>
> For additional commands, e-mail: [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=5879624&i=6>
>
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
> http://maven.40175.n5.nabble.com/Re-Building-jar-targeting-
> multiple-Java-versions-including-9-tp5879531p5879624.html
> To start a new topic under Maven Developers, email
> ml-node+s40175n142166h86@n5.nabble.com
> To unsubscribe from Maven Developers, click here
> <http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=142166&code=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg==>
> .
> NAML
> <http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
--
View this message in context: http://maven.40175.n5.nabble.com/Re-Building-jar-targeting-multiple-Java-versions-including-9-tp5879531p5879691.html
Sent from the Maven Developers mailing list archive at Nabble.com.
Re: Building jar targeting multiple Java versions, including 9
Posted by Richard Sand <rs...@idfconnect.com>.
Agree with Andreas, I can see MRJars usefulness too. APIs with lambdas
come to mind as a good example, or interfaces with default
implementations, are just a couple features of Java8 which I've avoided
adding because of needing backward compatibility.
Eclipse's maven support in general is very subpar... and it may be
difficult to avoid having multiple projects for different runtimes - but
I could envision a scenario where I'd simply have my project configured
in Eclipse as Java9, but in my pom configured for other builds. Eclipse
wouldn't be able to tell me if a particular piece of code was compatible
with the other runtimes, but maven sure would, and maybe Eclipse will
add the capability. In any event I wouldn't want the limitations of a
particular IDE to drive the POM design and in particular require
multi-projects when a single project could suffice. If I as the end user
can live with the limitations of the IDE (e.g. not being multi-runtime
aware) then I should be allowed to do so.
Richard Sand | CEO
IDF Connect, Inc.
2207 Concord Ave, #359
Wilmington | Delaware 19803 | USA
Office: +1 888 765 1611 | Fax: +1 866 765 7284
Mobile: +1 267 984 3651
------ Original Message ------
From: "Andreas Gudian" <an...@gmail.com>
To: "Maven Developers List" <de...@maven.apache.org>
Sent: 8/31/2016 4:52:16 PM
Subject: Re: Building jar targeting multiple Java versions, including 9
>2016-08-31 22:02 GMT+02:00 Tibor Digana <ti...@googlemail.com>:
>
>> >>So, we can try to have different source folders for different
>>runtimes.
>> No. If you are developers you would not say this.
>> No developer would develop and merge the same code multiple times!!!
>> Look, now let the maven-compiler-plugin to download jars of the same
>> artifact which was released for Version 1.7 and 1.8, and now let the
>> compiler wrap those two versions with current version 1.9 which is
>> ready to be released. Now you have fat jar MRjar.
>> This means any Java version of the artifact can be chosen on the top
>>of
>> JDK9.
>>
>> >>Most other plugins would need to be executed for each version as
>>well -
>> javadoc, junit
>> No. because the previous Versions were already tested and processed.
>>
>> >>Again if they *don't* need a separate execution, then why is MRJar
>> needed?
>> Exactly, and now I cannot imaging company which is going to
>>complicate
>> their project with a stupid MRJar and why so if they have WildFly
>> 8.2.1 which supports Java 8 do you think they EE project would
>> struggle with MRJar? Of course not. If they have WildFly 10.x
>> supporting Java 9 then again no developer would build MRJar.
>>
>> I think MRJar is suitable only for JDK internals and it is only
>> because of Oracle has problem with JCP because JCP does not let
>>Oracle
>> to break backwards compatibility and introduce dynamic language
>> features. So Oracle is trying for compromise.
>> Oracle is trying to let you build java.* JDK with javac, interchange
>> internal modules, etc.
>> Nothing for other non-JDK projects.
>>
>
>That's a bit off-topic, as this thread is about the _how_ and not the
>_why_, but I'd like to point out that I disagree with you here ;).
>MRJars
>would be great for a lot of frameworks and libraries that you would
>_use_
>in your end-product. Frameworks that offer different alternatives or
>extended features requiring a newer JDK now have to build and maintain
>artifacts either with different versions or with different artifactIds
>(e.g. funky-annotations and funky-annotations-jdk8, where the -jdk8
>variant
>contains annotations with @Repeatable) -- there are a lot of examples
>out
>there. And that's not only cumbersome for maintainers, but also for
>users
>(which is the bad thing).
>
>So go MRjars! Making them easily consumable for users is the
>top-prirority
>and it looks like a solid approach.
>
>Making them easy to build for the maintainers is way less important (as
>that's only a tiny percentage of the maven-users out there), but it
>sure
>needs to work with different IDEs and especially Eclipse would have
>problems handling different target JDKs in the same project.
>
>So for me as an Eclipse user, I'd have to take the road with the
>multi-module projects. But that's okay, as I'm just building a
>framework
>and separating the different variants for different JDKs has also a lot
>of
>benefits, as already described above: testing, generating javadocs, and
>all
>that other stuff is already there and can be used without having to
>change
>anything. For me, a project collecting the internally seperate
>artifacts
>and combining them into an MRjar would be totally fine.
>
>Andreas
>
>
>
>>
>> --
>> Cheers
>> Tibor
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Building jar targeting multiple Java versions, including 9
Posted by Andreas Gudian <an...@gmail.com>.
2016-08-31 22:02 GMT+02:00 Tibor Digana <ti...@googlemail.com>:
> >>So, we can try to have different source folders for different runtimes.
> No. If you are developers you would not say this.
> No developer would develop and merge the same code multiple times!!!
> Look, now let the maven-compiler-plugin to download jars of the same
> artifact which was released for Version 1.7 and 1.8, and now let the
> compiler wrap those two versions with current version 1.9 which is
> ready to be released. Now you have fat jar MRjar.
> This means any Java version of the artifact can be chosen on the top of
> JDK9.
>
> >>Most other plugins would need to be executed for each version as well -
> javadoc, junit
> No. because the previous Versions were already tested and processed.
>
> >>Again if they *don't* need a separate execution, then why is MRJar
> needed?
> Exactly, and now I cannot imaging company which is going to complicate
> their project with a stupid MRJar and why so if they have WildFly
> 8.2.1 which supports Java 8 do you think they EE project would
> struggle with MRJar? Of course not. If they have WildFly 10.x
> supporting Java 9 then again no developer would build MRJar.
>
> I think MRJar is suitable only for JDK internals and it is only
> because of Oracle has problem with JCP because JCP does not let Oracle
> to break backwards compatibility and introduce dynamic language
> features. So Oracle is trying for compromise.
> Oracle is trying to let you build java.* JDK with javac, interchange
> internal modules, etc.
> Nothing for other non-JDK projects.
>
That's a bit off-topic, as this thread is about the _how_ and not the
_why_, but I'd like to point out that I disagree with you here ;). MRJars
would be great for a lot of frameworks and libraries that you would _use_
in your end-product. Frameworks that offer different alternatives or
extended features requiring a newer JDK now have to build and maintain
artifacts either with different versions or with different artifactIds
(e.g. funky-annotations and funky-annotations-jdk8, where the -jdk8 variant
contains annotations with @Repeatable) -- there are a lot of examples out
there. And that's not only cumbersome for maintainers, but also for users
(which is the bad thing).
So go MRjars! Making them easily consumable for users is the top-prirority
and it looks like a solid approach.
Making them easy to build for the maintainers is way less important (as
that's only a tiny percentage of the maven-users out there), but it sure
needs to work with different IDEs and especially Eclipse would have
problems handling different target JDKs in the same project.
So for me as an Eclipse user, I'd have to take the road with the
multi-module projects. But that's okay, as I'm just building a framework
and separating the different variants for different JDKs has also a lot of
benefits, as already described above: testing, generating javadocs, and all
that other stuff is already there and can be used without having to change
anything. For me, a project collecting the internally seperate artifacts
and combining them into an MRjar would be totally fine.
Andreas
>
> --
> Cheers
> Tibor
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Building jar targeting multiple Java versions, including 9
Posted by Christian Schulte <cs...@schulte.it>.
Am 09/03/16 um 11:48 schrieb Robert Scholte:
> Simple? We have several options. Most user friendly might be to have the
> "magic" in the maven-compiler-plugin, which implies you need to be able to
> set the javac executable for both, set the source/target/release for both.
> And how about compilation results (success/failures/error)? Merge them?
This really is a shortcoming of the standard javac compiler. What about
this?
We have 'src/main/java' and 'src/test/java'. The compiler plugin
compiles these source roots the same way it did before. In addition, we
make that plugin support the following well-known source roots and make
it compile the sources by setting target and source automatically based
on the name of the source root in order of lowest to highest target so
that classes of a higher target platform can be compiled against classes
of a lower target platform. Like this:
'src/main/java1.1'
'src/main/java1.2'
'src/main/java1.3'
'src/main/java1.4'
'src/main/java1.5'
'src/main/java1.6'
'src/main/java1.7'
'src/main/java1.8'
'src/main/java1.9'
'src/test/java1.1'
'src/test/java1.2'
'src/test/java1.3'
'src/test/java1.4'
'src/test/java1.5'
'src/test/java1.6'
'src/test/java1.7'
'src/test/java1.8'
'src/test/java1.9'
All optional. The compiler plugin searches for these source roots and
does everything automatically in order 1.1 to 1.9 writing everything to
'target/classes'.
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Building jar targeting multiple Java versions, including 9
Posted by Robert Scholte <rf...@apache.org>.
On Sat, 03 Sep 2016 03:57:30 +0200, Christian Schulte <cs...@schulte.it>
wrote:
> Am 09/02/16 um 19:06 schrieb Robert Scholte:
>> I'll rephrase the question: What to do which projects who want to have
>> their code compatible with a version lower than Java 9 AND want to
>> provide
>> a module-info file as well?
>
> The main sources are compiled with, for example, -target 1.6 and only
> the module-info.java file is compiled with -target 1.9? That way? javac
> cannot compile a module-info.java file when not targetting 1.9, correct?
> Would be simple then.
Simple? We have several options. Most user friendly might be to have the
"magic" in the maven-compiler-plugin, which implies you need to be able to
set the javac executable for both, set the source/target/release for both.
And how about compilation results (success/failures/error)? Merge them?
All of this made we decide I don't like this option. So I suggest a bit
less user-friendly, but even than there are several options:
- 2 execution blocks with one of following options:
* 2 source folders, one for the java sources, other for the module
source(s).
* 1 source folder, with includes/excludes of module-info.java
- MultiRelease JAR
And their might be options I haven't thought of.
All options are valid, but I think we should come with our preferred
advice or recipe, because we will get these questions for sure.
Robert
>
> Regards,
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Building jar targeting multiple Java versions, including 9
Posted by Christian Schulte <cs...@schulte.it>.
Am 09/02/16 um 19:06 schrieb Robert Scholte:
> I'll rephrase the question: What to do which projects who want to have
> their code compatible with a version lower than Java 9 AND want to provide
> a module-info file as well?
The main sources are compiled with, for example, -target 1.6 and only
the module-info.java file is compiled with -target 1.9? That way? javac
cannot compile a module-info.java file when not targetting 1.9, correct?
Would be simple then.
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Building jar targeting multiple Java versions, including 9
Posted by Robert Scholte <rf...@apache.org>.
On Fri, 02 Sep 2016 15:49:36 +0200, Tibor Digana
<ti...@googlemail.com> wrote:
> Robert, I disagree with you. There is no reason to increase effort only
> because of one class.
> Now let's be concrete. I see many managers in commercial firms behave
> like
> non-dev managers, and it is horrible in almost every area because now in
> Europe the political decisions become more important than pragmatical
> thoughts.
> So we have to and we are responsible to talk about _why_ and then _how_
> and
> not opposite; otherwise it's just politics.
> Some people like making release management without coding, some are
> consultants and not daily coders. That's sad!
> Every month I am telling to all manager - think of cost and what makes
> sense. But they don't. They just see themselves and their positions
> higher
> and completely forge how harmful it can be to development staff.
>
I'm going to end this part, since it is completely off topic.
Start it again in a separate thread if you want, but not here.
I'll rephrase the question: What to do which projects who want to have
their code compatible with a version lower than Java 9 AND want to provide
a module-info file as well?
Robert
> On Wed, Aug 31, 2016 at 11:03 PM, Robert Scholte <rf...@apache.org>
> wrote:
>
>> On Wed, 31 Aug 2016 22:02:04 +0200, Tibor Digana <
>> tibor.digana@googlemail.com> wrote:
>>
>> So, we can try to have different source folders for different runtimes.
>>>>>
>>>> No. If you are developers you would not say this.
>>> No developer would develop and merge the same code multiple times!!!
>>> Look, now let the maven-compiler-plugin to download jars of the same
>>> artifact which was released for Version 1.7 and 1.8, and now let the
>>> compiler wrap those two versions with current version 1.9 which is
>>> ready to be released. Now you have fat jar MRjar.
>>> This means any Java version of the artifact can be chosen on the top of
>>> JDK9.
>>>
>>> Most other plugins would need to be executed for each version as well -
>>>>> javadoc, junit
>>>>>
>>>> No. because the previous Versions were already tested and processed.
>>>
>>> Again if they *don't* need a separate execution, then why is MRJar
>>> needed?
>>>>>
>>>> Exactly, and now I cannot imaging company which is going to complicate
>>> their project with a stupid MRJar and why so if they have WildFly
>>> 8.2.1 which supports Java 8 do you think they EE project would
>>> struggle with MRJar? Of course not. If they have WildFly 10.x
>>> supporting Java 9 then again no developer would build MRJar.
>>>
>>> I think MRJar is suitable only for JDK internals and it is only
>>> because of Oracle has problem with JCP because JCP does not let Oracle
>>> to break backwards compatibility and introduce dynamic language
>>> features. So Oracle is trying for compromise.
>>> Oracle is trying to let you build java.* JDK with javac, interchange
>>> internal modules, etc.
>>> Nothing for other non-JDK projects.
>>>
>>>
>> Shared-Utils is a very good candidate for a multirelease jar.
>> It has a class called Java7Support[1] which uses reflection to make
>> benefit of Java7 features, otherwise it falls back to Java6. Thanks to
>> reflection this code is compatible with Java6.
>>
>> There are probably more cases, and with the introduction I can imagine
>> there are projects who will consider to use it.
>> Even if this is mainly introduced to solve JDK internal issues (I doubt
>> that this is really true), it is great to see that such feature is also
>> exposed and available for the Java Community.
>>
>> Robert
>>
>> [1] https://maven.apache.org/shared/maven-shared-utils/xref/org/
>> apache/maven/shared/utils/io/Java7Support.html
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Building jar targeting multiple Java versions, including 9
Posted by Tibor Digana <ti...@googlemail.com>.
Robert, I disagree with you. There is no reason to increase effort only
because of one class.
Now let's be concrete. I see many managers in commercial firms behave like
non-dev managers, and it is horrible in almost every area because now in
Europe the political decisions become more important than pragmatical
thoughts.
So we have to and we are responsible to talk about _why_ and then _how_ and
not opposite; otherwise it's just politics.
Some people like making release management without coding, some are
consultants and not daily coders. That's sad!
Every month I am telling to all manager - think of cost and what makes
sense. But they don't. They just see themselves and their positions higher
and completely forge how harmful it can be to development staff.
On Wed, Aug 31, 2016 at 11:03 PM, Robert Scholte <rf...@apache.org>
wrote:
> On Wed, 31 Aug 2016 22:02:04 +0200, Tibor Digana <
> tibor.digana@googlemail.com> wrote:
>
> So, we can try to have different source folders for different runtimes.
>>>>
>>> No. If you are developers you would not say this.
>> No developer would develop and merge the same code multiple times!!!
>> Look, now let the maven-compiler-plugin to download jars of the same
>> artifact which was released for Version 1.7 and 1.8, and now let the
>> compiler wrap those two versions with current version 1.9 which is
>> ready to be released. Now you have fat jar MRjar.
>> This means any Java version of the artifact can be chosen on the top of
>> JDK9.
>>
>> Most other plugins would need to be executed for each version as well -
>>>> javadoc, junit
>>>>
>>> No. because the previous Versions were already tested and processed.
>>
>> Again if they *don't* need a separate execution, then why is MRJar needed?
>>>>
>>> Exactly, and now I cannot imaging company which is going to complicate
>> their project with a stupid MRJar and why so if they have WildFly
>> 8.2.1 which supports Java 8 do you think they EE project would
>> struggle with MRJar? Of course not. If they have WildFly 10.x
>> supporting Java 9 then again no developer would build MRJar.
>>
>> I think MRJar is suitable only for JDK internals and it is only
>> because of Oracle has problem with JCP because JCP does not let Oracle
>> to break backwards compatibility and introduce dynamic language
>> features. So Oracle is trying for compromise.
>> Oracle is trying to let you build java.* JDK with javac, interchange
>> internal modules, etc.
>> Nothing for other non-JDK projects.
>>
>>
> Shared-Utils is a very good candidate for a multirelease jar.
> It has a class called Java7Support[1] which uses reflection to make
> benefit of Java7 features, otherwise it falls back to Java6. Thanks to
> reflection this code is compatible with Java6.
>
> There are probably more cases, and with the introduction I can imagine
> there are projects who will consider to use it.
> Even if this is mainly introduced to solve JDK internal issues (I doubt
> that this is really true), it is great to see that such feature is also
> exposed and available for the Java Community.
>
> Robert
>
> [1] https://maven.apache.org/shared/maven-shared-utils/xref/org/
> apache/maven/shared/utils/io/Java7Support.html
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Cheers
Tibor
Re: Building jar targeting multiple Java versions, including 9
Posted by Robert Scholte <rf...@apache.org>.
On Wed, 31 Aug 2016 22:02:04 +0200, Tibor Digana
<ti...@googlemail.com> wrote:
>>> So, we can try to have different source folders for different runtimes.
> No. If you are developers you would not say this.
> No developer would develop and merge the same code multiple times!!!
> Look, now let the maven-compiler-plugin to download jars of the same
> artifact which was released for Version 1.7 and 1.8, and now let the
> compiler wrap those two versions with current version 1.9 which is
> ready to be released. Now you have fat jar MRjar.
> This means any Java version of the artifact can be chosen on the top of
> JDK9.
>
>>> Most other plugins would need to be executed for each version as well
>>> - javadoc, junit
> No. because the previous Versions were already tested and processed.
>
>>> Again if they *don't* need a separate execution, then why is MRJar
>>> needed?
> Exactly, and now I cannot imaging company which is going to complicate
> their project with a stupid MRJar and why so if they have WildFly
> 8.2.1 which supports Java 8 do you think they EE project would
> struggle with MRJar? Of course not. If they have WildFly 10.x
> supporting Java 9 then again no developer would build MRJar.
>
> I think MRJar is suitable only for JDK internals and it is only
> because of Oracle has problem with JCP because JCP does not let Oracle
> to break backwards compatibility and introduce dynamic language
> features. So Oracle is trying for compromise.
> Oracle is trying to let you build java.* JDK with javac, interchange
> internal modules, etc.
> Nothing for other non-JDK projects.
>
Shared-Utils is a very good candidate for a multirelease jar.
It has a class called Java7Support[1] which uses reflection to make
benefit of Java7 features, otherwise it falls back to Java6. Thanks to
reflection this code is compatible with Java6.
There are probably more cases, and with the introduction I can imagine
there are projects who will consider to use it.
Even if this is mainly introduced to solve JDK internal issues (I doubt
that this is really true), it is great to see that such feature is also
exposed and available for the Java Community.
Robert
[1]
https://maven.apache.org/shared/maven-shared-utils/xref/org/apache/maven/shared/utils/io/Java7Support.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Building jar targeting multiple Java versions, including 9
Posted by Tibor Digana <ti...@googlemail.com>.
>>So, we can try to have different source folders for different runtimes.
No. If you are developers you would not say this.
No developer would develop and merge the same code multiple times!!!
Look, now let the maven-compiler-plugin to download jars of the same
artifact which was released for Version 1.7 and 1.8, and now let the
compiler wrap those two versions with current version 1.9 which is
ready to be released. Now you have fat jar MRjar.
This means any Java version of the artifact can be chosen on the top of JDK9.
>>Most other plugins would need to be executed for each version as well - javadoc, junit
No. because the previous Versions were already tested and processed.
>>Again if they *don't* need a separate execution, then why is MRJar needed?
Exactly, and now I cannot imaging company which is going to complicate
their project with a stupid MRJar and why so if they have WildFly
8.2.1 which supports Java 8 do you think they EE project would
struggle with MRJar? Of course not. If they have WildFly 10.x
supporting Java 9 then again no developer would build MRJar.
I think MRJar is suitable only for JDK internals and it is only
because of Oracle has problem with JCP because JCP does not let Oracle
to break backwards compatibility and introduce dynamic language
features. So Oracle is trying for compromise.
Oracle is trying to let you build java.* JDK with javac, interchange
internal modules, etc.
Nothing for other non-JDK projects.
--
Cheers
Tibor
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Building jar targeting multiple Java versions, including 9
Posted by Richard Sand <rs...@idfconnect.com>.
Hi Paul - I certainly believe you that you've thought this through alot
further than I have. :-) I'm just speaking about a general sense of
striving towards keeping the projects as simple as possible. I think
that sometimes its a bit too easy to state that some build pattern
should just be done with a multi-module project, when a small fix or
improvement will neatly accomplish the same in a single POM. So I'm just
making a general sweeping statement and not specifically about MRJars.
Now I'm just typing out loud for discussion...
Java9 is definitely a paradigm shift more so than almost any other
release of java. I see your point - the MRJar isn't just about having
source and target versions in the compiler plugin. If the MRJar doesn't
leverage new runtime features, e.g. lambdas in Java8, then whats the
point of even having the MRJar? Just set the target to the lowest common
denominator and be done with it.
So the actual source code will be different for each java runtime -
otherwise there's no point. So, we can try to have different source
folders for different runtimes. Of course, most IDEs aren't going to
support enforcing different compiler settings etc. for different source
folders within a single project, but lets even set that aside for now -
just thinking about the maven implications:
Maven itself would have to be run with Java9The compiler plugin would
need a different configuration for each java versionMost other plugins
would need to be executed for each version as well - javadoc, junit,
surefire etc. Again if they *don't* need a separate execution, then why
is MRJar needed?At the very least, each execution would have unique
attached artifacts, either with classifiers or new artifact idsState
would need to be maintained from plugin to plugin about the specific jre
in use for that invocation
That certainly sounds like a multi-module project - at least that may be
the easiest solution. But if I wanted to use profiles and have a
separate profile for each JRE, and at the very end of the POM aggregate
the artifacts together - I can see that working as well.
You know, I've had similar struggles with multi-artifact projects as
well regardless of Java9. Example, for one particular project I build
multiple WAR files, each with a different classifier, with some
packaging customizations for different deployment models e.g. I have 1
war file that includes slf4j+logback, and another warfile that has
slf4j+jul bridge. There are other permutations too, e.g. some packages
have obfuscated code while others are not. So I have multiple executions
of maven-war-plugin, and in some cases I need to explicitly invoke the
install & deploy plugins too. But I have resisted breaking this up into
multiple projects with multiple poms simply because its easier (for me)
to work with all of the packaging and distribution logic in one place,
and maven provides the capabilities with profiles, executions, etc. to
give the flexibility I need. But there have certainly been times that
I've thought about just going multi-module.
I guess my long rambling point is that I can see MRJar being done both
ways, and wouldn't want to pigeon-hole anyone into doing it one way vs
another.
Richard Sand | CEO
IDF Connect, Inc. <http://www.idfconnect.com/>
2207 Concord Ave, #359
Wilmington | Delaware 19803 | USA
Office: +1 888 765 1611 | Fax: +1 866 765 7284
Mobile: +1 267 984 3651
------ Original Message ------
From: "Paul Benedict" <pb...@apache.org>
To: "Maven Developers List" <de...@maven.apache.org>; "Richard Sand"
<rs...@idfconnect.com>
Sent: 8/31/2016 11:50:26 AM
Subject: Re: Building jar targeting multiple Java versions, including 9
>Richard, I share your sentiment. I've given this subject some thought
>and
>I've come to the conclusion that a full project life cycle for each
>Java
>version is necessary for good measure. You will want to write main and
>test
>code for each class. IDEs treat individual projects as wholly contained
>so
>that means their own IDE project preferences too (code style, compiler
>version, etc.). I believe a mental shift is necessary here (not
>directed at
>you, per se, but directed toward anyone wanting to do a Multi-Release
>JAR)
>to accept that these really are individual projects -- not just
>subsets.
>
>However, I am completely willing to hear the opposite and learn why my
>opinion is wrong too. Feel free to tell me why it's better as one
>project.
>MRJAR feature is so new I am bound to learn much from others.
>
>Cheers,
>Paul
>
>On Wed, Aug 31, 2016 at 10:46 AM, Richard Sand <rs...@idfconnect.com>
>wrote:
>
>> Understood. I guess it wouldn't be horrible if it required a
>>multi-module
>> maven project but I would still prefer to avoid introducing a
>>requirement
>> for multi-module projects anywhere.
>>
>> Richard Sand | CEO
>> IDF Connect, Inc.
>> 2207 Concord Ave, #359
>> Wilmington | Delaware 19803 | USA
>> Office: +1 888 765 1611 | Fax: +1 866 765 7284
>> Mobile: +1 267 984 3651
>>
>>
>>
>>
>> ------ Original Message ------
>> From: "Paul Benedict" <pb...@apache.org>
>> To: "Richard Sand" <rs...@idfconnect.com>
>> Cc: "ZML-Apache-Maven-Developers" <de...@maven.apache.org>
>> Sent: 8/31/2016 11:10:33 AM
>> Subject: Re: Building jar targeting multiple Java versions, including
>>9
>>
>> To be clear, I was purely addressing the concern of a Multi-Release
>>JAR.
>>>
>>> Cheers,
>>> Paul
>>>
>>> On Wed, Aug 31, 2016 at 10:09 AM, Richard Sand
>>><rs...@idfconnect.com>
>>> wrote:
>>>
>>> I definitely concur with Robert's point: "I don't think we make
>>>> developers
>>>> very happy if they are advised to have a multimodule project just
>>>>to be
>>>> able to compile the module-info file.". I can live with the
>>>>requirement
>>>> that I must run Maven with Java9 to support creating module-info
>>>>and
>>>> having
>>>> the addtional modules created by a separate plugin. Simplicity
>>>>wherever
>>>> possible.
>>>>
>>>> Best regards,
>>>>
>>>> Richard Sand | CEO
>>>> IDF Connect, Inc.
>>>> 2207 Concord Ave, #359
>>>> Wilmington | Delaware 19803 | USA
>>>> Office: +1 888 765 1611 | Fax: +1 866 765 7284
>>>> Mobile: +1 267 984 3651
>>>>
>>>>
>>>> ------ Original Message ------
>>>> From: "Robert Scholte" <rf...@apache.org>
>>>> To: "ZML-Apache-Maven-Developers" <de...@maven.apache.org>; "Paul
>>>> Benedict"
>>>> <pb...@apache.org>
>>>> Sent: 8/31/2016 10:39:52 AM
>>>> Subject: Re: Building jar targeting multiple Java versions,
>>>>including 9
>>>>
>>>> Hi Paul,
>>>>
>>>>>
>>>>> no problem to move it to this thread. It is indeed about "The
>>>>>Maven
>>>>> Way", although we may need to start from the beginning,
>>>>>explaining the
>>>>> issue we're facing.
>>>>>
>>>>> Let's use ASM as an example, their 6.0_ALPHA has been built like
>>>>>this,
>>>>> although without Maven.
>>>>> ASM is an all purpose Java bytecode manipulation and analysis
>>>>> framework.
>>>>> IIRC their code is compatible with Java 1.2, but they've also
>>>>>added a
>>>>> module-info for those who want to use this dependency within a
>>>>> Java9/Jigsaw project.
>>>>> module-info MUST be built with Java9 with source/target or
>>>>>release = 9.
>>>>> Other sources must be built with an older JDK with source/target
>>>>>1.2
>>>>>
>>>>> There are several ways to solve this:
>>>>> - multi-module project and multi release jar like Paul suggest.
>>>>> However,
>>>>> IIRC the specs say that the module-info MUST exist in the root.
>>>>> - 2 source folders, src/main/java and src/main/jigsaw, both
>>>>>writing to
>>>>> target/classes. Here it is quite clear what happens per
>>>>>source-folder.
>>>>> - 1 source folder and all the magic of calling javac twice in the
>>>>> maven-compiler-plugin. I started with this, but I don't like it.
>>>>> Details
>>>>> are below.
>>>>> - 1 source folder and 2 execution blocks (one excluding
>>>>>module-info,
>>>>> one
>>>>> only including module-info).
>>>>>
>>>>> We shouldn't be looking at Maven alone, but also at IDE support.
>>>>>AFAIK
>>>>> Netbeans and IntelliJ simply call Maven. Eclipse is probably hard
>>>>>due
>>>>> to
>>>>> the m2eclipse extensions.
>>>>>
>>>>> Now back to Pauls suggestion. I don't think we make developers
>>>>>very
>>>>> happy if they are advised to have a multimodule project just to
>>>>>be
>>>>> able
>>>>> to compile the module-info file.
>>>>> I am aware that this is mainly an issue for library builders, end
>>>>>users
>>>>> simply build everything with Java9, no problems there. From
>>>>>library
>>>>> builders you can expect that they don't mind adding extra
>>>>> configuration to
>>>>> build their jar, but forcing them to set up a Maven multimodule
>>>>> project is
>>>>> not really nice.
>>>>> I would expect the module-info close to the related sourcefiles,
>>>>>so I
>>>>> would prefer in the same (single) MavenProject.
>>>>>
>>>>> *Unless* IDEs are so strong with handling multi release jars that
>>>>>it
>>>>> looks like I'm adjusting the module-info, even though it is
>>>>>actually
>>>>> located somewhere else.
>>>>>
>>>>> So let's see the opinions from others.
>>>>>
>>>>> thanks,
>>>>> Robert
>>>>>
>>>>> On Wed, 31 Aug 2016 15:59:04 +0200, Paul Benedict <
>>>>> pbenedict@apache.org>
>>>>> wrote:
>>>>>
>>>>> Robert, I'm responding to dev@maven so we can discuss Maven
>>>>>
>>>>>> philosophies...
>>>>>>
>>>>>> I believe the pattern should be based on a multi-module project.
>>>>>>Each
>>>>>> module should target the expected JDK version. Then introduce a
>>>>>>new
>>>>>> "mrjar"
>>>>>> type for the parent that knows how to bind them all together
>>>>>>into a
>>>>>> Multi-Release JAR.
>>>>>>
>>>>>> Cheers,
>>>>>> Paul
>>>>>>
>>>>>> On Wed, Aug 31, 2016 at 6:10 AM, Robert Scholte
>>>>>><rfscholte@apache.org
>>>>>> >
>>>>>> wrote:
>>>>>>
>>>>>> I've been working on the implementation of this in the
>>>>>>
>>>>>>> maven-compiler-plugin, but I'm not really pleased with the
>>>>>>>result.
>>>>>>> The problem is that in the worst case scenario we have to work
>>>>>>>with 3
>>>>>>> different versions of Java:
>>>>>>> - The Maven Runtime (set as JAVA_HOME)
>>>>>>> - JDK for the module-info.java
>>>>>>> - JDK for all other source files.
>>>>>>>
>>>>>>> The example below worked because all three were set to JDK9.
>>>>>>> But based on the source/target of 1.6 I cannot predict which
>>>>>>>JDK is
>>>>>>> used,
>>>>>>> only that it is at least JDK6. Should the plugin switch to
>>>>>>>another
>>>>>>> JDK?
>>>>>>> And if you want to compile with source/target 1.5 or less,
>>>>>>>you're in
>>>>>>> trouble. There's something called toolchain, where you can
>>>>>>>specify
>>>>>>> the
>>>>>>> JavaHome per version, but in case of maven-compiler-plugin it
>>>>>>>assumes
>>>>>>> that
>>>>>>> all java-related plugins and execution blocks want to use the
>>>>>>>same
>>>>>>> toolchain through the whole Maven project.
>>>>>>> The good news is that for the maven-jdeps-plugin I improved
>>>>>>>this
>>>>>>> part in
>>>>>>> Maven 3.3.1, since this plugin only works with Java8 and above,
>>>>>>>which
>>>>>>> doesn't have to be the same JDK to compile the sources with.
>>>>>>>Now you
>>>>>>> can
>>>>>>> simple say: I want the toolchain for version X. This feature
>>>>>>>needs
>>>>>>> to be
>>>>>>> added to the plugin.
>>>>>>>
>>>>>>> That said I think I will write a recipe for this. This is first
>>>>>>>of
>>>>>>> all
>>>>>>> an
>>>>>>> issue for library writers who want to have their jar compatible
>>>>>>>with
>>>>>>> multiple Java versions for their end users.
>>>>>>> Result: One javac call per execution block as it was meant to
>>>>>>>be.
>>>>>>>
>>>>>>> thanks,
>>>>>>> Robert
>>>>>>>
>>>>>>> On Fri, 26 Aug 2016 15:31:07 +0200, Oliver Gondža
>>>>>>><ogondza@gmail.com
>>>>>>> >
>>>>>>> wrote:
>>>>>>>
>>>>>>> Thank you all for your suggestions. I managed to get the
>>>>>>>project to
>>>>>>> build
>>>>>>>
>>>>>>> with following maven setup:
>>>>>>>>
>>>>>>>> ```
>>>>>>>> <!--
>>>>>>>> When using compiler from java 8 and older, ignore
>>>>>>>>module
>>>>>>>> files
>>>>>>>> altogether.
>>>>>>>> Otherwise, use 2 phase compilation to build
>>>>>>>> - all classes for target version and
>>>>>>>> - module-info.java with 9+ source and target level
>>>>>>>> -->
>>>>>>>> <build>
>>>>>>>> <plugins>
>>>>>>>> <plugin>
>>>>>>>> <groupId>org.apache.maven.plugins</groupId>
>>>>>>>> <artifactId>maven-compiler-plugin</artifactId>
>>>>>>>> <version>3.5.1</version>
>>>>>>>> <configuration>
>>>>>>>> <source>1.6</source>
>>>>>>>> <target>1.6</target>
>>>>>>>> </configuration>
>>>>>>>> <executions>
>>>>>>>> <execution>
>>>>>>>> <id>default-compile</id>
>>>>>>>> <configuration>
>>>>>>>> <excludes>
>>>>>>>> <exclude>**/module-info.java</exclude>
>>>>>>>> </excludes>
>>>>>>>> </configuration>
>>>>>>>> </execution>
>>>>>>>> </executions>
>>>>>>>> </plugin>
>>>>>>>> </plugins>
>>>>>>>> </build>
>>>>>>>>
>>>>>>>> <profiles>
>>>>>>>> <profile>
>>>>>>>> <id>jigsaw</id>
>>>>>>>> <activation>
>>>>>>>> <jdk>[1.9,)</jdk>
>>>>>>>> </activation>
>>>>>>>> <build>
>>>>>>>> <plugins>
>>>>>>>> <plugin>
>>>>>>>> <groupId>org.apache.maven.plugins</groupId>
>>>>>>>> <artifactId>maven-compiler-plugin</artifactId>
>>>>>>>> <version>3.5.1</version>
>>>>>>>> <configuration>
>>>>>>>> <source>1.9</source>
>>>>>>>> <target>1.9</target>
>>>>>>>> </configuration>
>>>>>>>> <executions>
>>>>>>>> <execution>
>>>>>>>> <id>module-infos</id>
>>>>>>>> <phase>compile</phase>
>>>>>>>> <goals>
>>>>>>>> <goal>compile</goal>
>>>>>>>> </goals>
>>>>>>>> <configuration>
>>>>>>>> <includes>
>>>>>>>> <include>**/module-info.java</include>
>>>>>>>> </includes>
>>>>>>>> </configuration>
>>>>>>>> </execution>
>>>>>>>> </executions>
>>>>>>>> </plugin>
>>>>>>>> </plugins>
>>>>>>>> </build>
>>>>>>>> </profile>
>>>>>>>> </profiles>
>>>>>>>> ```
>>>>>>>>
>>>>>>>> It does compile with older javac versions as a bonus. Given
>>>>>>>>this is
>>>>>>>> nothing else than using `-source 9 -target 9` for
>>>>>>>>module-info.java
>>>>>>>> if
>>>>>>>> present, I dare to say maven-compiler-plugin can be adapted to
>>>>>>>> figure
>>>>>>>> this
>>>>>>>> out on its own.
>>>>>>>>
>>>>>>>>
>>>>>>>> -----------------------------------------------------------
>>>>> ----------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
Re: Building jar targeting multiple Java versions, including 9
Posted by Paul Benedict <pb...@apache.org>.
Richard, I share your sentiment. I've given this subject some thought and
I've come to the conclusion that a full project life cycle for each Java
version is necessary for good measure. You will want to write main and test
code for each class. IDEs treat individual projects as wholly contained so
that means their own IDE project preferences too (code style, compiler
version, etc.). I believe a mental shift is necessary here (not directed at
you, per se, but directed toward anyone wanting to do a Multi-Release JAR)
to accept that these really are individual projects -- not just subsets.
However, I am completely willing to hear the opposite and learn why my
opinion is wrong too. Feel free to tell me why it's better as one project.
MRJAR feature is so new I am bound to learn much from others.
Cheers,
Paul
On Wed, Aug 31, 2016 at 10:46 AM, Richard Sand <rs...@idfconnect.com> wrote:
> Understood. I guess it wouldn't be horrible if it required a multi-module
> maven project but I would still prefer to avoid introducing a requirement
> for multi-module projects anywhere.
>
> Richard Sand | CEO
> IDF Connect, Inc.
> 2207 Concord Ave, #359
> Wilmington | Delaware 19803 | USA
> Office: +1 888 765 1611 | Fax: +1 866 765 7284
> Mobile: +1 267 984 3651
>
>
>
>
> ------ Original Message ------
> From: "Paul Benedict" <pb...@apache.org>
> To: "Richard Sand" <rs...@idfconnect.com>
> Cc: "ZML-Apache-Maven-Developers" <de...@maven.apache.org>
> Sent: 8/31/2016 11:10:33 AM
> Subject: Re: Building jar targeting multiple Java versions, including 9
>
> To be clear, I was purely addressing the concern of a Multi-Release JAR.
>>
>> Cheers,
>> Paul
>>
>> On Wed, Aug 31, 2016 at 10:09 AM, Richard Sand <rs...@idfconnect.com>
>> wrote:
>>
>> I definitely concur with Robert's point: "I don't think we make
>>> developers
>>> very happy if they are advised to have a multimodule project just to be
>>> able to compile the module-info file.". I can live with the requirement
>>> that I must run Maven with Java9 to support creating module-info and
>>> having
>>> the addtional modules created by a separate plugin. Simplicity wherever
>>> possible.
>>>
>>> Best regards,
>>>
>>> Richard Sand | CEO
>>> IDF Connect, Inc.
>>> 2207 Concord Ave, #359
>>> Wilmington | Delaware 19803 | USA
>>> Office: +1 888 765 1611 | Fax: +1 866 765 7284
>>> Mobile: +1 267 984 3651
>>>
>>>
>>> ------ Original Message ------
>>> From: "Robert Scholte" <rf...@apache.org>
>>> To: "ZML-Apache-Maven-Developers" <de...@maven.apache.org>; "Paul
>>> Benedict"
>>> <pb...@apache.org>
>>> Sent: 8/31/2016 10:39:52 AM
>>> Subject: Re: Building jar targeting multiple Java versions, including 9
>>>
>>> Hi Paul,
>>>
>>>>
>>>> no problem to move it to this thread. It is indeed about "The Maven
>>>> Way", although we may need to start from the beginning, explaining the
>>>> issue we're facing.
>>>>
>>>> Let's use ASM as an example, their 6.0_ALPHA has been built like this,
>>>> although without Maven.
>>>> ASM is an all purpose Java bytecode manipulation and analysis
>>>> framework.
>>>> IIRC their code is compatible with Java 1.2, but they've also added a
>>>> module-info for those who want to use this dependency within a
>>>> Java9/Jigsaw project.
>>>> module-info MUST be built with Java9 with source/target or release = 9.
>>>> Other sources must be built with an older JDK with source/target 1.2
>>>>
>>>> There are several ways to solve this:
>>>> - multi-module project and multi release jar like Paul suggest.
>>>> However,
>>>> IIRC the specs say that the module-info MUST exist in the root.
>>>> - 2 source folders, src/main/java and src/main/jigsaw, both writing to
>>>> target/classes. Here it is quite clear what happens per source-folder.
>>>> - 1 source folder and all the magic of calling javac twice in the
>>>> maven-compiler-plugin. I started with this, but I don't like it.
>>>> Details
>>>> are below.
>>>> - 1 source folder and 2 execution blocks (one excluding module-info,
>>>> one
>>>> only including module-info).
>>>>
>>>> We shouldn't be looking at Maven alone, but also at IDE support. AFAIK
>>>> Netbeans and IntelliJ simply call Maven. Eclipse is probably hard due
>>>> to
>>>> the m2eclipse extensions.
>>>>
>>>> Now back to Pauls suggestion. I don't think we make developers very
>>>> happy if they are advised to have a multimodule project just to be
>>>> able
>>>> to compile the module-info file.
>>>> I am aware that this is mainly an issue for library builders, end users
>>>> simply build everything with Java9, no problems there. From library
>>>> builders you can expect that they don't mind adding extra
>>>> configuration to
>>>> build their jar, but forcing them to set up a Maven multimodule
>>>> project is
>>>> not really nice.
>>>> I would expect the module-info close to the related sourcefiles, so I
>>>> would prefer in the same (single) MavenProject.
>>>>
>>>> *Unless* IDEs are so strong with handling multi release jars that it
>>>> looks like I'm adjusting the module-info, even though it is actually
>>>> located somewhere else.
>>>>
>>>> So let's see the opinions from others.
>>>>
>>>> thanks,
>>>> Robert
>>>>
>>>> On Wed, 31 Aug 2016 15:59:04 +0200, Paul Benedict <
>>>> pbenedict@apache.org>
>>>> wrote:
>>>>
>>>> Robert, I'm responding to dev@maven so we can discuss Maven
>>>>
>>>>> philosophies...
>>>>>
>>>>> I believe the pattern should be based on a multi-module project. Each
>>>>> module should target the expected JDK version. Then introduce a new
>>>>> "mrjar"
>>>>> type for the parent that knows how to bind them all together into a
>>>>> Multi-Release JAR.
>>>>>
>>>>> Cheers,
>>>>> Paul
>>>>>
>>>>> On Wed, Aug 31, 2016 at 6:10 AM, Robert Scholte <rfscholte@apache.org
>>>>> >
>>>>> wrote:
>>>>>
>>>>> I've been working on the implementation of this in the
>>>>>
>>>>>> maven-compiler-plugin, but I'm not really pleased with the result.
>>>>>> The problem is that in the worst case scenario we have to work with 3
>>>>>> different versions of Java:
>>>>>> - The Maven Runtime (set as JAVA_HOME)
>>>>>> - JDK for the module-info.java
>>>>>> - JDK for all other source files.
>>>>>>
>>>>>> The example below worked because all three were set to JDK9.
>>>>>> But based on the source/target of 1.6 I cannot predict which JDK is
>>>>>> used,
>>>>>> only that it is at least JDK6. Should the plugin switch to another
>>>>>> JDK?
>>>>>> And if you want to compile with source/target 1.5 or less, you're in
>>>>>> trouble. There's something called toolchain, where you can specify
>>>>>> the
>>>>>> JavaHome per version, but in case of maven-compiler-plugin it assumes
>>>>>> that
>>>>>> all java-related plugins and execution blocks want to use the same
>>>>>> toolchain through the whole Maven project.
>>>>>> The good news is that for the maven-jdeps-plugin I improved this
>>>>>> part in
>>>>>> Maven 3.3.1, since this plugin only works with Java8 and above, which
>>>>>> doesn't have to be the same JDK to compile the sources with. Now you
>>>>>> can
>>>>>> simple say: I want the toolchain for version X. This feature needs
>>>>>> to be
>>>>>> added to the plugin.
>>>>>>
>>>>>> That said I think I will write a recipe for this. This is first of
>>>>>> all
>>>>>> an
>>>>>> issue for library writers who want to have their jar compatible with
>>>>>> multiple Java versions for their end users.
>>>>>> Result: One javac call per execution block as it was meant to be.
>>>>>>
>>>>>> thanks,
>>>>>> Robert
>>>>>>
>>>>>> On Fri, 26 Aug 2016 15:31:07 +0200, Oliver Gondža <ogondza@gmail.com
>>>>>> >
>>>>>> wrote:
>>>>>>
>>>>>> Thank you all for your suggestions. I managed to get the project to
>>>>>> build
>>>>>>
>>>>>> with following maven setup:
>>>>>>>
>>>>>>> ```
>>>>>>> <!--
>>>>>>> When using compiler from java 8 and older, ignore module
>>>>>>> files
>>>>>>> altogether.
>>>>>>> Otherwise, use 2 phase compilation to build
>>>>>>> - all classes for target version and
>>>>>>> - module-info.java with 9+ source and target level
>>>>>>> -->
>>>>>>> <build>
>>>>>>> <plugins>
>>>>>>> <plugin>
>>>>>>> <groupId>org.apache.maven.plugins</groupId>
>>>>>>> <artifactId>maven-compiler-plugin</artifactId>
>>>>>>> <version>3.5.1</version>
>>>>>>> <configuration>
>>>>>>> <source>1.6</source>
>>>>>>> <target>1.6</target>
>>>>>>> </configuration>
>>>>>>> <executions>
>>>>>>> <execution>
>>>>>>> <id>default-compile</id>
>>>>>>> <configuration>
>>>>>>> <excludes>
>>>>>>> <exclude>**/module-info.java</exclude>
>>>>>>> </excludes>
>>>>>>> </configuration>
>>>>>>> </execution>
>>>>>>> </executions>
>>>>>>> </plugin>
>>>>>>> </plugins>
>>>>>>> </build>
>>>>>>>
>>>>>>> <profiles>
>>>>>>> <profile>
>>>>>>> <id>jigsaw</id>
>>>>>>> <activation>
>>>>>>> <jdk>[1.9,)</jdk>
>>>>>>> </activation>
>>>>>>> <build>
>>>>>>> <plugins>
>>>>>>> <plugin>
>>>>>>> <groupId>org.apache.maven.plugins</groupId>
>>>>>>> <artifactId>maven-compiler-plugin</artifactId>
>>>>>>> <version>3.5.1</version>
>>>>>>> <configuration>
>>>>>>> <source>1.9</source>
>>>>>>> <target>1.9</target>
>>>>>>> </configuration>
>>>>>>> <executions>
>>>>>>> <execution>
>>>>>>> <id>module-infos</id>
>>>>>>> <phase>compile</phase>
>>>>>>> <goals>
>>>>>>> <goal>compile</goal>
>>>>>>> </goals>
>>>>>>> <configuration>
>>>>>>> <includes>
>>>>>>> <include>**/module-info.java</include>
>>>>>>> </includes>
>>>>>>> </configuration>
>>>>>>> </execution>
>>>>>>> </executions>
>>>>>>> </plugin>
>>>>>>> </plugins>
>>>>>>> </build>
>>>>>>> </profile>
>>>>>>> </profiles>
>>>>>>> ```
>>>>>>>
>>>>>>> It does compile with older javac versions as a bonus. Given this is
>>>>>>> nothing else than using `-source 9 -target 9` for module-info.java
>>>>>>> if
>>>>>>> present, I dare to say maven-compiler-plugin can be adapted to
>>>>>>> figure
>>>>>>> this
>>>>>>> out on its own.
>>>>>>>
>>>>>>>
>>>>>>> -----------------------------------------------------------
>>>> ----------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Building jar targeting multiple Java versions, including 9
Posted by Richard Sand <rs...@idfconnect.com>.
Understood. I guess it wouldn't be horrible if it required a
multi-module maven project but I would still prefer to avoid introducing
a requirement for multi-module projects anywhere.
Richard Sand | CEO
IDF Connect, Inc.
2207 Concord Ave, #359
Wilmington | Delaware 19803 | USA
Office: +1 888 765 1611 | Fax: +1 866 765 7284
Mobile: +1 267 984 3651
------ Original Message ------
From: "Paul Benedict" <pb...@apache.org>
To: "Richard Sand" <rs...@idfconnect.com>
Cc: "ZML-Apache-Maven-Developers" <de...@maven.apache.org>
Sent: 8/31/2016 11:10:33 AM
Subject: Re: Building jar targeting multiple Java versions, including 9
>To be clear, I was purely addressing the concern of a Multi-Release
>JAR.
>
>Cheers,
>Paul
>
>On Wed, Aug 31, 2016 at 10:09 AM, Richard Sand <rs...@idfconnect.com>
>wrote:
>
>> I definitely concur with Robert's point: "I don't think we make
>>developers
>> very happy if they are advised to have a multimodule project just to
>>be
>> able to compile the module-info file.". I can live with the
>>requirement
>> that I must run Maven with Java9 to support creating module-info and
>>having
>> the addtional modules created by a separate plugin. Simplicity
>>wherever
>> possible.
>>
>> Best regards,
>>
>> Richard Sand | CEO
>> IDF Connect, Inc.
>> 2207 Concord Ave, #359
>> Wilmington | Delaware 19803 | USA
>> Office: +1 888 765 1611 | Fax: +1 866 765 7284
>> Mobile: +1 267 984 3651
>>
>>
>> ------ Original Message ------
>> From: "Robert Scholte" <rf...@apache.org>
>> To: "ZML-Apache-Maven-Developers" <de...@maven.apache.org>; "Paul
>>Benedict"
>> <pb...@apache.org>
>> Sent: 8/31/2016 10:39:52 AM
>> Subject: Re: Building jar targeting multiple Java versions, including
>>9
>>
>> Hi Paul,
>>>
>>> no problem to move it to this thread. It is indeed about "The Maven
>>> Way", although we may need to start from the beginning, explaining
>>>the
>>> issue we're facing.
>>>
>>> Let's use ASM as an example, their 6.0_ALPHA has been built like
>>>this,
>>> although without Maven.
>>> ASM is an all purpose Java bytecode manipulation and analysis
>>>framework.
>>> IIRC their code is compatible with Java 1.2, but they've also added
>>>a
>>> module-info for those who want to use this dependency within a
>>> Java9/Jigsaw project.
>>> module-info MUST be built with Java9 with source/target or release =
>>>9.
>>> Other sources must be built with an older JDK with source/target 1.2
>>>
>>> There are several ways to solve this:
>>> - multi-module project and multi release jar like Paul suggest.
>>>However,
>>> IIRC the specs say that the module-info MUST exist in the root.
>>> - 2 source folders, src/main/java and src/main/jigsaw, both writing
>>>to
>>> target/classes. Here it is quite clear what happens per
>>>source-folder.
>>> - 1 source folder and all the magic of calling javac twice in the
>>> maven-compiler-plugin. I started with this, but I don't like it.
>>>Details
>>> are below.
>>> - 1 source folder and 2 execution blocks (one excluding module-info,
>>>one
>>> only including module-info).
>>>
>>> We shouldn't be looking at Maven alone, but also at IDE support.
>>>AFAIK
>>> Netbeans and IntelliJ simply call Maven. Eclipse is probably hard
>>>due to
>>> the m2eclipse extensions.
>>>
>>> Now back to Pauls suggestion. I don't think we make developers very
>>> happy if they are advised to have a multimodule project just to be
>>>able
>>> to compile the module-info file.
>>> I am aware that this is mainly an issue for library builders, end
>>>users
>>> simply build everything with Java9, no problems there. From library
>>> builders you can expect that they don't mind adding extra
>>>configuration to
>>> build their jar, but forcing them to set up a Maven multimodule
>>>project is
>>> not really nice.
>>> I would expect the module-info close to the related sourcefiles, so
>>>I
>>> would prefer in the same (single) MavenProject.
>>>
>>> *Unless* IDEs are so strong with handling multi release jars that it
>>> looks like I'm adjusting the module-info, even though it is
>>>actually
>>> located somewhere else.
>>>
>>> So let's see the opinions from others.
>>>
>>> thanks,
>>> Robert
>>>
>>> On Wed, 31 Aug 2016 15:59:04 +0200, Paul Benedict
>>><pb...@apache.org>
>>> wrote:
>>>
>>> Robert, I'm responding to dev@maven so we can discuss Maven
>>>> philosophies...
>>>>
>>>> I believe the pattern should be based on a multi-module project.
>>>>Each
>>>> module should target the expected JDK version. Then introduce a new
>>>> "mrjar"
>>>> type for the parent that knows how to bind them all together into a
>>>> Multi-Release JAR.
>>>>
>>>> Cheers,
>>>> Paul
>>>>
>>>> On Wed, Aug 31, 2016 at 6:10 AM, Robert Scholte
>>>><rf...@apache.org>
>>>> wrote:
>>>>
>>>> I've been working on the implementation of this in the
>>>>> maven-compiler-plugin, but I'm not really pleased with the result.
>>>>> The problem is that in the worst case scenario we have to work
>>>>>with 3
>>>>> different versions of Java:
>>>>> - The Maven Runtime (set as JAVA_HOME)
>>>>> - JDK for the module-info.java
>>>>> - JDK for all other source files.
>>>>>
>>>>> The example below worked because all three were set to JDK9.
>>>>> But based on the source/target of 1.6 I cannot predict which JDK
>>>>>is
>>>>> used,
>>>>> only that it is at least JDK6. Should the plugin switch to another
>>>>>JDK?
>>>>> And if you want to compile with source/target 1.5 or less, you're
>>>>>in
>>>>> trouble. There's something called toolchain, where you can specify
>>>>>the
>>>>> JavaHome per version, but in case of maven-compiler-plugin it
>>>>>assumes
>>>>> that
>>>>> all java-related plugins and execution blocks want to use the same
>>>>> toolchain through the whole Maven project.
>>>>> The good news is that for the maven-jdeps-plugin I improved this
>>>>>part in
>>>>> Maven 3.3.1, since this plugin only works with Java8 and above,
>>>>>which
>>>>> doesn't have to be the same JDK to compile the sources with. Now
>>>>>you can
>>>>> simple say: I want the toolchain for version X. This feature needs
>>>>>to be
>>>>> added to the plugin.
>>>>>
>>>>> That said I think I will write a recipe for this. This is first of
>>>>>all
>>>>> an
>>>>> issue for library writers who want to have their jar compatible
>>>>>with
>>>>> multiple Java versions for their end users.
>>>>> Result: One javac call per execution block as it was meant to be.
>>>>>
>>>>> thanks,
>>>>> Robert
>>>>>
>>>>> On Fri, 26 Aug 2016 15:31:07 +0200, Oliver Gondža
>>>>><og...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> Thank you all for your suggestions. I managed to get the project
>>>>>to
>>>>> build
>>>>>
>>>>>> with following maven setup:
>>>>>>
>>>>>> ```
>>>>>> <!--
>>>>>> When using compiler from java 8 and older, ignore module
>>>>>>files
>>>>>> altogether.
>>>>>> Otherwise, use 2 phase compilation to build
>>>>>> - all classes for target version and
>>>>>> - module-info.java with 9+ source and target level
>>>>>> -->
>>>>>> <build>
>>>>>> <plugins>
>>>>>> <plugin>
>>>>>> <groupId>org.apache.maven.plugins</groupId>
>>>>>> <artifactId>maven-compiler-plugin</artifactId>
>>>>>> <version>3.5.1</version>
>>>>>> <configuration>
>>>>>> <source>1.6</source>
>>>>>> <target>1.6</target>
>>>>>> </configuration>
>>>>>> <executions>
>>>>>> <execution>
>>>>>> <id>default-compile</id>
>>>>>> <configuration>
>>>>>> <excludes>
>>>>>> <exclude>**/module-info.java</exclude>
>>>>>> </excludes>
>>>>>> </configuration>
>>>>>> </execution>
>>>>>> </executions>
>>>>>> </plugin>
>>>>>> </plugins>
>>>>>> </build>
>>>>>>
>>>>>> <profiles>
>>>>>> <profile>
>>>>>> <id>jigsaw</id>
>>>>>> <activation>
>>>>>> <jdk>[1.9,)</jdk>
>>>>>> </activation>
>>>>>> <build>
>>>>>> <plugins>
>>>>>> <plugin>
>>>>>> <groupId>org.apache.maven.plugins</groupId>
>>>>>> <artifactId>maven-compiler-plugin</artifactId>
>>>>>> <version>3.5.1</version>
>>>>>> <configuration>
>>>>>> <source>1.9</source>
>>>>>> <target>1.9</target>
>>>>>> </configuration>
>>>>>> <executions>
>>>>>> <execution>
>>>>>> <id>module-infos</id>
>>>>>> <phase>compile</phase>
>>>>>> <goals>
>>>>>> <goal>compile</goal>
>>>>>> </goals>
>>>>>> <configuration>
>>>>>> <includes>
>>>>>> <include>**/module-info.java</include>
>>>>>> </includes>
>>>>>> </configuration>
>>>>>> </execution>
>>>>>> </executions>
>>>>>> </plugin>
>>>>>> </plugins>
>>>>>> </build>
>>>>>> </profile>
>>>>>> </profiles>
>>>>>> ```
>>>>>>
>>>>>> It does compile with older javac versions as a bonus. Given this
>>>>>>is
>>>>>> nothing else than using `-source 9 -target 9` for
>>>>>>module-info.java if
>>>>>> present, I dare to say maven-compiler-plugin can be adapted to
>>>>>>figure
>>>>>> this
>>>>>> out on its own.
>>>>>>
>>>>>>
>>>
>>>---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Building jar targeting multiple Java versions, including 9
Posted by Paul Benedict <pb...@apache.org>.
To be clear, I was purely addressing the concern of a Multi-Release JAR.
Cheers,
Paul
On Wed, Aug 31, 2016 at 10:09 AM, Richard Sand <rs...@idfconnect.com> wrote:
> I definitely concur with Robert's point: "I don't think we make developers
> very happy if they are advised to have a multimodule project just to be
> able to compile the module-info file.". I can live with the requirement
> that I must run Maven with Java9 to support creating module-info and having
> the addtional modules created by a separate plugin. Simplicity wherever
> possible.
>
> Best regards,
>
> Richard Sand | CEO
> IDF Connect, Inc.
> 2207 Concord Ave, #359
> Wilmington | Delaware 19803 | USA
> Office: +1 888 765 1611 | Fax: +1 866 765 7284
> Mobile: +1 267 984 3651
>
>
> ------ Original Message ------
> From: "Robert Scholte" <rf...@apache.org>
> To: "ZML-Apache-Maven-Developers" <de...@maven.apache.org>; "Paul Benedict"
> <pb...@apache.org>
> Sent: 8/31/2016 10:39:52 AM
> Subject: Re: Building jar targeting multiple Java versions, including 9
>
> Hi Paul,
>>
>> no problem to move it to this thread. It is indeed about "The Maven
>> Way", although we may need to start from the beginning, explaining the
>> issue we're facing.
>>
>> Let's use ASM as an example, their 6.0_ALPHA has been built like this,
>> although without Maven.
>> ASM is an all purpose Java bytecode manipulation and analysis framework.
>> IIRC their code is compatible with Java 1.2, but they've also added a
>> module-info for those who want to use this dependency within a
>> Java9/Jigsaw project.
>> module-info MUST be built with Java9 with source/target or release = 9.
>> Other sources must be built with an older JDK with source/target 1.2
>>
>> There are several ways to solve this:
>> - multi-module project and multi release jar like Paul suggest. However,
>> IIRC the specs say that the module-info MUST exist in the root.
>> - 2 source folders, src/main/java and src/main/jigsaw, both writing to
>> target/classes. Here it is quite clear what happens per source-folder.
>> - 1 source folder and all the magic of calling javac twice in the
>> maven-compiler-plugin. I started with this, but I don't like it. Details
>> are below.
>> - 1 source folder and 2 execution blocks (one excluding module-info, one
>> only including module-info).
>>
>> We shouldn't be looking at Maven alone, but also at IDE support. AFAIK
>> Netbeans and IntelliJ simply call Maven. Eclipse is probably hard due to
>> the m2eclipse extensions.
>>
>> Now back to Pauls suggestion. I don't think we make developers very
>> happy if they are advised to have a multimodule project just to be able
>> to compile the module-info file.
>> I am aware that this is mainly an issue for library builders, end users
>> simply build everything with Java9, no problems there. From library
>> builders you can expect that they don't mind adding extra configuration to
>> build their jar, but forcing them to set up a Maven multimodule project is
>> not really nice.
>> I would expect the module-info close to the related sourcefiles, so I
>> would prefer in the same (single) MavenProject.
>>
>> *Unless* IDEs are so strong with handling multi release jars that it
>> looks like I'm adjusting the module-info, even though it is actually
>> located somewhere else.
>>
>> So let's see the opinions from others.
>>
>> thanks,
>> Robert
>>
>> On Wed, 31 Aug 2016 15:59:04 +0200, Paul Benedict <pb...@apache.org>
>> wrote:
>>
>> Robert, I'm responding to dev@maven so we can discuss Maven
>>> philosophies...
>>>
>>> I believe the pattern should be based on a multi-module project. Each
>>> module should target the expected JDK version. Then introduce a new
>>> "mrjar"
>>> type for the parent that knows how to bind them all together into a
>>> Multi-Release JAR.
>>>
>>> Cheers,
>>> Paul
>>>
>>> On Wed, Aug 31, 2016 at 6:10 AM, Robert Scholte <rf...@apache.org>
>>> wrote:
>>>
>>> I've been working on the implementation of this in the
>>>> maven-compiler-plugin, but I'm not really pleased with the result.
>>>> The problem is that in the worst case scenario we have to work with 3
>>>> different versions of Java:
>>>> - The Maven Runtime (set as JAVA_HOME)
>>>> - JDK for the module-info.java
>>>> - JDK for all other source files.
>>>>
>>>> The example below worked because all three were set to JDK9.
>>>> But based on the source/target of 1.6 I cannot predict which JDK is
>>>> used,
>>>> only that it is at least JDK6. Should the plugin switch to another JDK?
>>>> And if you want to compile with source/target 1.5 or less, you're in
>>>> trouble. There's something called toolchain, where you can specify the
>>>> JavaHome per version, but in case of maven-compiler-plugin it assumes
>>>> that
>>>> all java-related plugins and execution blocks want to use the same
>>>> toolchain through the whole Maven project.
>>>> The good news is that for the maven-jdeps-plugin I improved this part in
>>>> Maven 3.3.1, since this plugin only works with Java8 and above, which
>>>> doesn't have to be the same JDK to compile the sources with. Now you can
>>>> simple say: I want the toolchain for version X. This feature needs to be
>>>> added to the plugin.
>>>>
>>>> That said I think I will write a recipe for this. This is first of all
>>>> an
>>>> issue for library writers who want to have their jar compatible with
>>>> multiple Java versions for their end users.
>>>> Result: One javac call per execution block as it was meant to be.
>>>>
>>>> thanks,
>>>> Robert
>>>>
>>>> On Fri, 26 Aug 2016 15:31:07 +0200, Oliver Gondža <og...@gmail.com>
>>>> wrote:
>>>>
>>>> Thank you all for your suggestions. I managed to get the project to
>>>> build
>>>>
>>>>> with following maven setup:
>>>>>
>>>>> ```
>>>>> <!--
>>>>> When using compiler from java 8 and older, ignore module files
>>>>> altogether.
>>>>> Otherwise, use 2 phase compilation to build
>>>>> - all classes for target version and
>>>>> - module-info.java with 9+ source and target level
>>>>> -->
>>>>> <build>
>>>>> <plugins>
>>>>> <plugin>
>>>>> <groupId>org.apache.maven.plugins</groupId>
>>>>> <artifactId>maven-compiler-plugin</artifactId>
>>>>> <version>3.5.1</version>
>>>>> <configuration>
>>>>> <source>1.6</source>
>>>>> <target>1.6</target>
>>>>> </configuration>
>>>>> <executions>
>>>>> <execution>
>>>>> <id>default-compile</id>
>>>>> <configuration>
>>>>> <excludes>
>>>>> <exclude>**/module-info.java</exclude>
>>>>> </excludes>
>>>>> </configuration>
>>>>> </execution>
>>>>> </executions>
>>>>> </plugin>
>>>>> </plugins>
>>>>> </build>
>>>>>
>>>>> <profiles>
>>>>> <profile>
>>>>> <id>jigsaw</id>
>>>>> <activation>
>>>>> <jdk>[1.9,)</jdk>
>>>>> </activation>
>>>>> <build>
>>>>> <plugins>
>>>>> <plugin>
>>>>> <groupId>org.apache.maven.plugins</groupId>
>>>>> <artifactId>maven-compiler-plugin</artifactId>
>>>>> <version>3.5.1</version>
>>>>> <configuration>
>>>>> <source>1.9</source>
>>>>> <target>1.9</target>
>>>>> </configuration>
>>>>> <executions>
>>>>> <execution>
>>>>> <id>module-infos</id>
>>>>> <phase>compile</phase>
>>>>> <goals>
>>>>> <goal>compile</goal>
>>>>> </goals>
>>>>> <configuration>
>>>>> <includes>
>>>>> <include>**/module-info.java</include>
>>>>> </includes>
>>>>> </configuration>
>>>>> </execution>
>>>>> </executions>
>>>>> </plugin>
>>>>> </plugins>
>>>>> </build>
>>>>> </profile>
>>>>> </profiles>
>>>>> ```
>>>>>
>>>>> It does compile with older javac versions as a bonus. Given this is
>>>>> nothing else than using `-source 9 -target 9` for module-info.java if
>>>>> present, I dare to say maven-compiler-plugin can be adapted to figure
>>>>> this
>>>>> out on its own.
>>>>>
>>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
Re: Building jar targeting multiple Java versions, including 9
Posted by Richard Sand <rs...@idfconnect.com>.
I definitely concur with Robert's point: "I don't think we make
developers very happy if they are advised to have a multimodule project
just to be able to compile the module-info file.". I can live with the
requirement that I must run Maven with Java9 to support creating
module-info and having the addtional modules created by a separate
plugin. Simplicity wherever possible.
Best regards,
Richard Sand | CEO
IDF Connect, Inc.
2207 Concord Ave, #359
Wilmington | Delaware 19803 | USA
Office: +1 888 765 1611 | Fax: +1 866 765 7284
Mobile: +1 267 984 3651
------ Original Message ------
From: "Robert Scholte" <rf...@apache.org>
To: "ZML-Apache-Maven-Developers" <de...@maven.apache.org>; "Paul
Benedict" <pb...@apache.org>
Sent: 8/31/2016 10:39:52 AM
Subject: Re: Building jar targeting multiple Java versions, including 9
>Hi Paul,
>
>no problem to move it to this thread. It is indeed about "The Maven
>Way", although we may need to start from the beginning, explaining the
>issue we're facing.
>
>Let's use ASM as an example, their 6.0_ALPHA has been built like this,
>although without Maven.
>ASM is an all purpose Java bytecode manipulation and analysis
>framework. IIRC their code is compatible with Java 1.2, but they've
>also added a module-info for those who want to use this dependency
>within a Java9/Jigsaw project.
>module-info MUST be built with Java9 with source/target or release = 9.
> Other sources must be built with an older JDK with source/target 1.2
>
>There are several ways to solve this:
>- multi-module project and multi release jar like Paul suggest.
>However, IIRC the specs say that the module-info MUST exist in the
>root.
>- 2 source folders, src/main/java and src/main/jigsaw, both writing to
>target/classes. Here it is quite clear what happens per source-folder.
>- 1 source folder and all the magic of calling javac twice in the
>maven-compiler-plugin. I started with this, but I don't like it.
>Details are below.
>- 1 source folder and 2 execution blocks (one excluding module-info,
>one only including module-info).
>
>We shouldn't be looking at Maven alone, but also at IDE support. AFAIK
>Netbeans and IntelliJ simply call Maven. Eclipse is probably hard due
>to the m2eclipse extensions.
>
>Now back to Pauls suggestion. I don't think we make developers very
>happy if they are advised to have a multimodule project just to be
>able to compile the module-info file.
>I am aware that this is mainly an issue for library builders, end users
> simply build everything with Java9, no problems there. From library
>builders you can expect that they don't mind adding extra configuration
>to build their jar, but forcing them to set up a Maven multimodule
>project is not really nice.
>I would expect the module-info close to the related sourcefiles, so I
>would prefer in the same (single) MavenProject.
>
>*Unless* IDEs are so strong with handling multi release jars that it
>looks like I'm adjusting the module-info, even though it is actually
>located somewhere else.
>
>So let's see the opinions from others.
>
>thanks,
>Robert
>
>On Wed, 31 Aug 2016 15:59:04 +0200, Paul Benedict
><pb...@apache.org> wrote:
>
>>Robert, I'm responding to dev@maven so we can discuss Maven
>>philosophies...
>>
>>I believe the pattern should be based on a multi-module project. Each
>>module should target the expected JDK version. Then introduce a new
>>"mrjar"
>>type for the parent that knows how to bind them all together into a
>>Multi-Release JAR.
>>
>>Cheers,
>>Paul
>>
>>On Wed, Aug 31, 2016 at 6:10 AM, Robert Scholte <rf...@apache.org>
>>wrote:
>>
>>>I've been working on the implementation of this in the
>>>maven-compiler-plugin, but I'm not really pleased with the result.
>>>The problem is that in the worst case scenario we have to work with 3
>>>different versions of Java:
>>>- The Maven Runtime (set as JAVA_HOME)
>>>- JDK for the module-info.java
>>>- JDK for all other source files.
>>>
>>>The example below worked because all three were set to JDK9.
>>>But based on the source/target of 1.6 I cannot predict which JDK is
>>>used,
>>>only that it is at least JDK6. Should the plugin switch to another
>>>JDK?
>>>And if you want to compile with source/target 1.5 or less, you're in
>>>trouble. There's something called toolchain, where you can specify
>>>the
>>>JavaHome per version, but in case of maven-compiler-plugin it assumes
>>> that
>>>all java-related plugins and execution blocks want to use the same
>>>toolchain through the whole Maven project.
>>>The good news is that for the maven-jdeps-plugin I improved this part
>>>in
>>>Maven 3.3.1, since this plugin only works with Java8 and above, which
>>>doesn't have to be the same JDK to compile the sources with. Now you
>>>can
>>>simple say: I want the toolchain for version X. This feature needs to
>>>be
>>>added to the plugin.
>>>
>>>That said I think I will write a recipe for this. This is first of
>>>all an
>>>issue for library writers who want to have their jar compatible with
>>>multiple Java versions for their end users.
>>>Result: One javac call per execution block as it was meant to be.
>>>
>>>thanks,
>>>Robert
>>>
>>>On Fri, 26 Aug 2016 15:31:07 +0200, Oliver Gondža <og...@gmail.com>
>>>wrote:
>>>
>>>Thank you all for your suggestions. I managed to get the project to
>>>build
>>>>with following maven setup:
>>>>
>>>>```
>>>> <!--
>>>> When using compiler from java 8 and older, ignore module
>>>>files
>>>>altogether.
>>>> Otherwise, use 2 phase compilation to build
>>>> - all classes for target version and
>>>> - module-info.java with 9+ source and target level
>>>> -->
>>>> <build>
>>>> <plugins>
>>>> <plugin>
>>>> <groupId>org.apache.maven.plugins</groupId>
>>>> <artifactId>maven-compiler-plugin</artifactId>
>>>> <version>3.5.1</version>
>>>> <configuration>
>>>> <source>1.6</source>
>>>> <target>1.6</target>
>>>> </configuration>
>>>> <executions>
>>>> <execution>
>>>> <id>default-compile</id>
>>>> <configuration>
>>>> <excludes>
>>>> <exclude>**/module-info.java</exclude>
>>>> </excludes>
>>>> </configuration>
>>>> </execution>
>>>> </executions>
>>>> </plugin>
>>>> </plugins>
>>>> </build>
>>>>
>>>> <profiles>
>>>> <profile>
>>>> <id>jigsaw</id>
>>>> <activation>
>>>> <jdk>[1.9,)</jdk>
>>>> </activation>
>>>> <build>
>>>> <plugins>
>>>> <plugin>
>>>> <groupId>org.apache.maven.plugins</groupId>
>>>> <artifactId>maven-compiler-plugin</artifactId>
>>>> <version>3.5.1</version>
>>>> <configuration>
>>>> <source>1.9</source>
>>>> <target>1.9</target>
>>>> </configuration>
>>>> <executions>
>>>> <execution>
>>>> <id>module-infos</id>
>>>> <phase>compile</phase>
>>>> <goals>
>>>> <goal>compile</goal>
>>>> </goals>
>>>> <configuration>
>>>> <includes>
>>>> <include>**/module-info.java</include>
>>>> </includes>
>>>> </configuration>
>>>> </execution>
>>>> </executions>
>>>> </plugin>
>>>> </plugins>
>>>> </build>
>>>> </profile>
>>>> </profiles>
>>>>```
>>>>
>>>>It does compile with older javac versions as a bonus. Given this is
>>>>nothing else than using `-source 9 -target 9` for module-info.java
>>>>if
>>>>present, I dare to say maven-compiler-plugin can be adapted to
>>>>figure this
>>>>out on its own.
>>>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Building jar targeting multiple Java versions, including 9
Posted by Robert Scholte <rf...@apache.org>.
Hi Paul,
no problem to move it to this thread. It is indeed about "The Maven Way",
although we may need to start from the beginning, explaining the issue
we're facing.
Let's use ASM as an example, their 6.0_ALPHA has been built like this,
although without Maven.
ASM is an all purpose Java bytecode manipulation and analysis framework.
IIRC their code is compatible with Java 1.2, but they've also added a
module-info for those who want to use this dependency within a
Java9/Jigsaw project.
module-info MUST be built with Java9 with source/target or release = 9.
Other sources must be built with an older JDK with source/target 1.2
There are several ways to solve this:
- multi-module project and multi release jar like Paul suggest. However,
IIRC the specs say that the module-info MUST exist in the root.
- 2 source folders, src/main/java and src/main/jigsaw, both writing to
target/classes. Here it is quite clear what happens per source-folder.
- 1 source folder and all the magic of calling javac twice in the
maven-compiler-plugin. I started with this, but I don't like it. Details
are below.
- 1 source folder and 2 execution blocks (one excluding module-info, one
only including module-info).
We shouldn't be looking at Maven alone, but also at IDE support. AFAIK
Netbeans and IntelliJ simply call Maven. Eclipse is probably hard due to
the m2eclipse extensions.
Now back to Pauls suggestion. I don't think we make developers very happy
if they are advised to have a multimodule project just to be able to
compile the module-info file.
I am aware that this is mainly an issue for library builders, end users
simply build everything with Java9, no problems there. From library
builders you can expect that they don't mind adding extra configuration to
build their jar, but forcing them to set up a Maven multimodule project is
not really nice.
I would expect the module-info close to the related sourcefiles, so I
would prefer in the same (single) MavenProject.
*Unless* IDEs are so strong with handling multi release jars that it looks
like I'm adjusting the module-info, even though it is actually located
somewhere else.
So let's see the opinions from others.
thanks,
Robert
On Wed, 31 Aug 2016 15:59:04 +0200, Paul Benedict <pb...@apache.org>
wrote:
> Robert, I'm responding to dev@maven so we can discuss Maven
> philosophies...
>
> I believe the pattern should be based on a multi-module project. Each
> module should target the expected JDK version. Then introduce a new
> "mrjar"
> type for the parent that knows how to bind them all together into a
> Multi-Release JAR.
>
> Cheers,
> Paul
>
> On Wed, Aug 31, 2016 at 6:10 AM, Robert Scholte <rf...@apache.org>
> wrote:
>
>> I've been working on the implementation of this in the
>> maven-compiler-plugin, but I'm not really pleased with the result.
>> The problem is that in the worst case scenario we have to work with 3
>> different versions of Java:
>> - The Maven Runtime (set as JAVA_HOME)
>> - JDK for the module-info.java
>> - JDK for all other source files.
>>
>> The example below worked because all three were set to JDK9.
>> But based on the source/target of 1.6 I cannot predict which JDK is
>> used,
>> only that it is at least JDK6. Should the plugin switch to another JDK?
>> And if you want to compile with source/target 1.5 or less, you're in
>> trouble. There's something called toolchain, where you can specify the
>> JavaHome per version, but in case of maven-compiler-plugin it assumes
>> that
>> all java-related plugins and execution blocks want to use the same
>> toolchain through the whole Maven project.
>> The good news is that for the maven-jdeps-plugin I improved this part in
>> Maven 3.3.1, since this plugin only works with Java8 and above, which
>> doesn't have to be the same JDK to compile the sources with. Now you can
>> simple say: I want the toolchain for version X. This feature needs to be
>> added to the plugin.
>>
>> That said I think I will write a recipe for this. This is first of all
>> an
>> issue for library writers who want to have their jar compatible with
>> multiple Java versions for their end users.
>> Result: One javac call per execution block as it was meant to be.
>>
>> thanks,
>> Robert
>>
>> On Fri, 26 Aug 2016 15:31:07 +0200, Oliver Gondža <og...@gmail.com>
>> wrote:
>>
>> Thank you all for your suggestions. I managed to get the project to
>> build
>>> with following maven setup:
>>>
>>> ```
>>> <!--
>>> When using compiler from java 8 and older, ignore module files
>>> altogether.
>>> Otherwise, use 2 phase compilation to build
>>> - all classes for target version and
>>> - module-info.java with 9+ source and target level
>>> -->
>>> <build>
>>> <plugins>
>>> <plugin>
>>> <groupId>org.apache.maven.plugins</groupId>
>>> <artifactId>maven-compiler-plugin</artifactId>
>>> <version>3.5.1</version>
>>> <configuration>
>>> <source>1.6</source>
>>> <target>1.6</target>
>>> </configuration>
>>> <executions>
>>> <execution>
>>> <id>default-compile</id>
>>> <configuration>
>>> <excludes>
>>> <exclude>**/module-info.java</exclude>
>>> </excludes>
>>> </configuration>
>>> </execution>
>>> </executions>
>>> </plugin>
>>> </plugins>
>>> </build>
>>>
>>> <profiles>
>>> <profile>
>>> <id>jigsaw</id>
>>> <activation>
>>> <jdk>[1.9,)</jdk>
>>> </activation>
>>> <build>
>>> <plugins>
>>> <plugin>
>>> <groupId>org.apache.maven.plugins</groupId>
>>> <artifactId>maven-compiler-plugin</artifactId>
>>> <version>3.5.1</version>
>>> <configuration>
>>> <source>1.9</source>
>>> <target>1.9</target>
>>> </configuration>
>>> <executions>
>>> <execution>
>>> <id>module-infos</id>
>>> <phase>compile</phase>
>>> <goals>
>>> <goal>compile</goal>
>>> </goals>
>>> <configuration>
>>> <includes>
>>> <include>**/module-info.java</include>
>>> </includes>
>>> </configuration>
>>> </execution>
>>> </executions>
>>> </plugin>
>>> </plugins>
>>> </build>
>>> </profile>
>>> </profiles>
>>> ```
>>>
>>> It does compile with older javac versions as a bonus. Given this is
>>> nothing else than using `-source 9 -target 9` for module-info.java if
>>> present, I dare to say maven-compiler-plugin can be adapted to figure
>>> this
>>> out on its own.
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org