maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Scholte" <rfscho...@apache.org>
Subject Re: [DISCUSSION] JEP 238: Multi-Version JAR Files
Date Mon, 27 Jul 2015 18:07:10 GMT
Hi Hervé,

there's no such thing as version specific configuration. And I don't think  
it is really an issue.
With almost every new major version come new javac arguments, such as -s  
for JDK6, -profile for JDK8.

IMHO it is up to the user to specify the release value and add an enforcer  
rule to require JDK9.
However, when using toolchains, it is easy to get the version.

thanks,
Robert

Op Mon, 27 Jul 2015 13:23:44 +0200 schreef Hervé BOUTEMY  
<herve.boutemy@free.fr>:

> I tested the new -release flag and it works like a charm: not only is it  
> easier
> to use (1 flag instead of 3 = source/target/bootclasspath), but it  
> avoids the
> famous covariance problem previously found [1] (and that happens with  
> JDK 9
> when not using this new -release flag)
>
>
> Then I think it's important to add support for this flag in a future  
> maven-
> compiler-plugin version.
>
> Striclty adding this option should not be a problem.
> But the problem I see is that once a build is configured with this flag,  
> you
> *must* use a JDK 9+ to build: I don't see how to make the flag used only  
> when
> available.
>
> Any idea?
>
> Regards,
>
> Hervé
>
>
> [1] https://gist.github.com/AlainODea/1375759b8720a3f9f094
>
> Le vendredi 17 juillet 2015 19:39:22 Arnaud Héritier a écrit :
>> Hi all,
>>
>>
>> FYI Paul Sandoz forwarded us this email if you don't follow the  
>> jdk9-dev ML
>>
>> ==
>>
>> Hi,
>>
>> In case you are not monitoring this alias.
>>
>> This is likely relevant to not just to MRJARs but also to maven java
>> compiler support and the sniffer/conformance plugins etc.
>>
>> Paul.
>>
>> Begin forwarded message:
>>
>> *From: *joe darcy <joe.darcy@oracle.com>
>> *Subject: **New feature in JDK 9 builds: javac -release $VERSION*
>> *Date: *July 13, 2015 5:50:54 AM GMT+02:00
>> *To: *"jdk9-dev@openjdk.java.net" <jdk9-dev@openjdk.java.net>
>>
>> Hello,
>>
>> As of JDK 9 b72 [1], a feature recently pushed by Jan Lahoda is now
>> available: the javac -release command line option.
>>
>> This feature was developed under JEP 247: Compile for Older Platform
>> Versions [2]. In brief, to use javac to cross-compile to an older  
>> release
>> of the platform it is not sufficient to just set the -source and -target
>> options to the older value; the bootclasspath must also be set to
>> correspond to the older release too. [3] Setting the bootclass was often
>> forgotten and acquiring the needed information could be inconvenient.
>>
>> The -release flag in javac addresses both of these shortcomings. Now  
>> only a
>> single flag (-release) needs to be set to cross compile compared to  
>> three
>> flags (-source, -target, -bootclasspath) and the needed information is
>> included in the JDK. The set of release values follows the same "one  
>> plus
>> three back" policy now used for the -source and -target options. [4]
>> Therefore, in JDK 9, the accepted argument values for -release are 6,  
>> 7, 8,
>> and 9.
>>
>> Feedback on the this feature can be sent to  
>> compiler-dev@openjdk.java.net.
>>
>> Cheers,
>>
>> -Joe
>>
>> [1] https://jdk9.java.net/download/
>>
>> [2] http://openjdk.java.net/jeps/247
>>
>> [3] "How to cross-compile for older platform versions,"
>> https://blogs.oracle.com/darcy/entry/how_to_cross_compile_for
>>
>> [4] JEP 182: Policy for Retiring javac -source and -target Options
>> http://openjdk.java.net/jeps/182
>>
>>
>> On Fri, Jul 10, 2015 at 8:47 AM, Hervé BOUTEMY <herve.boutemy@free.fr>
>>
>> wrote:
>> > Le jeudi 9 juillet 2015 09:48:13 Tibor Digana a écrit :
>> > > Nice project indeed.
>> > > Maybe only JRE has the benefit from multi-version JAR, but I cannot
>> >
>> > imaging
>> >
>> > > this feature in ordinal projects.
>> >
>> > +1
>> > currently, there are not so much projects that produce a different
>> > artifact for
>> > different JREs, but there are, even if not the majority
>> > see the JEP [1] "Motivation" section
>> >
>> > > Who has benefit from writing the code
>> > > three times if API of module matters. Maybe performance will be
>> > > different
>> > > only.
>> >
>> > notice that one of the motivation, apart from the use case you are
>> > thinking
>> > to, is that with JDK modularization, there are intends to deprecate  
>> some
>> > APIs
>> > (internal or not): this MVjar will be useful to deal with such type  
>> of JDK
>> > evolution (and stop with current problem that any new JDK adds APIs  
>> but
>> > never
>> > ever removes anything)
>> > This is a long term goal: the feature has to be there, be successful  
>> and
>> > prove
>> > being usable for the most specific libraries before expecting using it
>> > more to
>> > support JDK cleanup (in Java 10 or more)
>> >
>> >
>> > What I'm satisfied now with the working example is that whatever one
>> > thinks
>> > about the feature, Maven is not in the way: there is now a proved  
>> recipe
>> > to
>> > create MVjars if the feature gets added into a JRE, and this base  
>> recipe
>> > does
>> > not require any change in any tool (be it Maven or IDE integration)
>> >
>> > There is IMHO still one issue in the recipe: there is a trick  
>> (written by
>> > Paul
>> > Sandoz, who gave me its initial work) to avoid installing intermediate
>> > artifacts (to limit the impact of multi-modules, since intermediate
>> > artifacts
>> > don't really have any meaning). I didn't try to deploy the current  
>> demo,
>> > but I
>> > fear it currently would fail: I suppose that's my next test now the  
>> the
>> > mvjar
>> > is great (thanks to Robert's help :) )
>> >
>> > Regards,
>> >
>> > Hervé
>> >
>> >
>> > [1] http://openjdk.java.net/jeps/238
>> >
>> > > On Thu, Jul 9, 2015 at 1:08 AM, Hervé BOUTEMY [via Maven] <
>> > >
>> > > ml-node+s40175n5839659h69@n5.nabble.com> wrote:
>> > > > Hi,
>> > > >
>> > > > In april, we had a discussion about Multi-Version JAR Files.
>> > > >
>> > > > Since then, we worked to create a sample project built with  
>> Maven, to
>> >
>> > see
>> >
>> > > > how
>> > > > Maven configuration would currently look like, before trying to  
>> create
>> >
>> > new
>> >
>> > > > features to make more compact configuration and avoid  
>> multi-modules
>> > > > creation.
>> > > >
>> > > > Here is the result:
>> > > > https://github.com/hboutemy/maven-jep238
>> > > >
>> > > > AFAIK, the result of this code is a valid MVJar, and this gives a
 
>> good
>> > > > overview of a basic Maven recipe to make MVJars.
>> > > >
>> > > > There is one limitation I have with assembly in the last module: I
>> >
>> > can't
>> >
>> > > > exclude /META-INF content from every versioned content (ie avoid
>> > > > /META-
>> > > > INF/versions/*/META-INF in final MVJar).
>> > > >
>> > > > Is it me or excludes don't work as expected in assembly plugin?
>> > > >
>> > > > Regards,
>> > > >
>> > > > Hervé
>> > > >
>> > > >  
>> ---------------------------------------------------------------------
>> > > > To unsubscribe, e-mail: [hidden email]
>> > > > <http:///user/SendEmail.jtp?type=node&node=5839659&i=0>
>> > > > For additional commands, e-mail: [hidden email]
>> > > > <http:///user/SendEmail.jtp?type=node&node=5839659&i=1>
>> > > >
>> > > >
>> > > >
>> > > > ------------------------------
>> > > >
>> > > >  If you reply to this email, your message will be added to the
>> >
>> > discussion
>> >
>> > > > below:
>> >  
>> http://maven.40175.n5.nabble.com/DISCUSSION-JEP-238-Multi-Version-JAR-File
>> >
>> > > > s-tp5839659.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=unsubscri
>> >
>> >  
>> be_by_code&node=142166&code=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OT
>> >
>> > > > Q5MjEwMg==> .
>> > > > NAML
>> > > > <
>> >
>> >  
>> http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=macro_vie
>> >
>> >  
>> wer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.Basi
>> >
>> >  
>> cNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.templa
>> >
>> >  
>> te.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-inst
>> >
>> >  
>> ant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>> >
>> > > --
>> >
>> > > View this message in context:
>> >  
>> http://maven.40175.n5.nabble.com/Re-DISCUSSION-JEP-238-Multi-Version-JAR-F
>> > i
>> >
>> > > les-tp5839680.html Sent from the Maven Developers mailing list  
>> archive
>> > > at
>> > > Nabble.com.
>> >
>> > ---------------------------------------------------------------------
>> > 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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message