Re: [DISCUSS] Maven 3.7.0

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

Re: [DISCUSS] Maven 3.7.0

Tibor Digana
Hello guys,

For the user community these two issues are important:
https://issues.apache.org/jira/browse/MNG-6169
https://issues.apache.org/jira/browse/MNG-6548
The Tycho project is the user as well.
The J8 is internal code improvement/change => lower priority than the
user's priority => release order/priorities/dedicated time spent in
development.

Have a nice day.

Cheers
Tibor17

On Sat, Sep 28, 2019 at 2:08 PM Gary Gregory <[hidden email]> wrote:

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

Re: [DISCUSS] Maven 3.7.0

Olivier Lamy
+1 for Java 8
it's time now and we will probably having more contributions as young/cool
kids prefer using modern tools
Yup the world is not only made with Old Grumpy grand dad working only with
Java 5 :P )

On Tue, 1 Oct 2019 at 04:14, Robert Scholte <[hidden email]> wrote:

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

--
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Maven 3.7.0

stephenconnolly
+1 on Java 8 requirement for Maven runtime (note this still lets you
compile with Java 7 if you are prepared to use toolchains... the complexity
of using toolchains is an argument for improving/revisiting toolchains)

+1 on getting the place for filtering the pom.xml to produce the consumer
pom.xml, but I would go one step further. Enable it by default, but allow
opt-out. Also I would suggest to pick up a feature-flagging technique to
allow a project to opt out just by declaring the `maven.experimental.___`
property in the `pom.xml`. We should be clear that such flags will stop
working once the feature is confirmed solid, but NOBODY will turn the
experimental flag on, especially if it is a system property only flag...
and if we do not have confidence that the feature will work with both the
shade plugin and the gpg plugin then - quite frankly - the feature is not
ready

On Tue, 1 Oct 2019 at 18:31, Robert Scholte <[hidden email]> wrote:

> https://github.com/apache/maven/pull/286
>
> On Tue, 01 Oct 2019 13:49:25 +0200, Enrico Olivelli <[hidden email]>
>
> wrote:
>
> > Robert,
> > Can you create a PR?
> >
> > Enrico
> >
> > Il mar 1 ott 2019, 07:19 Sylwester Lachiewicz <[hidden email]> ha
> > scritto:
> >
> >> +1 for Java 8 - let's kill 7 faster ;-))
> >>
> >> Sylwester
> >>
> >> wt., 1 paź 2019, 02:41 użytkownik Olivier Lamy <[hidden email]>
> >> napisał:
> >>
> >> > +1 for Java 8
> >> > it's time now and we will probably having more contributions as
> >> young/cool
> >> > kids prefer using modern tools
> >> > Yup the world is not only made with Old Grumpy grand dad working only
> >> with
> >> > Java 5 :P )
> >> >
> >> > On Tue, 1 Oct 2019 at 04:14, Robert Scholte <[hidden email]>
> >> wrote:
> >> >
> >> > > The versions upgrades of plugins are part of another topic, which
> >> are
> >> > > indeed 3.7.0 candidates.
> >> > >
> >> > > As said, the Java 8 update is not just about internal code
> >> improvements
> >> > > or
> >> > > changes. Maven will expose new APIs/SPIs that contain Java 8
> >> Functions,
> >> > > so
> >> > > it must be seen as a requirement to implement the experimental
> >> > > buildconsumer feature.
> >> > >
> >> > > Robert
> >> > >
> >> > > On Sat, 28 Sep 2019 14:23:16 +0200, Tibor Digana <
> >> [hidden email]
> >> > >
> >> > >
> >> > > wrote:
> >> > >
> >> > > > Hello guys,
> >> > > >
> >> > > > For the user community these two issues are important:
> >> > > > https://issues.apache.org/jira/browse/MNG-6169
> >> > > > https://issues.apache.org/jira/browse/MNG-6548
> >> > > > The Tycho project is the user as well.
> >> > > > The J8 is internal code improvement/change => lower priority
> than
> >> the
> >> > > > user's priority => release order/priorities/dedicated time spent
> >> in
> >> > > > development.
> >> > > >
> >> > > > Have a nice day.
> >> > > >
> >> > > > Cheers
> >> > > > Tibor17
> >> > > >
> >> > > > On Sat, Sep 28, 2019 at 2:08 PM Gary Gregory
> >> <[hidden email]
> >> >
> >> > > > wrote:
> >> > > >
> >> > > >> I would say that fixing the Tycho issue comes first.
> >> > > >>
> >> > > >> Gary
> >> > > >>
> >> > > >> On Sat, Sep 28, 2019 at 8:04 AM Robert Scholte <
> >> [hidden email]>
> >> > > >> wrote:
> >> > > >>
> >> > > >> > Hi,
> >> > > >> >
> >> > > >> > TLDR; introduce maven.experimental.buildconsumer and push Java
> >> > > >> > requirement
> >> > > >> > to Java 8
> >> > > >> >
> >> > > >> > now that Maven 3.6.2 is out for a couple of weeks, it seems
> >> like
> >> we
> >> > > >> > didn't
> >> > > >> > face real regressions.
> >> > > >> > The only one might be tricky is the issue related to Tycho.
> >> > > >> >
> >> > > >> > However, I think we're ready to push Maven to the next level.
> >> > > >> >
> >> > > >> > For those actively reading this list, they should recognize the
> >> need
> >> > > >> for
> >> > > >> > splitting up the pom as it is on the local system versus the
> >> pom
> >> > being
> >> > > >> > uploaded. Once we truly control this mechanism we can think of
> >> > > >> > improvements on model 5.0.0 and new fileformats.
> >> > > >> >
> >> > > >> > I've created and implemented MNG-6656[1]. It also contains a
> >> zip
> >> > > with
> >> > > >> an
> >> > > >> > example (original, patched, README) to understand what's
> >> happening.
> >> > > >> >
> >> > > >> > In order to make this successful, we need IDEs and CI Servers
> >> to
> >> > > >> > understand and support these changes. The likely need to
> >> implement
> >> > > >> one of
> >> > > >> > the interfaces[2].
> >> > > >> > The new interface uses Java8 Functions (and especially
> >> > > >> SAXEventFactory is
> >> > > >> > way easier to read+maintain with Java 8). I've tried to keep
> >> Maven
> >> > > >> Java 7
> >> > > >> > compatible, but that was too hard to do.
> >> > > >> > So I'd like to use this opportunity to move Maven forward and
> >> start
> >> > > >> > requiring Java 8.
> >> > > >> >
> >> > > >> > There are some other improvements I'd like to add (those
> >> messages
> >> > will
> >> > > >> > follow), so this will imply that it will take some time
> before
> >> we
> >> > do a
> >> > > >> > new
> >> > > >> > release.
> >> > > >> >
> >> > > >> > WDTY,
> >> > > >> > Robert
> >> > > >> >
> >> > > >> > [1] https://issues.apache.org/jira/browse/MNG-6656
> >> > > >> > [2] https://github.com/apache/maven/compare/MNG-6656?expand=1
> >> > > >> >
> >> > > >> >
> >> > ---------------------------------------------------------------------
> >> > > >> > To unsubscribe, e-mail: [hidden email]
> >> > > >> > For additional commands, e-mail: [hidden email]
> >> > > >> >
> >> > > >> >
> >> > >
> >> > >
> >> ---------------------------------------------------------------------
> >> > > To unsubscribe, e-mail: [hidden email]
> >> > > For additional commands, e-mail: [hidden email]
> >> > >
> >> > >
> >> >
> >> > --
> >> > Olivier Lamy
> >> > http://twitter.com/olamy | http://linkedin.com/in/olamy
> >> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Maven 3.7.0

Elliotte Rusty Harold
In reply to this post by Tibor Digana
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]

Reply | Threaded
Open this post in threaded view
|

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

Re: [DISCUSS] Maven 3.7.0

Karl Heinz Marbaise-3
In reply to this post by Elliotte Rusty Harold
On 03.10.19 14:15, Elliotte Rusty Harold wrote:
> Strong -1 on Java 8 as the minimum version. Google Cloud Platform has
> lots of products and customers that still require Java 7. If Maven
> requires Java 8, we'd have to stick to the latest of whichever release
> does support Java 7 for at least a year and I'm guessing longer.

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

Furthermore Java 8 is out for five years (2014) so to be honest I
wouldn't trust an environment which is not upgrading etc. in particular
in a clould environment...

Why hadn't started Google to update their environment over the time to
JDK 8 etc. (I think they have much more resources than anyone).


One more thing is:
  There is a difference between running Maven to build for example
  with JDK 8 and running your resulting artifacts (see toolchain comment
  from Stephen Connolly..

Kind regards
Karl Heinz Marbaise


[1]: https://www.oracle.com/technetwork/java/java-se-support-roadmap.html


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

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

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Maven 3.7.0

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 <[hidden email]> wrote:

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

Re: [DISCUSS] Maven 3.7.0

Romain Manni-Bucau
In reply to this post by Karl Heinz Marbaise-3
Le jeu. 3 oct. 2019 à 21:23, Tibor Digana <[hidden email]> 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 <[hidden email]>
> wrote:
>
> > 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

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


> 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

stephenconnolly
On Fri, 4 Oct 2019 at 12:39, Aleksandar Kurtakov <[hidden email]>
wrote:

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

There is also the marketing effect of requiring to support old versions.

When you say "oh must work on _insert_really_old_thing_" you are really
saying "we are not modern".

The paradox is that people want to work on modern stuff... but they really
want rock solid stable from the stuff they rely on.

So as a project, Maven needs to try and maintain our reputation for rock
solid stable... but we cannot do that if there is nobody to work on the
project... and getting people to work on the project requires an element of
"we are modern"

Now for a build tool, I think Java 11 is "too modern" right now... but Java
8 is around a long time now... I personally think it has been time to move
for a while now... but we have been lacking the reason (i.e. "lets switch
everything to lambdas is not a good reason") We now have a reason in the
XML APIs that Robert's changes require... thus we move to Java 8 IMHO
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Maven 3.7.0

Alexander Ashitkin
In reply to this post by Tibor Digana
Totally support java 8. There is nothing to discuss here. Not sure everyone realizes that, but it's 2019 already.

Regarding the new features:
1) as you mentioned the new model, i think it will be good to introduce simple build graph balancing hints in the model. It is possible to examine critical path of the build, but not much you can do about that. Maven by itself has no knowledge of critical path and as developer i have no any tools to apply this knowledge. Though theoretically simple priority attribute at project level could help scheduler to work on a critical path first.
2) i like idea of grade api/implementation dependencies model in terms of java modules system compatibility. So you expose api and hide implementation. It feels like new packaging for jigsaw modules are very welcome.
3) i feel like model have to be reworked to immutable form, so concurrent code is easier to write. Current modello objects look unsafe in concurrent code. Though correct implementation is possible of course, but it takes a lot of efforts to examine correctness. Makes sense to rework current model to builders + immutable thread safe domain objects
4) From cache implementation perspective - i'd like to have metadata support on plugin parameters and project properties. That simplifies understanding of plugins behavior.

Thank you
Aleks

On 2019/09/28 12:05:34, "Robert Scholte" <[hidden email]> wrote:

> Hi,
>
> TLDR; introduce maven.experimental.buildconsumer and push Java requirement  
> to Java 8
>
> now that Maven 3.6.2 is out for a couple of weeks, it seems like we didn't  
> face real regressions.
> The only one might be tricky is the issue related to Tycho.
>
> However, I think we're ready to push Maven to the next level.
>
> For those actively reading this list, they should recognize the need for  
> splitting up the pom as it is on the local system versus the pom being  
> uploaded. Once we truly control this mechanism we can think of  
> improvements on model 5.0.0 and new fileformats.
>
> I've created and implemented MNG-6656[1]. It also contains a zip with an  
> example (original, patched, README) to understand what's happening.
>
> In order to make this successful, we need IDEs and CI Servers to  
> understand and support these changes. The likely need to implement one of  
> the interfaces[2].
> The new interface uses Java8 Functions (and especially SAXEventFactory is  
> way easier to read+maintain with Java 8). I've tried to keep Maven Java 7  
> compatible, but that was too hard to do.
> So I'd like to use this opportunity to move Maven forward and start  
> requiring Java 8.
>
> There are some other improvements I'd like to add (those messages will  
> follow), so this will imply that it will take some time before we do a new  
> release.
>
> WDTY,
> Robert
>
> [1] https://issues.apache.org/jira/browse/MNG-6656
> [2] https://github.com/apache/maven/compare/MNG-6656?expand=1
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

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