[DISCUSS] Maven 3.7.0

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

[DISCUSS] Maven 3.7.0

Robert Scholte-8
Hi,

TLDR; introduce maven.experimental.buildconsumer and push Java requirement  
to Java 8

now that Maven 3.6.2 is out for a couple of weeks, it seems like we didn't  
face real regressions.
The only one might be tricky is the issue related to Tycho.

However, I think we're ready to push Maven to the next level.

For those actively reading this list, they should recognize the need for  
splitting up the pom as it is on the local system versus the pom being  
uploaded. Once we truly control this mechanism we can think of  
improvements on model 5.0.0 and new fileformats.

I've created and implemented MNG-6656[1]. It also contains a zip with an  
example (original, patched, README) to understand what's happening.

In order to make this successful, we need IDEs and CI Servers to  
understand and support these changes. The likely need to implement one of  
the interfaces[2].
The new interface uses Java8 Functions (and especially SAXEventFactory is  
way easier to read+maintain with Java 8). I've tried to keep Maven Java 7  
compatible, but that was too hard to do.
So I'd like to use this opportunity to move Maven forward and start  
requiring Java 8.

There are some other improvements I'd like to add (those messages will  
follow), so this will imply that it will take some time before we do a new  
release.

WDTY,
Robert

[1] https://issues.apache.org/jira/browse/MNG-6656
[2] https://github.com/apache/maven/compare/MNG-6656?expand=1

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Maven 3.7.0

Karl Heinz Marbaise-3
Hi,

On 28.09.19 14:05, Robert Scholte wrote:
> Hi,
>
> TLDR; introduce maven.experimental.buildconsumer and push Java
> requirement to Java 8
>
> now that Maven 3.6.2 is out for a couple of weeks, it seems like we
> didn't face real regressions.
> The only one might be tricky is the issue related to Tycho.

Feedback of Michael Istria states different? Or do I miss a thing?

>
> However, I think we're ready to push Maven to the next level.

Yes that's very important to go that step...

>
> For those actively reading this list, they should recognize the need for
> splitting up the pom as it is on the local system versus the pom being
> uploaded. Once we truly control this mechanism we can think of
> improvements on model 5.0.0 and new fileformats.

Yes that will open up several parts we are thinking about for a long
time...(Build vs. Consumer POM).

>
> I've created and implemented MNG-6656[1]. It also contains a zip with an
> example (original, patched, README) to understand what's happening.
>
> In order to make this successful, we need IDEs and CI Servers to
> understand and support these changes. The likely need to implement one
> of the interfaces[2].

> The new interface uses Java8 Functions (and especially SAXEventFactory
> is way easier to read+maintain with Java 8).


> I've tried to keep Maven
> Java 7 compatible, but that was too hard to do.
This is a waste of time simply ...

> So I'd like to use this opportunity to move Maven forward and start
> requiring Java 8.

It's really time to get up to Java 8 at minimum ....


>
> There are some other improvements I'd like to add (those messages will
> follow), so this will imply that it will take some time before we do a
> new release.

Great go forward for Maven 3.7.0...

Kind regards
Karl Heinz Marbaise

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Maven 3.7.0

Mickael Istria-2
On Sat, Sep 28, 2019 at 5:35 PM Karl Heinz Marbaise <[hidden email]>
wrote:

>
> > now that Maven 3.6.2 is out for a couple of weeks, it seems like we
> > didn't face real regressions.
> > The only one might be tricky is the issue related to Tycho.
>
> Feedback of Michael Istria states different? Or do I miss a thing?


I think we should trust the various users who face this issue, and assume
the issue exist until proven otherwise.
This is likely a bug in Tycho and/or Polyglot Maven, and I believe this
reveals that some of the important Tycho tests are not performed against
latest Maven snapshots. I've started a thread on the [hidden email]
mailing-list on htis topic.
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Maven 3.7.0

Robert Scholte-8
In reply to this post by Robert Scholte-8
The versions upgrades of plugins are part of another topic, which are  
indeed 3.7.0 candidates.

As said, the Java 8 update is not just about internal code improvements or  
changes. Maven will expose new APIs/SPIs that contain Java 8 Functions, so  
it must be seen as a requirement to implement the experimental  
buildconsumer feature.

Robert

On Sat, 28 Sep 2019 14:23:16 +0200, Tibor Digana <[hidden email]>  
wrote:

> Hello guys,
>
> For the user community these two issues are important:
> https://issues.apache.org/jira/browse/MNG-6169
> https://issues.apache.org/jira/browse/MNG-6548
> The Tycho project is the user as well.
> The J8 is internal code improvement/change => lower priority than the
> user's priority => release order/priorities/dedicated time spent in
> development.
>
> Have a nice day.
>
> Cheers
> Tibor17
>
> On Sat, Sep 28, 2019 at 2:08 PM Gary Gregory <[hidden email]>  
> wrote:
>
>> I would say that fixing the Tycho issue comes first.
>>
>> Gary
>>
>> On Sat, Sep 28, 2019 at 8:04 AM Robert Scholte <[hidden email]>
>> wrote:
>>
>> > Hi,
>> >
>> > TLDR; introduce maven.experimental.buildconsumer and push Java
>> > requirement
>> > to Java 8
>> >
>> > now that Maven 3.6.2 is out for a couple of weeks, it seems like we
>> > didn't
>> > face real regressions.
>> > The only one might be tricky is the issue related to Tycho.
>> >
>> > However, I think we're ready to push Maven to the next level.
>> >
>> > For those actively reading this list, they should recognize the need  
>> for
>> > splitting up the pom as it is on the local system versus the pom being
>> > uploaded. Once we truly control this mechanism we can think of
>> > improvements on model 5.0.0 and new fileformats.
>> >
>> > I've created and implemented MNG-6656[1]. It also contains a zip with  
>> an
>> > example (original, patched, README) to understand what's happening.
>> >
>> > In order to make this successful, we need IDEs and CI Servers to
>> > understand and support these changes. The likely need to implement  
>> one of
>> > the interfaces[2].
>> > The new interface uses Java8 Functions (and especially  
>> SAXEventFactory is
>> > way easier to read+maintain with Java 8). I've tried to keep Maven  
>> Java 7
>> > compatible, but that was too hard to do.
>> > So I'd like to use this opportunity to move Maven forward and start
>> > requiring Java 8.
>> >
>> > There are some other improvements I'd like to add (those messages will
>> > follow), so this will imply that it will take some time before we do a
>> > new
>> > release.
>> >
>> > WDTY,
>> > Robert
>> >
>> > [1] https://issues.apache.org/jira/browse/MNG-6656
>> > [2] https://github.com/apache/maven/compare/MNG-6656?expand=1
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>> >
>> >

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Proposal: maven release lifecycle

Marco Schulz
In reply to this post by Robert Scholte-8
Hello Maven Dev & Community

Sine a long time I thought, it would be cool to have a well defined process to
prepare a release of an artifact and deploy it on mvn central. Now I got a bit
time to formulate a short proposal of my idea. I published a description of my
thought on my bolg:
https://enrebaja.wordpress.com/2019/10/03/next-generation-maven/

A poll is also created, may to see what other people think about it. Please feel
free to leave also comments, every feedback is welcome.

warm regards & thanks to the maven dev team for the great job they do.
.marco (@ElmarDott)

--
________________________________________________________________________________
 Dipl. Inf. Marco Schulz (MSc)

                  Expert for (WEB) Enterprise Applications
                           - worldwide -
      + Project Manager + Consultant + Writer + Speaker + Trainer +

[Contact]_______________________________________________________________________
                                                   
   WhatsApp :  +52 (1) 221 200 61 37 :: Mexico      
   Cell     :  +49 (0) 163 69 18 445 :: Germany  
   E-Mail   :  [hidden email]            
                                                   
   Blog     :  https://enRebaja.wordpress.com      
   twitter  :  https://twitter.com/ElmarDott       
   tumblr   :  https://elmardott.tumblr.com        
   facebook :  https://www.facebook.com/elmar.dott 

[Services]______________________________________________________________________

    + Individual software development
    + Software Project Management
    + Build-,  Configuration-, & Delivery Management
    + Release Management
    + Business Analysis
    + Software Architecture
    + Process Automation
________________________________________________________________________________
This message is intended only for the use of the individual or entity to which
it is addressed, and may contain information that is privileged, confidential
and that may not be made public by law or agreement. If you are not the intended
recipient or entity, you are hereby notified that any further dissemination,
distribution or copying of this information is strictly prohibited.
If you have received this communication in error, please contact us immediately
and delete the message from your system.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Maven 3.7.0

Karl Heinz Marbaise-3
In reply to this post by Robert Scholte-8
Hi,

On 03.10.19 14:36, Elliotte Rusty Harold wrote:
> Theoretically that would work. In practice though, every project I've
> seen convert to Java 8 rapidly starts adding lambdas that make the
> code more obfuscated for no good reason and soon introduces hard
> dependencies on Java 8, intentionally or otherwise. At a bare minimum,
> a CI environment that runs Java 7 is required.

If people don't understand how to use Java 8 code like Streams, lambdas,
functions etc... I think they should learn how to it the right way...I
admit that lambdas is a hard nut to crack ...

Apart from that Pual has gieven the hint to use toolchains as already
done by Stephen Connolly.. which supports exactly what is needed ..

Run your Build (Maven) on JDK 8 where as your code will run on Java 7
(build/test)..


So I don't see here a real issue to lift the minimum for Maven to JDK
8... (Furthermore the request of Robert Scholte)..


Kind regards
Karl Heinz Marbaise

>
> On Thu, Oct 3, 2019 at 8:25 AM Paul Hammant <[hidden email]> wrote:
>>
>> Would jdk 8 for maven itself and a target of 7 for the compiler (etc) for
>> maven-using projects be ok?
>>
>> On Thu, Oct 3, 2019 at 1:15 PM Elliotte Rusty Harold <[hidden email]>
>> wrote:
>>
>>> Strong -1 on Java 8 as the minimum version. Google Cloud Platform has
>>> lots of products and customers that still require Java 7. If Maven
>>> requires Java 8, we'd have to stick to the latest of whichever release
>>> does support Java 7 for at least a year and I'm guessing longer.
>>>
>>> On Sat, Sep 28, 2019 at 8:04 AM Robert Scholte <[hidden email]>
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> TLDR; introduce maven.experimental.buildconsumer and push Java
>>> requirement
>>>> to Java 8
>>>>
>>>> now that Maven 3.6.2 is out for a couple of weeks, it seems like we
>>> didn't
>>>> face real regressions.
>>>> The only one might be tricky is the issue related to Tycho.
>>>>
>>>> However, I think we're ready to push Maven to the next level.
>>>>
>>>> For those actively reading this list, they should recognize the need for
>>>> splitting up the pom as it is on the local system versus the pom being
>>>> uploaded. Once we truly control this mechanism we can think of
>>>> improvements on model 5.0.0 and new fileformats.
>>>>
>>>> I've created and implemented MNG-6656[1]. It also contains a zip with an
>>>> example (original, patched, README) to understand what's happening.
>>>>
>>>> In order to make this successful, we need IDEs and CI Servers to
>>>> understand and support these changes. The likely need to implement one of
>>>> the interfaces[2].
>>>> The new interface uses Java8 Functions (and especially SAXEventFactory is
>>>> way easier to read+maintain with Java 8). I've tried to keep Maven Java 7
>>>> compatible, but that was too hard to do.
>>>> So I'd like to use this opportunity to move Maven forward and start
>>>> requiring Java 8.
>>>>
>>>> There are some other improvements I'd like to add (those messages will
>>>> follow), so this will imply that it will take some time before we do a
>>> new
>>>> release.
>>>>
>>>> WDTY,
>>>> Robert
>>>>
>>>> [1] https://issues.apache.org/jira/browse/MNG-6656
>>>> [2] https://github.com/apache/maven/compare/MNG-6656?expand=1
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Maven 3.7.0

Tibor Digana
In reply to this post by Robert Scholte-8
This is not very serious discussion since we saw users on our mailing list
who said that he is using Java 1.6 compiler and JDK7 in Maven.
Serious discussion would uncover pros/cons and impact analysis.

I would have a problem with Java 1.8 in target and source code but I have
problem that we excluded our users from the VOTE.
Regarding Java 1.7 we clearly uncovered the migration plan, versions of
plugins, core etc. Here nothing like that exists - only that somebody
created a Jira ticket.

Technically I would be interested if somebody could explain what NEW
Security API is in Java 1.8 and performance impact of Streams API. That's
the impact in the source code.
Somebody has other questions too.
Then we can write Wiki as well as rules, conditions and plan.

Cheers
Tibor17

On Thu, Oct 3, 2019 at 4:55 PM Karl Heinz Marbaise <[hidden email]>
wrote:

> On 03.10.19 14:15, Elliotte Rusty Harold wrote:
> > Strong -1 on Java 8 as the minimum version. Google Cloud Platform has
> > lots of products and customers that still require Java 7. If Maven
> > requires Java 8, we'd have to stick to the latest of whichever release
> > does support Java 7 for at least a year and I'm guessing longer.
>
> Hm.. first Java 7 is out for eight years now (2011) (End of live) and
> has no public updates for security/bug fixes etc. since 2015
>
> Furthermore Java 8 is out for five years (2014) so to be honest I
> wouldn't trust an environment which is not upgrading etc. in particular
> in a clould environment...
>
> Why hadn't started Google to update their environment over the time to
> JDK 8 etc. (I think they have much more resources than anyone).
>
>
> One more thing is:
>   There is a difference between running Maven to build for example
>   with JDK 8 and running your resulting artifacts (see toolchain comment
>   from Stephen Connolly..
>
> Kind regards
> Karl Heinz Marbaise
>
>
> [1]: https://www.oracle.com/technetwork/java/java-se-support-roadmap.html
>
>
> >
> > On Sat, Sep 28, 2019 at 8:04 AM Robert Scholte <[hidden email]>
> wrote:
> >>
> >> Hi,
> >>
> >> TLDR; introduce maven.experimental.buildconsumer and push Java
> requirement
> >> to Java 8
> >>
> >> now that Maven 3.6.2 is out for a couple of weeks, it seems like we
> didn't
> >> face real regressions.
> >> The only one might be tricky is the issue related to Tycho.
> >>
> >> However, I think we're ready to push Maven to the next level.
> >>
> >> For those actively reading this list, they should recognize the need for
> >> splitting up the pom as it is on the local system versus the pom being
> >> uploaded. Once we truly control this mechanism we can think of
> >> improvements on model 5.0.0 and new fileformats.
> >>
> >> I've created and implemented MNG-6656[1]. It also contains a zip with an
> >> example (original, patched, README) to understand what's happening.
> >>
> >> In order to make this successful, we need IDEs and CI Servers to
> >> understand and support these changes. The likely need to implement one
> of
> >> the interfaces[2].
> >> The new interface uses Java8 Functions (and especially SAXEventFactory
> is
> >> way easier to read+maintain with Java 8). I've tried to keep Maven Java
> 7
> >> compatible, but that was too hard to do.
> >> So I'd like to use this opportunity to move Maven forward and start
> >> requiring Java 8.
> >>
> >> There are some other improvements I'd like to add (those messages will
> >> follow), so this will imply that it will take some time before we do a
> new
> >> release.
> >>
> >> WDTY,
> >> Robert
> >>
> >> [1] https://issues.apache.org/jira/browse/MNG-6656
> >> [2] https://github.com/apache/maven/compare/MNG-6656?expand=1
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Maven 3.7.0

Gary Gregory-2
Java 8 as a min is fine by me FWIW.

Gary

On Thu, Oct 3, 2019 at 11:07 AM Tibor Digana <[hidden email]> wrote:

> Sorry my important typo " I would have a problem with Java 1.8 ".
> Correction " I would NOT have a problem with Java 1.8 "
>
> On Thu, Oct 3, 2019 at 5:03 PM Tibor Digana <[hidden email]>
> wrote:
>
> > This is not very serious discussion since we saw users on our mailing
> list
> > who said that he is using Java 1.6 compiler and JDK7 in Maven.
> > Serious discussion would uncover pros/cons and impact analysis.
> >
> > I would have a problem with Java 1.8 in target and source code but I have
> > problem that we excluded our users from the VOTE.
> > Regarding Java 1.7 we clearly uncovered the migration plan, versions of
> > plugins, core etc. Here nothing like that exists - only that somebody
> > created a Jira ticket.
> >
> > Technically I would be interested if somebody could explain what NEW
> > Security API is in Java 1.8 and performance impact of Streams API. That's
> > the impact in the source code.
> > Somebody has other questions too.
> > Then we can write Wiki as well as rules, conditions and plan.
> >
> > Cheers
> > Tibor17
> >
> > On Thu, Oct 3, 2019 at 4:55 PM Karl Heinz Marbaise <[hidden email]>
> > wrote:
> >
> >> On 03.10.19 14:15, Elliotte Rusty Harold wrote:
> >> > Strong -1 on Java 8 as the minimum version. Google Cloud Platform has
> >> > lots of products and customers that still require Java 7. If Maven
> >> > requires Java 8, we'd have to stick to the latest of whichever release
> >> > does support Java 7 for at least a year and I'm guessing longer.
> >>
> >> Hm.. first Java 7 is out for eight years now (2011) (End of live) and
> >> has no public updates for security/bug fixes etc. since 2015
> >>
> >> Furthermore Java 8 is out for five years (2014) so to be honest I
> >> wouldn't trust an environment which is not upgrading etc. in particular
> >> in a clould environment...
> >>
> >> Why hadn't started Google to update their environment over the time to
> >> JDK 8 etc. (I think they have much more resources than anyone).
> >>
> >>
> >> One more thing is:
> >>   There is a difference between running Maven to build for example
> >>   with JDK 8 and running your resulting artifacts (see toolchain comment
> >>   from Stephen Connolly..
> >>
> >> Kind regards
> >> Karl Heinz Marbaise
> >>
> >>
> >> [1]:
> https://www.oracle.com/technetwork/java/java-se-support-roadmap.html
> >>
> >>
> >> >
> >> > On Sat, Sep 28, 2019 at 8:04 AM Robert Scholte <[hidden email]>
> >> wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >> TLDR; introduce maven.experimental.buildconsumer and push Java
> >> requirement
> >> >> to Java 8
> >> >>
> >> >> now that Maven 3.6.2 is out for a couple of weeks, it seems like we
> >> didn't
> >> >> face real regressions.
> >> >> The only one might be tricky is the issue related to Tycho.
> >> >>
> >> >> However, I think we're ready to push Maven to the next level.
> >> >>
> >> >> For those actively reading this list, they should recognize the need
> >> for
> >> >> splitting up the pom as it is on the local system versus the pom
> being
> >> >> uploaded. Once we truly control this mechanism we can think of
> >> >> improvements on model 5.0.0 and new fileformats.
> >> >>
> >> >> I've created and implemented MNG-6656[1]. It also contains a zip with
> >> an
> >> >> example (original, patched, README) to understand what's happening.
> >> >>
> >> >> In order to make this successful, we need IDEs and CI Servers to
> >> >> understand and support these changes. The likely need to implement
> one
> >> of
> >> >> the interfaces[2].
> >> >> The new interface uses Java8 Functions (and especially
> SAXEventFactory
> >> is
> >> >> way easier to read+maintain with Java 8). I've tried to keep Maven
> >> Java 7
> >> >> compatible, but that was too hard to do.
> >> >> So I'd like to use this opportunity to move Maven forward and start
> >> >> requiring Java 8.
> >> >>
> >> >> There are some other improvements I'd like to add (those messages
> will
> >> >> follow), so this will imply that it will take some time before we do
> a
> >> new
> >> >> release.
> >> >>
> >> >> WDTY,
> >> >> Robert
> >> >>
> >> >> [1] https://issues.apache.org/jira/browse/MNG-6656
> >> >> [2] https://github.com/apache/maven/compare/MNG-6656?expand=1
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: [hidden email]
> >> >> For additional commands, e-mail: [hidden email]
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Maven 3.7.0

Anders Hammar
In reply to this post by Robert Scholte-8
On Thu, Oct 3, 2019 at 5:47 PM Emmanuel Bourg <[hidden email]> wrote:

> Le 03/10/2019 à 16:54, Karl Heinz Marbaise a écrit :
>
> > Hm.. first Java 7 is out for eight years now (2011) (End of live) and
> > has no public updates for security/bug fixes etc. since 2015
>
> RedHat still maintains OpenJDK 7 until June 2020 [1].
>

And IBM will support Java 7 (on WAS) until July 2022 [1].

Having said that, I'm fine with bumping to Java 8 in Maven core now. One
reason for doing that could be used (external) libraries that start to
require Java 8 (maybe more often i plugins than in core, haven't checked).
I'm not saying that we should start to rewrite everything, but just setting
the baseline saying that new code may use new APIs, language features, etc.

/Anders

[1]
https://www.ibm.com/cloud/blog/websphere-application-server-extends-java-se-7-support



>
> Emmanuel Bourg
>
> [1]
> https://access.redhat.com/articles/1299013#OpenJDK_Lifecycle_Dates_and_RHEL_versions
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Maven 3.7.0

stephenconnolly
In reply to this post by Tibor Digana
On Fri, 4 Oct 2019 at 09:48, Robert Scholte <[hidden email]> wrote:

> Sorry Tibor, but I'm not going to do this.
>
> We've said that simply changing source/target(/release) to 1.8 is not a
> good reason to require Java 8.
> Now with the changes as mentioned in this thread (new APIs based on Java
> Functions) we finally have this good reason.
>
> I'm not going to explain why the move to Java 8 is important. I'm only
> interested in good arguments why to stay on Java 7 and so far I haven't
> seen any.
> People must understand that we're talking about the Java Runtime that
> Maven requires. There's a clear separation between Mavens runtime and the
> JDK. If you want to compile your code with an earlier JDK, that's already
> possible for a long time (but I guess most people simply use the Maven
> Runtime as their JDK).
>
> For those that argue that they must stay on Java 7 for their own projects
> must also keep in mind that with such statement they block the evolution
> of Maven for the whole Java community.
>
> I only saw a negative vote in relation with the Google Cloud Platform.
> Let
> this be a motivation for them to move forward too. Google should have
> enough resources to come up with a solution, either move to Java 8,
> maintain a backported version of Maven or maybe there are other solutions.
>
> Based on the responses on this thread I will continue with the proposed
> changed. A first PR has already been reviewed, and there are still a
> couple of TODO's I need to work on and I'll inform related tools
> regarding
> these changes.
>

+1


>
> I started the thread with one other question: do we need a 3.6.3
> regression release?
>

+1 to asking the question. Unclear to me if there is a need, but we should
certainly ask it especially if 3.7.0 will involve a big change in terms of
separation of the build pom from the consumer pom

The only thing I noticed are confirmations that there are regressions, but

> they are related to third party plugins/extensions/tools. Hopefully they
> can help analyze to help their own product.
> Based on that I'll put my focus fully Maven 3.7.0.
>
> thanks,
> Robert
>
> On Thu, 03 Oct 2019 20:22:06 +0200, Tibor Digana <[hidden email]>
>
> wrote:
>
> > The topic related to TLS is only related to runtime, means JDK, which is
> > under the control of the particular user or CI.
> > I guess the user can easily find the answer:
> >
> https://stackoverflow.com/questions/50824789/why-am-i-getting-received-fatal-alert-protocol-version-or-peer-not-authentic
> >
> > The thing is that we need to specify:
> > + advantages of Java 1.8 in code (Lambda, brief code, maybe)
> > + disadvantages of Java 1.8 in code (Streams performance when/how/what
> > approach???)
> >
> > Write notices for developers on the internal Wiki:
> > + toolchains
> > + limitations and solutions for disadvantages
> > + conditions when and how to migrate from J7 to J8
> >
> > and then we should Vote for J8.
> >
> > And there are users who is has J6 and J7 and they may require us to
> > maintain the old version 3.6.x.
> > What to do in this case?
> > Is the toolchain enough? Usually it is in ordinal projects!
> >
> > Cheers
> > T
> >
> >
> > On Thu, Oct 3, 2019 at 5:52 PM Stephen Connolly <
> > [hidden email]> wrote:
> >
> >> On Thu, 3 Oct 2019 at 16:49, Karl Heinz Marbaise <[hidden email]>
> >> wrote:
> >>
> >> > Hi,
> >> >
> >> > On 03.10.19 17:03, Tibor Digana wrote:
> >> > > This is not very serious discussion since we saw users on our
> >> mailing
> >> > > list who said that he is using Java 1.6 compiler and JDK7 in Maven.
> >> >
> >> > Would that change anything? Using JDK 8 for Maven and using JDK 6 for
> >> > compiling/test...
> >> >
> >> >
> >> > > Serious discussion would uncover pros/cons and impact analysis.
> >> > >
> >> > > I would have a problem with Java 1.8 in target and source code but I
> >> > > have problem that we excluded our users from the VOTE.
> >> >
> >> > > Regarding Java 1.7 we clearly uncovered the migration plan,
> >> versions of
> >> > > plugins, core etc. Here nothing like that exists - only that
> >> somebody
> >> > > created a Jira ticket.
> >> >
> >> > Hm...all plugins etc. running on JDK 7+...so in the first step we just
> >> > upgrade the minimum for Maven Core only (3.7.0)... (Apart from
> having
> >> a
> >> > plugin which is JDK8 minimum already).
> >> >
> >> > Plugins can upgrade to JDK 8 minimum as needed/wished afterwards
> (may
> >> be
> >> > we could do a version identification...but at the moment I don't see a
> >> > need for that cause they work on JDK7+).
> >> >
> >>
> >> Also, to my mind, unless the plugin specifically needs features in Maven
> >> 3.7.0 there is added reason for the plugin to stay on JDK7 until it
> >> bumps
> >> the core version of Maven it depends on (or it finds a use-case
> >> requiring
> >> Java 8)
> >>
> >> Finally, upgrading to Java 8 is basically a must have for easier TLS
> >> certificate validation as the JDK7 distributions do not all have good
> >> current TLS root certs
> >>
> >>
> >> > Kind regards
> >> > Karl Heinz Marbaise
> >> >
> >> > >
> >> > > Technically I would be interested if somebody could explain what NEW
> >> > > Security API is in Java 1.8 and performance impact of Streams API.
> >> > > That's the impact in the source code.
> >> > > Somebody has other questions too.
> >> > > Then we can write Wiki as well as rules, conditions and plan.
> >> > >
> >> > > Cheers
> >> > > Tibor17
> >> > >
> >> > > On Thu, Oct 3, 2019 at 4:55 PM Karl Heinz Marbaise
> >> <[hidden email]
> >> > > <mailto:[hidden email]>> wrote:
> >> > >
> >> > >     On 03.10.19 14:15, Elliotte Rusty Harold wrote:
> >> > >      > Strong -1 on Java 8 as the minimum version. Google Cloud
> >> Platform
> >> > has
> >> > >      > lots of products and customers that still require Java 7. If
> >> Maven
> >> > >      > requires Java 8, we'd have to stick to the latest of
> >> whichever
> >> > >     release
> >> > >      > does support Java 7 for at least a year and I'm guessing
> >> longer.
> >> > >
> >> > >     Hm.. first Java 7 is out for eight years now (2011) (End of
> >> live)
> >> and
> >> > >     has no public updates for security/bug fixes etc. since 2015
> >> > >
> >> > >     Furthermore Java 8 is out for five years (2014) so to be
> honest
> >> I
> >> > >     wouldn't trust an environment which is not upgrading etc. in
> >> > particular
> >> > >     in a clould environment...
> >> > >
> >> > >     Why hadn't started Google to update their environment over the
> >> time
> >> > to
> >> > >     JDK 8 etc. (I think they have much more resources than anyone).
> >> > >
> >> > >
> >> > >     One more thing is:
> >> > >        There is a difference between running Maven to build for
> >> example
> >> > >        with JDK 8 and running your resulting artifacts (see
> >> toolchain
> >> > >     comment
> >> > >        from Stephen Connolly..
> >> > >
> >> > >     Kind regards
> >> > >     Karl Heinz Marbaise
> >> > >
> >> > >
> >> > >     [1]:
> >> > >
> >> https://www.oracle.com/technetwork/java/java-se-support-roadmap.html
> >> > >
> >> > >
> >> > >      >
> >> > >      > On Sat, Sep 28, 2019 at 8:04 AM Robert Scholte
> >> > >     <[hidden email] <mailto:[hidden email]>> wrote:
> >> > >      >>
> >> > >      >> Hi,
> >> > >      >>
> >> > >      >> TLDR; introduce maven.experimental.buildconsumer and push
> >> Java
> >> > >     requirement
> >> > >      >> to Java 8
> >> > >      >>
> >> > >      >> now that Maven 3.6.2 is out for a couple of weeks, it seems
> >> like
> >> > >     we didn't
> >> > >      >> face real regressions.
> >> > >      >> The only one might be tricky is the issue related to Tycho.
> >> > >      >>
> >> > >      >> However, I think we're ready to push Maven to the next
> >> level.
> >> > >      >>
> >> > >      >> For those actively reading this list, they should
> recognize
> >> the
> >> > >     need for
> >> > >      >> splitting up the pom as it is on the local system versus the
> >> pom
> >> > >     being
> >> > >      >> uploaded. Once we truly control this mechanism we can
> think
> >> of
> >> > >      >> improvements on model 5.0.0 and new fileformats.
> >> > >      >>
> >> > >      >> I've created and implemented MNG-6656[1]. It also contains a
> >> zip
> >> > >     with an
> >> > >      >> example (original, patched, README) to understand what's
> >> > happening.
> >> > >      >>
> >> > >      >> In order to make this successful, we need IDEs and CI
> >> Servers
> >> to
> >> > >      >> understand and support these changes. The likely need to
> >> > >     implement one of
> >> > >      >> the interfaces[2].
> >> > >      >> The new interface uses Java8 Functions (and especially
> >> > >     SAXEventFactory is
> >> > >      >> way easier to read+maintain with Java 8). I've tried to keep
> >> > >     Maven Java 7
> >> > >      >> compatible, but that was too hard to do.
> >> > >      >> So I'd like to use this opportunity to move Maven forward
> >> and
> >> > start
> >> > >      >> requiring Java 8.
> >> > >      >>
> >> > >      >> There are some other improvements I'd like to add (those
> >> > >     messages will
> >> > >      >> follow), so this will imply that it will take some time
> >> before
> >> > >     we do a new
> >> > >      >> release.
> >> > >      >>
> >> > >      >> WDTY,
> >> > >      >> Robert
> >> > >      >>
> >> > >      >> [1] https://issues.apache.org/jira/browse/MNG-6656
> >> > >      >> [2]
> >> https://github.com/apache/maven/compare/MNG-6656?expand=1
> >> > >      >>
> >> > >      >>
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: [hidden email]
> >> > For additional commands, e-mail: [hidden email]
> >> >
> >> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: maven release lifecycle

Tibor Digana
In reply to this post by Marco Schulz
I have never seen a documentation for ship-maven-plugin.
It could be a good motivation for us.

I can say for myself, my requirements are to the new lifecycle and plugin
goal release:release:
1. executes phases from clean to deploy
2. installation of "release" artifacts is skipped (snapshots are not
skipped)
3. unit and integration tests are executed only once and not two times

Tagging and SCM checkout are just fine.

Second lifecycle for release without scm checkout and deployment. The test
would be executed once, tagging and both commit messages are the must.

WDYT? How you would like to see the release lifecysle?
Notice that we should not say how the project should look like in the
customer. The customer may have reasons to use his project structures as
they are and the architecture too. So we should NOT define these structures!


On Sat, Oct 5, 2019 at 2:47 PM Marco Schulz <[hidden email]>
wrote:

> All this points are in my opinion an indicator that a release is a complex
> process and very difficult to handle in just a plugin. To maintain all that
> different points a relesaplugin will ver a ueber (god) plugin.
>
> Docker for example is another big toic we need to think about.
>
> rwgards and anice weekend to all
> . marco
>
> Sent from Outlook Mobile<https://aka.ms/blhgte>
>
> ________________________________
> From: Romain Manni-Bucau <[hidden email]>
> Sent: Saturday, October 5, 2019 2:06:27 AM
> To: Maven Developers List <[hidden email]>
> Cc: users <[hidden email]>
> Subject: Re: Proposal: maven release lifecycle
>
> I like the words but fail to see the missing pieces (understand actions to
> do).
>
> Typically today when i release at work i use release plugin enriched with
> github page deployment for the doc using antora + a ftp update of my server
> output capture to have a mock backing openapi/swagger ui + docker ilage
> deployment on docker hub + an intellij plugin deployment on jetbrains
> marketplace etc...adding a flyway migration with a rolling update in a k8s
> cluster is trivial (ops need to say yes though ;)).
>
> So technically it is verbose but doable.
>
> Custom lifecycle definition is not neat, custom build tasks require a build
> hack or using groovy plugin but it works.
>
> Typically, an extension could enable all that based on convention, just
> injecting needed plugins based on the file presence and values of the
> distribution urls.
>
> This is why i ended up thinking we are more on 1. Sugar in release plugin
> and 2. Maybe on a generic extension cretion (it replaces rigid lifecycle
> for such cases these days due to their writing easiness)
>
> Am I missing something?
>
> Le sam. 5 oct. 2019 à 08:23, Marco Schulz <[hidden email]> a
> écrit :
>
> > Hello Romain, hello Tibor
> >
> > Thanks for your feedback. I had yesterday a very interesting conversation
> > with
> > Karl Heinz. He gave me some very informative links about deeply maven
> > insights.
> > Before I saw his talk on youtube I thought I have a good knowledge about
> > maven
> > ;-)  now I was lerning a lot of new things.
> >
> > He defined Maven as an plugin execution framework. I like to extend this
> > definition: Maven is a process engine framework and define industrial
> > defacto
> > standards for the software development process. And with this idea in
> mind
> > I
> > think it could be great to define more workflows in a equal manner like
> the
> > build lifecycle. The basic proposal is a first draft and I know some
> > points are
> > missing. I tried to keep the release process as simple as possible. Two
> > positions in this definition was impotent for me.
> >
> > Often companies don't really have well structured release processes. For
> > that
> > reason I would be great to have a workable standard. I have a small Java
> > project
> > on GitHub, an sometimes I also deploy to maven central. If you do this
> the
> > first
> > time a bit complicated process. And publishing on maven central is also a
> > release process. So I had the intention to define some ordered steps like
> > in the
> > build lifecycle to prepare and publish a release.
> >
> > Let me describe an example scenario for a release: After mvn build was
> > successful executed all unit tests are passed, the sprint is finished and
> > as
> > build manager we want to release our artifact. Very important would be an
> > option
> > to take the results from the build lifecycle and prepare the release. As
> > first
> > we need to see that the planned artifact version is not exist in any
> > configured
> > public repository and the pom contains all mandatory information for
> > publishing
> > on maven central(validate). To secure a reproducible build, in a second
> > step we
> > enforce that no SNAPSHOT artifacts are involved, the correct maven
> version
> > is
> > used etc. (the existing enforcer plugin do a great job). After the
> > preconditions
> > are fine we can execute external acceptance tests like JGiven. In another
> > step
> > the JavaDoc got generated. the pgp plugin sing the artifacts and check
> > that the
> > public key is available. The SCM plugin create a tag for the released
> > revision.
> > Difficult parts are auto increment the version number and auto check the
> > scm if
> > the release is produced with the last revision of the code. This actions
> > are by
> > my experience a bit error prune.
> > A release process could have some vocabulary like prepare, perform,
> > deploy. This
> > are just conventions, like it is used in the build lifecycle. To realize
> > this
> > idea, many already existing plugins can used, like the release plugin. In
> > this
> > proposal I was also not mentions external plugins to use like flyway, for
> > database versioning and so on. A lot of things ar imaginable.
> >
> > In future more lifecycles or workflows could be possible. For example a
> > deploy
> > lifecycle and so on. And then maven transform from a plugin execution
> > framework
> > to a process management framework, like Jason van Zyl described in his
> book
> > better build with maven.
> >
> > warm regards to all
> > .marco
> >
> >
> >
> >
> > On Fri, 2019-10-04 at 11:28 +0200, Romain Manni-Bucau wrote:
> > > @Tibor: I agree merging both in one "super" command can be neat (I
> always
> > > run both at once typically) but I disagree with last parts "skip the
> > test"
> > > - maven is also there to enforce tests as a good practise, if you don't
> > > automatically test it you can configure maven to skip tests for the
> > release
> > > but it is at your own risk, can be fine or not - and "skip the deploy"
> -
> > > here again you can configure maven to do it if you need but maven must
> > > respect the build attached artifact.
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> > >
> > >
> > > Le ven. 4 oct. 2019 à 11:22, Tibor Digana <[hidden email]> a
> > écrit :
> > >
> > > > It would be worth to add a new goal called "release" to the
> > > > maven-release-plugin which merges "prepare" and "perform".
> > > > We developers in companies use both goals prepare and perform
> > immediately
> > > > together because for us two goals do not make sense.
> > > > Two goals make sense for those who can wait days to start manual
> tests
> > of
> > > > the TAG but we don't!
> > > >
> > > > We are testing the JAR libraries beforehand and then we evaluate the
> > > > quality/manual tests with SNAPSHOT whether it makes sense to start
> the
> > > > release process in CLI.
> > > > If there are web archives, the prepare phase would be enough because
> > > > deployment in Nexus is useless nothing but the TAG itself and
> > Continuous
> > > > Delivery.
> > > >
> > > > On Fri, Oct 4, 2019 at 8:34 AM Romain Manni-Bucau <
> > [hidden email]>
> > > > wrote:
> > > >
> > > > > Hi Marco,
> > > > >
> > > > > I have 2 thoughts reading your post:
> > > > >
> > > > > 1. Should be enforced by an extension (sonatype plugin if target is
> > > > > central?)
> > > > > 2. It likely misses a few phases compared to maven release plugin
> > which
> > > > > validates the release can be done (including tests) and runs the
> > tests on
> > > > > the tag as well
> > > > >
> > > > > Now if 200 lines of xml can be replaced by a single extension I am
> > +1000
> > > >
> > > > on
> > > > > that track
> > > > >
> > > > > Le ven. 4 oct. 2019 à 08:24, Marco Schulz <
> [hidden email]>
> > a
> > > > > écrit :
> > > > >
> > > > > > Hello Maven Dev & Community
> > > > > >
> > > > > > Sine a long time I thought, it would be cool to have a well
> defined
> > > > > > process to
> > > > > > prepare a release of an artifact and deploy it on mvn central.
> Now
> > I
> > > >
> > > > got
> > > > > a
> > > > > > bit
> > > > > > time to formulate a short proposal of my idea. I published a
> > > >
> > > > description
> > > > > > of my
> > > > > > thought on my bolg:
> > > > > > https://enrebaja.wordpress.com/2019/10/03/next-generation-maven/
> > > > > >
> > > > > > A poll is also created, may to see what other people think about
> > it.
> > > > > > Please feel
> > > > > > free to leave also comments, every feedback is welcome.
> > > > > >
> > > > > > warm regards & thanks to the maven dev team for the great job
> they
> > do.
> > > > > > .marco (@ElmarDott)
> > > > > >
> > > > > > --
> > > > > >
> > > > > >
> > > >
> > > >
> >
> ____________________________________________________________________________
> > > > ____
> > > > > >  Dipl. Inf. Marco Schulz (MSc)
> > > > > >
> > > > > >                   Expert for (WEB) Enterprise Applications
> > > > > >                            - worldwide -
> > > > > >       + Project Manager + Consultant + Writer + Speaker +
> Trainer +
> > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> >
> [Contact]___________________________________________________________________
> > > > ____
> > > > > >
> > > > > >    WhatsApp :  +52 (1) 221 200 61 37 :: Mexico
> > > > > >    Cell     :  +49 (0) 163 69 18 445 :: Germany
> > > > > >    E-Mail   :  [hidden email]
> > > > > >
> > > > > >    Blog     :  https://enRebaja.wordpress.com
> > > > > >    twitter  :  https://twitter.com/ElmarDott
> > > > > >    tumblr   :  https://elmardott.tumblr.com
> > > > > >    facebook :  https://www.facebook.com/elmar.dott
> > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> >
> [Services]__________________________________________________________________
> > > > ____
> > > > > >
> > > > > >     + Individual software development
> > > > > >     + Software Project Management
> > > > > >     + Build-,  Configuration-, & Delivery Management
> > > > > >     + Release Management
> > > > > >     + Business Analysis
> > > > > >     + Software Architecture
> > > > > >     + Process Automation
> > > > > >
> > > > > >
> > > >
> > > >
> >
> ____________________________________________________________________________
> > > > ____
> > > > > > This message is intended only for the use of the individual or
> > entity
> > > >
> > > > to
> > > > > > which
> > > > > > it is addressed, and may contain information that is privileged,
> > > > > > confidential
> > > > > > and that may not be made public by law or agreement. If you are
> > not the
> > > > > > intended
> > > > > > recipient or entity, you are hereby notified that any further
> > > > > > dissemination,
> > > > > > distribution or copying of this information is strictly
> prohibited.
> > > > > > If you have received this communication in error, please contact
> us
> > > > > > immediately
> > > > > > and delete the message from your system.
> > > > > >
> > > > > >
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Maven 3.7.0

stephenconnolly
In reply to this post by Robert Scholte-8
You cannot have Java 8 sources produce Java 7 bytecode with the Java 8's
javac.

-target must be >= -source

So to say:

> So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!

Is not possible, you'll get something like:

$ javac Test -source 1.8 -target 1.7
javac: source release 1.8 requires target release 1.8

While we could use something like https://github.com/luontola/retrolambda
its usage is not without significant risks. You really need to be very
careful in how you use it, and the effort is IMHO far exceeding the risk.
Much better to just say Maven 3.7.0 is requires the runtime JVM be Java 8+,
use toolchains if you need to compile or unit tests with older JDKs.

We have agreed before that upgrading the Maven minor or major version would
affect the JREs that Maven can run on. Basically following a one and one
back for Oracle supported JDKs, thus 3.7.0 per that policy would be forced
to Java 8 as minimum anyway.... in other words, our users should be
expecting us to go Java 8 as baseline.

On Tue, 29 Oct 2019 at 10:28, Tibor Digana <[hidden email]> wrote:

> Stephen, what issue with current toolchain you mean?
>
> On Tue, Oct 29, 2019 at 11:11 AM Stephen Connolly <
> [hidden email]> wrote:
>
> > On Tue, 29 Oct 2019 at 08:02, Tibor Digana <[hidden email]>
> wrote:
> >
> > > Robert, I saw the code. The class has a method which returns Lambda
> > > function. The whole class was designed with OOP. The OOP is a good
> thing
> > > which you should follow and follow this approach and not to return the
> > > labda function. Basically it is a precedense created in the PR saying
> > that
> > > now J8 has to be used in the bytecode.
> > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
> > >
> >
> > That is not possible using the current toolchains. Let's just go with
> Java
> > 8. There seems no good reason to hold back
> >
> >
> > >
> > > On Tue, Oct 29, 2019 at 8:25 AM Robert Scholte <[hidden email]>
> > > wrote:
> > >
> > > > The outcome is quite clear to me. There no clear 'No' to add this
> > > > build/consumer feature into 3.7.0, so we'll add it which implies we
> > must
> > > > move to Java 8 due to new APIs with Java 8 class signatures.
> > > >
> > > > But first we need to deliver a 3.6.3 regression release.
> > > >
> > > > Robert
> > > >
> > > > On 29-10-2019 05:53:25, Romain Manni-Bucau <[hidden email]>
> > > wrote:
> > > > +1, the risk is more or less 0 since we can still use branches for
> > > > potential fixes for "old" projects using frozen java and maven
> versions
> > > > anyway
> > > >
> > > > Guess we can even be very precautionous doing 1. an upgrade to
> bytecode
> > > > version without any code change (to change the major version in
> > > bytecode),
> > > > 2. a M1 to let users test it if some still doubt.
> > > >
> > > > Le mar. 29 oct. 2019 à 04:06, Olivier Lamy a écrit :
> > > >
> > > > > so what is the status of this?
> > > > > will we discuss in 2025 about being able to use java 8 apis or do
> we
> > > have
> > > > > to wait 2030?
> > > > > Sorry to be sarcastic but not moving forward it's certainly a
> reason
> > > why
> > > > we
> > > > > do not have more people participating in the project....
> > > > > It is so frustrating to be stuck with old apis...
> > > > >
> > > > >
> > > > >
> > > > > On Thu, 10 Oct 2019 at 04:36, Tibor Digana wrote:
> > > > >
> > > > > > I have to fully agree on Michael Osipov. This discussion is
> > > > > > contraproductive from the time perspective.
> > > > > > He explained the situation in Maven very clearly that we have
> over
> > > 1800
> > > > > > bugs and here we are talking about javac compiler version which
> > does
> > > > not
> > > > > > fix these bugs.
> > > > > > We know that our community is quite big but we also know that we
> > have
> > > > > only
> > > > > > few several developers who regularily provides fixes for the bug
> > and
> > > > they
> > > > > > do it for free!
> > > > > > So my advice is to leave these talks alone about technology lobby
> > > (seen
> > > > > on
> > > > > > ML from outside as well) and rather concentrate on the bug. We
> have
> > > > seen
> > > > > > that the users/contributors handled performance issues and fixed
> > them
> > > > > which
> > > > > > means that these contributors got very good proficiency level!
> > > > > >
> > > > > > On Wed, Oct 9, 2019 at 7:56 PM Alexander Ashitkin <>
> > > > > [hidden email]
> > > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Totally disagree on the point. Writing java7 code after 8 makes
> > you
> > > > > feel
> > > > > > > suffering - because instead of expressive stream based
> operations
> > > and
> > > > > > > lambdas you write pointless iterators and copy collections.
> > > > > > > It is purely subjective opinion that lambdas make code less
> > > readable
> > > > -
> > > > > at
> > > > > > > least there is an absolutely opposite opinion
> > > > > > >
> > > > > > > Thank you
> > > > > > > Aleks
> > > > > > >
> > > > > > > On 2019/10/03 12:47:35, Paul Hammant wrote:
> > > > > > > > Who codes for 18 months before discovering that qa/prod are
> not
> > > > > > > compatible,
> > > > > > > > anymore? Especially if Google ship a use-this-Pom starter.
> > > > > > > >
> > > > > > > > On Thu, Oct 3, 2019 at 1:44 PM Elliotte Rusty Harold <>
> > > > > > [hidden email]
> > > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Theoretically that would work. In practice though, every
> > > project
> > > > > I've
> > > > > > > > > seen convert to Java 8 rapidly starts adding lambdas that
> > make
> > > > the
> > > > > > > > > code more obfuscated for no good reason and soon introduces
> > > hard
> > > > > > > > > dependencies on Java 8, intentionally or otherwise. At a
> bare
> > > > > > minimum,
> > > > > > > > > a CI environment that runs Java 7 is required.
> > > > > > > > >
> > > > > > > > > On Thu, Oct 3, 2019 at 8:25 AM Paul Hammant
> > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Would jdk 8 for maven itself and a target of 7 for the
> > > compiler
> > > > > > > (etc) for
> > > > > > > > > > maven-using projects be ok?
> > > > > > > > > >
> > > > > > > > > > On Thu, Oct 3, 2019 at 1:15 PM Elliotte Rusty Harold <>
> > > > > > > [hidden email]
> > > > > > > > > >
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Strong -1 on Java 8 as the minimum version. Google
> Cloud
> > > > > Platform
> > > > > > > has
> > > > > > > > > > > lots of products and customers that still require Java
> 7.
> > > If
> > > > > > Maven
> > > > > > > > > > > requires Java 8, we'd have to stick to the latest of
> > > > whichever
> > > > > > > release
> > > > > > > > > > > does support Java 7 for at least a year and I'm
> guessing
> > > > > longer.
> > > > > > > > > > >
> > > > > > > > > > > On Sat, Sep 28, 2019 at 8:04 AM Robert Scholte <>
> > > > > > > [hidden email]>
> > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Hi,
> > > > > > > > > > > >
> > > > > > > > > > > > TLDR; introduce maven.experimental.buildconsumer and
> > push
> > > > > Java
> > > > > > > > > > > requirement
> > > > > > > > > > > > to Java 8
> > > > > > > > > > > >
> > > > > > > > > > > > now that Maven 3.6.2 is out for a couple of weeks, it
> > > seems
> > > > > > like
> > > > > > > we
> > > > > > > > > > > didn't
> > > > > > > > > > > > face real regressions.
> > > > > > > > > > > > The only one might be tricky is the issue related to
> > > Tycho.
> > > > > > > > > > > >
> > > > > > > > > > > > However, I think we're ready to push Maven to the
> next
> > > > level.
> > > > > > > > > > > >
> > > > > > > > > > > > For those actively reading this list, they should
> > > recognize
> > > > > the
> > > > > > > need
> > > > > > > > > for
> > > > > > > > > > > > splitting up the pom as it is on the local system
> > versus
> > > > the
> > > > > > pom
> > > > > > > > > being
> > > > > > > > > > > > uploaded. Once we truly control this mechanism we can
> > > think
> > > > > of
> > > > > > > > > > > > improvements on model 5.0.0 and new fileformats.
> > > > > > > > > > > >
> > > > > > > > > > > > I've created and implemented MNG-6656[1]. It also
> > > contains
> > > > a
> > > > > > zip
> > > > > > > > > with an
> > > > > > > > > > > > example (original, patched, README) to understand
> > what's
> > > > > > > happening.
> > > > > > > > > > > >
> > > > > > > > > > > > In order to make this successful, we need IDEs and CI
> > > > Servers
> > > > > > to
> > > > > > > > > > > > understand and support these changes. The likely need
> > to
> > > > > > > implement
> > > > > > > > > one of
> > > > > > > > > > > > the interfaces[2].
> > > > > > > > > > > > The new interface uses Java8 Functions (and
> especially
> > > > > > > > > SAXEventFactory is
> > > > > > > > > > > > way easier to read+maintain with Java 8). I've tried
> to
> > > > keep
> > > > > > > Maven
> > > > > > > > > Java 7
> > > > > > > > > > > > compatible, but that was too hard to do.
> > > > > > > > > > > > So I'd like to use this opportunity to move Maven
> > forward
> > > > and
> > > > > > > start
> > > > > > > > > > > > requiring Java 8.
> > > > > > > > > > > >
> > > > > > > > > > > > There are some other improvements I'd like to add
> > (those
> > > > > > messages
> > > > > > > > > will
> > > > > > > > > > > > follow), so this will imply that it will take some
> time
> > > > > before
> > > > > > > we do
> > > > > > > > > a
> > > > > > > > > > > new
> > > > > > > > > > > > release.
> > > > > > > > > > > >
> > > > > > > > > > > > WDTY,
> > > > > > > > > > > > Robert
> > > > > > > > > > > >
> > > > > > > > > > > > [1] https://issues.apache.org/jira/browse/MNG-6656
> > > > > > > > > > > > [2]
> > > > > https://github.com/apache/maven/compare/MNG-6656?expand=1
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > > > > > > To unsubscribe, e-mail:
> > [hidden email]
> > > > > > > > > > > > For additional commands, e-mail:
> > > [hidden email]
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Elliotte Rusty Harold
> > > > > > > > > > > [hidden email]
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > > > > > To unsubscribe, e-mail:
> [hidden email]
> > > > > > > > > > > For additional commands, e-mail:
> > [hidden email]
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Elliotte Rusty Harold
> > > > > > > > > [hidden email]
> > > > > > > > >
> > > > > > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > > > > > To unsubscribe, e-mail: [hidden email]
> > > > > > > > > For additional commands, e-mail: [hidden email]
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: [hidden email]
> > > > > > > For additional commands, e-mail: [hidden email]
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Olivier Lamy
> > > > > http://twitter.com/olamy | http://linkedin.com/in/olamy
> > > > >
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Maven 3.7.0

stephenconnolly
On Tue, 29 Oct 2019 at 12:47, Stephen Connolly <
[hidden email]> wrote:

> We already have a version policy:
> https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy
>

(while that page says draft, the proposal was on-list in 2014 and just
converted into a wiki page afterwards - hence why the examples use 2014
dates)


> > The development line of Maven core should require a minimum JRE version
> that is no older than 18 months after the end of Oracle's public updates
> for that JRE version at the time that the first version of the development
> line was released, but may require a higher minimum JRE version if other
> requirements dictate a higher JRE version.
>
> End of public updates for Java 8 from Oracle was January 2019, thus if we
> cut a new minor version we would be Java 8 but not Java 7.
>
>
> On Tue, 29 Oct 2019 at 12:28, Tibor Digana <[hidden email]> wrote:
>
>> Stephen, we are in loop.
>> Of course I know these technical things.
>> But I am saying, and I am not alone (Michael Osipov too), that I agree
>> with
>> sources 1.8, but there must be1.  the Vote with milestones regarding Maven
>> and another Vote regarding plugins, and 2. written list of pros/cons
>> regarding J8 and 3. developer guideline for J8 (for devs, consultants,
>> another professions as well in the team).
>> You know, with video calls, all these public emails would be gone within
>> one or two hours, I am sure!
>> I am also sure that we will have another code preferences and therefore we
>> should have some guideline. For instance, I like to have clear OOP in the
>> public class/interfaces and Lambda in private code. And there are a lot of
>> stuff, like parallel streams ala thread pool of non-daemon threads,
>> performance of streams (when, how stream is constructed, etc), Date Time
>> API is new as well.
>>
>> No benefit for the community with J7 sources but yes with J8 code. Believe
>> me, this is true. Michael mentioned that as well.
>>
>
> Not true. Java 8 bytecode adds additional metadata that speeds up
> classloading (but only when the class graph is all Java 8)
>
>
>>
>> It is also true that we have a lot of bugs, and it is true that Maven
>> needs
>> to have breakthrough features like reproducible build and User POM, Docker
>> prefetched cache, etc.
>> I have no argument against these things. The only problem that I have and
>> Michael has is the way how this is managed but it is the only trivial
>> problem that we can solve between us.
>>
>>
>>
>>
>>
>> On Tue, Oct 29, 2019 at 1:04 PM Stephen Connolly <
>> [hidden email]> wrote:
>>
>> > You cannot have Java 8 sources produce Java 7 bytecode with the Java 8's
>> > javac.
>> >
>> > -target must be >= -source
>> >
>> > So to say:
>> >
>> > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
>> >
>> > Is not possible, you'll get something like:
>> >
>> > $ javac Test -source 1.8 -target 1.7
>> > javac: source release 1.8 requires target release 1.8
>> >
>> > While we could use something like
>> https://github.com/luontola/retrolambda
>> > its usage is not without significant risks. You really need to be very
>> > careful in how you use it, and the effort is IMHO far exceeding the
>> risk.
>> > Much better to just say Maven 3.7.0 is requires the runtime JVM be Java
>> 8+,
>> > use toolchains if you need to compile or unit tests with older JDKs.
>> >
>> > We have agreed before that upgrading the Maven minor or major version
>> would
>> > affect the JREs that Maven can run on. Basically following a one and one
>> > back for Oracle supported JDKs, thus 3.7.0 per that policy would be
>> forced
>> > to Java 8 as minimum anyway.... in other words, our users should be
>> > expecting us to go Java 8 as baseline.
>> >
>> > On Tue, 29 Oct 2019 at 10:28, Tibor Digana <[hidden email]>
>> wrote:
>> >
>> > > Stephen, what issue with current toolchain you mean?
>> > >
>> > > On Tue, Oct 29, 2019 at 11:11 AM Stephen Connolly <
>> > > [hidden email]> wrote:
>> > >
>> > > > On Tue, 29 Oct 2019 at 08:02, Tibor Digana <[hidden email]>
>> > > wrote:
>> > > >
>> > > > > Robert, I saw the code. The class has a method which returns
>> Lambda
>> > > > > function. The whole class was designed with OOP. The OOP is a good
>> > > thing
>> > > > > which you should follow and follow this approach and not to return
>> > the
>> > > > > labda function. Basically it is a precedense created in the PR
>> saying
>> > > > that
>> > > > > now J8 has to be used in the bytecode.
>> > > > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
>> > > > >
>> > > >
>> > > > That is not possible using the current toolchains. Let's just go
>> with
>> > > Java
>> > > > 8. There seems no good reason to hold back
>> > > >
>> > > >
>> > > > >
>> > > > > On Tue, Oct 29, 2019 at 8:25 AM Robert Scholte <
>> [hidden email]
>> > >
>> > > > > wrote:
>> > > > >
>> > > > > > The outcome is quite clear to me. There no clear 'No' to add
>> this
>> > > > > > build/consumer feature into 3.7.0, so we'll add it which
>> implies we
>> > > > must
>> > > > > > move to Java 8 due to new APIs with Java 8 class signatures.
>> > > > > >
>> > > > > > But first we need to deliver a 3.6.3 regression release.
>> > > > > >
>> > > > > > Robert
>> > > > > >
>> > > > > > On 29-10-2019 05:53:25, Romain Manni-Bucau <
>> [hidden email]>
>> > > > > wrote:
>> > > > > > +1, the risk is more or less 0 since we can still use branches
>> for
>> > > > > > potential fixes for "old" projects using frozen java and maven
>> > > versions
>> > > > > > anyway
>> > > > > >
>> > > > > > Guess we can even be very precautionous doing 1. an upgrade to
>> > > bytecode
>> > > > > > version without any code change (to change the major version in
>> > > > > bytecode),
>> > > > > > 2. a M1 to let users test it if some still doubt.
>> > > > > >
>> > > > > > Le mar. 29 oct. 2019 à 04:06, Olivier Lamy a écrit :
>> > > > > >
>> > > > > > > so what is the status of this?
>> > > > > > > will we discuss in 2025 about being able to use java 8 apis
>> or do
>> > > we
>> > > > > have
>> > > > > > > to wait 2030?
>> > > > > > > Sorry to be sarcastic but not moving forward it's certainly a
>> > > reason
>> > > > > why
>> > > > > > we
>> > > > > > > do not have more people participating in the project....
>> > > > > > > It is so frustrating to be stuck with old apis...
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > On Thu, 10 Oct 2019 at 04:36, Tibor Digana wrote:
>> > > > > > >
>> > > > > > > > I have to fully agree on Michael Osipov. This discussion is
>> > > > > > > > contraproductive from the time perspective.
>> > > > > > > > He explained the situation in Maven very clearly that we
>> have
>> > > over
>> > > > > 1800
>> > > > > > > > bugs and here we are talking about javac compiler version
>> which
>> > > > does
>> > > > > > not
>> > > > > > > > fix these bugs.
>> > > > > > > > We know that our community is quite big but we also know
>> that
>> > we
>> > > > have
>> > > > > > > only
>> > > > > > > > few several developers who regularily provides fixes for the
>> > bug
>> > > > and
>> > > > > > they
>> > > > > > > > do it for free!
>> > > > > > > > So my advice is to leave these talks alone about technology
>> > lobby
>> > > > > (seen
>> > > > > > > on
>> > > > > > > > ML from outside as well) and rather concentrate on the bug.
>> We
>> > > have
>> > > > > > seen
>> > > > > > > > that the users/contributors handled performance issues and
>> > fixed
>> > > > them
>> > > > > > > which
>> > > > > > > > means that these contributors got very good proficiency
>> level!
>> > > > > > > >
>> > > > > > > > On Wed, Oct 9, 2019 at 7:56 PM Alexander Ashitkin <>
>> > > > > > > [hidden email]
>> > > > > > > > >
>> > > > > > > > wrote:
>> > > > > > > >
>> > > > > > > > > Totally disagree on the point. Writing java7 code after 8
>> > makes
>> > > > you
>> > > > > > > feel
>> > > > > > > > > suffering - because instead of expressive stream based
>> > > operations
>> > > > > and
>> > > > > > > > > lambdas you write pointless iterators and copy
>> collections.
>> > > > > > > > > It is purely subjective opinion that lambdas make code
>> less
>> > > > > readable
>> > > > > > -
>> > > > > > > at
>> > > > > > > > > least there is an absolutely opposite opinion
>> > > > > > > > >
>> > > > > > > > > Thank you
>> > > > > > > > > Aleks
>> > > > > > > > >
>> > > > > > > > > On 2019/10/03 12:47:35, Paul Hammant wrote:
>> > > > > > > > > > Who codes for 18 months before discovering that qa/prod
>> are
>> > > not
>> > > > > > > > > compatible,
>> > > > > > > > > > anymore? Especially if Google ship a use-this-Pom
>> starter.
>> > > > > > > > > >
>> > > > > > > > > > On Thu, Oct 3, 2019 at 1:44 PM Elliotte Rusty Harold <>
>> > > > > > > > [hidden email]
>> > > > > > > > > >
>> > > > > > > > > > wrote:
>> > > > > > > > > >
>> > > > > > > > > > > Theoretically that would work. In practice though,
>> every
>> > > > > project
>> > > > > > > I've
>> > > > > > > > > > > seen convert to Java 8 rapidly starts adding lambdas
>> that
>> > > > make
>> > > > > > the
>> > > > > > > > > > > code more obfuscated for no good reason and soon
>> > introduces
>> > > > > hard
>> > > > > > > > > > > dependencies on Java 8, intentionally or otherwise.
>> At a
>> > > bare
>> > > > > > > > minimum,
>> > > > > > > > > > > a CI environment that runs Java 7 is required.
>> > > > > > > > > > >
>> > > > > > > > > > > On Thu, Oct 3, 2019 at 8:25 AM Paul Hammant
>> > > > > > > > wrote:
>> > > > > > > > > > > >
>> > > > > > > > > > > > Would jdk 8 for maven itself and a target of 7 for
>> the
>> > > > > compiler
>> > > > > > > > > (etc) for
>> > > > > > > > > > > > maven-using projects be ok?
>> > > > > > > > > > > >
>> > > > > > > > > > > > On Thu, Oct 3, 2019 at 1:15 PM Elliotte Rusty
>> Harold <>
>> > > > > > > > > [hidden email]
>> > > > > > > > > > > >
>> > > > > > > > > > > > wrote:
>> > > > > > > > > > > >
>> > > > > > > > > > > > > Strong -1 on Java 8 as the minimum version. Google
>> > > Cloud
>> > > > > > > Platform
>> > > > > > > > > has
>> > > > > > > > > > > > > lots of products and customers that still require
>> > Java
>> > > 7.
>> > > > > If
>> > > > > > > > Maven
>> > > > > > > > > > > > > requires Java 8, we'd have to stick to the latest
>> of
>> > > > > > whichever
>> > > > > > > > > release
>> > > > > > > > > > > > > does support Java 7 for at least a year and I'm
>> > > guessing
>> > > > > > > longer.
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > On Sat, Sep 28, 2019 at 8:04 AM Robert Scholte <>
>> > > > > > > > > [hidden email]>
>> > > > > > > > > > > > > wrote:
>> > > > > > > > > > > > > >
>> > > > > > > > > > > > > > Hi,
>> > > > > > > > > > > > > >
>> > > > > > > > > > > > > > TLDR; introduce maven.experimental.buildconsumer
>> > and
>> > > > push
>> > > > > > > Java
>> > > > > > > > > > > > > requirement
>> > > > > > > > > > > > > > to Java 8
>> > > > > > > > > > > > > >
>> > > > > > > > > > > > > > now that Maven 3.6.2 is out for a couple of
>> weeks,
>> > it
>> > > > > seems
>> > > > > > > > like
>> > > > > > > > > we
>> > > > > > > > > > > > > didn't
>> > > > > > > > > > > > > > face real regressions.
>> > > > > > > > > > > > > > The only one might be tricky is the issue
>> related
>> > to
>> > > > > Tycho.
>> > > > > > > > > > > > > >
>> > > > > > > > > > > > > > However, I think we're ready to push Maven to
>> the
>> > > next
>> > > > > > level.
>> > > > > > > > > > > > > >
>> > > > > > > > > > > > > > For those actively reading this list, they
>> should
>> > > > > recognize
>> > > > > > > the
>> > > > > > > > > need
>> > > > > > > > > > > for
>> > > > > > > > > > > > > > splitting up the pom as it is on the local
>> system
>> > > > versus
>> > > > > > the
>> > > > > > > > pom
>> > > > > > > > > > > being
>> > > > > > > > > > > > > > uploaded. Once we truly control this mechanism
>> we
>> > can
>> > > > > think
>> > > > > > > of
>> > > > > > > > > > > > > > improvements on model 5.0.0 and new fileformats.
>> > > > > > > > > > > > > >
>> > > > > > > > > > > > > > I've created and implemented MNG-6656[1]. It
>> also
>> > > > > contains
>> > > > > > a
>> > > > > > > > zip
>> > > > > > > > > > > with an
>> > > > > > > > > > > > > > example (original, patched, README) to
>> understand
>> > > > what's
>> > > > > > > > > happening.
>> > > > > > > > > > > > > >
>> > > > > > > > > > > > > > In order to make this successful, we need IDEs
>> and
>> > CI
>> > > > > > Servers
>> > > > > > > > to
>> > > > > > > > > > > > > > understand and support these changes. The likely
>> > need
>> > > > to
>> > > > > > > > > implement
>> > > > > > > > > > > one of
>> > > > > > > > > > > > > > the interfaces[2].
>> > > > > > > > > > > > > > The new interface uses Java8 Functions (and
>> > > especially
>> > > > > > > > > > > SAXEventFactory is
>> > > > > > > > > > > > > > way easier to read+maintain with Java 8). I've
>> > tried
>> > > to
>> > > > > > keep
>> > > > > > > > > Maven
>> > > > > > > > > > > Java 7
>> > > > > > > > > > > > > > compatible, but that was too hard to do.
>> > > > > > > > > > > > > > So I'd like to use this opportunity to move
>> Maven
>> > > > forward
>> > > > > > and
>> > > > > > > > > start
>> > > > > > > > > > > > > > requiring Java 8.
>> > > > > > > > > > > > > >
>> > > > > > > > > > > > > > There are some other improvements I'd like to
>> add
>> > > > (those
>> > > > > > > > messages
>> > > > > > > > > > > will
>> > > > > > > > > > > > > > follow), so this will imply that it will take
>> some
>> > > time
>> > > > > > > before
>> > > > > > > > > we do
>> > > > > > > > > > > a
>> > > > > > > > > > > > > new
>> > > > > > > > > > > > > > release.
>> > > > > > > > > > > > > >
>> > > > > > > > > > > > > > WDTY,
>> > > > > > > > > > > > > > Robert
>> > > > > > > > > > > > > >
>> > > > > > > > > > > > > > [1]
>> https://issues.apache.org/jira/browse/MNG-6656
>> > > > > > > > > > > > > > [2]
>> > > > > > > https://github.com/apache/maven/compare/MNG-6656?expand=1
>> > > > > > > > > > > > > >
>> > > > > > > > > > > > > >
>> > > > > > > > >
>> > > > >
>> ---------------------------------------------------------------------
>> > > > > > > > > > > > > > To unsubscribe, e-mail:
>> > > > [hidden email]
>> > > > > > > > > > > > > > For additional commands, e-mail:
>> > > > > [hidden email]
>> > > > > > > > > > > > > >
>> > > > > > > > > > > > >
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > --
>> > > > > > > > > > > > > Elliotte Rusty Harold
>> > > > > > > > > > > > > [hidden email]
>> > > > > > > > > > > > >
>> > > > > > > > > > > > >
>> > > > > > > > >
>> > > > >
>> ---------------------------------------------------------------------
>> > > > > > > > > > > > > To unsubscribe, e-mail:
>> > > [hidden email]
>> > > > > > > > > > > > > For additional commands, e-mail:
>> > > > [hidden email]
>> > > > > > > > > > > > >
>> > > > > > > > > > > > >
>> > > > > > > > > > >
>> > > > > > > > > > >
>> > > > > > > > > > >
>> > > > > > > > > > > --
>> > > > > > > > > > > Elliotte Rusty Harold
>> > > > > > > > > > > [hidden email]
>> > > > > > > > > > >
>> > > > > > > > > > >
>> > > > > > >
>> > > ---------------------------------------------------------------------
>> > > > > > > > > > > To unsubscribe, e-mail:
>> [hidden email]
>> > > > > > > > > > > For additional commands, e-mail:
>> > [hidden email]
>> > > > > > > > > > >
>> > > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > >
>> > > > > > > > >
>> > > > >
>> ---------------------------------------------------------------------
>> > > > > > > > > To unsubscribe, e-mail: [hidden email]
>> > > > > > > > > For additional commands, e-mail:
>> [hidden email]
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > --
>> > > > > > > Olivier Lamy
>> > > > > > > http://twitter.com/olamy | http://linkedin.com/in/olamy
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: [DISCUSS] Maven 3.7.0

Michael Osipov-3
I would absolutely not want to drop Java 8 before 2023 or later for the
same vendor support you have mentioned.

It is a good baseline for the years for now. Always consider that provide
a build tool and not a cutting-edge Spring Boot application.

Michael

> Gesendet: Dienstag, 29. Oktober 2019 um 14:21 Uhr
> Von: "Stephen Connolly" <[hidden email]>
> An: "Maven Developers List" <[hidden email]>
> Betreff: Re: Re: [DISCUSS] Maven 3.7.0
>
> Because maintaining Java 7 is a barrier to new contributors. It is tricky
> enough to get Java 8 set up for some developers. Every version we support
> adds complexity for contributors. Personally, I think we should be thinking
> about dropping even Java 8 if we wait until next year and just follow the
> latest LTS line... but I am happy to keep with Java 8 as a baseline for
> now. Java 7 is only supported for a limited number of environments right
> now, whereas Java 8 has multiple vendors supporting it against multiple
> platforms at least until mid 2023.
>
> We hold back the entire community if we stick on a base version for too
> long.
>
> On Tue, 29 Oct 2019 at 13:00, Michael Osipov <[hidden email]> wrote:
>
> > Why not have 3.7.0 plugin updates and other non-technical stuff, have it
> > parallely maintained for some time and move with Maven 3.8.0 to Java 8
> > next year?!
> >
> > Does that sound like a plan? I'd be happy with that. I'd also expect
> > an announcement on dev@, announce@ and users@.
> >
> > Michael
> >
> > > Gesendet: Dienstag, 29. Oktober 2019 um 13:49 Uhr
> > > Von: "Stephen Connolly" <[hidden email]>
> > > An: "Maven Developers List" <[hidden email]>
> > > Betreff: Re: [DISCUSS] Maven 3.7.0
> > >
> > > On Tue, 29 Oct 2019 at 12:47, Stephen Connolly <
> > > [hidden email]> wrote:
> > >
> > > > We already have a version policy:
> > > >
> > https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy
> > > >
> > >
> > > (while that page says draft, the proposal was on-list in 2014 and just
> > > converted into a wiki page afterwards - hence why the examples use 2014
> > > dates)
> > >
> > >
> > > > > The development line of Maven core should require a minimum JRE
> > version
> > > > that is no older than 18 months after the end of Oracle's public
> > updates
> > > > for that JRE version at the time that the first version of the
> > development
> > > > line was released, but may require a higher minimum JRE version if
> > other
> > > > requirements dictate a higher JRE version.
> > > >
> > > > End of public updates for Java 8 from Oracle was January 2019, thus if
> > we
> > > > cut a new minor version we would be Java 8 but not Java 7.
> > > >
> > > >
> > > > On Tue, 29 Oct 2019 at 12:28, Tibor Digana <[hidden email]>
> > wrote:
> > > >
> > > >> Stephen, we are in loop.
> > > >> Of course I know these technical things.
> > > >> But I am saying, and I am not alone (Michael Osipov too), that I agree
> > > >> with
> > > >> sources 1.8, but there must be1.  the Vote with milestones regarding
> > Maven
> > > >> and another Vote regarding plugins, and 2. written list of pros/cons
> > > >> regarding J8 and 3. developer guideline for J8 (for devs, consultants,
> > > >> another professions as well in the team).
> > > >> You know, with video calls, all these public emails would be gone
> > within
> > > >> one or two hours, I am sure!
> > > >> I am also sure that we will have another code preferences and
> > therefore we
> > > >> should have some guideline. For instance, I like to have clear OOP in
> > the
> > > >> public class/interfaces and Lambda in private code. And there are a
> > lot of
> > > >> stuff, like parallel streams ala thread pool of non-daemon threads,
> > > >> performance of streams (when, how stream is constructed, etc), Date
> > Time
> > > >> API is new as well.
> > > >>
> > > >> No benefit for the community with J7 sources but yes with J8 code.
> > Believe
> > > >> me, this is true. Michael mentioned that as well.
> > > >>
> > > >
> > > > Not true. Java 8 bytecode adds additional metadata that speeds up
> > > > classloading (but only when the class graph is all Java 8)
> > > >
> > > >
> > > >>
> > > >> It is also true that we have a lot of bugs, and it is true that Maven
> > > >> needs
> > > >> to have breakthrough features like reproducible build and User POM,
> > Docker
> > > >> prefetched cache, etc.
> > > >> I have no argument against these things. The only problem that I have
> > and
> > > >> Michael has is the way how this is managed but it is the only trivial
> > > >> problem that we can solve between us.
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> On Tue, Oct 29, 2019 at 1:04 PM Stephen Connolly <
> > > >> [hidden email]> wrote:
> > > >>
> > > >> > You cannot have Java 8 sources produce Java 7 bytecode with the
> > Java 8's
> > > >> > javac.
> > > >> >
> > > >> > -target must be >= -source
> > > >> >
> > > >> > So to say:
> > > >> >
> > > >> > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
> > > >> >
> > > >> > Is not possible, you'll get something like:
> > > >> >
> > > >> > $ javac Test -source 1.8 -target 1.7
> > > >> > javac: source release 1.8 requires target release 1.8
> > > >> >
> > > >> > While we could use something like
> > > >> https://github.com/luontola/retrolambda
> > > >> > its usage is not without significant risks. You really need to be
> > very
> > > >> > careful in how you use it, and the effort is IMHO far exceeding the
> > > >> risk.
> > > >> > Much better to just say Maven 3.7.0 is requires the runtime JVM be
> > Java
> > > >> 8+,
> > > >> > use toolchains if you need to compile or unit tests with older JDKs.
> > > >> >
> > > >> > We have agreed before that upgrading the Maven minor or major
> > version
> > > >> would
> > > >> > affect the JREs that Maven can run on. Basically following a one
> > and one
> > > >> > back for Oracle supported JDKs, thus 3.7.0 per that policy would be
> > > >> forced
> > > >> > to Java 8 as minimum anyway.... in other words, our users should be
> > > >> > expecting us to go Java 8 as baseline.
> > > >> >
> > > >> > On Tue, 29 Oct 2019 at 10:28, Tibor Digana <[hidden email]>
> > > >> wrote:
> > > >> >
> > > >> > > Stephen, what issue with current toolchain you mean?
> > > >> > >
> > > >> > > On Tue, Oct 29, 2019 at 11:11 AM Stephen Connolly <
> > > >> > > [hidden email]> wrote:
> > > >> > >
> > > >> > > > On Tue, 29 Oct 2019 at 08:02, Tibor Digana <
> > [hidden email]>
> > > >> > > wrote:
> > > >> > > >
> > > >> > > > > Robert, I saw the code. The class has a method which returns
> > > >> Lambda
> > > >> > > > > function. The whole class was designed with OOP. The OOP is a
> > good
> > > >> > > thing
> > > >> > > > > which you should follow and follow this approach and not to
> > return
> > > >> > the
> > > >> > > > > labda function. Basically it is a precedense created in the PR
> > > >> saying
> > > >> > > > that
> > > >> > > > > now J8 has to be used in the bytecode.
> > > >> > > > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source
> > code!
> > > >> > > > >
> > > >> > > >
> > > >> > > > That is not possible using the current toolchains. Let's just go
> > > >> with
> > > >> > > Java
> > > >> > > > 8. There seems no good reason to hold back
> > > >> > > >
> > > >> > > >
> > > >> > > > >
> > > >> > > > > On Tue, Oct 29, 2019 at 8:25 AM Robert Scholte <
> > > >> [hidden email]
> > > >> > >
> > > >> > > > > wrote:
> > > >> > > > >
> > > >> > > > > > The outcome is quite clear to me. There no clear 'No' to add
> > > >> this
> > > >> > > > > > build/consumer feature into 3.7.0, so we'll add it which
> > > >> implies we
> > > >> > > > must
> > > >> > > > > > move to Java 8 due to new APIs with Java 8 class signatures.
> > > >> > > > > >
> > > >> > > > > > But first we need to deliver a 3.6.3 regression release.
> > > >> > > > > >
> > > >> > > > > > Robert
> > > >> > > > > >
> > > >> > > > > > On 29-10-2019 05:53:25, Romain Manni-Bucau <
> > > >> [hidden email]>
> > > >> > > > > wrote:
> > > >> > > > > > +1, the risk is more or less 0 since we can still use
> > branches
> > > >> for
> > > >> > > > > > potential fixes for "old" projects using frozen java and
> > maven
> > > >> > > versions
> > > >> > > > > > anyway
> > > >> > > > > >
> > > >> > > > > > Guess we can even be very precautionous doing 1. an upgrade
> > to
> > > >> > > bytecode
> > > >> > > > > > version without any code change (to change the major
> > version in
> > > >> > > > > bytecode),
> > > >> > > > > > 2. a M1 to let users test it if some still doubt.
> > > >> > > > > >
> > > >> > > > > > Le mar. 29 oct. 2019 à 04:06, Olivier Lamy a écrit :
> > > >> > > > > >
> > > >> > > > > > > so what is the status of this?
> > > >> > > > > > > will we discuss in 2025 about being able to use java 8
> > apis
> > > >> or do
> > > >> > > we
> > > >> > > > > have
> > > >> > > > > > > to wait 2030?
> > > >> > > > > > > Sorry to be sarcastic but not moving forward it's
> > certainly a
> > > >> > > reason
> > > >> > > > > why
> > > >> > > > > > we
> > > >> > > > > > > do not have more people participating in the project....
> > > >> > > > > > > It is so frustrating to be stuck with old apis...
> > > >> > > > > > >
> > > >> > > > > > >
> > > >> > > > > > >
> > > >> > > > > > > On Thu, 10 Oct 2019 at 04:36, Tibor Digana wrote:
> > > >> > > > > > >
> > > >> > > > > > > > I have to fully agree on Michael Osipov. This
> > discussion is
> > > >> > > > > > > > contraproductive from the time perspective.
> > > >> > > > > > > > He explained the situation in Maven very clearly that we
> > > >> have
> > > >> > > over
> > > >> > > > > 1800
> > > >> > > > > > > > bugs and here we are talking about javac compiler
> > version
> > > >> which
> > > >> > > > does
> > > >> > > > > > not
> > > >> > > > > > > > fix these bugs.
> > > >> > > > > > > > We know that our community is quite big but we also know
> > > >> that
> > > >> > we
> > > >> > > > have
> > > >> > > > > > > only
> > > >> > > > > > > > few several developers who regularily provides fixes
> > for the
> > > >> > bug
> > > >> > > > and
> > > >> > > > > > they
> > > >> > > > > > > > do it for free!
> > > >> > > > > > > > So my advice is to leave these talks alone about
> > technology
> > > >> > lobby
> > > >> > > > > (seen
> > > >> > > > > > > on
> > > >> > > > > > > > ML from outside as well) and rather concentrate on the
> > bug.
> > > >> We
> > > >> > > have
> > > >> > > > > > seen
> > > >> > > > > > > > that the users/contributors handled performance issues
> > and
> > > >> > fixed
> > > >> > > > them
> > > >> > > > > > > which
> > > >> > > > > > > > means that these contributors got very good proficiency
> > > >> level!
> > > >> > > > > > > >
> > > >> > > > > > > > On Wed, Oct 9, 2019 at 7:56 PM Alexander Ashitkin <>
> > > >> > > > > > > [hidden email]
> > > >> > > > > > > > >
> > > >> > > > > > > > wrote:
> > > >> > > > > > > >
> > > >> > > > > > > > > Totally disagree on the point. Writing java7 code
> > after 8
> > > >> > makes
> > > >> > > > you
> > > >> > > > > > > feel
> > > >> > > > > > > > > suffering - because instead of expressive stream based
> > > >> > > operations
> > > >> > > > > and
> > > >> > > > > > > > > lambdas you write pointless iterators and copy
> > > >> collections.
> > > >> > > > > > > > > It is purely subjective opinion that lambdas make code
> > > >> less
> > > >> > > > > readable
> > > >> > > > > > -
> > > >> > > > > > > at
> > > >> > > > > > > > > least there is an absolutely opposite opinion
> > > >> > > > > > > > >
> > > >> > > > > > > > > Thank you
> > > >> > > > > > > > > Aleks
> > > >> > > > > > > > >
> > > >> > > > > > > > > On 2019/10/03 12:47:35, Paul Hammant wrote:
> > > >> > > > > > > > > > Who codes for 18 months before discovering that
> > qa/prod
> > > >> are
> > > >> > > not
> > > >> > > > > > > > > compatible,
> > > >> > > > > > > > > > anymore? Especially if Google ship a use-this-Pom
> > > >> starter.
> > > >> > > > > > > > > >
> > > >> > > > > > > > > > On Thu, Oct 3, 2019 at 1:44 PM Elliotte Rusty
> > Harold <>
> > > >> > > > > > > > [hidden email]
> > > >> > > > > > > > > >
> > > >> > > > > > > > > > wrote:
> > > >> > > > > > > > > >
> > > >> > > > > > > > > > > Theoretically that would work. In practice though,
> > > >> every
> > > >> > > > > project
> > > >> > > > > > > I've
> > > >> > > > > > > > > > > seen convert to Java 8 rapidly starts adding
> > lambdas
> > > >> that
> > > >> > > > make
> > > >> > > > > > the
> > > >> > > > > > > > > > > code more obfuscated for no good reason and soon
> > > >> > introduces
> > > >> > > > > hard
> > > >> > > > > > > > > > > dependencies on Java 8, intentionally or
> > otherwise.
> > > >> At a
> > > >> > > bare
> > > >> > > > > > > > minimum,
> > > >> > > > > > > > > > > a CI environment that runs Java 7 is required.
> > > >> > > > > > > > > > >
> > > >> > > > > > > > > > > On Thu, Oct 3, 2019 at 8:25 AM Paul Hammant
> > > >> > > > > > > > wrote:
> > > >> > > > > > > > > > > >
> > > >> > > > > > > > > > > > Would jdk 8 for maven itself and a target of 7
> > for
> > > >> the
> > > >> > > > > compiler
> > > >> > > > > > > > > (etc) for
> > > >> > > > > > > > > > > > maven-using projects be ok?
> > > >> > > > > > > > > > > >
> > > >> > > > > > > > > > > > On Thu, Oct 3, 2019 at 1:15 PM Elliotte Rusty
> > > >> Harold <>
> > > >> > > > > > > > > [hidden email]
> > > >> > > > > > > > > > > >
> > > >> > > > > > > > > > > > wrote:
> > > >> > > > > > > > > > > >
> > > >> > > > > > > > > > > > > Strong -1 on Java 8 as the minimum version.
> > Google
> > > >> > > Cloud
> > > >> > > > > > > Platform
> > > >> > > > > > > > > has
> > > >> > > > > > > > > > > > > lots of products and customers that still
> > require
> > > >> > Java
> > > >> > > 7.
> > > >> > > > > If
> > > >> > > > > > > > Maven
> > > >> > > > > > > > > > > > > requires Java 8, we'd have to stick to the
> > latest
> > > >> of
> > > >> > > > > > whichever
> > > >> > > > > > > > > release
> > > >> > > > > > > > > > > > > does support Java 7 for at least a year and
> > I'm
> > > >> > > guessing
> > > >> > > > > > > longer.
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > On Sat, Sep 28, 2019 at 8:04 AM Robert
> > Scholte <>
> > > >> > > > > > > > > [hidden email]>
> > > >> > > > > > > > > > > > > wrote:
> > > >> > > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > > Hi,
> > > >> > > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > > TLDR; introduce
> > maven.experimental.buildconsumer
> > > >> > and
> > > >> > > > push
> > > >> > > > > > > Java
> > > >> > > > > > > > > > > > > requirement
> > > >> > > > > > > > > > > > > > to Java 8
> > > >> > > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > > now that Maven 3.6.2 is out for a couple of
> > > >> weeks,
> > > >> > it
> > > >> > > > > seems
> > > >> > > > > > > > like
> > > >> > > > > > > > > we
> > > >> > > > > > > > > > > > > didn't
> > > >> > > > > > > > > > > > > > face real regressions.
> > > >> > > > > > > > > > > > > > The only one might be tricky is the issue
> > > >> related
> > > >> > to
> > > >> > > > > Tycho.
> > > >> > > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > > However, I think we're ready to push Maven
> > to
> > > >> the
> > > >> > > next
> > > >> > > > > > level.
> > > >> > > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > > For those actively reading this list, they
> > > >> should
> > > >> > > > > recognize
> > > >> > > > > > > the
> > > >> > > > > > > > > need
> > > >> > > > > > > > > > > for
> > > >> > > > > > > > > > > > > > splitting up the pom as it is on the local
> > > >> system
> > > >> > > > versus
> > > >> > > > > > the
> > > >> > > > > > > > pom
> > > >> > > > > > > > > > > being
> > > >> > > > > > > > > > > > > > uploaded. Once we truly control this
> > mechanism
> > > >> we
> > > >> > can
> > > >> > > > > think
> > > >> > > > > > > of
> > > >> > > > > > > > > > > > > > improvements on model 5.0.0 and new
> > fileformats.
> > > >> > > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > > I've created and implemented MNG-6656[1]. It
> > > >> also
> > > >> > > > > contains
> > > >> > > > > > a
> > > >> > > > > > > > zip
> > > >> > > > > > > > > > > with an
> > > >> > > > > > > > > > > > > > example (original, patched, README) to
> > > >> understand
> > > >> > > > what's
> > > >> > > > > > > > > happening.
> > > >> > > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > > In order to make this successful, we need
> > IDEs
> > > >> and
> > > >> > CI
> > > >> > > > > > Servers
> > > >> > > > > > > > to
> > > >> > > > > > > > > > > > > > understand and support these changes. The
> > likely
> > > >> > need
> > > >> > > > to
> > > >> > > > > > > > > implement
> > > >> > > > > > > > > > > one of
> > > >> > > > > > > > > > > > > > the interfaces[2].
> > > >> > > > > > > > > > > > > > The new interface uses Java8 Functions (and
> > > >> > > especially
> > > >> > > > > > > > > > > SAXEventFactory is
> > > >> > > > > > > > > > > > > > way easier to read+maintain with Java 8).
> > I've
> > > >> > tried
> > > >> > > to
> > > >> > > > > > keep
> > > >> > > > > > > > > Maven
> > > >> > > > > > > > > > > Java 7
> > > >> > > > > > > > > > > > > > compatible, but that was too hard to do.
> > > >> > > > > > > > > > > > > > So I'd like to use this opportunity to move
> > > >> Maven
> > > >> > > > forward
> > > >> > > > > > and
> > > >> > > > > > > > > start
> > > >> > > > > > > > > > > > > > requiring Java 8.
> > > >> > > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > > There are some other improvements I'd like
> > to
> > > >> add
> > > >> > > > (those
> > > >> > > > > > > > messages
> > > >> > > > > > > > > > > will
> > > >> > > > > > > > > > > > > > follow), so this will imply that it will
> > take
> > > >> some
> > > >> > > time
> > > >> > > > > > > before
> > > >> > > > > > > > > we do
> > > >> > > > > > > > > > > a
> > > >> > > > > > > > > > > > > new
> > > >> > > > > > > > > > > > > > release.
> > > >> > > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > > WDTY,
> > > >> > > > > > > > > > > > > > Robert
> > > >> > > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > > [1]
> > > >> https://issues.apache.org/jira/browse/MNG-6656
> > > >> > > > > > > > > > > > > > [2]
> > > >> > > > > > > https://github.com/apache/maven/compare/MNG-6656?expand=1
> > > >> > > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > >
> > > >> > > > > > > > >
> > > >> > > > >
> > > >> ---------------------------------------------------------------------
> > > >> > > > > > > > > > > > > > To unsubscribe, e-mail:
> > > >> > > > [hidden email]
> > > >> > > > > > > > > > > > > > For additional commands, e-mail:
> > > >> > > > > [hidden email]
> > > >> > > > > > > > > > > > > >
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > --
> > > >> > > > > > > > > > > > > Elliotte Rusty Harold
> > > >> > > > > > > > > > > > > [hidden email]
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > >
> > > >> > > > >
> > > >> ---------------------------------------------------------------------
> > > >> > > > > > > > > > > > > To unsubscribe, e-mail:
> > > >> > > [hidden email]
> > > >> > > > > > > > > > > > > For additional commands, e-mail:
> > > >> > > > [hidden email]
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > > > >
> > > >> > > > > > > > > > >
> > > >> > > > > > > > > > >
> > > >> > > > > > > > > > > --
> > > >> > > > > > > > > > > Elliotte Rusty Harold
> > > >> > > > > > > > > > > [hidden email]
> > > >> > > > > > > > > > >
> > > >> > > > > > > > > > >
> > > >> > > > > > >
> > > >> > >
> > ---------------------------------------------------------------------
> > > >> > > > > > > > > > > To unsubscribe, e-mail:
> > > >> [hidden email]
> > > >> > > > > > > > > > > For additional commands, e-mail:
> > > >> > [hidden email]
> > > >> > > > > > > > > > >
> > > >> > > > > > > > > > >
> > > >> > > > > > > > > >
> > > >> > > > > > > > >
> > > >> > > > > > > > >
> > > >> > > > >
> > > >> ---------------------------------------------------------------------
> > > >> > > > > > > > > To unsubscribe, e-mail:
> > [hidden email]
> > > >> > > > > > > > > For additional commands, e-mail:
> > > >> [hidden email]
> > > >> > > > > > > > >
> > > >> > > > > > > > >
> > > >> > > > > > > >
> > > >> > > > > > >
> > > >> > > > > > >
> > > >> > > > > > > --
> > > >> > > > > > > Olivier Lamy
> > > >> > > > > > > http://twitter.com/olamy | http://linkedin.com/in/olamy
> > > >> > > > > > >
> > > >> > > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]