Re: [DISCUSS] Maven 3.7.0

classic Classic list List threaded Threaded
26 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

Michael Osipov-2
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]
>
>
12