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" <[email protected]>
To: "Maven Developers List" <[email protected]>
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 <[email protected]>:
>>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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
