Re: [DISCUSS] Maven 3.7.0

[Romain Manni-Bucau]

Le jeu. 3 oct. 2019 à 21:23, Tibor Digana  a écrit :

> >> any previous jdk is not maintained
>
> Romain I was not talking about yes/no J8.
> I was talking about J8 sources.
> Not about dead J7 and Oracle support of J7.
>
> Not sure if the Maven devs would be able to use J8. Important is "how".
> Therefore the Wiki should help them "how".
>

We can make it simple and not force it but do it when we hit a need or so.
Batch migration dont bring anything and require a lot of validation to
ensure there is no perf regression or binary incompatibility (thanks
concurrenthashmap ;)).



>
> >> We can still get fixes releases on need backporting small fixes.
>
> Not for sure. You was not in the Maven when we said that we wouldnt
> backport to the old 3.x versions because it went with high cost and we do
> not have enough human resources.
>

I was not there but it is also fine, *we* dont need to do it.
My guess is that it will not happen - it works today - and worse case Im
sure we would be able to review a PR and do a release (if not we must fix
that urgently cause it is the basis of any community) - so I dont worry at
all of that.
Not proactive but supporting works for backports.


>
> On Thu, Oct 3, 2019 at 9:08 PM Romain Manni-Bucau 
> wrote:
>
> > Le jeu. 3 oct. 2019 à 20:22, Tibor Digana  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 <
> > > stephen.alan.conno...@gmail.com> wrote:
> > >
> > > > On Thu, 3 Oct 2019 at 16:49, Karl Heinz Marbaise 
> > > > 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 

Re: [DISCUSS] Maven 3.7.0

[Tibor Digana]

>> any previous jdk is not maintained

Romain I was not talking about yes/no J8.
I was talking about J8 sources.
Not about dead J7 and Oracle support of J7.

Not sure if the Maven devs would be able to use J8. Important is "how".
Therefore the Wiki should help them "how".


>> We can still get fixes releases on need backporting small fixes.

Not for sure. You was not in the Maven when we said that we wouldnt
backport to the old 3.x versions because it went with high cost and we do
not have enough human resources.


On Thu, Oct 3, 2019 at 9:08 PM Romain Manni-Bucau 
wrote:

> Le jeu. 3 oct. 2019 à 20:22, Tibor Digana  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 <
> > stephen.alan.conno...@gmail.com> wrote:
> >
> > > On Thu, 3 Oct 2019 at 16:49, Karl Heinz Marbaise 
> > > 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 <
> > khmarba...@gmx.de
> > > > > > 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
> 

Re: [DISCUSS] Maven 3.7.0

[Romain Manni-Bucau]

Le jeu. 3 oct. 2019 à 20:22, Tibor Digana  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 <
> stephen.alan.conno...@gmail.com> wrote:
>
> > On Thu, 3 Oct 2019 at 16:49, Karl Heinz Marbaise 
> > 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 <
> khmarba...@gmx.de
> > > > > 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..
> > 

Re: [DISCUSS] Maven 3.7.0

[Tibor Digana]

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 <
stephen.alan.conno...@gmail.com> wrote:

> On Thu, 3 Oct 2019 at 16:49, Karl Heinz Marbaise 
> 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  > > > 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
> > > mailto:rfscho...@apache.org>> 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 

Re: [DISCUSS] Maven 3.7.0

[Stephen Connolly]

On Thu, 3 Oct 2019 at 16:49, Karl Heinz Marbaise  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  > > 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
> > mailto:rfscho...@apache.org>> 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
> >  

Re: [DISCUSS] Maven 3.7.0

[Karl Heinz Marbaise]

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

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 mailto:khmarba...@gmx.de>> 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
mailto:rfscho...@apache.org>> 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: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Maven 3.7.0

[Emmanuel Bourg]

Le 03/10/2019 à 16:54, Karl Heinz Marbaise a écrit :

> Hm.. first Java 7 is out for eight years now (2011) (End of live) and
> has no public updates for security/bug fixes etc. since 2015

RedHat still maintains OpenJDK 7 until June 2020 [1].

Emmanuel Bourg

[1] 
https://access.redhat.com/articles/1299013#OpenJDK_Lifecycle_Dates_and_RHEL_versions

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

Re: [DISCUSS] Maven 3.7.0

[Gary Gregory]

Java 8 as a min is fine by me FWIW.

Gary

On Thu, Oct 3, 2019 at 11:07 AM Tibor Digana  wrote:

> Sorry my important typo " I would have a problem with Java 1.8 ".
> Correction " I would NOT have a problem with Java 1.8 "
>
> On Thu, Oct 3, 2019 at 5:03 PM Tibor Digana 
> wrote:
>
> > This is not very serious discussion since we saw users on our mailing
> list
> > who said that he is using Java 1.6 compiler and JDK7 in Maven.
> > Serious discussion would uncover pros/cons and impact analysis.
> >
> > I would have a problem with Java 1.8 in target and source code but I have
> > problem that we excluded our users from the VOTE.
> > Regarding Java 1.7 we clearly uncovered the migration plan, versions of
> > plugins, core etc. Here nothing like that exists - only that somebody
> > created a Jira ticket.
> >
> > Technically I would be interested if somebody could explain what NEW
> > Security API is in Java 1.8 and performance impact of Streams API. That's
> > the impact in the source code.
> > Somebody has other questions too.
> > Then we can write Wiki as well as rules, conditions and plan.
> >
> > Cheers
> > Tibor17
> >
> > On Thu, Oct 3, 2019 at 4:55 PM Karl Heinz Marbaise 
> > 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 
> >> 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: dev-unsubscr...@maven.apache.org
> >> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >>
>

Re: [DISCUSS] Maven 3.7.0

[Tibor Digana]

Sorry my important typo " I would have a problem with Java 1.8 ".
Correction " I would NOT have a problem with Java 1.8 "

On Thu, Oct 3, 2019 at 5:03 PM Tibor Digana  wrote:

> This is not very serious discussion since we saw users on our mailing list
> who said that he is using Java 1.6 compiler and JDK7 in Maven.
> Serious discussion would uncover pros/cons and impact analysis.
>
> I would have a problem with Java 1.8 in target and source code but I have
> problem that we excluded our users from the VOTE.
> Regarding Java 1.7 we clearly uncovered the migration plan, versions of
> plugins, core etc. Here nothing like that exists - only that somebody
> created a Jira ticket.
>
> Technically I would be interested if somebody could explain what NEW
> Security API is in Java 1.8 and performance impact of Streams API. That's
> the impact in the source code.
> Somebody has other questions too.
> Then we can write Wiki as well as rules, conditions and plan.
>
> Cheers
> Tibor17
>
> On Thu, Oct 3, 2019 at 4:55 PM Karl Heinz Marbaise 
> 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 
>> 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: dev-unsubscr...@maven.apache.org
>> >> For additional commands, e-mail: dev-h...@maven.apache.org
>> >>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>

Re: Proposal: maven release lifecycle

[Karl Heinz Marbaise]

Hi,

first thanks...

I have several question regarding your blog post ...

Apart from beeing not accurate in some part I miss one very important thing:

What is the real problem when doing a release via release plugin etc.
which works well (I haven't said that it could be improved)...

I want to know what the pain points are ?


Kind regards
Karl Heinz Marbaise


On 03.10.19 15:38, Marco Schulz wrote:

Hello Maven Dev & Community

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

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

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




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

Re: [DISCUSS] Maven 3.7.0

[Tibor Digana]

This is not very serious discussion since we saw users on our mailing list
who said that he is using Java 1.6 compiler and JDK7 in Maven.
Serious discussion would uncover pros/cons and impact analysis.

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

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

Cheers
Tibor17

On Thu, Oct 3, 2019 at 4:55 PM Karl Heinz Marbaise 
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 
> 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: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [DISCUSS] Maven 3.7.0

[Karl Heinz Marbaise]

Hi,

On 03.10.19 14:36, Elliotte Rusty Harold wrote:

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


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

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

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


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


Kind regards
Karl Heinz Marbaise



On Thu, Oct 3, 2019 at 8:25 AM Paul Hammant  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 
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 
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: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



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

Re: [DISCUSS] Maven 3.7.0

[Karl Heinz Marbaise]

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  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: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



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

Re: [DISCUSS] Maven 3.7.0

[Paul Hammant]

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 
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  >
> > 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 
> > > 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: dev-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > >
> > >
> > >
> > > --
> > > Elliotte Rusty Harold
> > > elh...@ibiblio.org
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
>
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [DISCUSS] Maven 3.7.0

[Elliotte Rusty Harold]

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 
> 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 
> > 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: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> >
> >
> > --
> > Elliotte Rusty Harold
> > elh...@ibiblio.org
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >



-- 
Elliotte Rusty Harold
elh...@ibiblio.org

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

Re: [DISCUSS] Maven 3.7.0

[Paul Hammant]

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 
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 
> 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: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [DISCUSS] Maven 3.7.0

[Elliotte Rusty Harold]

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  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: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>


-- 
Elliotte Rusty Harold
elh...@ibiblio.org

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