Re: [DISCUSS] Maven 3.7.0

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

Re: [DISCUSS] Maven 3.7.0

Romain Manni-Bucau
Le jeu. 3 oct. 2019 à 20:22, Tibor Digana <[hidden email]> a écrit :

> 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???)
>

There is also a not technical view, any previous jdk is not maintained so
its support is no more needed since we are far from any acceptable
migration for projects which would migrate.



> Write notices for developers on the internal Wiki:
> + toolchains
> + limitations and solutions for disadvantages
> + conditions when and how to migrate from J7 to J8
>


Or the most common option: stick to current mvn version.

We can still get fixes releases on need backporting small fixes. It is how
asf works after all.

I wouldnt bother users with toolchain, it is only needed for libs and the
active ones almost all migrated 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]
> > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Maven 3.7.0

rfscholte
In reply to this post by Tibor Digana
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.

I started the thread with one other question: do we need a 3.6.3  
regression release?
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: [DISCUSS] Maven 3.7.0

michaelo
In reply to this post by Gary Gregory-2
Am 2019-09-28 um 14:05 schrieb Robert Scholte:

> 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

Regardless of how good this sounds/is, we have quite other substantional
issues to solve first this year, this is not a real world problem which
needs to be solved instantly:

1. I would expect a formal vote for the bump and the justification for it.
2. Fix behavior changes for 3.7.0, update plugins (infrastructure if you
like)
3. Really really clean up JIRA. We have *1864* unresolved issues! It
*cannot* go on like that forever. I've been working hard this year to
push a lot of components like SCM, Wagon, etc. Even in 3.6.2 I have
addressed 25 issues.

Personally, I don't have any motivation nor the mental/physical fitness
and especially time to make any substantial contributions except leaving
comments on JIRA issues or reviewing a PR at most for the next three to
six months. I also won't participate in any further in-depth discussion
for 3.7.0 for the reasons I have mentioned previously. I just don't see
it fruitful.
The technical debt we have is huge and we are not able to handle it.

This is not intended to diminish your work anyhow, but to express our
current situation from my personal view.

Michael

---------------------------------------------------------------------
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

Aleksandar Kurtakov
On Fri, Oct 4, 2019 at 2:22 PM Stephen Connolly <
[hidden email]> wrote:

> On Fri, 4 Oct 2019 at 12:03, Michael Osipov <[hidden email]> wrote:
>
> > Am 2019-09-28 um 14:05 schrieb Robert Scholte:
> > > 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
> >
> > Regardless of how good this sounds/is, we have quite other substantional
> > issues to solve first this year, this is not a real world problem which
> > needs to be solved instantly:
> >
> > 1. I would expect a formal vote for the bump and the justification for
> it.
> > 2. Fix behavior changes for 3.7.0, update plugins (infrastructure if you
> > like)
> > 3. Really really clean up JIRA. We have *1864* unresolved issues! It
> > *cannot* go on like that forever. I've been working hard this year to
> > push a lot of components like SCM, Wagon, etc. Even in 3.6.2 I have
> > addressed 25 issues.
> >
> > Personally, I don't have any motivation nor the mental/physical fitness
> > and especially time to make any substantial contributions except leaving
> > comments on JIRA issues or reviewing a PR at most for the next three to
> > six months.
>
>
> I would love to have the energy to work on Maven in the short term... I put
> a lot of energy into the PDT proposal, but finding a way to move on that in
> the current code base is tricky, hence why I haven't even started!
>
>
> > I also won't participate in any further in-depth discussion
> > for 3.7.0 for the reasons I have mentioned previously. I just don't see
> > it fruitful.
> > The technical debt we have is huge and we are not able to handle it.
> >
>
> There is a chicken and egg situation though. A lot of the technical debt we
> have is fall-out from being unable to evolve the pom. We cannot evolve the
> pom without being able to split the build vs consumer pom, thus we keep
> leaking the technical debt.
>
> And potential contributors will keep getting pushed away until we provide a
> pom evolution path.
>
> We need more contributors, but to get them we need a way to help them
> scratch their itches.
>
> 3.4.0 was the result of a new contributor trying to make progress... but
> because we didn't have a clear path to solve evolution we ended up burning
> that individual as a contributor.
>
> We need an evolution path.
>

Just Maven user here but involved in a number of other FOSS projects. We
are seeing significant improvement in number of new contributors and their
longevity since relaxing a bit the rules to not be all about supporting
ancient versions of everything. And a project is its contributors - not
managing to attract new guys and old guys getting tired is probably hardest
one to solve.


>
>
> > This is not intended to diminish your work anyhow, but to express our
> > current situation from my personal view.
> >
> > Michael
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>


--
Alexander Kurtakov
Red Hat Eclipse Team
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Maven 3.7.0

Alexander Ashitkin
In reply to this post by Paul Hammant
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 <[hidden email]> 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 <[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]
> > > > >
> > > >
> > > >
> > > > --
> > > > 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]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Maven 3.7.0

Tibor Digana
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 <[hidden email]> 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 <[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]
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > 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]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Maven 3.7.0

Romain Manni-Bucau
+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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[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]
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > 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

Romain Manni-Bucau
@Tibor: the design comes from a time functional programming was not
mainstream and quite cumbersome with java, let's embrace current way of
doing and move forward otherwise we can go to attic ;).

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 mar. 29 oct. 2019 à 09:02, Tibor Digana <[hidden email]> a
écrit :

> 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!
>
> 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
In reply to this post by Romain Manni-Bucau
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

Tibor Digana
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

Tibor Digana
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.

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: [DISCUSS] Maven 3.7.0

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

> 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: [DISCUSS] Maven 3.7.0

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

> 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)
>

https://lists.apache.org/thread.html/41a693d0e5787fa8af33ab0724a95c3ed0374fe2d860c2357a5565a9@1392995450@%3Cdev.maven.apache.org%3E


>
>> > 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: [DISCUSS] Maven 3.7.0

stephenconnolly
In reply to this post by stephenconnolly
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]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Re: [DISCUSS] Maven 3.7.0

Enrico Olivelli
Il giorno mar 29 ott 2019 alle ore 14:22 Stephen Connolly <
[hidden email]> ha scritto:

> 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.
>

totally true !

We should only move to "target/source" 8, we do not need to change the code
(lamdas), we can do it whenever we want

Enrico



>
> 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]
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Re: [DISCUSS] Maven 3.7.0

Romain Manni-Bucau
Le mar. 29 oct. 2019 à 14:24, Enrico Olivelli <[hidden email]> a
écrit :

> Il giorno mar 29 ott 2019 alle ore 14:22 Stephen Connolly <
> [hidden email]> ha scritto:
>
> > 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.
> >
>
> totally true !
>
> We should only move to "target/source" 8, we do not need to change the code
> (lamdas), we can do it whenever we want
>


+1

If it helps these figures tend to encourage to make java 8 the mainstream
for maven as well:
1. https://snyk.io/blog/jvm-ecosystem-report-2018/
2. https://www.infoq.com/articles/java-jvm-trends-2019/
3. https://www.jetbrains.com/lp/devecosystem-2019/java/


>
> Enrico
>
>
>
> >
> > 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]
> > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Re: [DISCUSS] Maven 3.7.0

rfscholte
In reply to this post by stephenconnolly
One of the fundamental features of Maven is Convention Over Configuration, in other words: define defaults where possible, but make it possible to change these values.
However, "default" can be explained differently, either as constant (forever) or as a predefined value within a certain context.

A lot of projects don't lock their plugins and up until Maven 2.0.9 the LATEST version was used. This could mean that with any new plugin release builds could break without any changes in their own codebase. Because of that Maven started defining default versions for the most common plugins.
These defaults have been the same for a long time to prevent situations as before Maven 2.0.9
Upgrading plugin defaults in Maven will break builds, because project actually rely on these defaults, intended or not.

We should have a good answer when things do break. Some options:
- figure out the problematic plugins and lock their version
- stay on Maven 3.6.3 to have the combinations of plugin versions that do work together.

Assuming most developers only have 1 version of Maven on their machine, both these answer aren't nice. And even with multiple Maven versions, switching between them isn't that nice.
There is one other solution that will help in this case: make sure the project is being build with Maven version X.
Such solution already exists, but most users are not aware of it and expect it to be part of Maven itself (as with Gradle): it is called the Maven Wrapper.
I'm already negotiating about the codebase and IP, hopefully we'll have positive results soon.

To me the upgrades of plugin defaults must be combined with the introduction of the Maven Wrapper as part of Maven core to have the least amount of issues.

Robert 
On 29-10-2019 14:00:49, 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"
> An: "Maven Developers List"
> 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 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
> >> 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
> >> > > 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]

Reply | Threaded
Open this post in threaded view
|

Re: Re: [DISCUSS] Maven 3.7.0

Romain Manni-Bucau
Sdkman is also a good option (and avoids binaries in sources)

That said, cant plugin check out they work?
It does not sound hard to check java version/parameters/... and validate
that when creating a mojo, isnt it?


Le mar. 29 oct. 2019 à 19:46, Robert Scholte <[hidden email]> a
écrit :

> One of the fundamental features of Maven is Convention Over Configuration,
> in other words: define defaults where possible, but make it possible to
> change these values.
> However, "default" can be explained differently, either as constant
> (forever) or as a predefined value within a certain context.
>
> A lot of projects don't lock their plugins and up until Maven 2.0.9 the
> LATEST version was used. This could mean that with any new plugin release
> builds could break without any changes in their own codebase. Because of
> that Maven started defining default versions for the most common plugins.
> These defaults have been the same for a long time to prevent situations as
> before Maven 2.0.9
> Upgrading plugin defaults in Maven will break builds, because project
> actually rely on these defaults, intended or not.
>
> We should have a good answer when things do break. Some options:
> - figure out the problematic plugins and lock their version
> - stay on Maven 3.6.3 to have the combinations of plugin versions that do
> work together.
>
> Assuming most developers only have 1 version of Maven on their machine,
> both these answer aren't nice. And even with multiple Maven versions,
> switching between them isn't that nice.
> There is one other solution that will help in this case: make sure the
> project is being build with Maven version X.
> Such solution already exists, but most users are not aware of it and
> expect it to be part of Maven itself (as with Gradle): it is called the
> Maven Wrapper.
> I'm already negotiating about the codebase and IP, hopefully we'll have
> positive results soon.
>
> To me the upgrades of plugin defaults must be combined with the
> introduction of the Maven Wrapper as part of Maven core to have the least
> amount of issues.
>
> Robert
> On 29-10-2019 14:00:49, 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"
> > An: "Maven Developers List"
> > 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 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
> > >> 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
> > >> > > 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]
>
>
12