[DISCUSS] Maven 3.7.0

[Robert Scholte <rf...@apache.org>]

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

Re: [DISCUSS] Maven 3.7.0

[Stephen Connolly <st...@gmail.com>]

On Fri, 4 Oct 2019 at 12:39, Aleksandar Kurtakov <ak...@redhat.com>
wrote:

> On Fri, Oct 4, 2019 at 2:22 PM Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> > On Fri, 4 Oct 2019 at 12:03, Michael Osipov <mi...@apache.org> 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

Re: [DISCUSS] Maven 3.7.0

[Aleksandar Kurtakov <ak...@redhat.com>]

On Fri, Oct 4, 2019 at 2:22 PM Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

> On Fri, 4 Oct 2019 at 12:03, Michael Osipov <mi...@apache.org> wrote:
>
> > Am 2019-09-28 um 14:05 schrieb Robert Scholte:
> > > Hi,
> > >
> > > TLDR; introduce maven.experimental.buildconsumer and push Java
> > > requirement to Java 8
> > >
> > > now that Maven 3.6.2 is out for a couple of weeks, it seems like we
> > > didn't face real regressions.
> > > The only one might be tricky is the issue related to Tycho.
> > >
> > > However, I think we're ready to push Maven to the next level.
> > >
> > > For those actively reading this list, they should recognize the need
> for
> > > splitting up the pom as it is on the local system versus the pom being
> > > uploaded. Once we truly control this mechanism we can think of
> > > improvements on model 5.0.0 and new fileformats.
> > >
> > > I've created and implemented MNG-6656[1]. It also contains a zip with
> an
> > > example (original, patched, README) to understand what's happening.
> > >
> > > In order to make this successful, we need IDEs and CI Servers to
> > > understand and support these changes. The likely need to implement one
> > > of the interfaces[2].
> > > The new interface uses Java8 Functions (and especially SAXEventFactory
> > > is way easier to read+maintain with Java 8). I've tried to keep Maven
> > > Java 7 compatible, but that was too hard to do.
> > > So I'd like to use this opportunity to move Maven forward and start
> > > requiring Java 8.
> > >
> > > There are some other improvements I'd like to add (those messages will
> > > follow), so this will imply that it will take some time before we do a
> > > new release.
> > >
> > > WDTY,
> > > Robert
> > >
> > > [1] https://issues.apache.org/jira/browse/MNG-6656
> > > [2] https://github.com/apache/maven/compare/MNG-6656?expand=1
> >
> > Regardless of how good this sounds/is, we have quite other substantional
> > issues to solve first this year, this is not a real world problem which
> > needs to be solved instantly:
> >
> > 1. I would expect a formal vote for the bump and the justification for
> it.
> > 2. Fix behavior changes for 3.7.0, update plugins (infrastructure if you
> > like)
> > 3. Really really clean up JIRA. We have *1864* unresolved issues! It
> > *cannot* go on like that forever. I've been working hard this year to
> > push a lot of components like SCM, Wagon, etc. Even in 3.6.2 I have
> > addressed 25 issues.
> >
> > Personally, I don't have any motivation nor the mental/physical fitness
> > and especially time to make any substantial contributions except leaving
> > comments on JIRA issues or reviewing a PR at most for the next three to
> > six months.
>
>
> I would love to have the energy to work on Maven in the short term... I put
> a lot of energy into the PDT proposal, but finding a way to move on that in
> the current code base is tricky, hence why I haven't even started!
>
>
> > I also won't participate in any further in-depth discussion
> > for 3.7.0 for the reasons I have mentioned previously. I just don't see
> > it fruitful.
> > The technical debt we have is huge and we are not able to handle it.
> >
>
> There is a chicken and egg situation though. A lot of the technical debt we
> have is fall-out from being unable to evolve the pom. We cannot evolve the
> pom without being able to split the build vs consumer pom, thus we keep
> leaking the technical debt.
>
> And potential contributors will keep getting pushed away until we provide a
> pom evolution path.
>
> We need more contributors, but to get them we need a way to help them
> scratch their itches.
>
> 3.4.0 was the result of a new contributor trying to make progress... but
> because we didn't have a clear path to solve evolution we ended up burning
> that individual as a contributor.
>
> We need an evolution path.
>

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


>
>
> > This is not intended to diminish your work anyhow, but to express our
> > current situation from my personal view.
> >
> > Michael
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>


-- 
Alexander Kurtakov
Red Hat Eclipse Team

Re: [DISCUSS] Maven 3.7.0

[Stephen Connolly <st...@gmail.com>]

On Fri, 4 Oct 2019 at 12:03, Michael Osipov <mi...@apache.org> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: [DISCUSS] Maven 3.7.0

[Michael Osipov <mi...@apache.org>]

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

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

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

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

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

Michael

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

Re: [DISCUSS] Maven 3.7.0

[Karl Heinz Marbaise <kh...@gmx.de>]

Hi Mickael,

On 28.09.19 17:37, Mickael Istria wrote:
> On Sat, Sep 28, 2019 at 5:35 PM Karl Heinz Marbaise <kh...@gmx.de>
> wrote:
>
>>
>>> now that Maven 3.6.2 is out for a couple of weeks, it seems like we
>>> didn't face real regressions.
>>> The only one might be tricky is the issue related to Tycho.
>>
>> Feedback of Michael Istria states different? Or do I miss a thing?
>
>
> I think we should trust the various users who face this issue, and assume
> the issue exist until proven otherwise.
> This is likely a bug in Tycho and/or Polyglot Maven, and I believe this
> reveals that some of the important Tycho tests are not performed against
> latest Maven snapshots. I've started a thread on the tycho-dev@eclipse.org
> mailing-list on htis topic.

Ah Ok...now I understand your post on tycho-dev list..

Thanks that explains it...

Of course we should wait for the feedback..

Kind regards
Karl Heinz Marbaise

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

Re: [DISCUSS] Maven 3.7.0

[John Patrick <nh...@gmail.com>]

Been using Maven since spring 2005, so really happy with Maven...

I work on legacy applications so I still build on Java 6 & 7
weekly/monthly, but mainly on Java 8 with so experimenting with Java
11.

My feedback and input would be;

1) Drop Pre Java 8 support
It would hurt my as I use it for projects stuck on Java 6 and 7, but
it would also give me business case for needing to upgrade these
projects to supported versions.

2) Dual Support for Java 8 and 11
Bump base version of Java 8 and use multi-release version jars so core
components/plugins and use new features where needed.
e.g.
META-INF/MANIFEST.MF (Automatic-Module-Name)
META-INF/versions/11/module-info.class (really support modules)

3) extend toolchains support for all plugins/phases
Currently having issues i.e. wanting to execute surefire/failsafe with
a specific version but having to hack build.

4) Separate repo rebuilt for each major/minor release
Similar to Debian/Ubuntu where each release gets it's own brand new
repo with everything rebuilt. Just wildcard idea.
So each major version gets a new repo, so 3.x, 4.x, 5.x. or 3.6.x,
3.7.x. Everything in this repo allows a basic project to build, i.e.
compile, jar, test, install and deploy. I fell if we don't do anything
in another 10 years maven central might be say 1 PB. We need to think
about a way of starting to drop old old versions, do we need all the
jars that are needed for a maven 2.x build still in central???
Not sure the best idea but think something like this needs working on.

John
Maven Enthusiasts and Evangelist

On Mon, 30 Sep 2019 at 21:21, Romain Manni-Bucau <rm...@gmail.com> wrote:
>
> +1 for java 8
> Java 7 dev will likely stick to already published versions since the
> ecosystem is already EOL anyway so no reason to not make maven java 8 based
> IMHO
>
> Le lun. 30 sept. 2019 à 22:16, Mickael Istria <mi...@redhat.com> a écrit :
>
> > On Sat, Sep 28, 2019 at 5:37 PM Mickael Istria <mi...@redhat.com> wrote:
> >
> > > I believe this reveals that some of the important Tycho tests are not
> > > performed against latest Maven snapshots.
> > >
> >
> > After a fix, the failures with polyglot build using more recent version of
> > Maven are now surfacing.
> > Too bad we didn't spot this missing configuration earlier, it would have
> > allowed to spot the regression against snapshot, before it get released...
> >
> >
> > --
> > Mickael Istria
> > Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/>
> > developer, for Red Hat Developers <https://developers.redhat.com/>
> >

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

Re: [DISCUSS] Maven 3.7.0

[Romain Manni-Bucau <rm...@gmail.com>]

+1 for java 8
Java 7 dev will likely stick to already published versions since the
ecosystem is already EOL anyway so no reason to not make maven java 8 based
IMHO

Le lun. 30 sept. 2019 à 22:16, Mickael Istria <mi...@redhat.com> a écrit :

> On Sat, Sep 28, 2019 at 5:37 PM Mickael Istria <mi...@redhat.com> wrote:
>
> > I believe this reveals that some of the important Tycho tests are not
> > performed against latest Maven snapshots.
> >
>
> After a fix, the failures with polyglot build using more recent version of
> Maven are now surfacing.
> Too bad we didn't spot this missing configuration earlier, it would have
> allowed to spot the regression against snapshot, before it get released...
>
>
> --
> Mickael Istria
> Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/>
> developer, for Red Hat Developers <https://developers.redhat.com/>
>

Re: [DISCUSS] Maven 3.7.0

[Mickael Istria <mi...@redhat.com>]

On Sat, Sep 28, 2019 at 5:37 PM Mickael Istria <mi...@redhat.com> wrote:

> I believe this reveals that some of the important Tycho tests are not
> performed against latest Maven snapshots.
>

After a fix, the failures with polyglot build using more recent version of
Maven are now surfacing.
Too bad we didn't spot this missing configuration earlier, it would have
allowed to spot the regression against snapshot, before it get released...


-- 
Mickael Istria
Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/>
developer, for Red Hat Developers <https://developers.redhat.com/>

Re: [DISCUSS] Maven 3.7.0

[Mickael Istria <mi...@redhat.com>]

On Sat, Sep 28, 2019 at 5:35 PM Karl Heinz Marbaise <kh...@gmx.de>
wrote:

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


I think we should trust the various users who face this issue, and assume
the issue exist until proven otherwise.
This is likely a bug in Tycho and/or Polyglot Maven, and I believe this
reveals that some of the important Tycho tests are not performed against
latest Maven snapshots. I've started a thread on the tycho-dev@eclipse.org
mailing-list on htis topic.

Re: [DISCUSS] Maven 3.7.0

[Karl Heinz Marbaise <kh...@gmx.de>]

Hi,

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

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

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

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

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

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

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

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


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

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

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


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

Great go forward for Maven 3.7.0...

Kind regards
Karl Heinz Marbaise

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

Re: [DISCUSS] Maven 3.7.0

[Alexander Ashitkin <as...@gmail.com>]

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" <rf...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 
> 

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

Re: [DISCUSS] Maven 3.7.0

[Robert Scholte <rf...@apache.org>]

On Sat, 28 Sep 2019 16:53:00 +0200, Enrico Olivelli <eo...@gmail.com>  
wrote:

> Robert,
>
> Il sab 28 set 2019, 14:04 Robert Scholte <rf...@apache.org> ha  
> scritto:
>
>> 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.
>>
>
> This is really cool, I hope we get something like this very soon.
>
> One overall comment from me is about using XML and particularly SAX.
> We will have our Maven XML library but the core principle is that all of
> the transformations are in a streaming fashion, there is no overall view  
> of
> the whole document, and you cannot go backward and you can't see the tags
> after the current point.
> SAX is more memory efficient but if this will be a base for the future we
> should take into account future needs.

The choice for using XMLFilters is to be able to keep order of elements  
and also keep the comments (assuming the distributed pom is still an  
important source of information, otherwise we could decide to just  
recreate a new pom).
Validating *after* the resolved pom (phase 2, but before inheritence) will  
probably need extra care, since there might be an issue with the input  
location.

So please have a good look. As said, it will only be activated with the  
special flag and we simply need to start somewhere. It is all about  
collection first experiences, see what works and what doesn't.

Robert

>
> I will review carefully the patch when the approach is agreed by the
> community. I have already taken a first look, if you create the pull
> requests I can add comments
>
> Enrico
>
>
>
>> 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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>

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

Re: [DISCUSS] Maven 3.7.0

[Enrico Olivelli <eo...@gmail.com>]

Robert,

Il sab 28 set 2019, 14:04 Robert Scholte <rf...@apache.org> ha scritto:

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

This is really cool, I hope we get something like this very soon.

One overall comment from me is about using XML and particularly SAX.
We will have our Maven XML library but the core principle is that all of
the transformations are in a streaming fashion, there is no overall view of
the whole document, and you cannot go backward and you can't see the tags
after the current point.
SAX is more memory efficient but if this will be a base for the future we
should take into account future needs.

I will review carefully the patch when the approach is agreed by the
community. I have already taken a first look, if you create the pull
requests I can add comments

Enrico



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

Re: [DISCUSS] Maven 3.7.0

[Stephen Connolly <st...@gmail.com>]

+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 <rf...@apache.org> wrote:

> https://github.com/apache/maven/pull/286
>
> On Tue, 01 Oct 2019 13:49:25 +0200, Enrico Olivelli <eo...@gmail.com>
>
> wrote:
>
> > Robert,
> > Can you create a PR?
> >
> > Enrico
> >
> > Il mar 1 ott 2019, 07:19 Sylwester Lachiewicz <sl...@gmail.com> ha
> > scritto:
> >
> >> +1 for Java 8 - let's kill 7 faster ;-))
> >>
> >> Sylwester
> >>
> >> wt., 1 paź 2019, 02:41 użytkownik Olivier Lamy <ol...@apache.org>
> >> 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 <rf...@apache.org>
> >> 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 <
> >> tibordigana@apache.org
> >> > >
> >> > >
> >> > > 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
> >> <garydgregory@gmail.com
> >> >
> >> > > > wrote:
> >> > > >
> >> > > >> I would say that fixing the Tycho issue comes first.
> >> > > >>
> >> > > >> Gary
> >> > > >>
> >> > > >> On Sat, Sep 28, 2019 at 8:04 AM Robert Scholte <
> >> rfscholte@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-unsubscribe@maven.apache.org
> >> > > >> > For additional commands, e-mail: dev-help@maven.apache.org
> >> > > >> >
> >> > > >> >
> >> > >
> >> > >
> >> ---------------------------------------------------------------------
> >> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > > For additional commands, e-mail: dev-help@maven.apache.org
> >> > >
> >> > >
> >> >
> >> > --
> >> > Olivier Lamy
> >> > http://twitter.com/olamy | http://linkedin.com/in/olamy
> >> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: [DISCUSS] Maven 3.7.0

[Robert Scholte <rf...@apache.org>]

https://github.com/apache/maven/pull/286

On Tue, 01 Oct 2019 13:49:25 +0200, Enrico Olivelli <eo...@gmail.com>  
wrote:

> Robert,
> Can you create a PR?
>
> Enrico
>
> Il mar 1 ott 2019, 07:19 Sylwester Lachiewicz <sl...@gmail.com> ha
> scritto:
>
>> +1 for Java 8 - let's kill 7 faster ;-))
>>
>> Sylwester
>>
>> wt., 1 paź 2019, 02:41 użytkownik Olivier Lamy <ol...@apache.org>  
>> 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 <rf...@apache.org>
>> 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 <
>> tibordigana@apache.org
>> > >
>> > >
>> > > 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  
>> <garydgregory@gmail.com
>> >
>> > > > wrote:
>> > > >
>> > > >> I would say that fixing the Tycho issue comes first.
>> > > >>
>> > > >> Gary
>> > > >>
>> > > >> On Sat, Sep 28, 2019 at 8:04 AM Robert Scholte <
>> rfscholte@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-unsubscribe@maven.apache.org
>> > > >> > For additional commands, e-mail: dev-help@maven.apache.org
>> > > >> >
>> > > >> >
>> > >
>> > >  
>> ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > > For additional commands, e-mail: dev-help@maven.apache.org
>> > >
>> > >
>> >
>> > --
>> > Olivier Lamy
>> > http://twitter.com/olamy | http://linkedin.com/in/olamy
>> >

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

Re: [DISCUSS] Maven 3.7.0

[Enrico Olivelli <eo...@gmail.com>]

Robert,
Can you create a PR?

Enrico

Il mar 1 ott 2019, 07:19 Sylwester Lachiewicz <sl...@gmail.com> ha
scritto:

> +1 for Java 8 - let's kill 7 faster ;-))
>
> Sylwester
>
> wt., 1 paź 2019, 02:41 użytkownik Olivier Lamy <ol...@apache.org> 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 <rf...@apache.org>
> 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 <
> tibordigana@apache.org
> > >
> > >
> > > 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 <garydgregory@gmail.com
> >
> > > > wrote:
> > > >
> > > >> I would say that fixing the Tycho issue comes first.
> > > >>
> > > >> Gary
> > > >>
> > > >> On Sat, Sep 28, 2019 at 8:04 AM Robert Scholte <
> rfscholte@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-unsubscribe@maven.apache.org
> > > >> > For additional commands, e-mail: dev-help@maven.apache.org
> > > >> >
> > > >> >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
> > --
> > Olivier Lamy
> > http://twitter.com/olamy | http://linkedin.com/in/olamy
> >
>

Re: [DISCUSS] Maven 3.7.0

[Sylwester Lachiewicz <sl...@gmail.com>]

+1 for Java 8 - let's kill 7 faster ;-))

Sylwester

wt., 1 paź 2019, 02:41 użytkownik Olivier Lamy <ol...@apache.org> 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 <rf...@apache.org> 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 <tibordigana@apache.org
> >
> >
> > 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 <ga...@gmail.com>
> > > wrote:
> > >
> > >> I would say that fixing the Tycho issue comes first.
> > >>
> > >> Gary
> > >>
> > >> On Sat, Sep 28, 2019 at 8:04 AM Robert Scholte <rf...@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-unsubscribe@maven.apache.org
> > >> > For additional commands, e-mail: dev-help@maven.apache.org
> > >> >
> > >> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>

Re: [DISCUSS] Maven 3.7.0

[Olivier Lamy <ol...@apache.org>]

+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 <rf...@apache.org> 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 <ti...@apache.org>
>
> 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 <ga...@gmail.com>
> > wrote:
> >
> >> I would say that fixing the Tycho issue comes first.
> >>
> >> Gary
> >>
> >> On Sat, Sep 28, 2019 at 8:04 AM Robert Scholte <rf...@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-unsubscribe@maven.apache.org
> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >> >
> >> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: [DISCUSS] Maven 3.7.0

[Robert Scholte <rf...@apache.org>]

> Then why you are setting target to 1.8 without the code?

As said: there *are* Java 8 specific code changes:

https://github.com/apache/maven/compare/MNG-6656?expand=1#diff-becf9d362b95e48f9ca0f2ab76ca9f8fR54  
(and every other method in this class)
https://github.com/apache/maven/compare/MNG-6656?expand=1#diff-97970a066f1696b603d96aad18b0f016R30
https://github.com/apache/maven/compare/MNG-6656?expand=1#diff-42c7d5b776fd974f21918f6d7ff2ab24R82-R94
https://github.com/apache/maven/compare/MNG-6656?expand=1#diff-3af5d63445648bbb61fddf8863a53888R36-R62

Even though all these classes live in the new maven-xml module, if you try  
to only compile this module with Java 8, and let maven-core depend on it  
with an @Inject for the BuildPomXMLFilterFactory, Maven simple won't start  
on Java 7 anymore. Trying to keep Maven Java 7 compatible including these  
files will introduce unmaintainable and unreadable code.
Hence why I started this [discuss] topic.
Up until now most people see this as the right opportunity to require Java  
8.

Robert

On Mon, 30 Sep 2019 21:15:47 +0200, Tibor Digana <ti...@apache.org>  
wrote:

> Then why you are setting target to 1.8 without the code?
> It does not make sense to set it without adapting the code.
>
> You know what it looks like? Many people will hate me when I say this in
> public.
> It looks like a lobby. And there can be anything in background,
> organizations, money flow, anything. But we do not do it for money. We  
> are
> doing it for the top notch quality and satisfied user.
>
> We know the one of our user created a commit in a plugin where the code  
> was
> migrated automatically.
> It helps but still you have to remove the "modernizer" annotations:
>
> <plugin>
> <groupId>org.gaul</groupId>
> <artifactId>modernizer-maven-plugin</artifactId>
> <version>1.8.0</version>
> <executions>
>   <execution>
> <id>modernizer</id>
> <phase>verify</phase>
> <goals>
>  <goal>modernizer</goal>
> </goals>
>   </execution>
> </executions>
> <configuration>
>   <javaVersion>1.8</javaVersion>
> </configuration>
> </plugin>
>
>     <dependency>
>       <groupId>org.gaul</groupId>
>       <artifactId>modernizer-maven-annotations</artifactId>
>       <version>1.8.0</version>
>     </dependency>
>
> On Mon, Sep 30, 2019 at 9:04 PM Enrico Olivelli <eo...@gmail.com>  
> wrote:
>
>> Tibor
>>
>> Il lun 30 set 2019, 20:30 Tibor Digana <ti...@apache.org> ha
>> scritto:
>>
>> > Robert, you'r really right, there is only 3.7.0-candidate
>> > <
>> >
>> https://issues.apache.org/jira/issues/?jql=project+%3D+MNG+AND+fixVersion+%3D+3.7.0-candidate
>> > >
>> > version in Jira, see
>> >
>> >
>> https://issues.apache.org/jira/projects/MNG?selectedItem=com.atlassian.jira.jira-projects-plugin:release-page
>> > So this means MNG-6169 is in this discussion as well as it is 3.7.0.
>> > As well as many other issues in the list including the MNG-6548 and
>> > MNG-6656 too.
>> >
>> > Internal code regarding J8 means that you have to rewrite the code to  
>> J8.
>> > It can be done automatically but that's another topic.
>> >
>>
>> You know that compiling for j8 does not require to use lamdas or  
>> whatever,
>> don't have to change your code,but only set target=8
>>
>> Enrico
>>
>>
>> As far as I know the Maven developers they do not always have private  
>> spare
>> > time to do this job and therefore it is better to write a list of
>> > priorities and find the human resources for these issue. I know how
>> > difficult it is. This is the main problem.
>> > I am not against J8. I only say that we have to deliver important  
>> things
>> > from the user perspective first and then those less important whishes
>> which
>> > is called "priorities", nothing special.
>> >
>> > Cheers
>> > Tibor17
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Mon, Sep 30, 2019 at 8:14 PM Robert Scholte <rf...@apache.org>
>> > 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 <
>> tibordigana@apache.org
>> > >
>> > >
>> > > 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  
>> <garydgregory@gmail.com
>> >
>> > > > wrote:
>> > > >
>> > > >> I would say that fixing the Tycho issue comes first.
>> > > >>
>> > > >> Gary
>> > > >>
>> > > >> On Sat, Sep 28, 2019 at 8:04 AM Robert Scholte <
>> rfscholte@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-unsubscribe@maven.apache.org
>> > > >> > For additional commands, e-mail: dev-help@maven.apache.org
>> > > >> >
>> > > >> >
>> > >
>> > >  
>> ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > > For additional commands, e-mail: dev-help@maven.apache.org
>> > >
>> > >
>> >

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

Re: [DISCUSS] Maven 3.7.0

[Tibor Digana <ti...@apache.org>]

Then why you are setting target to 1.8 without the code?
It does not make sense to set it without adapting the code.

You know what it looks like? Many people will hate me when I say this in
public.
It looks like a lobby. And there can be anything in background,
organizations, money flow, anything. But we do not do it for money. We are
doing it for the top notch quality and satisfied user.

We know the one of our user created a commit in a plugin where the code was
migrated automatically.
It helps but still you have to remove the "modernizer" annotations:

<plugin>
<groupId>org.gaul</groupId>
<artifactId>modernizer-maven-plugin</artifactId>
<version>1.8.0</version>
<executions>
  <execution>
<id>modernizer</id>
<phase>verify</phase>
<goals>
 <goal>modernizer</goal>
</goals>
  </execution>
</executions>
<configuration>
  <javaVersion>1.8</javaVersion>
</configuration>
</plugin>

    <dependency>
      <groupId>org.gaul</groupId>
      <artifactId>modernizer-maven-annotations</artifactId>
      <version>1.8.0</version>
    </dependency>

On Mon, Sep 30, 2019 at 9:04 PM Enrico Olivelli <eo...@gmail.com> wrote:

> Tibor
>
> Il lun 30 set 2019, 20:30 Tibor Digana <ti...@apache.org> ha
> scritto:
>
> > Robert, you'r really right, there is only 3.7.0-candidate
> > <
> >
> https://issues.apache.org/jira/issues/?jql=project+%3D+MNG+AND+fixVersion+%3D+3.7.0-candidate
> > >
> > version in Jira, see
> >
> >
> https://issues.apache.org/jira/projects/MNG?selectedItem=com.atlassian.jira.jira-projects-plugin:release-page
> > So this means MNG-6169 is in this discussion as well as it is 3.7.0.
> > As well as many other issues in the list including the MNG-6548 and
> > MNG-6656 too.
> >
> > Internal code regarding J8 means that you have to rewrite the code to J8.
> > It can be done automatically but that's another topic.
> >
>
> You know that compiling for j8 does not require to use lamdas or whatever,
> don't have to change your code,but only set target=8
>
> Enrico
>
>
> As far as I know the Maven developers they do not always have private spare
> > time to do this job and therefore it is better to write a list of
> > priorities and find the human resources for these issue. I know how
> > difficult it is. This is the main problem.
> > I am not against J8. I only say that we have to deliver important things
> > from the user perspective first and then those less important whishes
> which
> > is called "priorities", nothing special.
> >
> > Cheers
> > Tibor17
> >
> >
> >
> >
> >
> >
> >
> > On Mon, Sep 30, 2019 at 8:14 PM Robert Scholte <rf...@apache.org>
> > 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 <
> tibordigana@apache.org
> > >
> > >
> > > 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 <garydgregory@gmail.com
> >
> > > > wrote:
> > > >
> > > >> I would say that fixing the Tycho issue comes first.
> > > >>
> > > >> Gary
> > > >>
> > > >> On Sat, Sep 28, 2019 at 8:04 AM Robert Scholte <
> rfscholte@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-unsubscribe@maven.apache.org
> > > >> > For additional commands, e-mail: dev-help@maven.apache.org
> > > >> >
> > > >> >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>

Re: [DISCUSS] Maven 3.7.0

[Enrico Olivelli <eo...@gmail.com>]

Tibor

Il lun 30 set 2019, 20:30 Tibor Digana <ti...@apache.org> ha scritto:

> Robert, you'r really right, there is only 3.7.0-candidate
> <
> https://issues.apache.org/jira/issues/?jql=project+%3D+MNG+AND+fixVersion+%3D+3.7.0-candidate
> >
> version in Jira, see
>
> https://issues.apache.org/jira/projects/MNG?selectedItem=com.atlassian.jira.jira-projects-plugin:release-page
> So this means MNG-6169 is in this discussion as well as it is 3.7.0.
> As well as many other issues in the list including the MNG-6548 and
> MNG-6656 too.
>
> Internal code regarding J8 means that you have to rewrite the code to J8.
> It can be done automatically but that's another topic.
>

You know that compiling for j8 does not require to use lamdas or whatever,
don't have to change your code,but only set target=8

Enrico


As far as I know the Maven developers they do not always have private spare
> time to do this job and therefore it is better to write a list of
> priorities and find the human resources for these issue. I know how
> difficult it is. This is the main problem.
> I am not against J8. I only say that we have to deliver important things
> from the user perspective first and then those less important whishes which
> is called "priorities", nothing special.
>
> Cheers
> Tibor17
>
>
>
>
>
>
>
> On Mon, Sep 30, 2019 at 8:14 PM Robert Scholte <rf...@apache.org>
> 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 <tibordigana@apache.org
> >
> >
> > 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 <ga...@gmail.com>
> > > wrote:
> > >
> > >> I would say that fixing the Tycho issue comes first.
> > >>
> > >> Gary
> > >>
> > >> On Sat, Sep 28, 2019 at 8:04 AM Robert Scholte <rf...@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-unsubscribe@maven.apache.org
> > >> > For additional commands, e-mail: dev-help@maven.apache.org
> > >> >
> > >> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>

Re: [DISCUSS] Maven 3.7.0

[Tibor Digana <ti...@apache.org>]

Robert, you'r really right, there is only 3.7.0-candidate
<https://issues.apache.org/jira/issues/?jql=project+%3D+MNG+AND+fixVersion+%3D+3.7.0-candidate>
version in Jira, see
https://issues.apache.org/jira/projects/MNG?selectedItem=com.atlassian.jira.jira-projects-plugin:release-page
So this means MNG-6169 is in this discussion as well as it is 3.7.0.
As well as many other issues in the list including the MNG-6548 and
MNG-6656 too.

Internal code regarding J8 means that you have to rewrite the code to J8.
It can be done automatically but that's another topic.
As far as I know the Maven developers they do not always have private spare
time to do this job and therefore it is better to write a list of
priorities and find the human resources for these issue. I know how
difficult it is. This is the main problem.
I am not against J8. I only say that we have to deliver important things
from the user perspective first and then those less important whishes which
is called "priorities", nothing special.

Cheers
Tibor17







On Mon, Sep 30, 2019 at 8:14 PM Robert Scholte <rf...@apache.org> 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 <ti...@apache.org>
>
> 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 <ga...@gmail.com>
> > wrote:
> >
> >> I would say that fixing the Tycho issue comes first.
> >>
> >> Gary
> >>
> >> On Sat, Sep 28, 2019 at 8:04 AM Robert Scholte <rf...@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-unsubscribe@maven.apache.org
> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >> >
> >> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: [DISCUSS] Maven 3.7.0

[Robert Scholte <rf...@apache.org>]

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 <ti...@apache.org>  
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 <ga...@gmail.com>  
> wrote:
>
>> I would say that fixing the Tycho issue comes first.
>>
>> Gary
>>
>> On Sat, Sep 28, 2019 at 8:04 AM Robert Scholte <rf...@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-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> >

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

Re: [DISCUSS] Maven 3.7.0

[Tibor Digana <ti...@apache.org>]

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 <ga...@gmail.com> wrote:

> I would say that fixing the Tycho issue comes first.
>
> Gary
>
> On Sat, Sep 28, 2019 at 8:04 AM Robert Scholte <rf...@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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>

Re: [DISCUSS] Maven 3.7.0

[Gary Gregory <ga...@gmail.com>]

I would say that fixing the Tycho issue comes first.

Gary

On Sat, Sep 28, 2019 at 8:04 AM Robert Scholte <rf...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: [DISCUSS] Maven 3.7.0

[Anders Hammar <an...@hammar.net>]

On Thu, Oct 3, 2019 at 5:47 PM Emmanuel Bourg <eb...@apache.org> wrote:

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

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

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

/Anders

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



>
> Emmanuel Bourg
>
> [1]
> https://access.redhat.com/articles/1299013#OpenJDK_Lifecycle_Dates_and_RHEL_versions
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: [DISCUSS] Maven 3.7.0

[Emmanuel Bourg <eb...@apache.org>]

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

Re: [DISCUSS] Maven 3.7.0

[Gary Gregory <ga...@gmail.com>]

Java 8 as a min is fine by me FWIW.

Gary

On Thu, Oct 3, 2019 at 11:07 AM Tibor Digana <ti...@apache.org> 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 <ti...@apache.org>
> 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 <kh...@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 <rf...@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-unsubscribe@maven.apache.org
> >> >> For additional commands, e-mail: dev-help@maven.apache.org
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
>

Re: [DISCUSS] Maven 3.7.0

[Tibor Digana <ti...@apache.org>]

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 <ti...@apache.org> 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 <kh...@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 <rf...@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-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>

Re: [DISCUSS] Maven 3.7.0

[Romain Manni-Bucau <rm...@gmail.com>]

Le jeu. 3 oct. 2019 à 21:23, Tibor Digana <ti...@apache.org> 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 <rm...@gmail.com>
> wrote:
>
> > Le jeu. 3 oct. 2019 à 20:22, Tibor Digana <ti...@apache.org> 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.connolly@gmail.com> wrote:
> > >
> > > > On Thu, 3 Oct 2019 at 16:49, Karl Heinz Marbaise <kh...@gmx.de>
> > > > 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 <
> > > khmarbaise@gmx.de
> > > > > > <ma...@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
> > > > > >     <rfscholte@apache.org <ma...@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-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Maven 3.7.0

[Tibor Digana <ti...@apache.org>]

>> 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 <rm...@gmail.com>
wrote:

> Le jeu. 3 oct. 2019 à 20:22, Tibor Digana <ti...@apache.org> 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.connolly@gmail.com> wrote:
> >
> > > On Thu, 3 Oct 2019 at 16:49, Karl Heinz Marbaise <kh...@gmx.de>
> > > 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 <
> > khmarbaise@gmx.de
> > > > > <ma...@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
> > > > >     <rfscholte@apache.org <ma...@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-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Maven 3.7.0

[Romain Manni-Bucau <rm...@gmail.com>]

Le jeu. 3 oct. 2019 à 20:22, Tibor Digana <ti...@apache.org> 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.connolly@gmail.com> wrote:
>
> > On Thu, 3 Oct 2019 at 16:49, Karl Heinz Marbaise <kh...@gmx.de>
> > 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 <
> khmarbaise@gmx.de
> > > > <ma...@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
> > > >     <rfscholte@apache.org <ma...@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-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>

Re: [DISCUSS] Maven 3.7.0

[Stephen Connolly <st...@gmail.com>]

On Fri, 4 Oct 2019 at 09:48, Robert Scholte <rf...@apache.org> wrote:

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

+1


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

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

The only thing I noticed are confirmations that there are regressions, but
> they are related to third party plugins/extensions/tools. Hopefully they
> can help analyze to help their own product.
> Based on that I'll put my focus fully Maven 3.7.0.
>
> thanks,
> Robert
>
> On Thu, 03 Oct 2019 20:22:06 +0200, Tibor Digana <ti...@apache.org>
>
> wrote:
>
> > The topic related to TLS is only related to runtime, means JDK, which is
> > under the control of the particular user or CI.
> > I guess the user can easily find the answer:
> >
> https://stackoverflow.com/questions/50824789/why-am-i-getting-received-fatal-alert-protocol-version-or-peer-not-authentic
> >
> > The thing is that we need to specify:
> > + advantages of Java 1.8 in code (Lambda, brief code, maybe)
> > + disadvantages of Java 1.8 in code (Streams performance when/how/what
> > approach???)
> >
> > Write notices for developers on the internal Wiki:
> > + toolchains
> > + limitations and solutions for disadvantages
> > + conditions when and how to migrate from J7 to J8
> >
> > and then we should Vote for J8.
> >
> > And there are users who is has J6 and J7 and they may require us to
> > maintain the old version 3.6.x.
> > What to do in this case?
> > Is the toolchain enough? Usually it is in ordinal projects!
> >
> > Cheers
> > T
> >
> >
> > On Thu, Oct 3, 2019 at 5:52 PM Stephen Connolly <
> > stephen.alan.connolly@gmail.com> wrote:
> >
> >> On Thu, 3 Oct 2019 at 16:49, Karl Heinz Marbaise <kh...@gmx.de>
> >> 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
> >> <khmarbaise@gmx.de
> >> > > <ma...@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
> >> > >     <rfscholte@apache.org <ma...@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-unsubscribe@maven.apache.org
> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >> >
> >> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: [DISCUSS] Maven 3.7.0

[Robert Scholte <rf...@apache.org>]

Sorry Tibor, but I'm not going to do this.

We've said that simply changing source/target(/release) to 1.8 is not a  
good reason to require Java 8.
Now with the changes as mentioned in this thread (new APIs based on Java  
Functions) we finally have this good reason.

I'm not going to explain why the move to Java 8 is important. I'm only  
interested in good arguments why to stay on Java 7 and so far I haven't  
seen any.
People must understand that we're talking about the Java Runtime that  
Maven requires. There's a clear separation between Mavens runtime and the  
JDK. If you want to compile your code with an earlier JDK, that's already  
possible for a long time (but I guess most people simply use the Maven  
Runtime as their JDK).

For those that argue that they must stay on Java 7 for their own projects  
must also keep in mind that with such statement they block the evolution  
of Maven for the whole Java community.

I only saw a negative vote in relation with the Google Cloud Platform. Let  
this be a motivation for them to move forward too. Google should have  
enough resources to come up with a solution, either move to Java 8,  
maintain a backported version of Maven or maybe there are other solutions.

Based on the responses on this thread I will continue with the proposed  
changed. A first PR has already been reviewed, and there are still a  
couple of TODO's I need to work on and I'll inform related tools regarding  
these changes.

I started the thread with one other question: do we need a 3.6.3  
regression release?
The only thing I noticed are confirmations that there are regressions, but  
they are related to third party plugins/extensions/tools. Hopefully they  
can help analyze to help their own product.
Based on that I'll put my focus fully Maven 3.7.0.

thanks,
Robert

On Thu, 03 Oct 2019 20:22:06 +0200, Tibor Digana <ti...@apache.org>  
wrote:

> The topic related to TLS is only related to runtime, means JDK, which is
> under the control of the particular user or CI.
> I guess the user can easily find the answer:
> https://stackoverflow.com/questions/50824789/why-am-i-getting-received-fatal-alert-protocol-version-or-peer-not-authentic
>
> The thing is that we need to specify:
> + advantages of Java 1.8 in code (Lambda, brief code, maybe)
> + disadvantages of Java 1.8 in code (Streams performance when/how/what
> approach???)
>
> Write notices for developers on the internal Wiki:
> + toolchains
> + limitations and solutions for disadvantages
> + conditions when and how to migrate from J7 to J8
>
> and then we should Vote for J8.
>
> And there are users who is has J6 and J7 and they may require us to
> maintain the old version 3.6.x.
> What to do in this case?
> Is the toolchain enough? Usually it is in ordinal projects!
>
> Cheers
> T
>
>
> On Thu, Oct 3, 2019 at 5:52 PM Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
>> On Thu, 3 Oct 2019 at 16:49, Karl Heinz Marbaise <kh...@gmx.de>
>> 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  
>> <khmarbaise@gmx.de
>> > > <ma...@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
>> > >     <rfscholte@apache.org <ma...@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-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> >

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

Re: [DISCUSS] Maven 3.7.0

[Tibor Digana <ti...@apache.org>]

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.connolly@gmail.com> wrote:

> On Thu, 3 Oct 2019 at 16:49, Karl Heinz Marbaise <kh...@gmx.de>
> 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 <khmarbaise@gmx.de
> > > <ma...@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
> > >     <rfscholte@apache.org <ma...@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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>

Re: [DISCUSS] Maven 3.7.0

[Stephen Connolly <st...@gmail.com>]

On Thu, 3 Oct 2019 at 16:49, Karl Heinz Marbaise <kh...@gmx.de> 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 <khmarbaise@gmx.de
> > <ma...@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
> >     <rfscholte@apache.org <ma...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: [DISCUSS] Maven 3.7.0

[Karl Heinz Marbaise <kh...@gmx.de>]

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 <khmarbaise@gmx.de
> <ma...@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
>     <rfscholte@apache.org <ma...@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [DISCUSS] Maven 3.7.0

[Tibor Digana <ti...@apache.org>]

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 <kh...@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 <rf...@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-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: [DISCUSS] Maven 3.7.0

[Karl Heinz Marbaise <kh...@gmx.de>]

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

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

Re: Proposal: maven release lifecycle

[Hervé BOUTEMY <he...@free.fr>]

we talk about the maven-release-plugin, but I think that we should also talk 
about the release profile = the way we extend the goals run during a non-
release build with a few additional goals on a release build

see for example the "apache-release" profile documentation of ASF parent
https://maven.apache.org/pom/asf/

By adding a new lifecycle, you would loose the sharing of most steps between 
non-release and release builds


Like Karl Heinz, I really don't get the pain points you're trying to solve

Regards

Hervé

Le jeudi 3 octobre 2019, 17:04:02 CEST Karl Heinz Marbaise a écrit :
> 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org





---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Proposal: maven release lifecycle

[Hervé BOUTEMY <he...@free.fr>]

we talk about the maven-release-plugin, but I think that we should also talk 
about the release profile = the way we extend the goals run during a non-
release build with a few additional goals on a release build

see for example the "apache-release" profile documentation of ASF parent
https://maven.apache.org/pom/asf/

By adding a new lifecycle, you would loose the sharing of most steps between 
non-release and release builds


Like Karl Heinz, I really don't get the pain points you're trying to solve

Regards

Hervé

Le jeudi 3 octobre 2019, 17:04:02 CEST Karl Heinz Marbaise a écrit :
> 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org





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

Re: Proposal: maven release lifecycle

[Tibor Digana <ti...@apache.org>]

I did not say that we skip test. I never skip the tests in prepare/perform.
Some colleagues do but for me it is good time to spend in the kitchen and
take a tea.

Our architecture was simply designed with isolated SCM projects, so the
dependencies are being downloaded into it and therefore I verify that what
would happen in SCM2 now if I compiled the lib in SCM1. Usually it is okay
because we have good ITs in SCM1 and we are cool devs ;-)

On Fri, Oct 4, 2019 at 11:28 AM Romain Manni-Bucau <rm...@gmail.com>
wrote:

> @Tibor: I agree merging both in one "super" command can be neat (I always
> run both at once typically) but I disagree with last parts "skip the test"
> - maven is also there to enforce tests as a good practise, if you don't
> automatically test it you can configure maven to skip tests for the release
> but it is at your own risk, can be fine or not - and "skip the deploy" -
> here again you can configure maven to do it if you need but maven must
> respect the build attached artifact.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le ven. 4 oct. 2019 à 11:22, Tibor Digana <ti...@apache.org> a
> écrit :
>
> > It would be worth to add a new goal called "release" to the
> > maven-release-plugin which merges "prepare" and "perform".
> > We developers in companies use both goals prepare and perform immediately
> > together because for us two goals do not make sense.
> > Two goals make sense for those who can wait days to start manual tests of
> > the TAG but we don't!
> >
> > We are testing the JAR libraries beforehand and then we evaluate the
> > quality/manual tests with SNAPSHOT whether it makes sense to start the
> > release process in CLI.
> > If there are web archives, the prepare phase would be enough because
> > deployment in Nexus is useless nothing but the TAG itself and Continuous
> > Delivery.
> >
> > On Fri, Oct 4, 2019 at 8:34 AM Romain Manni-Bucau <rmannibucau@gmail.com
> >
> > wrote:
> >
> > > Hi Marco,
> > >
> > > I have 2 thoughts reading your post:
> > >
> > > 1. Should be enforced by an extension (sonatype plugin if target is
> > > central?)
> > > 2. It likely misses a few phases compared to maven release plugin which
> > > validates the release can be done (including tests) and runs the tests
> on
> > > the tag as well
> > >
> > > Now if 200 lines of xml can be replaced by a single extension I am
> +1000
> > on
> > > that track
> > >
> > > Le ven. 4 oct. 2019 à 08:24, Marco Schulz <ma...@outlook.com> a
> > > écrit :
> > >
> > > > Hello Maven Dev & Community
> > > >
> > > > Sine a long time I thought, it would be cool to have a well defined
> > > > process to
> > > > prepare a release of an artifact and deploy it on mvn central. Now I
> > got
> > > a
> > > > bit
> > > > time to formulate a short proposal of my idea. I published a
> > description
> > > > of my
> > > > thought on my bolg:
> > > > https://enrebaja.wordpress.com/2019/10/03/next-generation-maven/
> > > >
> > > > A poll is also created, may to see what other people think about it.
> > > > Please feel
> > > > free to leave also comments, every feedback is welcome.
> > > >
> > > > warm regards & thanks to the maven dev team for the great job they
> do.
> > > > .marco (@ElmarDott)
> > > >
> > > > --
> > > >
> > > >
> > >
> >
> ________________________________________________________________________________
> > > >  Dipl. Inf. Marco Schulz (MSc)
> > > >
> > > >                   Expert for (WEB) Enterprise Applications
> > > >                            - worldwide -
> > > >       + Project Manager + Consultant + Writer + Speaker + Trainer +
> > > >
> > > >
> > > >
> > >
> >
> [Contact]_______________________________________________________________________
> > > >
> > > >    WhatsApp :  +52 (1) 221 200 61 37 :: Mexico
> > > >    Cell     :  +49 (0) 163 69 18 445 :: Germany
> > > >    E-Mail   :  marco.schulz@outlook.com
> > > >
> > > >    Blog     :  https://enRebaja.wordpress.com
> > > >    twitter  :  https://twitter.com/ElmarDott
> > > >    tumblr   :  https://elmardott.tumblr.com
> > > >    facebook :  https://www.facebook.com/elmar.dott
> > > >
> > > >
> > > >
> > >
> >
> [Services]______________________________________________________________________
> > > >
> > > >     + Individual software development
> > > >     + Software Project Management
> > > >     + Build-,  Configuration-, & Delivery Management
> > > >     + Release Management
> > > >     + Business Analysis
> > > >     + Software Architecture
> > > >     + Process Automation
> > > >
> > > >
> > >
> >
> ________________________________________________________________________________
> > > > This message is intended only for the use of the individual or entity
> > to
> > > > which
> > > > it is addressed, and may contain information that is privileged,
> > > > confidential
> > > > and that may not be made public by law or agreement. If you are not
> the
> > > > intended
> > > > recipient or entity, you are hereby notified that any further
> > > > dissemination,
> > > > distribution or copying of this information is strictly prohibited.
> > > > If you have received this communication in error, please contact us
> > > > immediately
> > > > and delete the message from your system.
> > > >
> > > >
> > >
> >
>

Re: Proposal: maven release lifecycle

[Tibor Digana <ti...@apache.org>]

I did not say that we skip test. I never skip the tests in prepare/perform.
Some colleagues do but for me it is good time to spend in the kitchen and
take a tea.

Our architecture was simply designed with isolated SCM projects, so the
dependencies are being downloaded into it and therefore I verify that what
would happen in SCM2 now if I compiled the lib in SCM1. Usually it is okay
because we have good ITs in SCM1 and we are cool devs ;-)

On Fri, Oct 4, 2019 at 11:28 AM Romain Manni-Bucau <rm...@gmail.com>
wrote:

> @Tibor: I agree merging both in one "super" command can be neat (I always
> run both at once typically) but I disagree with last parts "skip the test"
> - maven is also there to enforce tests as a good practise, if you don't
> automatically test it you can configure maven to skip tests for the release
> but it is at your own risk, can be fine or not - and "skip the deploy" -
> here again you can configure maven to do it if you need but maven must
> respect the build attached artifact.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le ven. 4 oct. 2019 à 11:22, Tibor Digana <ti...@apache.org> a
> écrit :
>
> > It would be worth to add a new goal called "release" to the
> > maven-release-plugin which merges "prepare" and "perform".
> > We developers in companies use both goals prepare and perform immediately
> > together because for us two goals do not make sense.
> > Two goals make sense for those who can wait days to start manual tests of
> > the TAG but we don't!
> >
> > We are testing the JAR libraries beforehand and then we evaluate the
> > quality/manual tests with SNAPSHOT whether it makes sense to start the
> > release process in CLI.
> > If there are web archives, the prepare phase would be enough because
> > deployment in Nexus is useless nothing but the TAG itself and Continuous
> > Delivery.
> >
> > On Fri, Oct 4, 2019 at 8:34 AM Romain Manni-Bucau <rmannibucau@gmail.com
> >
> > wrote:
> >
> > > Hi Marco,
> > >
> > > I have 2 thoughts reading your post:
> > >
> > > 1. Should be enforced by an extension (sonatype plugin if target is
> > > central?)
> > > 2. It likely misses a few phases compared to maven release plugin which
> > > validates the release can be done (including tests) and runs the tests
> on
> > > the tag as well
> > >
> > > Now if 200 lines of xml can be replaced by a single extension I am
> +1000
> > on
> > > that track
> > >
> > > Le ven. 4 oct. 2019 à 08:24, Marco Schulz <ma...@outlook.com> a
> > > écrit :
> > >
> > > > Hello Maven Dev & Community
> > > >
> > > > Sine a long time I thought, it would be cool to have a well defined
> > > > process to
> > > > prepare a release of an artifact and deploy it on mvn central. Now I
> > got
> > > a
> > > > bit
> > > > time to formulate a short proposal of my idea. I published a
> > description
> > > > of my
> > > > thought on my bolg:
> > > > https://enrebaja.wordpress.com/2019/10/03/next-generation-maven/
> > > >
> > > > A poll is also created, may to see what other people think about it.
> > > > Please feel
> > > > free to leave also comments, every feedback is welcome.
> > > >
> > > > warm regards & thanks to the maven dev team for the great job they
> do.
> > > > .marco (@ElmarDott)
> > > >
> > > > --
> > > >
> > > >
> > >
> >
> ________________________________________________________________________________
> > > >  Dipl. Inf. Marco Schulz (MSc)
> > > >
> > > >                   Expert for (WEB) Enterprise Applications
> > > >                            - worldwide -
> > > >       + Project Manager + Consultant + Writer + Speaker + Trainer +
> > > >
> > > >
> > > >
> > >
> >
> [Contact]_______________________________________________________________________
> > > >
> > > >    WhatsApp :  +52 (1) 221 200 61 37 :: Mexico
> > > >    Cell     :  +49 (0) 163 69 18 445 :: Germany
> > > >    E-Mail   :  marco.schulz@outlook.com
> > > >
> > > >    Blog     :  https://enRebaja.wordpress.com
> > > >    twitter  :  https://twitter.com/ElmarDott
> > > >    tumblr   :  https://elmardott.tumblr.com
> > > >    facebook :  https://www.facebook.com/elmar.dott
> > > >
> > > >
> > > >
> > >
> >
> [Services]______________________________________________________________________
> > > >
> > > >     + Individual software development
> > > >     + Software Project Management
> > > >     + Build-,  Configuration-, & Delivery Management
> > > >     + Release Management
> > > >     + Business Analysis
> > > >     + Software Architecture
> > > >     + Process Automation
> > > >
> > > >
> > >
> >
> ________________________________________________________________________________
> > > > This message is intended only for the use of the individual or entity
> > to
> > > > which
> > > > it is addressed, and may contain information that is privileged,
> > > > confidential
> > > > and that may not be made public by law or agreement. If you are not
> the
> > > > intended
> > > > recipient or entity, you are hereby notified that any further
> > > > dissemination,
> > > > distribution or copying of this information is strictly prohibited.
> > > > If you have received this communication in error, please contact us
> > > > immediately
> > > > and delete the message from your system.
> > > >
> > > >
> > >
> >
>

Re: Proposal: maven release lifecycle

[Tibor Digana <ti...@apache.org>]

Release lifecycle does not exist yet.
There's only "default", "clean", "site".

Therefore i would prefer to have this in CLI, i.e.
$ maven release

>> nowdays needs (release, js build, cloud deployment, gh-pages, etc...)
We cannot be technology specific but we can provide customization of the
release lifecycle.

The outcome of this discussion should be some frame-work as well as list of
items where we can agree and start writing Wiki page.
We do not have to go deeply "how" to do.
We should agree on "what" to do at least.



On Sat, Oct 5, 2019 at 4:08 PM Romain Manni-Bucau <rm...@gmail.com>
wrote:

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

Re: Proposal: maven release lifecycle

[Tibor Digana <ti...@apache.org>]

Release lifecycle does not exist yet.
There's only "default", "clean", "site".

Therefore i would prefer to have this in CLI, i.e.
$ maven release

>> nowdays needs (release, js build, cloud deployment, gh-pages, etc...)
We cannot be technology specific but we can provide customization of the
release lifecycle.

The outcome of this discussion should be some frame-work as well as list of
items where we can agree and start writing Wiki page.
We do not have to go deeply "how" to do.
We should agree on "what" to do at least.



On Sat, Oct 5, 2019 at 4:08 PM Romain Manni-Bucau <rm...@gmail.com>
wrote:

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

Re: Proposal: maven release lifecycle

[Romain Manni-Bucau <rm...@gmail.com>]

Personally Id like to keep current release lifecycle, it is the most
generic one we can get but we need to let users create their own chain of
mojo very easily in the pom.

It is trivial to do with a custom descriptor and extension but it must be
built in cause of nowdays needs (release, js build, cloud deployment,
gh-pages, etc...)

Le sam. 5 oct. 2019 à 15:18, Tibor Digana <ti...@apache.org> a écrit :

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

Re: Proposal: maven release lifecycle

[Romain Manni-Bucau <rm...@gmail.com>]

Personally Id like to keep current release lifecycle, it is the most
generic one we can get but we need to let users create their own chain of
mojo very easily in the pom.

It is trivial to do with a custom descriptor and extension but it must be
built in cause of nowdays needs (release, js build, cloud deployment,
gh-pages, etc...)

Le sam. 5 oct. 2019 à 15:18, Tibor Digana <ti...@apache.org> a écrit :

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

Re: Proposal: maven release lifecycle

[Tibor Digana <ti...@apache.org>]

I have never seen a documentation for ship-maven-plugin.
It could be a good motivation for us.

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

Tagging and SCM checkout are just fine.

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

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


On Sat, Oct 5, 2019 at 2:47 PM Marco Schulz <ma...@outlook.com>
wrote:

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

Re: Proposal: maven release lifecycle

[Tibor Digana <ti...@apache.org>]

I have never seen a documentation for ship-maven-plugin.
It could be a good motivation for us.

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

Tagging and SCM checkout are just fine.

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

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


On Sat, Oct 5, 2019 at 2:47 PM Marco Schulz <ma...@outlook.com>
wrote:

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

Re: Proposal: maven release lifecycle

[Marco Schulz <ma...@outlook.com>]

All this points are in my opinion an indicator that a release is a complex process and very difficult to handle in just a plugin. To maintain all that different points a relesaplugin will ver a ueber (god) plugin.

Docker for example is another big toic we need to think about.

rwgards and anice weekend to all
. marco

Sent from Outlook Mobile<https://aka.ms/blhgte>

________________________________
From: Romain Manni-Bucau <rm...@gmail.com>
Sent: Saturday, October 5, 2019 2:06:27 AM
To: Maven Developers List <de...@maven.apache.org>
Cc: users <us...@maven.apache.org>
Subject: Re: Proposal: maven release lifecycle

I like the words but fail to see the missing pieces (understand actions to
do).

Typically today when i release at work i use release plugin enriched with
github page deployment for the doc using antora + a ftp update of my server
output capture to have a mock backing openapi/swagger ui + docker ilage
deployment on docker hub + an intellij plugin deployment on jetbrains
marketplace etc...adding a flyway migration with a rolling update in a k8s
cluster is trivial (ops need to say yes though ;)).

So technically it is verbose but doable.

Custom lifecycle definition is not neat, custom build tasks require a build
hack or using groovy plugin but it works.

Typically, an extension could enable all that based on convention, just
injecting needed plugins based on the file presence and values of the
distribution urls.

This is why i ended up thinking we are more on 1. Sugar in release plugin
and 2. Maybe on a generic extension cretion (it replaces rigid lifecycle
for such cases these days due to their writing easiness)

Am I missing something?

Le sam. 5 oct. 2019 à 08:23, Marco Schulz <ma...@outlook.com> a
écrit :

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

Re: Proposal: maven release lifecycle

[Marco Schulz <ma...@outlook.com>]

All this points are in my opinion an indicator that a release is a complex process and very difficult to handle in just a plugin. To maintain all that different points a relesaplugin will ver a ueber (god) plugin.

Docker for example is another big toic we need to think about.

rwgards and anice weekend to all
. marco

Sent from Outlook Mobile<https://aka.ms/blhgte>

________________________________
From: Romain Manni-Bucau <rm...@gmail.com>
Sent: Saturday, October 5, 2019 2:06:27 AM
To: Maven Developers List <de...@maven.apache.org>
Cc: users <us...@maven.apache.org>
Subject: Re: Proposal: maven release lifecycle

I like the words but fail to see the missing pieces (understand actions to
do).

Typically today when i release at work i use release plugin enriched with
github page deployment for the doc using antora + a ftp update of my server
output capture to have a mock backing openapi/swagger ui + docker ilage
deployment on docker hub + an intellij plugin deployment on jetbrains
marketplace etc...adding a flyway migration with a rolling update in a k8s
cluster is trivial (ops need to say yes though ;)).

So technically it is verbose but doable.

Custom lifecycle definition is not neat, custom build tasks require a build
hack or using groovy plugin but it works.

Typically, an extension could enable all that based on convention, just
injecting needed plugins based on the file presence and values of the
distribution urls.

This is why i ended up thinking we are more on 1. Sugar in release plugin
and 2. Maybe on a generic extension cretion (it replaces rigid lifecycle
for such cases these days due to their writing easiness)

Am I missing something?

Le sam. 5 oct. 2019 à 08:23, Marco Schulz <ma...@outlook.com> a
écrit :

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

Re: Proposal: maven release lifecycle

[Tibor Digana <ti...@apache.org>]

Marco, did you mean the SCM graph?

Notice that companies have plenty of different ones.
The plugin should be so much flexible that it would not have a problem to
understand any of the graph and support it.

On Sat, Oct 5, 2019 at 4:15 PM Marco Schulz <ma...@outlook.com>
wrote:

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

Re: Proposal: maven release lifecycle

[Marco Schulz <ma...@outlook.com>]

I mention a ship lifecycle 😅

Sent from Outlook Mobile<https://aka.ms/blhgte>

________________________________
From: Stephen Connolly <st...@gmail.com>
Sent: Saturday, October 5, 2019 2:49:51 AM
To: Maven Developers List <de...@maven.apache.org>
Subject: Re: Proposal: maven release lifecycle

On Sat 5 Oct 2019 at 08:14, Romain Manni-Bucau <rm...@gmail.com>
wrote:

> I like the words but fail to see the missing pieces (understand actions to
> do).
>
> Typically today when i release at work i use release plugin enriched with
> github page deployment for the doc using antora + a ftp update of my server
> output capture to have a mock backing openapi/swagger ui + docker ilage
> deployment on docker hub + an intellij plugin deployment on jetbrains
> marketplace etc...adding a flyway migration with a rolling update in a k8s
> cluster is trivial (ops need to say yes though ;)).
>
> So technically it is verbose but doable.
>
> Custom lifecycle definition is not neat, custom build tasks require a build
> hack or using groovy plugin but it works.


Such a pity my ship-maven-plugin never gained traction


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

Re: Proposal: maven release lifecycle

[Stephen Connolly <st...@gmail.com>]

On Sat 5 Oct 2019 at 08:14, Romain Manni-Bucau <rm...@gmail.com>
wrote:

> I like the words but fail to see the missing pieces (understand actions to
> do).
>
> Typically today when i release at work i use release plugin enriched with
> github page deployment for the doc using antora + a ftp update of my server
> output capture to have a mock backing openapi/swagger ui + docker ilage
> deployment on docker hub + an intellij plugin deployment on jetbrains
> marketplace etc...adding a flyway migration with a rolling update in a k8s
> cluster is trivial (ops need to say yes though ;)).
>
> So technically it is verbose but doable.
>
> Custom lifecycle definition is not neat, custom build tasks require a build
> hack or using groovy plugin but it works.


Such a pity my ship-maven-plugin never gained traction


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

Re: Proposal: maven release lifecycle

[Romain Manni-Bucau <rm...@gmail.com>]

I like the words but fail to see the missing pieces (understand actions to
do).

Typically today when i release at work i use release plugin enriched with
github page deployment for the doc using antora + a ftp update of my server
output capture to have a mock backing openapi/swagger ui + docker ilage
deployment on docker hub + an intellij plugin deployment on jetbrains
marketplace etc...adding a flyway migration with a rolling update in a k8s
cluster is trivial (ops need to say yes though ;)).

So technically it is verbose but doable.

Custom lifecycle definition is not neat, custom build tasks require a build
hack or using groovy plugin but it works.

Typically, an extension could enable all that based on convention, just
injecting needed plugins based on the file presence and values of the
distribution urls.

This is why i ended up thinking we are more on 1. Sugar in release plugin
and 2. Maybe on a generic extension cretion (it replaces rigid lifecycle
for such cases these days due to their writing easiness)

Am I missing something?

Le sam. 5 oct. 2019 à 08:23, Marco Schulz <ma...@outlook.com> a
écrit :

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

Re: Proposal: maven release lifecycle

[Romain Manni-Bucau <rm...@gmail.com>]

I like the words but fail to see the missing pieces (understand actions to
do).

Typically today when i release at work i use release plugin enriched with
github page deployment for the doc using antora + a ftp update of my server
output capture to have a mock backing openapi/swagger ui + docker ilage
deployment on docker hub + an intellij plugin deployment on jetbrains
marketplace etc...adding a flyway migration with a rolling update in a k8s
cluster is trivial (ops need to say yes though ;)).

So technically it is verbose but doable.

Custom lifecycle definition is not neat, custom build tasks require a build
hack or using groovy plugin but it works.

Typically, an extension could enable all that based on convention, just
injecting needed plugins based on the file presence and values of the
distribution urls.

This is why i ended up thinking we are more on 1. Sugar in release plugin
and 2. Maybe on a generic extension cretion (it replaces rigid lifecycle
for such cases these days due to their writing easiness)

Am I missing something?

Le sam. 5 oct. 2019 à 08:23, Marco Schulz <ma...@outlook.com> a
écrit :

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

Re: Proposal: maven release lifecycle

[Marco Schulz <ma...@outlook.com>]

Hello Romain, hello Tibor

Thanks for your feedback. I had yesterday a very interesting conversation with
Karl Heinz. He gave me some very informative links about deeply maven insights.
Before I saw his talk on youtube I thought I have a good knowledge about maven
;-)  now I was lerning a lot of new things.

He defined Maven as an plugin execution framework. I like to extend this
definition: Maven is a process engine framework and define industrial defacto
standards for the software development process. And with this idea in mind I
think it could be great to define more workflows in a equal manner like the
build lifecycle. The basic proposal is a first draft and I know some points are
missing. I tried to keep the release process as simple as possible. Two
positions in this definition was impotent for me.

Often companies don't really have well structured release processes. For that
reason I would be great to have a workable standard. I have a small Java project
on GitHub, an sometimes I also deploy to maven central. If you do this the first
time a bit complicated process. And publishing on maven central is also a
release process. So I had the intention to define some ordered steps like in the
build lifecycle to prepare and publish a release.

Let me describe an example scenario for a release: After mvn build was
successful executed all unit tests are passed, the sprint is finished and as
build manager we want to release our artifact. Very important would be an option
to take the results from the build lifecycle and prepare the release. As first
we need to see that the planned artifact version is not exist in any configured
public repository and the pom contains all mandatory information for publishing
on maven central(validate). To secure a reproducible build, in a second step we
enforce that no SNAPSHOT artifacts are involved, the correct maven version is
used etc. (the existing enforcer plugin do a great job). After the preconditions
are fine we can execute external acceptance tests like JGiven. In another step
the JavaDoc got generated. the pgp plugin sing the artifacts and check that the
public key is available. The SCM plugin create a tag for the released revision. 
Difficult parts are auto increment the version number and auto check the scm if
the release is produced with the last revision of the code. This actions are by
my experience a bit error prune.
A release process could have some vocabulary like prepare, perform, deploy. This
are just conventions, like it is used in the build lifecycle. To realize this
idea, many already existing plugins can used, like the release plugin. In this
proposal I was also not mentions external plugins to use like flyway, for
database versioning and so on. A lot of things ar imaginable. 

In future more lifecycles or workflows could be possible. For example a deploy
lifecycle and so on. And then maven transform from a plugin execution framework
to a process management framework, like Jason van Zyl described in his book
better build with maven.

warm regards to all
.marco




On Fri, 2019-10-04 at 11:28 +0200, Romain Manni-Bucau wrote:
> @Tibor: I agree merging both in one "super" command can be neat (I always
> run both at once typically) but I disagree with last parts "skip the test"
> - maven is also there to enforce tests as a good practise, if you don't
> automatically test it you can configure maven to skip tests for the release
> but it is at your own risk, can be fine or not - and "skip the deploy" -
> here again you can configure maven to do it if you need but maven must
> respect the build attached artifact.
> 
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
> 
> 
> Le ven. 4 oct. 2019 à 11:22, Tibor Digana <ti...@apache.org> a écrit :
> 
> > It would be worth to add a new goal called "release" to the
> > maven-release-plugin which merges "prepare" and "perform".
> > We developers in companies use both goals prepare and perform immediately
> > together because for us two goals do not make sense.
> > Two goals make sense for those who can wait days to start manual tests of
> > the TAG but we don't!
> > 
> > We are testing the JAR libraries beforehand and then we evaluate the
> > quality/manual tests with SNAPSHOT whether it makes sense to start the
> > release process in CLI.
> > If there are web archives, the prepare phase would be enough because
> > deployment in Nexus is useless nothing but the TAG itself and Continuous
> > Delivery.
> > 
> > On Fri, Oct 4, 2019 at 8:34 AM Romain Manni-Bucau <rm...@gmail.com>
> > wrote:
> > 
> > > Hi Marco,
> > > 
> > > I have 2 thoughts reading your post:
> > > 
> > > 1. Should be enforced by an extension (sonatype plugin if target is
> > > central?)
> > > 2. It likely misses a few phases compared to maven release plugin which
> > > validates the release can be done (including tests) and runs the tests on
> > > the tag as well
> > > 
> > > Now if 200 lines of xml can be replaced by a single extension I am +1000
> > 
> > on
> > > that track
> > > 
> > > Le ven. 4 oct. 2019 à 08:24, Marco Schulz <ma...@outlook.com> a
> > > écrit :
> > > 
> > > > Hello Maven Dev & Community
> > > > 
> > > > Sine a long time I thought, it would be cool to have a well defined
> > > > process to
> > > > prepare a release of an artifact and deploy it on mvn central. Now I
> > 
> > got
> > > a
> > > > bit
> > > > time to formulate a short proposal of my idea. I published a
> > 
> > description
> > > > of my
> > > > thought on my bolg:
> > > > https://enrebaja.wordpress.com/2019/10/03/next-generation-maven/
> > > > 
> > > > A poll is also created, may to see what other people think about it.
> > > > Please feel
> > > > free to leave also comments, every feedback is welcome.
> > > > 
> > > > warm regards & thanks to the maven dev team for the great job they do.
> > > > .marco (@ElmarDott)
> > > > 
> > > > --
> > > > 
> > > > 
> > 
> > ____________________________________________________________________________
> > ____
> > > >  Dipl. Inf. Marco Schulz (MSc)
> > > > 
> > > >                   Expert for (WEB) Enterprise Applications
> > > >                            - worldwide -
> > > >       + Project Manager + Consultant + Writer + Speaker + Trainer +
> > > > 
> > > > 
> > > > 
> > 
> > [Contact]___________________________________________________________________
> > ____
> > > > 
> > > >    WhatsApp :  +52 (1) 221 200 61 37 :: Mexico
> > > >    Cell     :  +49 (0) 163 69 18 445 :: Germany
> > > >    E-Mail   :  marco.schulz@outlook.com
> > > > 
> > > >    Blog     :  https://enRebaja.wordpress.com
> > > >    twitter  :  https://twitter.com/ElmarDott
> > > >    tumblr   :  https://elmardott.tumblr.com
> > > >    facebook :  https://www.facebook.com/elmar.dott
> > > > 
> > > > 
> > > > 
> > 
> > [Services]__________________________________________________________________
> > ____
> > > > 
> > > >     + Individual software development
> > > >     + Software Project Management
> > > >     + Build-,  Configuration-, & Delivery Management
> > > >     + Release Management
> > > >     + Business Analysis
> > > >     + Software Architecture
> > > >     + Process Automation
> > > > 
> > > > 
> > 
> > ____________________________________________________________________________
> > ____
> > > > This message is intended only for the use of the individual or entity
> > 
> > to
> > > > which
> > > > it is addressed, and may contain information that is privileged,
> > > > confidential
> > > > and that may not be made public by law or agreement. If you are not the
> > > > intended
> > > > recipient or entity, you are hereby notified that any further
> > > > dissemination,
> > > > distribution or copying of this information is strictly prohibited.
> > > > If you have received this communication in error, please contact us
> > > > immediately
> > > > and delete the message from your system.
> > > > 
> > > > 

Re: Proposal: maven release lifecycle

[Marco Schulz <ma...@outlook.com>]

Hello Romain, hello Tibor

Thanks for your feedback. I had yesterday a very interesting conversation with
Karl Heinz. He gave me some very informative links about deeply maven insights.
Before I saw his talk on youtube I thought I have a good knowledge about maven
;-)  now I was lerning a lot of new things.

He defined Maven as an plugin execution framework. I like to extend this
definition: Maven is a process engine framework and define industrial defacto
standards for the software development process. And with this idea in mind I
think it could be great to define more workflows in a equal manner like the
build lifecycle. The basic proposal is a first draft and I know some points are
missing. I tried to keep the release process as simple as possible. Two
positions in this definition was impotent for me.

Often companies don't really have well structured release processes. For that
reason I would be great to have a workable standard. I have a small Java project
on GitHub, an sometimes I also deploy to maven central. If you do this the first
time a bit complicated process. And publishing on maven central is also a
release process. So I had the intention to define some ordered steps like in the
build lifecycle to prepare and publish a release.

Let me describe an example scenario for a release: After mvn build was
successful executed all unit tests are passed, the sprint is finished and as
build manager we want to release our artifact. Very important would be an option
to take the results from the build lifecycle and prepare the release. As first
we need to see that the planned artifact version is not exist in any configured
public repository and the pom contains all mandatory information for publishing
on maven central(validate). To secure a reproducible build, in a second step we
enforce that no SNAPSHOT artifacts are involved, the correct maven version is
used etc. (the existing enforcer plugin do a great job). After the preconditions
are fine we can execute external acceptance tests like JGiven. In another step
the JavaDoc got generated. the pgp plugin sing the artifacts and check that the
public key is available. The SCM plugin create a tag for the released revision. 
Difficult parts are auto increment the version number and auto check the scm if
the release is produced with the last revision of the code. This actions are by
my experience a bit error prune.
A release process could have some vocabulary like prepare, perform, deploy. This
are just conventions, like it is used in the build lifecycle. To realize this
idea, many already existing plugins can used, like the release plugin. In this
proposal I was also not mentions external plugins to use like flyway, for
database versioning and so on. A lot of things ar imaginable. 

In future more lifecycles or workflows could be possible. For example a deploy
lifecycle and so on. And then maven transform from a plugin execution framework
to a process management framework, like Jason van Zyl described in his book
better build with maven.

warm regards to all
.marco




On Fri, 2019-10-04 at 11:28 +0200, Romain Manni-Bucau wrote:
> @Tibor: I agree merging both in one "super" command can be neat (I always
> run both at once typically) but I disagree with last parts "skip the test"
> - maven is also there to enforce tests as a good practise, if you don't
> automatically test it you can configure maven to skip tests for the release
> but it is at your own risk, can be fine or not - and "skip the deploy" -
> here again you can configure maven to do it if you need but maven must
> respect the build attached artifact.
> 
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
> 
> 
> Le ven. 4 oct. 2019 à 11:22, Tibor Digana <ti...@apache.org> a écrit :
> 
> > It would be worth to add a new goal called "release" to the
> > maven-release-plugin which merges "prepare" and "perform".
> > We developers in companies use both goals prepare and perform immediately
> > together because for us two goals do not make sense.
> > Two goals make sense for those who can wait days to start manual tests of
> > the TAG but we don't!
> > 
> > We are testing the JAR libraries beforehand and then we evaluate the
> > quality/manual tests with SNAPSHOT whether it makes sense to start the
> > release process in CLI.
> > If there are web archives, the prepare phase would be enough because
> > deployment in Nexus is useless nothing but the TAG itself and Continuous
> > Delivery.
> > 
> > On Fri, Oct 4, 2019 at 8:34 AM Romain Manni-Bucau <rm...@gmail.com>
> > wrote:
> > 
> > > Hi Marco,
> > > 
> > > I have 2 thoughts reading your post:
> > > 
> > > 1. Should be enforced by an extension (sonatype plugin if target is
> > > central?)
> > > 2. It likely misses a few phases compared to maven release plugin which
> > > validates the release can be done (including tests) and runs the tests on
> > > the tag as well
> > > 
> > > Now if 200 lines of xml can be replaced by a single extension I am +1000
> > 
> > on
> > > that track
> > > 
> > > Le ven. 4 oct. 2019 à 08:24, Marco Schulz <ma...@outlook.com> a
> > > écrit :
> > > 
> > > > Hello Maven Dev & Community
> > > > 
> > > > Sine a long time I thought, it would be cool to have a well defined
> > > > process to
> > > > prepare a release of an artifact and deploy it on mvn central. Now I
> > 
> > got
> > > a
> > > > bit
> > > > time to formulate a short proposal of my idea. I published a
> > 
> > description
> > > > of my
> > > > thought on my bolg:
> > > > https://enrebaja.wordpress.com/2019/10/03/next-generation-maven/
> > > > 
> > > > A poll is also created, may to see what other people think about it.
> > > > Please feel
> > > > free to leave also comments, every feedback is welcome.
> > > > 
> > > > warm regards & thanks to the maven dev team for the great job they do.
> > > > .marco (@ElmarDott)
> > > > 
> > > > --
> > > > 
> > > > 
> > 
> > ____________________________________________________________________________
> > ____
> > > >  Dipl. Inf. Marco Schulz (MSc)
> > > > 
> > > >                   Expert for (WEB) Enterprise Applications
> > > >                            - worldwide -
> > > >       + Project Manager + Consultant + Writer + Speaker + Trainer +
> > > > 
> > > > 
> > > > 
> > 
> > [Contact]___________________________________________________________________
> > ____
> > > > 
> > > >    WhatsApp :  +52 (1) 221 200 61 37 :: Mexico
> > > >    Cell     :  +49 (0) 163 69 18 445 :: Germany
> > > >    E-Mail   :  marco.schulz@outlook.com
> > > > 
> > > >    Blog     :  https://enRebaja.wordpress.com
> > > >    twitter  :  https://twitter.com/ElmarDott
> > > >    tumblr   :  https://elmardott.tumblr.com
> > > >    facebook :  https://www.facebook.com/elmar.dott
> > > > 
> > > > 
> > > > 
> > 
> > [Services]__________________________________________________________________
> > ____
> > > > 
> > > >     + Individual software development
> > > >     + Software Project Management
> > > >     + Build-,  Configuration-, & Delivery Management
> > > >     + Release Management
> > > >     + Business Analysis
> > > >     + Software Architecture
> > > >     + Process Automation
> > > > 
> > > > 
> > 
> > ____________________________________________________________________________
> > ____
> > > > This message is intended only for the use of the individual or entity
> > 
> > to
> > > > which
> > > > it is addressed, and may contain information that is privileged,
> > > > confidential
> > > > and that may not be made public by law or agreement. If you are not the
> > > > intended
> > > > recipient or entity, you are hereby notified that any further
> > > > dissemination,
> > > > distribution or copying of this information is strictly prohibited.
> > > > If you have received this communication in error, please contact us
> > > > immediately
> > > > and delete the message from your system.
> > > > 
> > > > 

Re: Proposal: maven release lifecycle

[Romain Manni-Bucau <rm...@gmail.com>]

@Tibor: I agree merging both in one "super" command can be neat (I always
run both at once typically) but I disagree with last parts "skip the test"
- maven is also there to enforce tests as a good practise, if you don't
automatically test it you can configure maven to skip tests for the release
but it is at your own risk, can be fine or not - and "skip the deploy" -
here again you can configure maven to do it if you need but maven must
respect the build attached artifact.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le ven. 4 oct. 2019 à 11:22, Tibor Digana <ti...@apache.org> a écrit :

> It would be worth to add a new goal called "release" to the
> maven-release-plugin which merges "prepare" and "perform".
> We developers in companies use both goals prepare and perform immediately
> together because for us two goals do not make sense.
> Two goals make sense for those who can wait days to start manual tests of
> the TAG but we don't!
>
> We are testing the JAR libraries beforehand and then we evaluate the
> quality/manual tests with SNAPSHOT whether it makes sense to start the
> release process in CLI.
> If there are web archives, the prepare phase would be enough because
> deployment in Nexus is useless nothing but the TAG itself and Continuous
> Delivery.
>
> On Fri, Oct 4, 2019 at 8:34 AM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > Hi Marco,
> >
> > I have 2 thoughts reading your post:
> >
> > 1. Should be enforced by an extension (sonatype plugin if target is
> > central?)
> > 2. It likely misses a few phases compared to maven release plugin which
> > validates the release can be done (including tests) and runs the tests on
> > the tag as well
> >
> > Now if 200 lines of xml can be replaced by a single extension I am +1000
> on
> > that track
> >
> > Le ven. 4 oct. 2019 à 08:24, Marco Schulz <ma...@outlook.com> a
> > écrit :
> >
> > > Hello Maven Dev & Community
> > >
> > > Sine a long time I thought, it would be cool to have a well defined
> > > process to
> > > prepare a release of an artifact and deploy it on mvn central. Now I
> got
> > a
> > > bit
> > > time to formulate a short proposal of my idea. I published a
> description
> > > of my
> > > thought on my bolg:
> > > https://enrebaja.wordpress.com/2019/10/03/next-generation-maven/
> > >
> > > A poll is also created, may to see what other people think about it.
> > > Please feel
> > > free to leave also comments, every feedback is welcome.
> > >
> > > warm regards & thanks to the maven dev team for the great job they do.
> > > .marco (@ElmarDott)
> > >
> > > --
> > >
> > >
> >
> ________________________________________________________________________________
> > >  Dipl. Inf. Marco Schulz (MSc)
> > >
> > >                   Expert for (WEB) Enterprise Applications
> > >                            - worldwide -
> > >       + Project Manager + Consultant + Writer + Speaker + Trainer +
> > >
> > >
> > >
> >
> [Contact]_______________________________________________________________________
> > >
> > >    WhatsApp :  +52 (1) 221 200 61 37 :: Mexico
> > >    Cell     :  +49 (0) 163 69 18 445 :: Germany
> > >    E-Mail   :  marco.schulz@outlook.com
> > >
> > >    Blog     :  https://enRebaja.wordpress.com
> > >    twitter  :  https://twitter.com/ElmarDott
> > >    tumblr   :  https://elmardott.tumblr.com
> > >    facebook :  https://www.facebook.com/elmar.dott
> > >
> > >
> > >
> >
> [Services]______________________________________________________________________
> > >
> > >     + Individual software development
> > >     + Software Project Management
> > >     + Build-,  Configuration-, & Delivery Management
> > >     + Release Management
> > >     + Business Analysis
> > >     + Software Architecture
> > >     + Process Automation
> > >
> > >
> >
> ________________________________________________________________________________
> > > This message is intended only for the use of the individual or entity
> to
> > > which
> > > it is addressed, and may contain information that is privileged,
> > > confidential
> > > and that may not be made public by law or agreement. If you are not the
> > > intended
> > > recipient or entity, you are hereby notified that any further
> > > dissemination,
> > > distribution or copying of this information is strictly prohibited.
> > > If you have received this communication in error, please contact us
> > > immediately
> > > and delete the message from your system.
> > >
> > >
> >
>

Re: Proposal: maven release lifecycle

[Romain Manni-Bucau <rm...@gmail.com>]

@Tibor: I agree merging both in one "super" command can be neat (I always
run both at once typically) but I disagree with last parts "skip the test"
- maven is also there to enforce tests as a good practise, if you don't
automatically test it you can configure maven to skip tests for the release
but it is at your own risk, can be fine or not - and "skip the deploy" -
here again you can configure maven to do it if you need but maven must
respect the build attached artifact.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le ven. 4 oct. 2019 à 11:22, Tibor Digana <ti...@apache.org> a écrit :

> It would be worth to add a new goal called "release" to the
> maven-release-plugin which merges "prepare" and "perform".
> We developers in companies use both goals prepare and perform immediately
> together because for us two goals do not make sense.
> Two goals make sense for those who can wait days to start manual tests of
> the TAG but we don't!
>
> We are testing the JAR libraries beforehand and then we evaluate the
> quality/manual tests with SNAPSHOT whether it makes sense to start the
> release process in CLI.
> If there are web archives, the prepare phase would be enough because
> deployment in Nexus is useless nothing but the TAG itself and Continuous
> Delivery.
>
> On Fri, Oct 4, 2019 at 8:34 AM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > Hi Marco,
> >
> > I have 2 thoughts reading your post:
> >
> > 1. Should be enforced by an extension (sonatype plugin if target is
> > central?)
> > 2. It likely misses a few phases compared to maven release plugin which
> > validates the release can be done (including tests) and runs the tests on
> > the tag as well
> >
> > Now if 200 lines of xml can be replaced by a single extension I am +1000
> on
> > that track
> >
> > Le ven. 4 oct. 2019 à 08:24, Marco Schulz <ma...@outlook.com> a
> > écrit :
> >
> > > Hello Maven Dev & Community
> > >
> > > Sine a long time I thought, it would be cool to have a well defined
> > > process to
> > > prepare a release of an artifact and deploy it on mvn central. Now I
> got
> > a
> > > bit
> > > time to formulate a short proposal of my idea. I published a
> description
> > > of my
> > > thought on my bolg:
> > > https://enrebaja.wordpress.com/2019/10/03/next-generation-maven/
> > >
> > > A poll is also created, may to see what other people think about it.
> > > Please feel
> > > free to leave also comments, every feedback is welcome.
> > >
> > > warm regards & thanks to the maven dev team for the great job they do.
> > > .marco (@ElmarDott)
> > >
> > > --
> > >
> > >
> >
> ________________________________________________________________________________
> > >  Dipl. Inf. Marco Schulz (MSc)
> > >
> > >                   Expert for (WEB) Enterprise Applications
> > >                            - worldwide -
> > >       + Project Manager + Consultant + Writer + Speaker + Trainer +
> > >
> > >
> > >
> >
> [Contact]_______________________________________________________________________
> > >
> > >    WhatsApp :  +52 (1) 221 200 61 37 :: Mexico
> > >    Cell     :  +49 (0) 163 69 18 445 :: Germany
> > >    E-Mail   :  marco.schulz@outlook.com
> > >
> > >    Blog     :  https://enRebaja.wordpress.com
> > >    twitter  :  https://twitter.com/ElmarDott
> > >    tumblr   :  https://elmardott.tumblr.com
> > >    facebook :  https://www.facebook.com/elmar.dott
> > >
> > >
> > >
> >
> [Services]______________________________________________________________________
> > >
> > >     + Individual software development
> > >     + Software Project Management
> > >     + Build-,  Configuration-, & Delivery Management
> > >     + Release Management
> > >     + Business Analysis
> > >     + Software Architecture
> > >     + Process Automation
> > >
> > >
> >
> ________________________________________________________________________________
> > > This message is intended only for the use of the individual or entity
> to
> > > which
> > > it is addressed, and may contain information that is privileged,
> > > confidential
> > > and that may not be made public by law or agreement. If you are not the
> > > intended
> > > recipient or entity, you are hereby notified that any further
> > > dissemination,
> > > distribution or copying of this information is strictly prohibited.
> > > If you have received this communication in error, please contact us
> > > immediately
> > > and delete the message from your system.
> > >
> > >
> >
>

Re: Proposal: maven release lifecycle

[Tibor Digana <ti...@apache.org>]

It would be worth to add a new goal called "release" to the
maven-release-plugin which merges "prepare" and "perform".
We developers in companies use both goals prepare and perform immediately
together because for us two goals do not make sense.
Two goals make sense for those who can wait days to start manual tests of
the TAG but we don't!

We are testing the JAR libraries beforehand and then we evaluate the
quality/manual tests with SNAPSHOT whether it makes sense to start the
release process in CLI.
If there are web archives, the prepare phase would be enough because
deployment in Nexus is useless nothing but the TAG itself and Continuous
Delivery.

On Fri, Oct 4, 2019 at 8:34 AM Romain Manni-Bucau <rm...@gmail.com>
wrote:

> Hi Marco,
>
> I have 2 thoughts reading your post:
>
> 1. Should be enforced by an extension (sonatype plugin if target is
> central?)
> 2. It likely misses a few phases compared to maven release plugin which
> validates the release can be done (including tests) and runs the tests on
> the tag as well
>
> Now if 200 lines of xml can be replaced by a single extension I am +1000 on
> that track
>
> Le ven. 4 oct. 2019 à 08:24, Marco Schulz <ma...@outlook.com> a
> écrit :
>
> > Hello Maven Dev & Community
> >
> > Sine a long time I thought, it would be cool to have a well defined
> > process to
> > prepare a release of an artifact and deploy it on mvn central. Now I got
> a
> > bit
> > time to formulate a short proposal of my idea. I published a description
> > of my
> > thought on my bolg:
> > https://enrebaja.wordpress.com/2019/10/03/next-generation-maven/
> >
> > A poll is also created, may to see what other people think about it.
> > Please feel
> > free to leave also comments, every feedback is welcome.
> >
> > warm regards & thanks to the maven dev team for the great job they do.
> > .marco (@ElmarDott)
> >
> > --
> >
> >
> ________________________________________________________________________________
> >  Dipl. Inf. Marco Schulz (MSc)
> >
> >                   Expert for (WEB) Enterprise Applications
> >                            - worldwide -
> >       + Project Manager + Consultant + Writer + Speaker + Trainer +
> >
> >
> >
> [Contact]_______________________________________________________________________
> >
> >    WhatsApp :  +52 (1) 221 200 61 37 :: Mexico
> >    Cell     :  +49 (0) 163 69 18 445 :: Germany
> >    E-Mail   :  marco.schulz@outlook.com
> >
> >    Blog     :  https://enRebaja.wordpress.com
> >    twitter  :  https://twitter.com/ElmarDott
> >    tumblr   :  https://elmardott.tumblr.com
> >    facebook :  https://www.facebook.com/elmar.dott
> >
> >
> >
> [Services]______________________________________________________________________
> >
> >     + Individual software development
> >     + Software Project Management
> >     + Build-,  Configuration-, & Delivery Management
> >     + Release Management
> >     + Business Analysis
> >     + Software Architecture
> >     + Process Automation
> >
> >
> ________________________________________________________________________________
> > This message is intended only for the use of the individual or entity to
> > which
> > it is addressed, and may contain information that is privileged,
> > confidential
> > and that may not be made public by law or agreement. If you are not the
> > intended
> > recipient or entity, you are hereby notified that any further
> > dissemination,
> > distribution or copying of this information is strictly prohibited.
> > If you have received this communication in error, please contact us
> > immediately
> > and delete the message from your system.
> >
> >
>

Re: Proposal: maven release lifecycle

[Tibor Digana <ti...@apache.org>]

It would be worth to add a new goal called "release" to the
maven-release-plugin which merges "prepare" and "perform".
We developers in companies use both goals prepare and perform immediately
together because for us two goals do not make sense.
Two goals make sense for those who can wait days to start manual tests of
the TAG but we don't!

We are testing the JAR libraries beforehand and then we evaluate the
quality/manual tests with SNAPSHOT whether it makes sense to start the
release process in CLI.
If there are web archives, the prepare phase would be enough because
deployment in Nexus is useless nothing but the TAG itself and Continuous
Delivery.

On Fri, Oct 4, 2019 at 8:34 AM Romain Manni-Bucau <rm...@gmail.com>
wrote:

> Hi Marco,
>
> I have 2 thoughts reading your post:
>
> 1. Should be enforced by an extension (sonatype plugin if target is
> central?)
> 2. It likely misses a few phases compared to maven release plugin which
> validates the release can be done (including tests) and runs the tests on
> the tag as well
>
> Now if 200 lines of xml can be replaced by a single extension I am +1000 on
> that track
>
> Le ven. 4 oct. 2019 à 08:24, Marco Schulz <ma...@outlook.com> a
> écrit :
>
> > Hello Maven Dev & Community
> >
> > Sine a long time I thought, it would be cool to have a well defined
> > process to
> > prepare a release of an artifact and deploy it on mvn central. Now I got
> a
> > bit
> > time to formulate a short proposal of my idea. I published a description
> > of my
> > thought on my bolg:
> > https://enrebaja.wordpress.com/2019/10/03/next-generation-maven/
> >
> > A poll is also created, may to see what other people think about it.
> > Please feel
> > free to leave also comments, every feedback is welcome.
> >
> > warm regards & thanks to the maven dev team for the great job they do.
> > .marco (@ElmarDott)
> >
> > --
> >
> >
> ________________________________________________________________________________
> >  Dipl. Inf. Marco Schulz (MSc)
> >
> >                   Expert for (WEB) Enterprise Applications
> >                            - worldwide -
> >       + Project Manager + Consultant + Writer + Speaker + Trainer +
> >
> >
> >
> [Contact]_______________________________________________________________________
> >
> >    WhatsApp :  +52 (1) 221 200 61 37 :: Mexico
> >    Cell     :  +49 (0) 163 69 18 445 :: Germany
> >    E-Mail   :  marco.schulz@outlook.com
> >
> >    Blog     :  https://enRebaja.wordpress.com
> >    twitter  :  https://twitter.com/ElmarDott
> >    tumblr   :  https://elmardott.tumblr.com
> >    facebook :  https://www.facebook.com/elmar.dott
> >
> >
> >
> [Services]______________________________________________________________________
> >
> >     + Individual software development
> >     + Software Project Management
> >     + Build-,  Configuration-, & Delivery Management
> >     + Release Management
> >     + Business Analysis
> >     + Software Architecture
> >     + Process Automation
> >
> >
> ________________________________________________________________________________
> > This message is intended only for the use of the individual or entity to
> > which
> > it is addressed, and may contain information that is privileged,
> > confidential
> > and that may not be made public by law or agreement. If you are not the
> > intended
> > recipient or entity, you are hereby notified that any further
> > dissemination,
> > distribution or copying of this information is strictly prohibited.
> > If you have received this communication in error, please contact us
> > immediately
> > and delete the message from your system.
> >
> >
>

Re: Proposal: maven release lifecycle

[Romain Manni-Bucau <rm...@gmail.com>]

Hi Marco,

I have 2 thoughts reading your post:

1. Should be enforced by an extension (sonatype plugin if target is
central?)
2. It likely misses a few phases compared to maven release plugin which
validates the release can be done (including tests) and runs the tests on
the tag as well

Now if 200 lines of xml can be replaced by a single extension I am +1000 on
that track

Le ven. 4 oct. 2019 à 08:24, Marco Schulz <ma...@outlook.com> a
écrit :

> Hello Maven Dev & Community
>
> Sine a long time I thought, it would be cool to have a well defined
> process to
> prepare a release of an artifact and deploy it on mvn central. Now I got a
> bit
> time to formulate a short proposal of my idea. I published a description
> of my
> thought on my bolg:
> https://enrebaja.wordpress.com/2019/10/03/next-generation-maven/
>
> A poll is also created, may to see what other people think about it.
> Please feel
> free to leave also comments, every feedback is welcome.
>
> warm regards & thanks to the maven dev team for the great job they do.
> .marco (@ElmarDott)
>
> --
>
> ________________________________________________________________________________
>  Dipl. Inf. Marco Schulz (MSc)
>
>                   Expert for (WEB) Enterprise Applications
>                            - worldwide -
>       + Project Manager + Consultant + Writer + Speaker + Trainer +
>
>
> [Contact]_______________________________________________________________________
>
>    WhatsApp :  +52 (1) 221 200 61 37 :: Mexico
>    Cell     :  +49 (0) 163 69 18 445 :: Germany
>    E-Mail   :  marco.schulz@outlook.com
>
>    Blog     :  https://enRebaja.wordpress.com
>    twitter  :  https://twitter.com/ElmarDott
>    tumblr   :  https://elmardott.tumblr.com
>    facebook :  https://www.facebook.com/elmar.dott
>
>
> [Services]______________________________________________________________________
>
>     + Individual software development
>     + Software Project Management
>     + Build-,  Configuration-, & Delivery Management
>     + Release Management
>     + Business Analysis
>     + Software Architecture
>     + Process Automation
>
> ________________________________________________________________________________
> This message is intended only for the use of the individual or entity to
> which
> it is addressed, and may contain information that is privileged,
> confidential
> and that may not be made public by law or agreement. If you are not the
> intended
> recipient or entity, you are hereby notified that any further
> dissemination,
> distribution or copying of this information is strictly prohibited.
> If you have received this communication in error, please contact us
> immediately
> and delete the message from your system.
>
>

Re: Proposal: maven release lifecycle

[Karl Heinz Marbaise <kh...@gmx.de>]

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

Re: Proposal: maven release lifecycle

[Karl Heinz Marbaise <kh...@gmx.de>]

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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Proposal: maven release lifecycle

[Romain Manni-Bucau <rm...@gmail.com>]

Hi Marco,

I have 2 thoughts reading your post:

1. Should be enforced by an extension (sonatype plugin if target is
central?)
2. It likely misses a few phases compared to maven release plugin which
validates the release can be done (including tests) and runs the tests on
the tag as well

Now if 200 lines of xml can be replaced by a single extension I am +1000 on
that track

Le ven. 4 oct. 2019 à 08:24, Marco Schulz <ma...@outlook.com> a
écrit :

> Hello Maven Dev & Community
>
> Sine a long time I thought, it would be cool to have a well defined
> process to
> prepare a release of an artifact and deploy it on mvn central. Now I got a
> bit
> time to formulate a short proposal of my idea. I published a description
> of my
> thought on my bolg:
> https://enrebaja.wordpress.com/2019/10/03/next-generation-maven/
>
> A poll is also created, may to see what other people think about it.
> Please feel
> free to leave also comments, every feedback is welcome.
>
> warm regards & thanks to the maven dev team for the great job they do.
> .marco (@ElmarDott)
>
> --
>
> ________________________________________________________________________________
>  Dipl. Inf. Marco Schulz (MSc)
>
>                   Expert for (WEB) Enterprise Applications
>                            - worldwide -
>       + Project Manager + Consultant + Writer + Speaker + Trainer +
>
>
> [Contact]_______________________________________________________________________
>
>    WhatsApp :  +52 (1) 221 200 61 37 :: Mexico
>    Cell     :  +49 (0) 163 69 18 445 :: Germany
>    E-Mail   :  marco.schulz@outlook.com
>
>    Blog     :  https://enRebaja.wordpress.com
>    twitter  :  https://twitter.com/ElmarDott
>    tumblr   :  https://elmardott.tumblr.com
>    facebook :  https://www.facebook.com/elmar.dott
>
>
> [Services]______________________________________________________________________
>
>     + Individual software development
>     + Software Project Management
>     + Build-,  Configuration-, & Delivery Management
>     + Release Management
>     + Business Analysis
>     + Software Architecture
>     + Process Automation
>
> ________________________________________________________________________________
> This message is intended only for the use of the individual or entity to
> which
> it is addressed, and may contain information that is privileged,
> confidential
> and that may not be made public by law or agreement. If you are not the
> intended
> recipient or entity, you are hereby notified that any further
> dissemination,
> distribution or copying of this information is strictly prohibited.
> If you have received this communication in error, please contact us
> immediately
> and delete the message from your system.
>
>

Proposal: maven release lifecycle

[Marco Schulz <ma...@outlook.com>]

Hello Maven Dev & Community

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

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

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

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

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

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

[Services]______________________________________________________________________

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

Re: [DISCUSS] Maven 3.7.0

[Karl Heinz Marbaise <kh...@gmx.de>]

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 <pa...@hammant.org> 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 <el...@ibiblio.org>
>> 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 <rf...@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>

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

Re: [DISCUSS] Maven 3.7.0

[Romain Manni-Bucau <rm...@gmail.com>]

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

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mar. 29 oct. 2019 à 09:02, Tibor Digana <ti...@apache.org> a
écrit :

> Robert, I saw the code. The class has a method which returns Lambda
> function. The whole class was designed with OOP. The OOP is a good thing
> which you should follow and follow this approach and not to return the
> labda function. Basically it is a precedense created in the PR saying that
> now J8 has to be used in the bytecode.
> So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
>
> On Tue, Oct 29, 2019 at 8:25 AM Robert Scholte <rf...@apache.org>
> wrote:
>
> > The outcome is quite clear to me. There no clear 'No' to add this
> > build/consumer feature into 3.7.0, so we'll add it which implies we must
> > move to Java 8 due to new APIs with Java 8 class signatures.
> >
> > But first we need to deliver a 3.6.3 regression release.
> >
> > Robert
> >
> > On 29-10-2019 05:53:25, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
> > +1, the risk is more or less 0 since we can still use branches for
> > potential fixes for "old" projects using frozen java and maven versions
> > anyway
> >
> > Guess we can even be very precautionous doing 1. an upgrade to bytecode
> > version without any code change (to change the major version in
> bytecode),
> > 2. a M1 to let users test it if some still doubt.
> >
> > Le mar. 29 oct. 2019 à 04:06, Olivier Lamy a écrit :
> >
> > > so what is the status of this?
> > > will we discuss in 2025 about being able to use java 8 apis or do we
> have
> > > to wait 2030?
> > > Sorry to be sarcastic but not moving forward it's certainly a reason
> why
> > we
> > > do not have more people participating in the project....
> > > It is so frustrating to be stuck with old apis...
> > >
> > >
> > >
> > > On Thu, 10 Oct 2019 at 04:36, Tibor Digana wrote:
> > >
> > > > I have to fully agree on Michael Osipov. This discussion is
> > > > contraproductive from the time perspective.
> > > > He explained the situation in Maven very clearly that we have over
> 1800
> > > > bugs and here we are talking about javac compiler version which does
> > not
> > > > fix these bugs.
> > > > We know that our community is quite big but we also know that we have
> > > only
> > > > few several developers who regularily provides fixes for the bug and
> > they
> > > > do it for free!
> > > > So my advice is to leave these talks alone about technology lobby
> (seen
> > > on
> > > > ML from outside as well) and rather concentrate on the bug. We have
> > seen
> > > > that the users/contributors handled performance issues and fixed them
> > > which
> > > > means that these contributors got very good proficiency level!
> > > >
> > > > On Wed, Oct 9, 2019 at 7:56 PM Alexander Ashitkin <>
> > > ashitkin.alex@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > Totally disagree on the point. Writing java7 code after 8 makes you
> > > feel
> > > > > suffering - because instead of expressive stream based operations
> and
> > > > > lambdas you write pointless iterators and copy collections.
> > > > > It is purely subjective opinion that lambdas make code less
> readable
> > -
> > > at
> > > > > least there is an absolutely opposite opinion
> > > > >
> > > > > Thank you
> > > > > Aleks
> > > > >
> > > > > On 2019/10/03 12:47:35, Paul Hammant wrote:
> > > > > > Who codes for 18 months before discovering that qa/prod are not
> > > > > compatible,
> > > > > > anymore? Especially if Google ship a use-this-Pom starter.
> > > > > >
> > > > > > On Thu, Oct 3, 2019 at 1:44 PM Elliotte Rusty Harold <>
> > > > elharo@ibiblio.org
> > > > > >
> > > > > > 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 <>
> > > > > elharo@ibiblio.org
> > > > > > > >
> > > > > > > > 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 <>
> > > > > rfscholte@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-unsubscribe@maven.apache.org
> > > > > > > > > > For additional commands, e-mail:
> dev-help@maven.apache.org
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Elliotte Rusty Harold
> > > > > > > > > elharo@ibiblio.org
> > > > > > > > >
> > > > > > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Elliotte Rusty Harold
> > > > > > > elharo@ibiblio.org
> > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Olivier Lamy
> > > http://twitter.com/olamy | http://linkedin.com/in/olamy
> > >
> >
>

Re: Re: Re: [DISCUSS] Maven 3.7.0

[Michael Osipov <19...@gmx.net>]

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

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

Michael

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

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

Re: Re: [DISCUSS] Maven 3.7.0

[Romain Manni-Bucau <rm...@gmail.com>]

Le mar. 29 oct. 2019 à 14:24, Enrico Olivelli <eo...@gmail.com> a
écrit :

> Il giorno mar 29 ott 2019 alle ore 14:22 Stephen Connolly <
> stephen.alan.connolly@gmail.com> ha scritto:
>
> > Because maintaining Java 7 is a barrier to new contributors. It is tricky
> > enough to get Java 8 set up for some developers. Every version we support
> > adds complexity for contributors. Personally, I think we should be
> thinking
> > about dropping even Java 8 if we wait until next year and just follow the
> > latest LTS line... but I am happy to keep with Java 8 as a baseline for
> > now. Java 7 is only supported for a limited number of environments right
> > now, whereas Java 8 has multiple vendors supporting it against multiple
> > platforms at least until mid 2023.
> >
> > We hold back the entire community if we stick on a base version for too
> > long.
> >
>
> totally true !
>
> We should only move to "target/source" 8, we do not need to change the code
> (lamdas), we can do it whenever we want
>


+1

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


>
> Enrico
>
>
>
> >
> > On Tue, 29 Oct 2019 at 13:00, Michael Osipov <19...@gmx.net> wrote:
> >
> > > Why not have 3.7.0 plugin updates and other non-technical stuff, have
> it
> > > parallely maintained for some time and move with Maven 3.8.0 to Java 8
> > > next year?!
> > >
> > > Does that sound like a plan? I'd be happy with that. I'd also expect
> > > an announcement on dev@, announce@ and users@.
> > >
> > > Michael
> > >
> > > > Gesendet: Dienstag, 29. Oktober 2019 um 13:49 Uhr
> > > > Von: "Stephen Connolly" <st...@gmail.com>
> > > > An: "Maven Developers List" <de...@maven.apache.org>
> > > > Betreff: Re: [DISCUSS] Maven 3.7.0
> > > >
> > > > On Tue, 29 Oct 2019 at 12:47, Stephen Connolly <
> > > > stephen.alan.connolly@gmail.com> wrote:
> > > >
> > > > > We already have a version policy:
> > > > >
> > >
> https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy
> > > > >
> > > >
> > > > (while that page says draft, the proposal was on-list in 2014 and
> just
> > > > converted into a wiki page afterwards - hence why the examples use
> 2014
> > > > dates)
> > > >
> > > >
> > > > > > The development line of Maven core should require a minimum JRE
> > > version
> > > > > that is no older than 18 months after the end of Oracle's public
> > > updates
> > > > > for that JRE version at the time that the first version of the
> > > development
> > > > > line was released, but may require a higher minimum JRE version if
> > > other
> > > > > requirements dictate a higher JRE version.
> > > > >
> > > > > End of public updates for Java 8 from Oracle was January 2019, thus
> > if
> > > we
> > > > > cut a new minor version we would be Java 8 but not Java 7.
> > > > >
> > > > >
> > > > > On Tue, 29 Oct 2019 at 12:28, Tibor Digana <tibordigana@apache.org
> >
> > > wrote:
> > > > >
> > > > >> Stephen, we are in loop.
> > > > >> Of course I know these technical things.
> > > > >> But I am saying, and I am not alone (Michael Osipov too), that I
> > agree
> > > > >> with
> > > > >> sources 1.8, but there must be1.  the Vote with milestones
> regarding
> > > Maven
> > > > >> and another Vote regarding plugins, and 2. written list of
> pros/cons
> > > > >> regarding J8 and 3. developer guideline for J8 (for devs,
> > consultants,
> > > > >> another professions as well in the team).
> > > > >> You know, with video calls, all these public emails would be gone
> > > within
> > > > >> one or two hours, I am sure!
> > > > >> I am also sure that we will have another code preferences and
> > > therefore we
> > > > >> should have some guideline. For instance, I like to have clear OOP
> > in
> > > the
> > > > >> public class/interfaces and Lambda in private code. And there are
> a
> > > lot of
> > > > >> stuff, like parallel streams ala thread pool of non-daemon
> threads,
> > > > >> performance of streams (when, how stream is constructed, etc),
> Date
> > > Time
> > > > >> API is new as well.
> > > > >>
> > > > >> No benefit for the community with J7 sources but yes with J8 code.
> > > Believe
> > > > >> me, this is true. Michael mentioned that as well.
> > > > >>
> > > > >
> > > > > Not true. Java 8 bytecode adds additional metadata that speeds up
> > > > > classloading (but only when the class graph is all Java 8)
> > > > >
> > > > >
> > > > >>
> > > > >> It is also true that we have a lot of bugs, and it is true that
> > Maven
> > > > >> needs
> > > > >> to have breakthrough features like reproducible build and User
> POM,
> > > Docker
> > > > >> prefetched cache, etc.
> > > > >> I have no argument against these things. The only problem that I
> > have
> > > and
> > > > >> Michael has is the way how this is managed but it is the only
> > trivial
> > > > >> problem that we can solve between us.
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> On Tue, Oct 29, 2019 at 1:04 PM Stephen Connolly <
> > > > >> stephen.alan.connolly@gmail.com> wrote:
> > > > >>
> > > > >> > You cannot have Java 8 sources produce Java 7 bytecode with the
> > > Java 8's
> > > > >> > javac.
> > > > >> >
> > > > >> > -target must be >= -source
> > > > >> >
> > > > >> > So to say:
> > > > >> >
> > > > >> > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source
> code!
> > > > >> >
> > > > >> > Is not possible, you'll get something like:
> > > > >> >
> > > > >> > $ javac Test -source 1.8 -target 1.7
> > > > >> > javac: source release 1.8 requires target release 1.8
> > > > >> >
> > > > >> > While we could use something like
> > > > >> https://github.com/luontola/retrolambda
> > > > >> > its usage is not without significant risks. You really need to
> be
> > > very
> > > > >> > careful in how you use it, and the effort is IMHO far exceeding
> > the
> > > > >> risk.
> > > > >> > Much better to just say Maven 3.7.0 is requires the runtime JVM
> be
> > > Java
> > > > >> 8+,
> > > > >> > use toolchains if you need to compile or unit tests with older
> > JDKs.
> > > > >> >
> > > > >> > We have agreed before that upgrading the Maven minor or major
> > > version
> > > > >> would
> > > > >> > affect the JREs that Maven can run on. Basically following a one
> > > and one
> > > > >> > back for Oracle supported JDKs, thus 3.7.0 per that policy would
> > be
> > > > >> forced
> > > > >> > to Java 8 as minimum anyway.... in other words, our users should
> > be
> > > > >> > expecting us to go Java 8 as baseline.
> > > > >> >
> > > > >> > On Tue, 29 Oct 2019 at 10:28, Tibor Digana <
> > tibordigana@apache.org>
> > > > >> wrote:
> > > > >> >
> > > > >> > > Stephen, what issue with current toolchain you mean?
> > > > >> > >
> > > > >> > > On Tue, Oct 29, 2019 at 11:11 AM Stephen Connolly <
> > > > >> > > stephen.alan.connolly@gmail.com> wrote:
> > > > >> > >
> > > > >> > > > On Tue, 29 Oct 2019 at 08:02, Tibor Digana <
> > > tibordigana@apache.org>
> > > > >> > > wrote:
> > > > >> > > >
> > > > >> > > > > Robert, I saw the code. The class has a method which
> returns
> > > > >> Lambda
> > > > >> > > > > function. The whole class was designed with OOP. The OOP
> is
> > a
> > > good
> > > > >> > > thing
> > > > >> > > > > which you should follow and follow this approach and not
> to
> > > return
> > > > >> > the
> > > > >> > > > > labda function. Basically it is a precedense created in
> the
> > PR
> > > > >> saying
> > > > >> > > > that
> > > > >> > > > > now J8 has to be used in the bytecode.
> > > > >> > > > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source
> > > code!
> > > > >> > > > >
> > > > >> > > >
> > > > >> > > > That is not possible using the current toolchains. Let's
> just
> > go
> > > > >> with
> > > > >> > > Java
> > > > >> > > > 8. There seems no good reason to hold back
> > > > >> > > >
> > > > >> > > >
> > > > >> > > > >
> > > > >> > > > > On Tue, Oct 29, 2019 at 8:25 AM Robert Scholte <
> > > > >> rfscholte@apache.org
> > > > >> > >
> > > > >> > > > > wrote:
> > > > >> > > > >
> > > > >> > > > > > The outcome is quite clear to me. There no clear 'No' to
> > add
> > > > >> this
> > > > >> > > > > > build/consumer feature into 3.7.0, so we'll add it which
> > > > >> implies we
> > > > >> > > > must
> > > > >> > > > > > move to Java 8 due to new APIs with Java 8 class
> > signatures.
> > > > >> > > > > >
> > > > >> > > > > > But first we need to deliver a 3.6.3 regression release.
> > > > >> > > > > >
> > > > >> > > > > > Robert
> > > > >> > > > > >
> > > > >> > > > > > On 29-10-2019 05:53:25, Romain Manni-Bucau <
> > > > >> rmannibucau@gmail.com>
> > > > >> > > > > wrote:
> > > > >> > > > > > +1, the risk is more or less 0 since we can still use
> > > branches
> > > > >> for
> > > > >> > > > > > potential fixes for "old" projects using frozen java and
> > > maven
> > > > >> > > versions
> > > > >> > > > > > anyway
> > > > >> > > > > >
> > > > >> > > > > > Guess we can even be very precautionous doing 1. an
> > upgrade
> > > to
> > > > >> > > bytecode
> > > > >> > > > > > version without any code change (to change the major
> > > version in
> > > > >> > > > > bytecode),
> > > > >> > > > > > 2. a M1 to let users test it if some still doubt.
> > > > >> > > > > >
> > > > >> > > > > > Le mar. 29 oct. 2019 à 04:06, Olivier Lamy a écrit :
> > > > >> > > > > >
> > > > >> > > > > > > so what is the status of this?
> > > > >> > > > > > > will we discuss in 2025 about being able to use java 8
> > > apis
> > > > >> or do
> > > > >> > > we
> > > > >> > > > > have
> > > > >> > > > > > > to wait 2030?
> > > > >> > > > > > > Sorry to be sarcastic but not moving forward it's
> > > certainly a
> > > > >> > > reason
> > > > >> > > > > why
> > > > >> > > > > > we
> > > > >> > > > > > > do not have more people participating in the
> project....
> > > > >> > > > > > > It is so frustrating to be stuck with old apis...
> > > > >> > > > > > >
> > > > >> > > > > > >
> > > > >> > > > > > >
> > > > >> > > > > > > On Thu, 10 Oct 2019 at 04:36, Tibor Digana wrote:
> > > > >> > > > > > >
> > > > >> > > > > > > > I have to fully agree on Michael Osipov. This
> > > discussion is
> > > > >> > > > > > > > contraproductive from the time perspective.
> > > > >> > > > > > > > He explained the situation in Maven very clearly
> that
> > we
> > > > >> have
> > > > >> > > over
> > > > >> > > > > 1800
> > > > >> > > > > > > > bugs and here we are talking about javac compiler
> > > version
> > > > >> which
> > > > >> > > > does
> > > > >> > > > > > not
> > > > >> > > > > > > > fix these bugs.
> > > > >> > > > > > > > We know that our community is quite big but we also
> > know
> > > > >> that
> > > > >> > we
> > > > >> > > > have
> > > > >> > > > > > > only
> > > > >> > > > > > > > few several developers who regularily provides fixes
> > > for the
> > > > >> > bug
> > > > >> > > > and
> > > > >> > > > > > they
> > > > >> > > > > > > > do it for free!
> > > > >> > > > > > > > So my advice is to leave these talks alone about
> > > technology
> > > > >> > lobby
> > > > >> > > > > (seen
> > > > >> > > > > > > on
> > > > >> > > > > > > > ML from outside as well) and rather concentrate on
> the
> > > bug.
> > > > >> We
> > > > >> > > have
> > > > >> > > > > > seen
> > > > >> > > > > > > > that the users/contributors handled performance
> issues
> > > and
> > > > >> > fixed
> > > > >> > > > them
> > > > >> > > > > > > which
> > > > >> > > > > > > > means that these contributors got very good
> > proficiency
> > > > >> level!
> > > > >> > > > > > > >
> > > > >> > > > > > > > On Wed, Oct 9, 2019 at 7:56 PM Alexander Ashitkin <>
> > > > >> > > > > > > ashitkin.alex@gmail.com
> > > > >> > > > > > > > >
> > > > >> > > > > > > > wrote:
> > > > >> > > > > > > >
> > > > >> > > > > > > > > Totally disagree on the point. Writing java7 code
> > > after 8
> > > > >> > makes
> > > > >> > > > you
> > > > >> > > > > > > feel
> > > > >> > > > > > > > > suffering - because instead of expressive stream
> > based
> > > > >> > > operations
> > > > >> > > > > and
> > > > >> > > > > > > > > lambdas you write pointless iterators and copy
> > > > >> collections.
> > > > >> > > > > > > > > It is purely subjective opinion that lambdas make
> > code
> > > > >> less
> > > > >> > > > > readable
> > > > >> > > > > > -
> > > > >> > > > > > > at
> > > > >> > > > > > > > > least there is an absolutely opposite opinion
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > Thank you
> > > > >> > > > > > > > > Aleks
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > On 2019/10/03 12:47:35, Paul Hammant wrote:
> > > > >> > > > > > > > > > Who codes for 18 months before discovering that
> > > qa/prod
> > > > >> are
> > > > >> > > not
> > > > >> > > > > > > > > compatible,
> > > > >> > > > > > > > > > anymore? Especially if Google ship a
> use-this-Pom
> > > > >> starter.
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > > On Thu, Oct 3, 2019 at 1:44 PM Elliotte Rusty
> > > Harold <>
> > > > >> > > > > > > > elharo@ibiblio.org
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > > 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 <>
> > > > >> > > > > > > > > elharo@ibiblio.org
> > > > >> > > > > > > > > > > >
> > > > >> > > > > > > > > > > > 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 <>
> > > > >> > > > > > > > > rfscholte@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-unsubscribe@maven.apache.org
> > > > >> > > > > > > > > > > > > > For additional commands, e-mail:
> > > > >> > > > > dev-help@maven.apache.org
> > > > >> > > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > > --
> > > > >> > > > > > > > > > > > > Elliotte Rusty Harold
> > > > >> > > > > > > > > > > > > elharo@ibiblio.org
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > >
> > > > >> > > > >
> > > > >>
> > ---------------------------------------------------------------------
> > > > >> > > > > > > > > > > > > To unsubscribe, e-mail:
> > > > >> > > dev-unsubscribe@maven.apache.org
> > > > >> > > > > > > > > > > > > For additional commands, e-mail:
> > > > >> > > > dev-help@maven.apache.org
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > > > >
> > > > >> > > > > > > > > > >
> > > > >> > > > > > > > > > >
> > > > >> > > > > > > > > > >
> > > > >> > > > > > > > > > > --
> > > > >> > > > > > > > > > > Elliotte Rusty Harold
> > > > >> > > > > > > > > > > elharo@ibiblio.org
> > > > >> > > > > > > > > > >
> > > > >> > > > > > > > > > >
> > > > >> > > > > > >
> > > > >> > >
> > > ---------------------------------------------------------------------
> > > > >> > > > > > > > > > > To unsubscribe, e-mail:
> > > > >> dev-unsubscribe@maven.apache.org
> > > > >> > > > > > > > > > > For additional commands, e-mail:
> > > > >> > dev-help@maven.apache.org
> > > > >> > > > > > > > > > >
> > > > >> > > > > > > > > > >
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > >
> > > > >> > > > > > > > >
> > > > >> > > > >
> > > > >>
> > ---------------------------------------------------------------------
> > > > >> > > > > > > > > To unsubscribe, e-mail:
> > > dev-unsubscribe@maven.apache.org
> > > > >> > > > > > > > > For additional commands, e-mail:
> > > > >> dev-help@maven.apache.org
> > > > >> > > > > > > > >
> > > > >> > > > > > > > >
> > > > >> > > > > > > >
> > > > >> > > > > > >
> > > > >> > > > > > >
> > > > >> > > > > > > --
> > > > >> > > > > > > Olivier Lamy
> > > > >> > > > > > > http://twitter.com/olamy |
> http://linkedin.com/in/olamy
> > > > >> > > > > > >
> > > > >> > > > > >
> > > > >> > > > >
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>

Re: Re: [DISCUSS] Maven 3.7.0

[Enrico Olivelli <eo...@gmail.com>]

Il giorno mar 29 ott 2019 alle ore 14:22 Stephen Connolly <
stephen.alan.connolly@gmail.com> ha scritto:

> Because maintaining Java 7 is a barrier to new contributors. It is tricky
> enough to get Java 8 set up for some developers. Every version we support
> adds complexity for contributors. Personally, I think we should be thinking
> about dropping even Java 8 if we wait until next year and just follow the
> latest LTS line... but I am happy to keep with Java 8 as a baseline for
> now. Java 7 is only supported for a limited number of environments right
> now, whereas Java 8 has multiple vendors supporting it against multiple
> platforms at least until mid 2023.
>
> We hold back the entire community if we stick on a base version for too
> long.
>

totally true !

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

Enrico



>
> On Tue, 29 Oct 2019 at 13:00, Michael Osipov <19...@gmx.net> wrote:
>
> > Why not have 3.7.0 plugin updates and other non-technical stuff, have it
> > parallely maintained for some time and move with Maven 3.8.0 to Java 8
> > next year?!
> >
> > Does that sound like a plan? I'd be happy with that. I'd also expect
> > an announcement on dev@, announce@ and users@.
> >
> > Michael
> >
> > > Gesendet: Dienstag, 29. Oktober 2019 um 13:49 Uhr
> > > Von: "Stephen Connolly" <st...@gmail.com>
> > > An: "Maven Developers List" <de...@maven.apache.org>
> > > Betreff: Re: [DISCUSS] Maven 3.7.0
> > >
> > > On Tue, 29 Oct 2019 at 12:47, Stephen Connolly <
> > > stephen.alan.connolly@gmail.com> wrote:
> > >
> > > > We already have a version policy:
> > > >
> > https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy
> > > >
> > >
> > > (while that page says draft, the proposal was on-list in 2014 and just
> > > converted into a wiki page afterwards - hence why the examples use 2014
> > > dates)
> > >
> > >
> > > > > The development line of Maven core should require a minimum JRE
> > version
> > > > that is no older than 18 months after the end of Oracle's public
> > updates
> > > > for that JRE version at the time that the first version of the
> > development
> > > > line was released, but may require a higher minimum JRE version if
> > other
> > > > requirements dictate a higher JRE version.
> > > >
> > > > End of public updates for Java 8 from Oracle was January 2019, thus
> if
> > we
> > > > cut a new minor version we would be Java 8 but not Java 7.
> > > >
> > > >
> > > > On Tue, 29 Oct 2019 at 12:28, Tibor Digana <ti...@apache.org>
> > wrote:
> > > >
> > > >> Stephen, we are in loop.
> > > >> Of course I know these technical things.
> > > >> But I am saying, and I am not alone (Michael Osipov too), that I
> agree
> > > >> with
> > > >> sources 1.8, but there must be1.  the Vote with milestones regarding
> > Maven
> > > >> and another Vote regarding plugins, and 2. written list of pros/cons
> > > >> regarding J8 and 3. developer guideline for J8 (for devs,
> consultants,
> > > >> another professions as well in the team).
> > > >> You know, with video calls, all these public emails would be gone
> > within
> > > >> one or two hours, I am sure!
> > > >> I am also sure that we will have another code preferences and
> > therefore we
> > > >> should have some guideline. For instance, I like to have clear OOP
> in
> > the
> > > >> public class/interfaces and Lambda in private code. And there are a
> > lot of
> > > >> stuff, like parallel streams ala thread pool of non-daemon threads,
> > > >> performance of streams (when, how stream is constructed, etc), Date
> > Time
> > > >> API is new as well.
> > > >>
> > > >> No benefit for the community with J7 sources but yes with J8 code.
> > Believe
> > > >> me, this is true. Michael mentioned that as well.
> > > >>
> > > >
> > > > Not true. Java 8 bytecode adds additional metadata that speeds up
> > > > classloading (but only when the class graph is all Java 8)
> > > >
> > > >
> > > >>
> > > >> It is also true that we have a lot of bugs, and it is true that
> Maven
> > > >> needs
> > > >> to have breakthrough features like reproducible build and User POM,
> > Docker
> > > >> prefetched cache, etc.
> > > >> I have no argument against these things. The only problem that I
> have
> > and
> > > >> Michael has is the way how this is managed but it is the only
> trivial
> > > >> problem that we can solve between us.
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> On Tue, Oct 29, 2019 at 1:04 PM Stephen Connolly <
> > > >> stephen.alan.connolly@gmail.com> wrote:
> > > >>
> > > >> > You cannot have Java 8 sources produce Java 7 bytecode with the
> > Java 8's
> > > >> > javac.
> > > >> >
> > > >> > -target must be >= -source
> > > >> >
> > > >> > So to say:
> > > >> >
> > > >> > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
> > > >> >
> > > >> > Is not possible, you'll get something like:
> > > >> >
> > > >> > $ javac Test -source 1.8 -target 1.7
> > > >> > javac: source release 1.8 requires target release 1.8
> > > >> >
> > > >> > While we could use something like
> > > >> https://github.com/luontola/retrolambda
> > > >> > its usage is not without significant risks. You really need to be
> > very
> > > >> > careful in how you use it, and the effort is IMHO far exceeding
> the
> > > >> risk.
> > > >> > Much better to just say Maven 3.7.0 is requires the runtime JVM be
> > Java
> > > >> 8+,
> > > >> > use toolchains if you need to compile or unit tests with older
> JDKs.
> > > >> >
> > > >> > We have agreed before that upgrading the Maven minor or major
> > version
> > > >> would
> > > >> > affect the JREs that Maven can run on. Basically following a one
> > and one
> > > >> > back for Oracle supported JDKs, thus 3.7.0 per that policy would
> be
> > > >> forced
> > > >> > to Java 8 as minimum anyway.... in other words, our users should
> be
> > > >> > expecting us to go Java 8 as baseline.
> > > >> >
> > > >> > On Tue, 29 Oct 2019 at 10:28, Tibor Digana <
> tibordigana@apache.org>
> > > >> wrote:
> > > >> >
> > > >> > > Stephen, what issue with current toolchain you mean?
> > > >> > >
> > > >> > > On Tue, Oct 29, 2019 at 11:11 AM Stephen Connolly <
> > > >> > > stephen.alan.connolly@gmail.com> wrote:
> > > >> > >
> > > >> > > > On Tue, 29 Oct 2019 at 08:02, Tibor Digana <
> > tibordigana@apache.org>
> > > >> > > wrote:
> > > >> > > >
> > > >> > > > > Robert, I saw the code. The class has a method which returns
> > > >> Lambda
> > > >> > > > > function. The whole class was designed with OOP. The OOP is
> a
> > good
> > > >> > > thing
> > > >> > > > > which you should follow and follow this approach and not to
> > return
> > > >> > the
> > > >> > > > > labda function. Basically it is a precedense created in the
> PR
> > > >> saying
> > > >> > > > that
> > > >> > > > > now J8 has to be used in the bytecode.
> > > >> > > > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source
> > code!
> > > >> > > > >
> > > >> > > >
> > > >> > > > That is not possible using the current toolchains. Let's just
> go
> > > >> with
> > > >> > > Java
> > > >> > > > 8. There seems no good reason to hold back
> > > >> > > >
> > > >> > > >
> > > >> > > > >
> > > >> > > > > On Tue, Oct 29, 2019 at 8:25 AM Robert Scholte <
> > > >> rfscholte@apache.org
> > > >> > >
> > > >> > > > > wrote:
> > > >> > > > >
> > > >> > > > > > The outcome is quite clear to me. There no clear 'No' to
> add
> > > >> this
> > > >> > > > > > build/consumer feature into 3.7.0, so we'll add it which
> > > >> implies we
> > > >> > > > must
> > > >> > > > > > move to Java 8 due to new APIs with Java 8 class
> signatures.
> > > >> > > > > >
> > > >> > > > > > But first we need to deliver a 3.6.3 regression release.
> > > >> > > > > >
> > > >> > > > > > Robert
> > > >> > > > > >
> > > >> > > > > > On 29-10-2019 05:53:25, Romain Manni-Bucau <
> > > >> rmannibucau@gmail.com>
> > > >> > > > > wrote:
> > > >> > > > > > +1, the risk is more or less 0 since we can still use
> > branches
> > > >> for
> > > >> > > > > > potential fixes for "old" projects using frozen java and
> > maven
> > > >> > > versions
> > > >> > > > > > anyway
> > > >> > > > > >
> > > >> > > > > > Guess we can even be very precautionous doing 1. an
> upgrade
> > to
> > > >> > > bytecode
> > > >> > > > > > version without any code change (to change the major
> > version in
> > > >> > > > > bytecode),
> > > >> > > > > > 2. a M1 to let users test it if some still doubt.
> > > >> > > > > >
> > > >> > > > > > Le mar. 29 oct. 2019 à 04:06, Olivier Lamy a écrit :
> > > >> > > > > >
> > > >> > > > > > > so what is the status of this?
> > > >> > > > > > > will we discuss in 2025 about being able to use java 8
> > apis
> > > >> or do
> > > >> > > we
> > > >> > > > > have
> > > >> > > > > > > to wait 2030?
> > > >> > > > > > > Sorry to be sarcastic but not moving forward it's
> > certainly a
> > > >> > > reason
> > > >> > > > > why
> > > >> > > > > > we
> > > >> > > > > > > do not have more people participating in the project....
> > > >> > > > > > > It is so frustrating to be stuck with old apis...
> > > >> > > > > > >
> > > >> > > > > > >
> > > >> > > > > > >
> > > >> > > > > > > On Thu, 10 Oct 2019 at 04:36, Tibor Digana wrote:
> > > >> > > > > > >
> > > >> > > > > > > > I have to fully agree on Michael Osipov. This
> > discussion is
> > > >> > > > > > > > contraproductive from the time perspective.
> > > >> > > > > > > > He explained the situation in Maven very clearly that
> we
> > > >> have
> > > >> > > over
> > > >> > > > > 1800
> > > >> > > > > > > > bugs and here we are talking about javac compiler
> > version
> > > >> which
> > > >> > > > does
> > > >> > > > > > not
> > > >> > > > > > > > fix these bugs.
> > > >> > > > > > > > We know that our community is quite big but we also
> know
> > > >> that
> > > >> > we
> > > >> > > > have
> > > >> > > > > > > only
> > > >> > > > > > > > few several developers who regularily provides fixes
> > for the
> > > >> > bug
> > > >> > > > and
> > > >> > > > > > they
> > > >> > > > > > > > do it for free!
> > > >> > > > > > > > So my advice is to leave these talks alone about
> > technology
> > > >> > lobby
> > > >> > > > > (seen
> > > >> > > > > > > on
> > > >> > > > > > > > ML from outside as well) and rather concentrate on the
> > bug.
> > > >> We
> > > >> > > have
> > > >> > > > > > seen
> > > >> > > > > > > > that the users/contributors handled performance issues
> > and
> > > >> > fixed
> > > >> > > > them
> > > >> > > > > > > which
> > > >> > > > > > > > means that these contributors got very good
> proficiency
> > > >> level!
> > > >> > > > > > > >
> > > >> > > > > > > > On Wed, Oct 9, 2019 at 7:56 PM Alexander Ashitkin <>
> > > >> > > > > > > ashitkin.alex@gmail.com
> > > >> > > > > > > > >
> > > >> > > > > > > > wrote:
> > > >> > > > > > > >
> > > >> > > > > > > > > Totally disagree on the point. Writing java7 code
> > after 8
> > > >> > makes
> > > >> > > > you
> > > >> > > > > > > feel
> > > >> > > > > > > > > suffering - because instead of expressive stream
> based
> > > >> > > operations
> > > >> > > > > and
> > > >> > > > > > > > > lambdas you write pointless iterators and copy
> > > >> collections.
> > > >> > > > > > > > > It is purely subjective opinion that lambdas make
> code
> > > >> less
> > > >> > > > > readable
> > > >> > > > > > -
> > > >> > > > > > > at
> > > >> > > > > > > > > least there is an absolutely opposite opinion
> > > >> > > > > > > > >
> > > >> > > > > > > > > Thank you
> > > >> > > > > > > > > Aleks
> > > >> > > > > > > > >
> > > >> > > > > > > > > On 2019/10/03 12:47:35, Paul Hammant wrote:
> > > >> > > > > > > > > > Who codes for 18 months before discovering that
> > qa/prod
> > > >> are
> > > >> > > not
> > > >> > > > > > > > > compatible,
> > > >> > > > > > > > > > anymore? Especially if Google ship a use-this-Pom
> > > >> starter.
> > > >> > > > > > > > > >
> > > >> > > > > > > > > > On Thu, Oct 3, 2019 at 1:44 PM Elliotte Rusty
> > Harold <>
> > > >> > > > > > > > elharo@ibiblio.org
> > > >> > > > > > > > > >
> > > >> > > > > > > > > > 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 <>
> > > >> > > > > > > > > elharo@ibiblio.org
> > > >> > > > > > > > > > > >
> > > >> > > > > > > > > > > > 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 <>
> > > >> > > > > > > > > rfscholte@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-unsubscribe@maven.apache.org
> > > >> > > > > > > > > > > > > > For additional commands, e-mail:
> > > >> > > > > dev-help@maven.apache.org
> > > >> > > > > > > > > > > > > >
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > > > > > > --
> > > >> > > > > > > > > > > > > Elliotte Rusty Harold
> > > >> > > > > > > > > > > > > elharo@ibiblio.org
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > >
> > > >> > > > >
> > > >>
> ---------------------------------------------------------------------
> > > >> > > > > > > > > > > > > To unsubscribe, e-mail:
> > > >> > > dev-unsubscribe@maven.apache.org
> > > >> > > > > > > > > > > > > For additional commands, e-mail:
> > > >> > > > dev-help@maven.apache.org
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > > > > > >
> > > >> > > > > > > > > > >
> > > >> > > > > > > > > > >
> > > >> > > > > > > > > > >
> > > >> > > > > > > > > > > --
> > > >> > > > > > > > > > > Elliotte Rusty Harold
> > > >> > > > > > > > > > > elharo@ibiblio.org
> > > >> > > > > > > > > > >
> > > >> > > > > > > > > > >
> > > >> > > > > > >
> > > >> > >
> > ---------------------------------------------------------------------
> > > >> > > > > > > > > > > To unsubscribe, e-mail:
> > > >> dev-unsubscribe@maven.apache.org
> > > >> > > > > > > > > > > For additional commands, e-mail:
> > > >> > dev-help@maven.apache.org
> > > >> > > > > > > > > > >
> > > >> > > > > > > > > > >
> > > >> > > > > > > > > >
> > > >> > > > > > > > >
> > > >> > > > > > > > >
> > > >> > > > >
> > > >>
> ---------------------------------------------------------------------
> > > >> > > > > > > > > To unsubscribe, e-mail:
> > dev-unsubscribe@maven.apache.org
> > > >> > > > > > > > > For additional commands, e-mail:
> > > >> dev-help@maven.apache.org
> > > >> > > > > > > > >
> > > >> > > > > > > > >
> > > >> > > > > > > >
> > > >> > > > > > >
> > > >> > > > > > >
> > > >> > > > > > > --
> > > >> > > > > > > Olivier Lamy
> > > >> > > > > > > http://twitter.com/olamy | http://linkedin.com/in/olamy
> > > >> > > > > > >
> > > >> > > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>

Re: Re: [DISCUSS] Maven 3.7.0

[Stephen Connolly <st...@gmail.com>]

Because maintaining Java 7 is a barrier to new contributors. It is tricky
enough to get Java 8 set up for some developers. Every version we support
adds complexity for contributors. Personally, I think we should be thinking
about dropping even Java 8 if we wait until next year and just follow the
latest LTS line... but I am happy to keep with Java 8 as a baseline for
now. Java 7 is only supported for a limited number of environments right
now, whereas Java 8 has multiple vendors supporting it against multiple
platforms at least until mid 2023.

We hold back the entire community if we stick on a base version for too
long.

On Tue, 29 Oct 2019 at 13:00, Michael Osipov <19...@gmx.net> wrote:

> Why not have 3.7.0 plugin updates and other non-technical stuff, have it
> parallely maintained for some time and move with Maven 3.8.0 to Java 8
> next year?!
>
> Does that sound like a plan? I'd be happy with that. I'd also expect
> an announcement on dev@, announce@ and users@.
>
> Michael
>
> > Gesendet: Dienstag, 29. Oktober 2019 um 13:49 Uhr
> > Von: "Stephen Connolly" <st...@gmail.com>
> > An: "Maven Developers List" <de...@maven.apache.org>
> > Betreff: Re: [DISCUSS] Maven 3.7.0
> >
> > On Tue, 29 Oct 2019 at 12:47, Stephen Connolly <
> > stephen.alan.connolly@gmail.com> wrote:
> >
> > > We already have a version policy:
> > >
> https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy
> > >
> >
> > (while that page says draft, the proposal was on-list in 2014 and just
> > converted into a wiki page afterwards - hence why the examples use 2014
> > dates)
> >
> >
> > > > The development line of Maven core should require a minimum JRE
> version
> > > that is no older than 18 months after the end of Oracle's public
> updates
> > > for that JRE version at the time that the first version of the
> development
> > > line was released, but may require a higher minimum JRE version if
> other
> > > requirements dictate a higher JRE version.
> > >
> > > End of public updates for Java 8 from Oracle was January 2019, thus if
> we
> > > cut a new minor version we would be Java 8 but not Java 7.
> > >
> > >
> > > On Tue, 29 Oct 2019 at 12:28, Tibor Digana <ti...@apache.org>
> wrote:
> > >
> > >> Stephen, we are in loop.
> > >> Of course I know these technical things.
> > >> But I am saying, and I am not alone (Michael Osipov too), that I agree
> > >> with
> > >> sources 1.8, but there must be1.  the Vote with milestones regarding
> Maven
> > >> and another Vote regarding plugins, and 2. written list of pros/cons
> > >> regarding J8 and 3. developer guideline for J8 (for devs, consultants,
> > >> another professions as well in the team).
> > >> You know, with video calls, all these public emails would be gone
> within
> > >> one or two hours, I am sure!
> > >> I am also sure that we will have another code preferences and
> therefore we
> > >> should have some guideline. For instance, I like to have clear OOP in
> the
> > >> public class/interfaces and Lambda in private code. And there are a
> lot of
> > >> stuff, like parallel streams ala thread pool of non-daemon threads,
> > >> performance of streams (when, how stream is constructed, etc), Date
> Time
> > >> API is new as well.
> > >>
> > >> No benefit for the community with J7 sources but yes with J8 code.
> Believe
> > >> me, this is true. Michael mentioned that as well.
> > >>
> > >
> > > Not true. Java 8 bytecode adds additional metadata that speeds up
> > > classloading (but only when the class graph is all Java 8)
> > >
> > >
> > >>
> > >> It is also true that we have a lot of bugs, and it is true that Maven
> > >> needs
> > >> to have breakthrough features like reproducible build and User POM,
> Docker
> > >> prefetched cache, etc.
> > >> I have no argument against these things. The only problem that I have
> and
> > >> Michael has is the way how this is managed but it is the only trivial
> > >> problem that we can solve between us.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> On Tue, Oct 29, 2019 at 1:04 PM Stephen Connolly <
> > >> stephen.alan.connolly@gmail.com> wrote:
> > >>
> > >> > You cannot have Java 8 sources produce Java 7 bytecode with the
> Java 8's
> > >> > javac.
> > >> >
> > >> > -target must be >= -source
> > >> >
> > >> > So to say:
> > >> >
> > >> > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
> > >> >
> > >> > Is not possible, you'll get something like:
> > >> >
> > >> > $ javac Test -source 1.8 -target 1.7
> > >> > javac: source release 1.8 requires target release 1.8
> > >> >
> > >> > While we could use something like
> > >> https://github.com/luontola/retrolambda
> > >> > its usage is not without significant risks. You really need to be
> very
> > >> > careful in how you use it, and the effort is IMHO far exceeding the
> > >> risk.
> > >> > Much better to just say Maven 3.7.0 is requires the runtime JVM be
> Java
> > >> 8+,
> > >> > use toolchains if you need to compile or unit tests with older JDKs.
> > >> >
> > >> > We have agreed before that upgrading the Maven minor or major
> version
> > >> would
> > >> > affect the JREs that Maven can run on. Basically following a one
> and one
> > >> > back for Oracle supported JDKs, thus 3.7.0 per that policy would be
> > >> forced
> > >> > to Java 8 as minimum anyway.... in other words, our users should be
> > >> > expecting us to go Java 8 as baseline.
> > >> >
> > >> > On Tue, 29 Oct 2019 at 10:28, Tibor Digana <ti...@apache.org>
> > >> wrote:
> > >> >
> > >> > > Stephen, what issue with current toolchain you mean?
> > >> > >
> > >> > > On Tue, Oct 29, 2019 at 11:11 AM Stephen Connolly <
> > >> > > stephen.alan.connolly@gmail.com> wrote:
> > >> > >
> > >> > > > On Tue, 29 Oct 2019 at 08:02, Tibor Digana <
> tibordigana@apache.org>
> > >> > > wrote:
> > >> > > >
> > >> > > > > Robert, I saw the code. The class has a method which returns
> > >> Lambda
> > >> > > > > function. The whole class was designed with OOP. The OOP is a
> good
> > >> > > thing
> > >> > > > > which you should follow and follow this approach and not to
> return
> > >> > the
> > >> > > > > labda function. Basically it is a precedense created in the PR
> > >> saying
> > >> > > > that
> > >> > > > > now J8 has to be used in the bytecode.
> > >> > > > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source
> code!
> > >> > > > >
> > >> > > >
> > >> > > > That is not possible using the current toolchains. Let's just go
> > >> with
> > >> > > Java
> > >> > > > 8. There seems no good reason to hold back
> > >> > > >
> > >> > > >
> > >> > > > >
> > >> > > > > On Tue, Oct 29, 2019 at 8:25 AM Robert Scholte <
> > >> rfscholte@apache.org
> > >> > >
> > >> > > > > wrote:
> > >> > > > >
> > >> > > > > > The outcome is quite clear to me. There no clear 'No' to add
> > >> this
> > >> > > > > > build/consumer feature into 3.7.0, so we'll add it which
> > >> implies we
> > >> > > > must
> > >> > > > > > move to Java 8 due to new APIs with Java 8 class signatures.
> > >> > > > > >
> > >> > > > > > But first we need to deliver a 3.6.3 regression release.
> > >> > > > > >
> > >> > > > > > Robert
> > >> > > > > >
> > >> > > > > > On 29-10-2019 05:53:25, Romain Manni-Bucau <
> > >> rmannibucau@gmail.com>
> > >> > > > > wrote:
> > >> > > > > > +1, the risk is more or less 0 since we can still use
> branches
> > >> for
> > >> > > > > > potential fixes for "old" projects using frozen java and
> maven
> > >> > > versions
> > >> > > > > > anyway
> > >> > > > > >
> > >> > > > > > Guess we can even be very precautionous doing 1. an upgrade
> to
> > >> > > bytecode
> > >> > > > > > version without any code change (to change the major
> version in
> > >> > > > > bytecode),
> > >> > > > > > 2. a M1 to let users test it if some still doubt.
> > >> > > > > >
> > >> > > > > > Le mar. 29 oct. 2019 à 04:06, Olivier Lamy a écrit :
> > >> > > > > >
> > >> > > > > > > so what is the status of this?
> > >> > > > > > > will we discuss in 2025 about being able to use java 8
> apis
> > >> or do
> > >> > > we
> > >> > > > > have
> > >> > > > > > > to wait 2030?
> > >> > > > > > > Sorry to be sarcastic but not moving forward it's
> certainly a
> > >> > > reason
> > >> > > > > why
> > >> > > > > > we
> > >> > > > > > > do not have more people participating in the project....
> > >> > > > > > > It is so frustrating to be stuck with old apis...
> > >> > > > > > >
> > >> > > > > > >
> > >> > > > > > >
> > >> > > > > > > On Thu, 10 Oct 2019 at 04:36, Tibor Digana wrote:
> > >> > > > > > >
> > >> > > > > > > > I have to fully agree on Michael Osipov. This
> discussion is
> > >> > > > > > > > contraproductive from the time perspective.
> > >> > > > > > > > He explained the situation in Maven very clearly that we
> > >> have
> > >> > > over
> > >> > > > > 1800
> > >> > > > > > > > bugs and here we are talking about javac compiler
> version
> > >> which
> > >> > > > does
> > >> > > > > > not
> > >> > > > > > > > fix these bugs.
> > >> > > > > > > > We know that our community is quite big but we also know
> > >> that
> > >> > we
> > >> > > > have
> > >> > > > > > > only
> > >> > > > > > > > few several developers who regularily provides fixes
> for the
> > >> > bug
> > >> > > > and
> > >> > > > > > they
> > >> > > > > > > > do it for free!
> > >> > > > > > > > So my advice is to leave these talks alone about
> technology
> > >> > lobby
> > >> > > > > (seen
> > >> > > > > > > on
> > >> > > > > > > > ML from outside as well) and rather concentrate on the
> bug.
> > >> We
> > >> > > have
> > >> > > > > > seen
> > >> > > > > > > > that the users/contributors handled performance issues
> and
> > >> > fixed
> > >> > > > them
> > >> > > > > > > which
> > >> > > > > > > > means that these contributors got very good proficiency
> > >> level!
> > >> > > > > > > >
> > >> > > > > > > > On Wed, Oct 9, 2019 at 7:56 PM Alexander Ashitkin <>
> > >> > > > > > > ashitkin.alex@gmail.com
> > >> > > > > > > > >
> > >> > > > > > > > wrote:
> > >> > > > > > > >
> > >> > > > > > > > > Totally disagree on the point. Writing java7 code
> after 8
> > >> > makes
> > >> > > > you
> > >> > > > > > > feel
> > >> > > > > > > > > suffering - because instead of expressive stream based
> > >> > > operations
> > >> > > > > and
> > >> > > > > > > > > lambdas you write pointless iterators and copy
> > >> collections.
> > >> > > > > > > > > It is purely subjective opinion that lambdas make code
> > >> less
> > >> > > > > readable
> > >> > > > > > -
> > >> > > > > > > at
> > >> > > > > > > > > least there is an absolutely opposite opinion
> > >> > > > > > > > >
> > >> > > > > > > > > Thank you
> > >> > > > > > > > > Aleks
> > >> > > > > > > > >
> > >> > > > > > > > > On 2019/10/03 12:47:35, Paul Hammant wrote:
> > >> > > > > > > > > > Who codes for 18 months before discovering that
> qa/prod
> > >> are
> > >> > > not
> > >> > > > > > > > > compatible,
> > >> > > > > > > > > > anymore? Especially if Google ship a use-this-Pom
> > >> starter.
> > >> > > > > > > > > >
> > >> > > > > > > > > > On Thu, Oct 3, 2019 at 1:44 PM Elliotte Rusty
> Harold <>
> > >> > > > > > > > elharo@ibiblio.org
> > >> > > > > > > > > >
> > >> > > > > > > > > > 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 <>
> > >> > > > > > > > > elharo@ibiblio.org
> > >> > > > > > > > > > > >
> > >> > > > > > > > > > > > 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 <>
> > >> > > > > > > > > rfscholte@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-unsubscribe@maven.apache.org
> > >> > > > > > > > > > > > > > For additional commands, e-mail:
> > >> > > > > dev-help@maven.apache.org
> > >> > > > > > > > > > > > > >
> > >> > > > > > > > > > > > >
> > >> > > > > > > > > > > > >
> > >> > > > > > > > > > > > > --
> > >> > > > > > > > > > > > > Elliotte Rusty Harold
> > >> > > > > > > > > > > > > elharo@ibiblio.org
> > >> > > > > > > > > > > > >
> > >> > > > > > > > > > > > >
> > >> > > > > > > > >
> > >> > > > >
> > >> ---------------------------------------------------------------------
> > >> > > > > > > > > > > > > To unsubscribe, e-mail:
> > >> > > dev-unsubscribe@maven.apache.org
> > >> > > > > > > > > > > > > For additional commands, e-mail:
> > >> > > > dev-help@maven.apache.org
> > >> > > > > > > > > > > > >
> > >> > > > > > > > > > > > >
> > >> > > > > > > > > > >
> > >> > > > > > > > > > >
> > >> > > > > > > > > > >
> > >> > > > > > > > > > > --
> > >> > > > > > > > > > > Elliotte Rusty Harold
> > >> > > > > > > > > > > elharo@ibiblio.org
> > >> > > > > > > > > > >
> > >> > > > > > > > > > >
> > >> > > > > > >
> > >> > >
> ---------------------------------------------------------------------
> > >> > > > > > > > > > > To unsubscribe, e-mail:
> > >> dev-unsubscribe@maven.apache.org
> > >> > > > > > > > > > > For additional commands, e-mail:
> > >> > dev-help@maven.apache.org
> > >> > > > > > > > > > >
> > >> > > > > > > > > > >
> > >> > > > > > > > > >
> > >> > > > > > > > >
> > >> > > > > > > > >
> > >> > > > >
> > >> ---------------------------------------------------------------------
> > >> > > > > > > > > To unsubscribe, e-mail:
> dev-unsubscribe@maven.apache.org
> > >> > > > > > > > > For additional commands, e-mail:
> > >> dev-help@maven.apache.org
> > >> > > > > > > > >
> > >> > > > > > > > >
> > >> > > > > > > >
> > >> > > > > > >
> > >> > > > > > >
> > >> > > > > > > --
> > >> > > > > > > Olivier Lamy
> > >> > > > > > > http://twitter.com/olamy | http://linkedin.com/in/olamy
> > >> > > > > > >
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: Re: [DISCUSS] Maven 3.7.0

[Romain Manni-Bucau <rm...@gmail.com>]

Sdkman is also a good option (and avoids binaries in sources)

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


Le mar. 29 oct. 2019 à 19:46, Robert Scholte <rf...@apache.org> a
écrit :

> One of the fundamental features of Maven is Convention Over Configuration,
> in other words: define defaults where possible, but make it possible to
> change these values.
> However, "default" can be explained differently, either as constant
> (forever) or as a predefined value within a certain context.
>
> A lot of projects don't lock their plugins and up until Maven 2.0.9 the
> LATEST version was used. This could mean that with any new plugin release
> builds could break without any changes in their own codebase. Because of
> that Maven started defining default versions for the most common plugins.
> These defaults have been the same for a long time to prevent situations as
> before Maven 2.0.9
> Upgrading plugin defaults in Maven will break builds, because project
> actually rely on these defaults, intended or not.
>
> We should have a good answer when things do break. Some options:
> - figure out the problematic plugins and lock their version
> - stay on Maven 3.6.3 to have the combinations of plugin versions that do
> work together.
>
> Assuming most developers only have 1 version of Maven on their machine,
> both these answer aren't nice. And even with multiple Maven versions,
> switching between them isn't that nice.
> There is one other solution that will help in this case: make sure the
> project is being build with Maven version X.
> Such solution already exists, but most users are not aware of it and
> expect it to be part of Maven itself (as with Gradle): it is called the
> Maven Wrapper.
> I'm already negotiating about the codebase and IP, hopefully we'll have
> positive results soon.
>
> To me the upgrades of plugin defaults must be combined with the
> introduction of the Maven Wrapper as part of Maven core to have the least
> amount of issues.
>
> Robert
> On 29-10-2019 14:00:49, Michael Osipov <19...@gmx.net> wrote:
> Why not have 3.7.0 plugin updates and other non-technical stuff, have it
> parallely maintained for some time and move with Maven 3.8.0 to Java 8
> next year?!
>
> Does that sound like a plan? I'd be happy with that. I'd also expect
> an announcement on dev@, announce@ and users@.
>
> Michael
>
> > Gesendet: Dienstag, 29. Oktober 2019 um 13:49 Uhr
> > Von: "Stephen Connolly"
> > An: "Maven Developers List"
> > Betreff: Re: [DISCUSS] Maven 3.7.0
> >
> > On Tue, 29 Oct 2019 at 12:47, Stephen Connolly <>
> > stephen.alan.connolly@gmail.com> wrote:
> >
> > > We already have a version policy:
> > >
> https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy
> > >
> >
> > (while that page says draft, the proposal was on-list in 2014 and just
> > converted into a wiki page afterwards - hence why the examples use 2014
> > dates)
> >
> >
> > > > The development line of Maven core should require a minimum JRE
> version
> > > that is no older than 18 months after the end of Oracle's public
> updates
> > > for that JRE version at the time that the first version of the
> development
> > > line was released, but may require a higher minimum JRE version if
> other
> > > requirements dictate a higher JRE version.
> > >
> > > End of public updates for Java 8 from Oracle was January 2019, thus if
> we
> > > cut a new minor version we would be Java 8 but not Java 7.
> > >
> > >
> > > On Tue, 29 Oct 2019 at 12:28, Tibor Digana wrote:
> > >
> > >> Stephen, we are in loop.
> > >> Of course I know these technical things.
> > >> But I am saying, and I am not alone (Michael Osipov too), that I agree
> > >> with
> > >> sources 1.8, but there must be1. the Vote with milestones regarding
> Maven
> > >> and another Vote regarding plugins, and 2. written list of pros/cons
> > >> regarding J8 and 3. developer guideline for J8 (for devs, consultants,
> > >> another professions as well in the team).
> > >> You know, with video calls, all these public emails would be gone
> within
> > >> one or two hours, I am sure!
> > >> I am also sure that we will have another code preferences and
> therefore we
> > >> should have some guideline. For instance, I like to have clear OOP in
> the
> > >> public class/interfaces and Lambda in private code. And there are a
> lot of
> > >> stuff, like parallel streams ala thread pool of non-daemon threads,
> > >> performance of streams (when, how stream is constructed, etc), Date
> Time
> > >> API is new as well.
> > >>
> > >> No benefit for the community with J7 sources but yes with J8 code.
> Believe
> > >> me, this is true. Michael mentioned that as well.
> > >>
> > >
> > > Not true. Java 8 bytecode adds additional metadata that speeds up
> > > classloading (but only when the class graph is all Java 8)
> > >
> > >
> > >>
> > >> It is also true that we have a lot of bugs, and it is true that Maven
> > >> needs
> > >> to have breakthrough features like reproducible build and User POM,
> Docker
> > >> prefetched cache, etc.
> > >> I have no argument against these things. The only problem that I have
> and
> > >> Michael has is the way how this is managed but it is the only trivial
> > >> problem that we can solve between us.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> On Tue, Oct 29, 2019 at 1:04 PM Stephen Connolly <>
> > >> stephen.alan.connolly@gmail.com> wrote:
> > >>
> > >> > You cannot have Java 8 sources produce Java 7 bytecode with the
> Java 8's
> > >> > javac.
> > >> >
> > >> > -target must be >= -source
> > >> >
> > >> > So to say:
> > >> >
> > >> > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
> > >> >
> > >> > Is not possible, you'll get something like:
> > >> >
> > >> > $ javac Test -source 1.8 -target 1.7
> > >> > javac: source release 1.8 requires target release 1.8
> > >> >
> > >> > While we could use something like
> > >> https://github.com/luontola/retrolambda
> > >> > its usage is not without significant risks. You really need to be
> very
> > >> > careful in how you use it, and the effort is IMHO far exceeding the
> > >> risk.
> > >> > Much better to just say Maven 3.7.0 is requires the runtime JVM be
> Java
> > >> 8+,
> > >> > use toolchains if you need to compile or unit tests with older JDKs.
> > >> >
> > >> > We have agreed before that upgrading the Maven minor or major
> version
> > >> would
> > >> > affect the JREs that Maven can run on. Basically following a one
> and one
> > >> > back for Oracle supported JDKs, thus 3.7.0 per that policy would be
> > >> forced
> > >> > to Java 8 as minimum anyway.... in other words, our users should be
> > >> > expecting us to go Java 8 as baseline.
> > >> >
> > >> > On Tue, 29 Oct 2019 at 10:28, Tibor Digana
> > >> wrote:
> > >> >
> > >> > > Stephen, what issue with current toolchain you mean?
> > >> > >
> > >> > > On Tue, Oct 29, 2019 at 11:11 AM Stephen Connolly <>
> > >> > > stephen.alan.connolly@gmail.com> wrote:
> > >> > >
> > >> > > > On Tue, 29 Oct 2019 at 08:02, Tibor Digana
> > >> > > wrote:
> > >> > > >
> > >> > > > > Robert, I saw the code. The class has a method which returns
> > >> Lambda
> > >> > > > > function. The whole class was designed with OOP. The OOP is a
> good
> > >> > > thing
> > >> > > > > which you should follow and follow this approach and not to
> return
> > >> > the
> > >> > > > > labda function. Basically it is a precedense created in the PR
> > >> saying
> > >> > > > that
> > >> > > > > now J8 has to be used in the bytecode.
> > >> > > > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source
> code!
> > >> > > > >
> > >> > > >
> > >> > > > That is not possible using the current toolchains. Let's just go
> > >> with
> > >> > > Java
> > >> > > > 8. There seems no good reason to hold back
> > >> > > >
> > >> > > >
> > >> > > > >
> > >> > > > > On Tue, Oct 29, 2019 at 8:25 AM Robert Scholte <>
> > >> rfscholte@apache.org
> > >> > >
> > >> > > > > wrote:
> > >> > > > >
> > >> > > > > > The outcome is quite clear to me. There no clear 'No' to add
> > >> this
> > >> > > > > > build/consumer feature into 3.7.0, so we'll add it which
> > >> implies we
> > >> > > > must
> > >> > > > > > move to Java 8 due to new APIs with Java 8 class signatures.
> > >> > > > > >
> > >> > > > > > But first we need to deliver a 3.6.3 regression release.
> > >> > > > > >
> > >> > > > > > Robert
> > >> > > > > >
> > >> > > > > > On 29-10-2019 05:53:25, Romain Manni-Bucau <>
> > >> rmannibucau@gmail.com>
> > >> > > > > wrote:
> > >> > > > > > +1, the risk is more or less 0 since we can still use
> branches
> > >> for
> > >> > > > > > potential fixes for "old" projects using frozen java and
> maven
> > >> > > versions
> > >> > > > > > anyway
> > >> > > > > >
> > >> > > > > > Guess we can even be very precautionous doing 1. an upgrade
> to
> > >> > > bytecode
> > >> > > > > > version without any code change (to change the major
> version in
> > >> > > > > bytecode),
> > >> > > > > > 2. a M1 to let users test it if some still doubt.
> > >> > > > > >
> > >> > > > > > Le mar. 29 oct. 2019 à 04:06, Olivier Lamy a écrit :
> > >> > > > > >
> > >> > > > > > > so what is the status of this?
> > >> > > > > > > will we discuss in 2025 about being able to use java 8
> apis
> > >> or do
> > >> > > we
> > >> > > > > have
> > >> > > > > > > to wait 2030?
> > >> > > > > > > Sorry to be sarcastic but not moving forward it's
> certainly a
> > >> > > reason
> > >> > > > > why
> > >> > > > > > we
> > >> > > > > > > do not have more people participating in the project....
> > >> > > > > > > It is so frustrating to be stuck with old apis...
> > >> > > > > > >
> > >> > > > > > >
> > >> > > > > > >
> > >> > > > > > > On Thu, 10 Oct 2019 at 04:36, Tibor Digana wrote:
> > >> > > > > > >
> > >> > > > > > > > I have to fully agree on Michael Osipov. This
> discussion is
> > >> > > > > > > > contraproductive from the time perspective.
> > >> > > > > > > > He explained the situation in Maven very clearly that we
> > >> have
> > >> > > over
> > >> > > > > 1800
> > >> > > > > > > > bugs and here we are talking about javac compiler
> version
> > >> which
> > >> > > > does
> > >> > > > > > not
> > >> > > > > > > > fix these bugs.
> > >> > > > > > > > We know that our community is quite big but we also know
> > >> that
> > >> > we
> > >> > > > have
> > >> > > > > > > only
> > >> > > > > > > > few several developers who regularily provides fixes
> for the
> > >> > bug
> > >> > > > and
> > >> > > > > > they
> > >> > > > > > > > do it for free!
> > >> > > > > > > > So my advice is to leave these talks alone about
> technology
> > >> > lobby
> > >> > > > > (seen
> > >> > > > > > > on
> > >> > > > > > > > ML from outside as well) and rather concentrate on the
> bug.
> > >> We
> > >> > > have
> > >> > > > > > seen
> > >> > > > > > > > that the users/contributors handled performance issues
> and
> > >> > fixed
> > >> > > > them
> > >> > > > > > > which
> > >> > > > > > > > means that these contributors got very good proficiency
> > >> level!
> > >> > > > > > > >
> > >> > > > > > > > On Wed, Oct 9, 2019 at 7:56 PM Alexander Ashitkin <>
> > >> > > > > > > ashitkin.alex@gmail.com
> > >> > > > > > > > >
> > >> > > > > > > > wrote:
> > >> > > > > > > >
> > >> > > > > > > > > Totally disagree on the point. Writing java7 code
> after 8
> > >> > makes
> > >> > > > you
> > >> > > > > > > feel
> > >> > > > > > > > > suffering - because instead of expressive stream based
> > >> > > operations
> > >> > > > > and
> > >> > > > > > > > > lambdas you write pointless iterators and copy
> > >> collections.
> > >> > > > > > > > > It is purely subjective opinion that lambdas make code
> > >> less
> > >> > > > > readable
> > >> > > > > > -
> > >> > > > > > > at
> > >> > > > > > > > > least there is an absolutely opposite opinion
> > >> > > > > > > > >
> > >> > > > > > > > > Thank you
> > >> > > > > > > > > Aleks
> > >> > > > > > > > >
> > >> > > > > > > > > On 2019/10/03 12:47:35, Paul Hammant wrote:
> > >> > > > > > > > > > Who codes for 18 months before discovering that
> qa/prod
> > >> are
> > >> > > not
> > >> > > > > > > > > compatible,
> > >> > > > > > > > > > anymore? Especially if Google ship a use-this-Pom
> > >> starter.
> > >> > > > > > > > > >
> > >> > > > > > > > > > On Thu, Oct 3, 2019 at 1:44 PM Elliotte Rusty
> Harold <>
> > >> > > > > > > > elharo@ibiblio.org
> > >> > > > > > > > > >
> > >> > > > > > > > > > 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 <>
> > >> > > > > > > > > elharo@ibiblio.org
> > >> > > > > > > > > > > >
> > >> > > > > > > > > > > > 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 <>
> > >> > > > > > > > > rfscholte@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-unsubscribe@maven.apache.org
> > >> > > > > > > > > > > > > > For additional commands, e-mail:
> > >> > > > > dev-help@maven.apache.org
> > >> > > > > > > > > > > > > >
> > >> > > > > > > > > > > > >
> > >> > > > > > > > > > > > >
> > >> > > > > > > > > > > > > --
> > >> > > > > > > > > > > > > Elliotte Rusty Harold
> > >> > > > > > > > > > > > > elharo@ibiblio.org
> > >> > > > > > > > > > > > >
> > >> > > > > > > > > > > > >
> > >> > > > > > > > >
> > >> > > > >
> > >> ---------------------------------------------------------------------
> > >> > > > > > > > > > > > > To unsubscribe, e-mail:
> > >> > > dev-unsubscribe@maven.apache.org
> > >> > > > > > > > > > > > > For additional commands, e-mail:
> > >> > > > dev-help@maven.apache.org
> > >> > > > > > > > > > > > >
> > >> > > > > > > > > > > > >
> > >> > > > > > > > > > >
> > >> > > > > > > > > > >
> > >> > > > > > > > > > >
> > >> > > > > > > > > > > --
> > >> > > > > > > > > > > Elliotte Rusty Harold
> > >> > > > > > > > > > > elharo@ibiblio.org
> > >> > > > > > > > > > >
> > >> > > > > > > > > > >
> > >> > > > > > >
> > >> > >
> ---------------------------------------------------------------------
> > >> > > > > > > > > > > To unsubscribe, e-mail:
> > >> dev-unsubscribe@maven.apache.org
> > >> > > > > > > > > > > For additional commands, e-mail:
> > >> > dev-help@maven.apache.org
> > >> > > > > > > > > > >
> > >> > > > > > > > > > >
> > >> > > > > > > > > >
> > >> > > > > > > > >
> > >> > > > > > > > >
> > >> > > > >
> > >> ---------------------------------------------------------------------
> > >> > > > > > > > > To unsubscribe, e-mail:
> dev-unsubscribe@maven.apache.org
> > >> > > > > > > > > For additional commands, e-mail:
> > >> dev-help@maven.apache.org
> > >> > > > > > > > >
> > >> > > > > > > > >
> > >> > > > > > > >
> > >> > > > > > >
> > >> > > > > > >
> > >> > > > > > > --
> > >> > > > > > > Olivier Lamy
> > >> > > > > > > http://twitter.com/olamy | http://linkedin.com/in/olamy
> > >> > > > > > >
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: Re: [DISCUSS] Maven 3.7.0

[Robert Scholte <rf...@apache.org>]

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

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

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

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

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

Robert 
On 29-10-2019 14:00:49, Michael Osipov <19...@gmx.net> wrote:
Why not have 3.7.0 plugin updates and other non-technical stuff, have it
parallely maintained for some time and move with Maven 3.8.0 to Java 8 next year?!

Does that sound like a plan? I'd be happy with that. I'd also expect
an announcement on dev@, announce@ and users@.

Michael

> Gesendet: Dienstag, 29. Oktober 2019 um 13:49 Uhr
> Von: "Stephen Connolly"
> An: "Maven Developers List"
> Betreff: Re: [DISCUSS] Maven 3.7.0
>
> On Tue, 29 Oct 2019 at 12:47, Stephen Connolly <>
> stephen.alan.connolly@gmail.com> wrote:
>
> > We already have a version policy:
> > https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy
> >
>
> (while that page says draft, the proposal was on-list in 2014 and just
> converted into a wiki page afterwards - hence why the examples use 2014
> dates)
>
>
> > > The development line of Maven core should require a minimum JRE version
> > that is no older than 18 months after the end of Oracle's public updates
> > for that JRE version at the time that the first version of the development
> > line was released, but may require a higher minimum JRE version if other
> > requirements dictate a higher JRE version.
> >
> > End of public updates for Java 8 from Oracle was January 2019, thus if we
> > cut a new minor version we would be Java 8 but not Java 7.
> >
> >
> > On Tue, 29 Oct 2019 at 12:28, Tibor Digana wrote:
> >
> >> Stephen, we are in loop.
> >> Of course I know these technical things.
> >> But I am saying, and I am not alone (Michael Osipov too), that I agree
> >> with
> >> sources 1.8, but there must be1. the Vote with milestones regarding Maven
> >> and another Vote regarding plugins, and 2. written list of pros/cons
> >> regarding J8 and 3. developer guideline for J8 (for devs, consultants,
> >> another professions as well in the team).
> >> You know, with video calls, all these public emails would be gone within
> >> one or two hours, I am sure!
> >> I am also sure that we will have another code preferences and therefore we
> >> should have some guideline. For instance, I like to have clear OOP in the
> >> public class/interfaces and Lambda in private code. And there are a lot of
> >> stuff, like parallel streams ala thread pool of non-daemon threads,
> >> performance of streams (when, how stream is constructed, etc), Date Time
> >> API is new as well.
> >>
> >> No benefit for the community with J7 sources but yes with J8 code. Believe
> >> me, this is true. Michael mentioned that as well.
> >>
> >
> > Not true. Java 8 bytecode adds additional metadata that speeds up
> > classloading (but only when the class graph is all Java 8)
> >
> >
> >>
> >> It is also true that we have a lot of bugs, and it is true that Maven
> >> needs
> >> to have breakthrough features like reproducible build and User POM, Docker
> >> prefetched cache, etc.
> >> I have no argument against these things. The only problem that I have and
> >> Michael has is the way how this is managed but it is the only trivial
> >> problem that we can solve between us.
> >>
> >>
> >>
> >>
> >>
> >> On Tue, Oct 29, 2019 at 1:04 PM Stephen Connolly <>
> >> stephen.alan.connolly@gmail.com> wrote:
> >>
> >> > You cannot have Java 8 sources produce Java 7 bytecode with the Java 8's
> >> > javac.
> >> >
> >> > -target must be >= -source
> >> >
> >> > So to say:
> >> >
> >> > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
> >> >
> >> > Is not possible, you'll get something like:
> >> >
> >> > $ javac Test -source 1.8 -target 1.7
> >> > javac: source release 1.8 requires target release 1.8
> >> >
> >> > While we could use something like
> >> https://github.com/luontola/retrolambda
> >> > its usage is not without significant risks. You really need to be very
> >> > careful in how you use it, and the effort is IMHO far exceeding the
> >> risk.
> >> > Much better to just say Maven 3.7.0 is requires the runtime JVM be Java
> >> 8+,
> >> > use toolchains if you need to compile or unit tests with older JDKs.
> >> >
> >> > We have agreed before that upgrading the Maven minor or major version
> >> would
> >> > affect the JREs that Maven can run on. Basically following a one and one
> >> > back for Oracle supported JDKs, thus 3.7.0 per that policy would be
> >> forced
> >> > to Java 8 as minimum anyway.... in other words, our users should be
> >> > expecting us to go Java 8 as baseline.
> >> >
> >> > On Tue, 29 Oct 2019 at 10:28, Tibor Digana
> >> wrote:
> >> >
> >> > > Stephen, what issue with current toolchain you mean?
> >> > >
> >> > > On Tue, Oct 29, 2019 at 11:11 AM Stephen Connolly <>
> >> > > stephen.alan.connolly@gmail.com> wrote:
> >> > >
> >> > > > On Tue, 29 Oct 2019 at 08:02, Tibor Digana
> >> > > wrote:
> >> > > >
> >> > > > > Robert, I saw the code. The class has a method which returns
> >> Lambda
> >> > > > > function. The whole class was designed with OOP. The OOP is a good
> >> > > thing
> >> > > > > which you should follow and follow this approach and not to return
> >> > the
> >> > > > > labda function. Basically it is a precedense created in the PR
> >> saying
> >> > > > that
> >> > > > > now J8 has to be used in the bytecode.
> >> > > > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
> >> > > > >
> >> > > >
> >> > > > That is not possible using the current toolchains. Let's just go
> >> with
> >> > > Java
> >> > > > 8. There seems no good reason to hold back
> >> > > >
> >> > > >
> >> > > > >
> >> > > > > On Tue, Oct 29, 2019 at 8:25 AM Robert Scholte <>
> >> rfscholte@apache.org
> >> > >
> >> > > > > wrote:
> >> > > > >
> >> > > > > > The outcome is quite clear to me. There no clear 'No' to add
> >> this
> >> > > > > > build/consumer feature into 3.7.0, so we'll add it which
> >> implies we
> >> > > > must
> >> > > > > > move to Java 8 due to new APIs with Java 8 class signatures.
> >> > > > > >
> >> > > > > > But first we need to deliver a 3.6.3 regression release.
> >> > > > > >
> >> > > > > > Robert
> >> > > > > >
> >> > > > > > On 29-10-2019 05:53:25, Romain Manni-Bucau <>
> >> rmannibucau@gmail.com>
> >> > > > > wrote:
> >> > > > > > +1, the risk is more or less 0 since we can still use branches
> >> for
> >> > > > > > potential fixes for "old" projects using frozen java and maven
> >> > > versions
> >> > > > > > anyway
> >> > > > > >
> >> > > > > > Guess we can even be very precautionous doing 1. an upgrade to
> >> > > bytecode
> >> > > > > > version without any code change (to change the major version in
> >> > > > > bytecode),
> >> > > > > > 2. a M1 to let users test it if some still doubt.
> >> > > > > >
> >> > > > > > Le mar. 29 oct. 2019 à 04:06, Olivier Lamy a écrit :
> >> > > > > >
> >> > > > > > > so what is the status of this?
> >> > > > > > > will we discuss in 2025 about being able to use java 8 apis
> >> or do
> >> > > we
> >> > > > > have
> >> > > > > > > to wait 2030?
> >> > > > > > > Sorry to be sarcastic but not moving forward it's certainly a
> >> > > reason
> >> > > > > why
> >> > > > > > we
> >> > > > > > > do not have more people participating in the project....
> >> > > > > > > It is so frustrating to be stuck with old apis...
> >> > > > > > >
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > On Thu, 10 Oct 2019 at 04:36, Tibor Digana wrote:
> >> > > > > > >
> >> > > > > > > > I have to fully agree on Michael Osipov. This discussion is
> >> > > > > > > > contraproductive from the time perspective.
> >> > > > > > > > He explained the situation in Maven very clearly that we
> >> have
> >> > > over
> >> > > > > 1800
> >> > > > > > > > bugs and here we are talking about javac compiler version
> >> which
> >> > > > does
> >> > > > > > not
> >> > > > > > > > fix these bugs.
> >> > > > > > > > We know that our community is quite big but we also know
> >> that
> >> > we
> >> > > > have
> >> > > > > > > only
> >> > > > > > > > few several developers who regularily provides fixes for the
> >> > bug
> >> > > > and
> >> > > > > > they
> >> > > > > > > > do it for free!
> >> > > > > > > > So my advice is to leave these talks alone about technology
> >> > lobby
> >> > > > > (seen
> >> > > > > > > on
> >> > > > > > > > ML from outside as well) and rather concentrate on the bug.
> >> We
> >> > > have
> >> > > > > > seen
> >> > > > > > > > that the users/contributors handled performance issues and
> >> > fixed
> >> > > > them
> >> > > > > > > which
> >> > > > > > > > means that these contributors got very good proficiency
> >> level!
> >> > > > > > > >
> >> > > > > > > > On Wed, Oct 9, 2019 at 7:56 PM Alexander Ashitkin <>
> >> > > > > > > ashitkin.alex@gmail.com
> >> > > > > > > > >
> >> > > > > > > > wrote:
> >> > > > > > > >
> >> > > > > > > > > Totally disagree on the point. Writing java7 code after 8
> >> > makes
> >> > > > you
> >> > > > > > > feel
> >> > > > > > > > > suffering - because instead of expressive stream based
> >> > > operations
> >> > > > > and
> >> > > > > > > > > lambdas you write pointless iterators and copy
> >> collections.
> >> > > > > > > > > It is purely subjective opinion that lambdas make code
> >> less
> >> > > > > readable
> >> > > > > > -
> >> > > > > > > at
> >> > > > > > > > > least there is an absolutely opposite opinion
> >> > > > > > > > >
> >> > > > > > > > > Thank you
> >> > > > > > > > > Aleks
> >> > > > > > > > >
> >> > > > > > > > > On 2019/10/03 12:47:35, Paul Hammant wrote:
> >> > > > > > > > > > Who codes for 18 months before discovering that qa/prod
> >> are
> >> > > not
> >> > > > > > > > > compatible,
> >> > > > > > > > > > anymore? Especially if Google ship a use-this-Pom
> >> starter.
> >> > > > > > > > > >
> >> > > > > > > > > > On Thu, Oct 3, 2019 at 1:44 PM Elliotte Rusty Harold <>
> >> > > > > > > > elharo@ibiblio.org
> >> > > > > > > > > >
> >> > > > > > > > > > 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 <>
> >> > > > > > > > > elharo@ibiblio.org
> >> > > > > > > > > > > >
> >> > > > > > > > > > > > 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 <>
> >> > > > > > > > > rfscholte@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-unsubscribe@maven.apache.org
> >> > > > > > > > > > > > > > For additional commands, e-mail:
> >> > > > > dev-help@maven.apache.org
> >> > > > > > > > > > > > > >
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > > --
> >> > > > > > > > > > > > > Elliotte Rusty Harold
> >> > > > > > > > > > > > > elharo@ibiblio.org
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > >
> >> > > > > > > > >
> >> > > > >
> >> ---------------------------------------------------------------------
> >> > > > > > > > > > > > > To unsubscribe, e-mail:
> >> > > dev-unsubscribe@maven.apache.org
> >> > > > > > > > > > > > > For additional commands, e-mail:
> >> > > > dev-help@maven.apache.org
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > >
> >> > > > > > > > > > >
> >> > > > > > > > > > >
> >> > > > > > > > > > >
> >> > > > > > > > > > > --
> >> > > > > > > > > > > Elliotte Rusty Harold
> >> > > > > > > > > > > elharo@ibiblio.org
> >> > > > > > > > > > >
> >> > > > > > > > > > >
> >> > > > > > >
> >> > > ---------------------------------------------------------------------
> >> > > > > > > > > > > To unsubscribe, e-mail:
> >> dev-unsubscribe@maven.apache.org
> >> > > > > > > > > > > For additional commands, e-mail:
> >> > dev-help@maven.apache.org
> >> > > > > > > > > > >
> >> > > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > >
> >> > > > >
> >> ---------------------------------------------------------------------
> >> > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > > > > > > > > For additional commands, e-mail:
> >> dev-help@maven.apache.org
> >> > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > >
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > --
> >> > > > > > > Olivier Lamy
> >> > > > > > > http://twitter.com/olamy | http://linkedin.com/in/olamy
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
>

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

Re: Re: [DISCUSS] Maven 3.7.0

[Michael Osipov <19...@gmx.net>]

Why not have 3.7.0 plugin updates and other non-technical stuff, have it
parallely maintained for some time and move with Maven 3.8.0 to Java 8 next year?!

Does that sound like a plan? I'd be happy with that. I'd also expect
an announcement on dev@, announce@ and users@.

Michael

> Gesendet: Dienstag, 29. Oktober 2019 um 13:49 Uhr
> Von: "Stephen Connolly" <st...@gmail.com>
> An: "Maven Developers List" <de...@maven.apache.org>
> Betreff: Re: [DISCUSS] Maven 3.7.0
>
> On Tue, 29 Oct 2019 at 12:47, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
> 
> > We already have a version policy:
> > https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy
> >
> 
> (while that page says draft, the proposal was on-list in 2014 and just
> converted into a wiki page afterwards - hence why the examples use 2014
> dates)
> 
> 
> > > The development line of Maven core should require a minimum JRE version
> > that is no older than 18 months after the end of Oracle's public updates
> > for that JRE version at the time that the first version of the development
> > line was released, but may require a higher minimum JRE version if other
> > requirements dictate a higher JRE version.
> >
> > End of public updates for Java 8 from Oracle was January 2019, thus if we
> > cut a new minor version we would be Java 8 but not Java 7.
> >
> >
> > On Tue, 29 Oct 2019 at 12:28, Tibor Digana <ti...@apache.org> wrote:
> >
> >> Stephen, we are in loop.
> >> Of course I know these technical things.
> >> But I am saying, and I am not alone (Michael Osipov too), that I agree
> >> with
> >> sources 1.8, but there must be1.  the Vote with milestones regarding Maven
> >> and another Vote regarding plugins, and 2. written list of pros/cons
> >> regarding J8 and 3. developer guideline for J8 (for devs, consultants,
> >> another professions as well in the team).
> >> You know, with video calls, all these public emails would be gone within
> >> one or two hours, I am sure!
> >> I am also sure that we will have another code preferences and therefore we
> >> should have some guideline. For instance, I like to have clear OOP in the
> >> public class/interfaces and Lambda in private code. And there are a lot of
> >> stuff, like parallel streams ala thread pool of non-daemon threads,
> >> performance of streams (when, how stream is constructed, etc), Date Time
> >> API is new as well.
> >>
> >> No benefit for the community with J7 sources but yes with J8 code. Believe
> >> me, this is true. Michael mentioned that as well.
> >>
> >
> > Not true. Java 8 bytecode adds additional metadata that speeds up
> > classloading (but only when the class graph is all Java 8)
> >
> >
> >>
> >> It is also true that we have a lot of bugs, and it is true that Maven
> >> needs
> >> to have breakthrough features like reproducible build and User POM, Docker
> >> prefetched cache, etc.
> >> I have no argument against these things. The only problem that I have and
> >> Michael has is the way how this is managed but it is the only trivial
> >> problem that we can solve between us.
> >>
> >>
> >>
> >>
> >>
> >> On Tue, Oct 29, 2019 at 1:04 PM Stephen Connolly <
> >> stephen.alan.connolly@gmail.com> wrote:
> >>
> >> > You cannot have Java 8 sources produce Java 7 bytecode with the Java 8's
> >> > javac.
> >> >
> >> > -target must be >= -source
> >> >
> >> > So to say:
> >> >
> >> > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
> >> >
> >> > Is not possible, you'll get something like:
> >> >
> >> > $ javac Test -source 1.8 -target 1.7
> >> > javac: source release 1.8 requires target release 1.8
> >> >
> >> > While we could use something like
> >> https://github.com/luontola/retrolambda
> >> > its usage is not without significant risks. You really need to be very
> >> > careful in how you use it, and the effort is IMHO far exceeding the
> >> risk.
> >> > Much better to just say Maven 3.7.0 is requires the runtime JVM be Java
> >> 8+,
> >> > use toolchains if you need to compile or unit tests with older JDKs.
> >> >
> >> > We have agreed before that upgrading the Maven minor or major version
> >> would
> >> > affect the JREs that Maven can run on. Basically following a one and one
> >> > back for Oracle supported JDKs, thus 3.7.0 per that policy would be
> >> forced
> >> > to Java 8 as minimum anyway.... in other words, our users should be
> >> > expecting us to go Java 8 as baseline.
> >> >
> >> > On Tue, 29 Oct 2019 at 10:28, Tibor Digana <ti...@apache.org>
> >> wrote:
> >> >
> >> > > Stephen, what issue with current toolchain you mean?
> >> > >
> >> > > On Tue, Oct 29, 2019 at 11:11 AM Stephen Connolly <
> >> > > stephen.alan.connolly@gmail.com> wrote:
> >> > >
> >> > > > On Tue, 29 Oct 2019 at 08:02, Tibor Digana <ti...@apache.org>
> >> > > wrote:
> >> > > >
> >> > > > > Robert, I saw the code. The class has a method which returns
> >> Lambda
> >> > > > > function. The whole class was designed with OOP. The OOP is a good
> >> > > thing
> >> > > > > which you should follow and follow this approach and not to return
> >> > the
> >> > > > > labda function. Basically it is a precedense created in the PR
> >> saying
> >> > > > that
> >> > > > > now J8 has to be used in the bytecode.
> >> > > > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
> >> > > > >
> >> > > >
> >> > > > That is not possible using the current toolchains. Let's just go
> >> with
> >> > > Java
> >> > > > 8. There seems no good reason to hold back
> >> > > >
> >> > > >
> >> > > > >
> >> > > > > On Tue, Oct 29, 2019 at 8:25 AM Robert Scholte <
> >> rfscholte@apache.org
> >> > >
> >> > > > > wrote:
> >> > > > >
> >> > > > > > The outcome is quite clear to me. There no clear 'No' to add
> >> this
> >> > > > > > build/consumer feature into 3.7.0, so we'll add it which
> >> implies we
> >> > > > must
> >> > > > > > move to Java 8 due to new APIs with Java 8 class signatures.
> >> > > > > >
> >> > > > > > But first we need to deliver a 3.6.3 regression release.
> >> > > > > >
> >> > > > > > Robert
> >> > > > > >
> >> > > > > > On 29-10-2019 05:53:25, Romain Manni-Bucau <
> >> rmannibucau@gmail.com>
> >> > > > > wrote:
> >> > > > > > +1, the risk is more or less 0 since we can still use branches
> >> for
> >> > > > > > potential fixes for "old" projects using frozen java and maven
> >> > > versions
> >> > > > > > anyway
> >> > > > > >
> >> > > > > > Guess we can even be very precautionous doing 1. an upgrade to
> >> > > bytecode
> >> > > > > > version without any code change (to change the major version in
> >> > > > > bytecode),
> >> > > > > > 2. a M1 to let users test it if some still doubt.
> >> > > > > >
> >> > > > > > Le mar. 29 oct. 2019 à 04:06, Olivier Lamy a écrit :
> >> > > > > >
> >> > > > > > > so what is the status of this?
> >> > > > > > > will we discuss in 2025 about being able to use java 8 apis
> >> or do
> >> > > we
> >> > > > > have
> >> > > > > > > to wait 2030?
> >> > > > > > > Sorry to be sarcastic but not moving forward it's certainly a
> >> > > reason
> >> > > > > why
> >> > > > > > we
> >> > > > > > > do not have more people participating in the project....
> >> > > > > > > It is so frustrating to be stuck with old apis...
> >> > > > > > >
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > On Thu, 10 Oct 2019 at 04:36, Tibor Digana wrote:
> >> > > > > > >
> >> > > > > > > > I have to fully agree on Michael Osipov. This discussion is
> >> > > > > > > > contraproductive from the time perspective.
> >> > > > > > > > He explained the situation in Maven very clearly that we
> >> have
> >> > > over
> >> > > > > 1800
> >> > > > > > > > bugs and here we are talking about javac compiler version
> >> which
> >> > > > does
> >> > > > > > not
> >> > > > > > > > fix these bugs.
> >> > > > > > > > We know that our community is quite big but we also know
> >> that
> >> > we
> >> > > > have
> >> > > > > > > only
> >> > > > > > > > few several developers who regularily provides fixes for the
> >> > bug
> >> > > > and
> >> > > > > > they
> >> > > > > > > > do it for free!
> >> > > > > > > > So my advice is to leave these talks alone about technology
> >> > lobby
> >> > > > > (seen
> >> > > > > > > on
> >> > > > > > > > ML from outside as well) and rather concentrate on the bug.
> >> We
> >> > > have
> >> > > > > > seen
> >> > > > > > > > that the users/contributors handled performance issues and
> >> > fixed
> >> > > > them
> >> > > > > > > which
> >> > > > > > > > means that these contributors got very good proficiency
> >> level!
> >> > > > > > > >
> >> > > > > > > > On Wed, Oct 9, 2019 at 7:56 PM Alexander Ashitkin <>
> >> > > > > > > ashitkin.alex@gmail.com
> >> > > > > > > > >
> >> > > > > > > > wrote:
> >> > > > > > > >
> >> > > > > > > > > Totally disagree on the point. Writing java7 code after 8
> >> > makes
> >> > > > you
> >> > > > > > > feel
> >> > > > > > > > > suffering - because instead of expressive stream based
> >> > > operations
> >> > > > > and
> >> > > > > > > > > lambdas you write pointless iterators and copy
> >> collections.
> >> > > > > > > > > It is purely subjective opinion that lambdas make code
> >> less
> >> > > > > readable
> >> > > > > > -
> >> > > > > > > at
> >> > > > > > > > > least there is an absolutely opposite opinion
> >> > > > > > > > >
> >> > > > > > > > > Thank you
> >> > > > > > > > > Aleks
> >> > > > > > > > >
> >> > > > > > > > > On 2019/10/03 12:47:35, Paul Hammant wrote:
> >> > > > > > > > > > Who codes for 18 months before discovering that qa/prod
> >> are
> >> > > not
> >> > > > > > > > > compatible,
> >> > > > > > > > > > anymore? Especially if Google ship a use-this-Pom
> >> starter.
> >> > > > > > > > > >
> >> > > > > > > > > > On Thu, Oct 3, 2019 at 1:44 PM Elliotte Rusty Harold <>
> >> > > > > > > > elharo@ibiblio.org
> >> > > > > > > > > >
> >> > > > > > > > > > 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 <>
> >> > > > > > > > > elharo@ibiblio.org
> >> > > > > > > > > > > >
> >> > > > > > > > > > > > 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 <>
> >> > > > > > > > > rfscholte@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-unsubscribe@maven.apache.org
> >> > > > > > > > > > > > > > For additional commands, e-mail:
> >> > > > > dev-help@maven.apache.org
> >> > > > > > > > > > > > > >
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > > --
> >> > > > > > > > > > > > > Elliotte Rusty Harold
> >> > > > > > > > > > > > > elharo@ibiblio.org
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > >
> >> > > > > > > > >
> >> > > > >
> >> ---------------------------------------------------------------------
> >> > > > > > > > > > > > > To unsubscribe, e-mail:
> >> > > dev-unsubscribe@maven.apache.org
> >> > > > > > > > > > > > > For additional commands, e-mail:
> >> > > > dev-help@maven.apache.org
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > >
> >> > > > > > > > > > >
> >> > > > > > > > > > >
> >> > > > > > > > > > >
> >> > > > > > > > > > > --
> >> > > > > > > > > > > Elliotte Rusty Harold
> >> > > > > > > > > > > elharo@ibiblio.org
> >> > > > > > > > > > >
> >> > > > > > > > > > >
> >> > > > > > >
> >> > > ---------------------------------------------------------------------
> >> > > > > > > > > > > To unsubscribe, e-mail:
> >> dev-unsubscribe@maven.apache.org
> >> > > > > > > > > > > For additional commands, e-mail:
> >> > dev-help@maven.apache.org
> >> > > > > > > > > > >
> >> > > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > >
> >> > > > >
> >> ---------------------------------------------------------------------
> >> > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > > > > > > > > For additional commands, e-mail:
> >> dev-help@maven.apache.org
> >> > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > >
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > --
> >> > > > > > > Olivier Lamy
> >> > > > > > > http://twitter.com/olamy | http://linkedin.com/in/olamy
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
>

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

Re: [DISCUSS] Maven 3.7.0

[Stephen Connolly <st...@gmail.com>]

On Tue, 29 Oct 2019 at 12:49, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

> On Tue, 29 Oct 2019 at 12:47, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
>> We already have a version policy:
>> https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy
>>
>
> (while that page says draft, the proposal was on-list in 2014 and just
> converted into a wiki page afterwards - hence why the examples use 2014
> dates)
>

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


>
>> > The development line of Maven core should require a minimum JRE version
>> that is no older than 18 months after the end of Oracle's public updates
>> for that JRE version at the time that the first version of the development
>> line was released, but may require a higher minimum JRE version if other
>> requirements dictate a higher JRE version.
>>
>> End of public updates for Java 8 from Oracle was January 2019, thus if we
>> cut a new minor version we would be Java 8 but not Java 7.
>>
>>
>> On Tue, 29 Oct 2019 at 12:28, Tibor Digana <ti...@apache.org>
>> wrote:
>>
>>> Stephen, we are in loop.
>>> Of course I know these technical things.
>>> But I am saying, and I am not alone (Michael Osipov too), that I agree
>>> with
>>> sources 1.8, but there must be1.  the Vote with milestones regarding
>>> Maven
>>> and another Vote regarding plugins, and 2. written list of pros/cons
>>> regarding J8 and 3. developer guideline for J8 (for devs, consultants,
>>> another professions as well in the team).
>>> You know, with video calls, all these public emails would be gone within
>>> one or two hours, I am sure!
>>> I am also sure that we will have another code preferences and therefore
>>> we
>>> should have some guideline. For instance, I like to have clear OOP in the
>>> public class/interfaces and Lambda in private code. And there are a lot
>>> of
>>> stuff, like parallel streams ala thread pool of non-daemon threads,
>>> performance of streams (when, how stream is constructed, etc), Date Time
>>> API is new as well.
>>>
>>> No benefit for the community with J7 sources but yes with J8 code.
>>> Believe
>>> me, this is true. Michael mentioned that as well.
>>>
>>
>> Not true. Java 8 bytecode adds additional metadata that speeds up
>> classloading (but only when the class graph is all Java 8)
>>
>>
>>>
>>> It is also true that we have a lot of bugs, and it is true that Maven
>>> needs
>>> to have breakthrough features like reproducible build and User POM,
>>> Docker
>>> prefetched cache, etc.
>>> I have no argument against these things. The only problem that I have and
>>> Michael has is the way how this is managed but it is the only trivial
>>> problem that we can solve between us.
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Oct 29, 2019 at 1:04 PM Stephen Connolly <
>>> stephen.alan.connolly@gmail.com> wrote:
>>>
>>> > You cannot have Java 8 sources produce Java 7 bytecode with the Java
>>> 8's
>>> > javac.
>>> >
>>> > -target must be >= -source
>>> >
>>> > So to say:
>>> >
>>> > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
>>> >
>>> > Is not possible, you'll get something like:
>>> >
>>> > $ javac Test -source 1.8 -target 1.7
>>> > javac: source release 1.8 requires target release 1.8
>>> >
>>> > While we could use something like
>>> https://github.com/luontola/retrolambda
>>> > its usage is not without significant risks. You really need to be very
>>> > careful in how you use it, and the effort is IMHO far exceeding the
>>> risk.
>>> > Much better to just say Maven 3.7.0 is requires the runtime JVM be
>>> Java 8+,
>>> > use toolchains if you need to compile or unit tests with older JDKs.
>>> >
>>> > We have agreed before that upgrading the Maven minor or major version
>>> would
>>> > affect the JREs that Maven can run on. Basically following a one and
>>> one
>>> > back for Oracle supported JDKs, thus 3.7.0 per that policy would be
>>> forced
>>> > to Java 8 as minimum anyway.... in other words, our users should be
>>> > expecting us to go Java 8 as baseline.
>>> >
>>> > On Tue, 29 Oct 2019 at 10:28, Tibor Digana <ti...@apache.org>
>>> wrote:
>>> >
>>> > > Stephen, what issue with current toolchain you mean?
>>> > >
>>> > > On Tue, Oct 29, 2019 at 11:11 AM Stephen Connolly <
>>> > > stephen.alan.connolly@gmail.com> wrote:
>>> > >
>>> > > > On Tue, 29 Oct 2019 at 08:02, Tibor Digana <tibordigana@apache.org
>>> >
>>> > > wrote:
>>> > > >
>>> > > > > Robert, I saw the code. The class has a method which returns
>>> Lambda
>>> > > > > function. The whole class was designed with OOP. The OOP is a
>>> good
>>> > > thing
>>> > > > > which you should follow and follow this approach and not to
>>> return
>>> > the
>>> > > > > labda function. Basically it is a precedense created in the PR
>>> saying
>>> > > > that
>>> > > > > now J8 has to be used in the bytecode.
>>> > > > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
>>> > > > >
>>> > > >
>>> > > > That is not possible using the current toolchains. Let's just go
>>> with
>>> > > Java
>>> > > > 8. There seems no good reason to hold back
>>> > > >
>>> > > >
>>> > > > >
>>> > > > > On Tue, Oct 29, 2019 at 8:25 AM Robert Scholte <
>>> rfscholte@apache.org
>>> > >
>>> > > > > wrote:
>>> > > > >
>>> > > > > > The outcome is quite clear to me. There no clear 'No' to add
>>> this
>>> > > > > > build/consumer feature into 3.7.0, so we'll add it which
>>> implies we
>>> > > > must
>>> > > > > > move to Java 8 due to new APIs with Java 8 class signatures.
>>> > > > > >
>>> > > > > > But first we need to deliver a 3.6.3 regression release.
>>> > > > > >
>>> > > > > > Robert
>>> > > > > >
>>> > > > > > On 29-10-2019 05:53:25, Romain Manni-Bucau <
>>> rmannibucau@gmail.com>
>>> > > > > wrote:
>>> > > > > > +1, the risk is more or less 0 since we can still use branches
>>> for
>>> > > > > > potential fixes for "old" projects using frozen java and maven
>>> > > versions
>>> > > > > > anyway
>>> > > > > >
>>> > > > > > Guess we can even be very precautionous doing 1. an upgrade to
>>> > > bytecode
>>> > > > > > version without any code change (to change the major version in
>>> > > > > bytecode),
>>> > > > > > 2. a M1 to let users test it if some still doubt.
>>> > > > > >
>>> > > > > > Le mar. 29 oct. 2019 à 04:06, Olivier Lamy a écrit :
>>> > > > > >
>>> > > > > > > so what is the status of this?
>>> > > > > > > will we discuss in 2025 about being able to use java 8 apis
>>> or do
>>> > > we
>>> > > > > have
>>> > > > > > > to wait 2030?
>>> > > > > > > Sorry to be sarcastic but not moving forward it's certainly a
>>> > > reason
>>> > > > > why
>>> > > > > > we
>>> > > > > > > do not have more people participating in the project....
>>> > > > > > > It is so frustrating to be stuck with old apis...
>>> > > > > > >
>>> > > > > > >
>>> > > > > > >
>>> > > > > > > On Thu, 10 Oct 2019 at 04:36, Tibor Digana wrote:
>>> > > > > > >
>>> > > > > > > > I have to fully agree on Michael Osipov. This discussion is
>>> > > > > > > > contraproductive from the time perspective.
>>> > > > > > > > He explained the situation in Maven very clearly that we
>>> have
>>> > > over
>>> > > > > 1800
>>> > > > > > > > bugs and here we are talking about javac compiler version
>>> which
>>> > > > does
>>> > > > > > not
>>> > > > > > > > fix these bugs.
>>> > > > > > > > We know that our community is quite big but we also know
>>> that
>>> > we
>>> > > > have
>>> > > > > > > only
>>> > > > > > > > few several developers who regularily provides fixes for
>>> the
>>> > bug
>>> > > > and
>>> > > > > > they
>>> > > > > > > > do it for free!
>>> > > > > > > > So my advice is to leave these talks alone about technology
>>> > lobby
>>> > > > > (seen
>>> > > > > > > on
>>> > > > > > > > ML from outside as well) and rather concentrate on the
>>> bug. We
>>> > > have
>>> > > > > > seen
>>> > > > > > > > that the users/contributors handled performance issues and
>>> > fixed
>>> > > > them
>>> > > > > > > which
>>> > > > > > > > means that these contributors got very good proficiency
>>> level!
>>> > > > > > > >
>>> > > > > > > > On Wed, Oct 9, 2019 at 7:56 PM Alexander Ashitkin <>
>>> > > > > > > ashitkin.alex@gmail.com
>>> > > > > > > > >
>>> > > > > > > > wrote:
>>> > > > > > > >
>>> > > > > > > > > Totally disagree on the point. Writing java7 code after 8
>>> > makes
>>> > > > you
>>> > > > > > > feel
>>> > > > > > > > > suffering - because instead of expressive stream based
>>> > > operations
>>> > > > > and
>>> > > > > > > > > lambdas you write pointless iterators and copy
>>> collections.
>>> > > > > > > > > It is purely subjective opinion that lambdas make code
>>> less
>>> > > > > readable
>>> > > > > > -
>>> > > > > > > at
>>> > > > > > > > > least there is an absolutely opposite opinion
>>> > > > > > > > >
>>> > > > > > > > > Thank you
>>> > > > > > > > > Aleks
>>> > > > > > > > >
>>> > > > > > > > > On 2019/10/03 12:47:35, Paul Hammant wrote:
>>> > > > > > > > > > Who codes for 18 months before discovering that
>>> qa/prod are
>>> > > not
>>> > > > > > > > > compatible,
>>> > > > > > > > > > anymore? Especially if Google ship a use-this-Pom
>>> starter.
>>> > > > > > > > > >
>>> > > > > > > > > > On Thu, Oct 3, 2019 at 1:44 PM Elliotte Rusty Harold <>
>>> > > > > > > > elharo@ibiblio.org
>>> > > > > > > > > >
>>> > > > > > > > > > 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 <>
>>> > > > > > > > > elharo@ibiblio.org
>>> > > > > > > > > > > >
>>> > > > > > > > > > > > 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 <>
>>> > > > > > > > > rfscholte@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-unsubscribe@maven.apache.org
>>> > > > > > > > > > > > > > For additional commands, e-mail:
>>> > > > > dev-help@maven.apache.org
>>> > > > > > > > > > > > > >
>>> > > > > > > > > > > > >
>>> > > > > > > > > > > > >
>>> > > > > > > > > > > > > --
>>> > > > > > > > > > > > > Elliotte Rusty Harold
>>> > > > > > > > > > > > > elharo@ibiblio.org
>>> > > > > > > > > > > > >
>>> > > > > > > > > > > > >
>>> > > > > > > > >
>>> > > > >
>>> ---------------------------------------------------------------------
>>> > > > > > > > > > > > > To unsubscribe, e-mail:
>>> > > dev-unsubscribe@maven.apache.org
>>> > > > > > > > > > > > > For additional commands, e-mail:
>>> > > > dev-help@maven.apache.org
>>> > > > > > > > > > > > >
>>> > > > > > > > > > > > >
>>> > > > > > > > > > >
>>> > > > > > > > > > >
>>> > > > > > > > > > >
>>> > > > > > > > > > > --
>>> > > > > > > > > > > Elliotte Rusty Harold
>>> > > > > > > > > > > elharo@ibiblio.org
>>> > > > > > > > > > >
>>> > > > > > > > > > >
>>> > > > > > >
>>> > > ---------------------------------------------------------------------
>>> > > > > > > > > > > To unsubscribe, e-mail:
>>> dev-unsubscribe@maven.apache.org
>>> > > > > > > > > > > For additional commands, e-mail:
>>> > dev-help@maven.apache.org
>>> > > > > > > > > > >
>>> > > > > > > > > > >
>>> > > > > > > > > >
>>> > > > > > > > >
>>> > > > > > > > >
>>> > > > >
>>> ---------------------------------------------------------------------
>>> > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> > > > > > > > > For additional commands, e-mail:
>>> dev-help@maven.apache.org
>>> > > > > > > > >
>>> > > > > > > > >
>>> > > > > > > >
>>> > > > > > >
>>> > > > > > >
>>> > > > > > > --
>>> > > > > > > Olivier Lamy
>>> > > > > > > http://twitter.com/olamy | http://linkedin.com/in/olamy
>>> > > > > > >
>>> > > > > >
>>> > > > >
>>> > > >
>>> > >
>>> >
>>>
>>

Re: [DISCUSS] Maven 3.7.0

[Stephen Connolly <st...@gmail.com>]

On Tue, 29 Oct 2019 at 12:47, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

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

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


> > The development line of Maven core should require a minimum JRE version
> that is no older than 18 months after the end of Oracle's public updates
> for that JRE version at the time that the first version of the development
> line was released, but may require a higher minimum JRE version if other
> requirements dictate a higher JRE version.
>
> End of public updates for Java 8 from Oracle was January 2019, thus if we
> cut a new minor version we would be Java 8 but not Java 7.
>
>
> On Tue, 29 Oct 2019 at 12:28, Tibor Digana <ti...@apache.org> wrote:
>
>> Stephen, we are in loop.
>> Of course I know these technical things.
>> But I am saying, and I am not alone (Michael Osipov too), that I agree
>> with
>> sources 1.8, but there must be1.  the Vote with milestones regarding Maven
>> and another Vote regarding plugins, and 2. written list of pros/cons
>> regarding J8 and 3. developer guideline for J8 (for devs, consultants,
>> another professions as well in the team).
>> You know, with video calls, all these public emails would be gone within
>> one or two hours, I am sure!
>> I am also sure that we will have another code preferences and therefore we
>> should have some guideline. For instance, I like to have clear OOP in the
>> public class/interfaces and Lambda in private code. And there are a lot of
>> stuff, like parallel streams ala thread pool of non-daemon threads,
>> performance of streams (when, how stream is constructed, etc), Date Time
>> API is new as well.
>>
>> No benefit for the community with J7 sources but yes with J8 code. Believe
>> me, this is true. Michael mentioned that as well.
>>
>
> Not true. Java 8 bytecode adds additional metadata that speeds up
> classloading (but only when the class graph is all Java 8)
>
>
>>
>> It is also true that we have a lot of bugs, and it is true that Maven
>> needs
>> to have breakthrough features like reproducible build and User POM, Docker
>> prefetched cache, etc.
>> I have no argument against these things. The only problem that I have and
>> Michael has is the way how this is managed but it is the only trivial
>> problem that we can solve between us.
>>
>>
>>
>>
>>
>> On Tue, Oct 29, 2019 at 1:04 PM Stephen Connolly <
>> stephen.alan.connolly@gmail.com> wrote:
>>
>> > You cannot have Java 8 sources produce Java 7 bytecode with the Java 8's
>> > javac.
>> >
>> > -target must be >= -source
>> >
>> > So to say:
>> >
>> > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
>> >
>> > Is not possible, you'll get something like:
>> >
>> > $ javac Test -source 1.8 -target 1.7
>> > javac: source release 1.8 requires target release 1.8
>> >
>> > While we could use something like
>> https://github.com/luontola/retrolambda
>> > its usage is not without significant risks. You really need to be very
>> > careful in how you use it, and the effort is IMHO far exceeding the
>> risk.
>> > Much better to just say Maven 3.7.0 is requires the runtime JVM be Java
>> 8+,
>> > use toolchains if you need to compile or unit tests with older JDKs.
>> >
>> > We have agreed before that upgrading the Maven minor or major version
>> would
>> > affect the JREs that Maven can run on. Basically following a one and one
>> > back for Oracle supported JDKs, thus 3.7.0 per that policy would be
>> forced
>> > to Java 8 as minimum anyway.... in other words, our users should be
>> > expecting us to go Java 8 as baseline.
>> >
>> > On Tue, 29 Oct 2019 at 10:28, Tibor Digana <ti...@apache.org>
>> wrote:
>> >
>> > > Stephen, what issue with current toolchain you mean?
>> > >
>> > > On Tue, Oct 29, 2019 at 11:11 AM Stephen Connolly <
>> > > stephen.alan.connolly@gmail.com> wrote:
>> > >
>> > > > On Tue, 29 Oct 2019 at 08:02, Tibor Digana <ti...@apache.org>
>> > > wrote:
>> > > >
>> > > > > Robert, I saw the code. The class has a method which returns
>> Lambda
>> > > > > function. The whole class was designed with OOP. The OOP is a good
>> > > thing
>> > > > > which you should follow and follow this approach and not to return
>> > the
>> > > > > labda function. Basically it is a precedense created in the PR
>> saying
>> > > > that
>> > > > > now J8 has to be used in the bytecode.
>> > > > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
>> > > > >
>> > > >
>> > > > That is not possible using the current toolchains. Let's just go
>> with
>> > > Java
>> > > > 8. There seems no good reason to hold back
>> > > >
>> > > >
>> > > > >
>> > > > > On Tue, Oct 29, 2019 at 8:25 AM Robert Scholte <
>> rfscholte@apache.org
>> > >
>> > > > > wrote:
>> > > > >
>> > > > > > The outcome is quite clear to me. There no clear 'No' to add
>> this
>> > > > > > build/consumer feature into 3.7.0, so we'll add it which
>> implies we
>> > > > must
>> > > > > > move to Java 8 due to new APIs with Java 8 class signatures.
>> > > > > >
>> > > > > > But first we need to deliver a 3.6.3 regression release.
>> > > > > >
>> > > > > > Robert
>> > > > > >
>> > > > > > On 29-10-2019 05:53:25, Romain Manni-Bucau <
>> rmannibucau@gmail.com>
>> > > > > wrote:
>> > > > > > +1, the risk is more or less 0 since we can still use branches
>> for
>> > > > > > potential fixes for "old" projects using frozen java and maven
>> > > versions
>> > > > > > anyway
>> > > > > >
>> > > > > > Guess we can even be very precautionous doing 1. an upgrade to
>> > > bytecode
>> > > > > > version without any code change (to change the major version in
>> > > > > bytecode),
>> > > > > > 2. a M1 to let users test it if some still doubt.
>> > > > > >
>> > > > > > Le mar. 29 oct. 2019 à 04:06, Olivier Lamy a écrit :
>> > > > > >
>> > > > > > > so what is the status of this?
>> > > > > > > will we discuss in 2025 about being able to use java 8 apis
>> or do
>> > > we
>> > > > > have
>> > > > > > > to wait 2030?
>> > > > > > > Sorry to be sarcastic but not moving forward it's certainly a
>> > > reason
>> > > > > why
>> > > > > > we
>> > > > > > > do not have more people participating in the project....
>> > > > > > > It is so frustrating to be stuck with old apis...
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > On Thu, 10 Oct 2019 at 04:36, Tibor Digana wrote:
>> > > > > > >
>> > > > > > > > I have to fully agree on Michael Osipov. This discussion is
>> > > > > > > > contraproductive from the time perspective.
>> > > > > > > > He explained the situation in Maven very clearly that we
>> have
>> > > over
>> > > > > 1800
>> > > > > > > > bugs and here we are talking about javac compiler version
>> which
>> > > > does
>> > > > > > not
>> > > > > > > > fix these bugs.
>> > > > > > > > We know that our community is quite big but we also know
>> that
>> > we
>> > > > have
>> > > > > > > only
>> > > > > > > > few several developers who regularily provides fixes for the
>> > bug
>> > > > and
>> > > > > > they
>> > > > > > > > do it for free!
>> > > > > > > > So my advice is to leave these talks alone about technology
>> > lobby
>> > > > > (seen
>> > > > > > > on
>> > > > > > > > ML from outside as well) and rather concentrate on the bug.
>> We
>> > > have
>> > > > > > seen
>> > > > > > > > that the users/contributors handled performance issues and
>> > fixed
>> > > > them
>> > > > > > > which
>> > > > > > > > means that these contributors got very good proficiency
>> level!
>> > > > > > > >
>> > > > > > > > On Wed, Oct 9, 2019 at 7:56 PM Alexander Ashitkin <>
>> > > > > > > ashitkin.alex@gmail.com
>> > > > > > > > >
>> > > > > > > > wrote:
>> > > > > > > >
>> > > > > > > > > Totally disagree on the point. Writing java7 code after 8
>> > makes
>> > > > you
>> > > > > > > feel
>> > > > > > > > > suffering - because instead of expressive stream based
>> > > operations
>> > > > > and
>> > > > > > > > > lambdas you write pointless iterators and copy
>> collections.
>> > > > > > > > > It is purely subjective opinion that lambdas make code
>> less
>> > > > > readable
>> > > > > > -
>> > > > > > > at
>> > > > > > > > > least there is an absolutely opposite opinion
>> > > > > > > > >
>> > > > > > > > > Thank you
>> > > > > > > > > Aleks
>> > > > > > > > >
>> > > > > > > > > On 2019/10/03 12:47:35, Paul Hammant wrote:
>> > > > > > > > > > Who codes for 18 months before discovering that qa/prod
>> are
>> > > not
>> > > > > > > > > compatible,
>> > > > > > > > > > anymore? Especially if Google ship a use-this-Pom
>> starter.
>> > > > > > > > > >
>> > > > > > > > > > On Thu, Oct 3, 2019 at 1:44 PM Elliotte Rusty Harold <>
>> > > > > > > > elharo@ibiblio.org
>> > > > > > > > > >
>> > > > > > > > > > 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 <>
>> > > > > > > > > elharo@ibiblio.org
>> > > > > > > > > > > >
>> > > > > > > > > > > > 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 <>
>> > > > > > > > > rfscholte@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-unsubscribe@maven.apache.org
>> > > > > > > > > > > > > > For additional commands, e-mail:
>> > > > > dev-help@maven.apache.org
>> > > > > > > > > > > > > >
>> > > > > > > > > > > > >
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > --
>> > > > > > > > > > > > > Elliotte Rusty Harold
>> > > > > > > > > > > > > elharo@ibiblio.org
>> > > > > > > > > > > > >
>> > > > > > > > > > > > >
>> > > > > > > > >
>> > > > >
>> ---------------------------------------------------------------------
>> > > > > > > > > > > > > To unsubscribe, e-mail:
>> > > dev-unsubscribe@maven.apache.org
>> > > > > > > > > > > > > For additional commands, e-mail:
>> > > > dev-help@maven.apache.org
>> > > > > > > > > > > > >
>> > > > > > > > > > > > >
>> > > > > > > > > > >
>> > > > > > > > > > >
>> > > > > > > > > > >
>> > > > > > > > > > > --
>> > > > > > > > > > > Elliotte Rusty Harold
>> > > > > > > > > > > elharo@ibiblio.org
>> > > > > > > > > > >
>> > > > > > > > > > >
>> > > > > > >
>> > > ---------------------------------------------------------------------
>> > > > > > > > > > > To unsubscribe, e-mail:
>> dev-unsubscribe@maven.apache.org
>> > > > > > > > > > > For additional commands, e-mail:
>> > dev-help@maven.apache.org
>> > > > > > > > > > >
>> > > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > >
>> > > > > > > > >
>> > > > >
>> ---------------------------------------------------------------------
>> > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > > > > > > > > For additional commands, e-mail:
>> dev-help@maven.apache.org
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > --
>> > > > > > > Olivier Lamy
>> > > > > > > http://twitter.com/olamy | http://linkedin.com/in/olamy
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>

Re: [DISCUSS] Maven 3.7.0

[Stephen Connolly <st...@gmail.com>]

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

> The development line of Maven core should require a minimum JRE version
that is no older than 18 months after the end of Oracle's public updates
for that JRE version at the time that the first version of the development
line was released, but may require a higher minimum JRE version if other
requirements dictate a higher JRE version.

End of public updates for Java 8 from Oracle was January 2019, thus if we
cut a new minor version we would be Java 8 but not Java 7.


On Tue, 29 Oct 2019 at 12:28, Tibor Digana <ti...@apache.org> wrote:

> Stephen, we are in loop.
> Of course I know these technical things.
> But I am saying, and I am not alone (Michael Osipov too), that I agree with
> sources 1.8, but there must be1.  the Vote with milestones regarding Maven
> and another Vote regarding plugins, and 2. written list of pros/cons
> regarding J8 and 3. developer guideline for J8 (for devs, consultants,
> another professions as well in the team).
> You know, with video calls, all these public emails would be gone within
> one or two hours, I am sure!
> I am also sure that we will have another code preferences and therefore we
> should have some guideline. For instance, I like to have clear OOP in the
> public class/interfaces and Lambda in private code. And there are a lot of
> stuff, like parallel streams ala thread pool of non-daemon threads,
> performance of streams (when, how stream is constructed, etc), Date Time
> API is new as well.
>
> No benefit for the community with J7 sources but yes with J8 code. Believe
> me, this is true. Michael mentioned that as well.
>

Not true. Java 8 bytecode adds additional metadata that speeds up
classloading (but only when the class graph is all Java 8)


>
> It is also true that we have a lot of bugs, and it is true that Maven needs
> to have breakthrough features like reproducible build and User POM, Docker
> prefetched cache, etc.
> I have no argument against these things. The only problem that I have and
> Michael has is the way how this is managed but it is the only trivial
> problem that we can solve between us.
>
>
>
>
>
> On Tue, Oct 29, 2019 at 1:04 PM Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> > You cannot have Java 8 sources produce Java 7 bytecode with the Java 8's
> > javac.
> >
> > -target must be >= -source
> >
> > So to say:
> >
> > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
> >
> > Is not possible, you'll get something like:
> >
> > $ javac Test -source 1.8 -target 1.7
> > javac: source release 1.8 requires target release 1.8
> >
> > While we could use something like
> https://github.com/luontola/retrolambda
> > its usage is not without significant risks. You really need to be very
> > careful in how you use it, and the effort is IMHO far exceeding the risk.
> > Much better to just say Maven 3.7.0 is requires the runtime JVM be Java
> 8+,
> > use toolchains if you need to compile or unit tests with older JDKs.
> >
> > We have agreed before that upgrading the Maven minor or major version
> would
> > affect the JREs that Maven can run on. Basically following a one and one
> > back for Oracle supported JDKs, thus 3.7.0 per that policy would be
> forced
> > to Java 8 as minimum anyway.... in other words, our users should be
> > expecting us to go Java 8 as baseline.
> >
> > On Tue, 29 Oct 2019 at 10:28, Tibor Digana <ti...@apache.org>
> wrote:
> >
> > > Stephen, what issue with current toolchain you mean?
> > >
> > > On Tue, Oct 29, 2019 at 11:11 AM Stephen Connolly <
> > > stephen.alan.connolly@gmail.com> wrote:
> > >
> > > > On Tue, 29 Oct 2019 at 08:02, Tibor Digana <ti...@apache.org>
> > > wrote:
> > > >
> > > > > Robert, I saw the code. The class has a method which returns Lambda
> > > > > function. The whole class was designed with OOP. The OOP is a good
> > > thing
> > > > > which you should follow and follow this approach and not to return
> > the
> > > > > labda function. Basically it is a precedense created in the PR
> saying
> > > > that
> > > > > now J8 has to be used in the bytecode.
> > > > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
> > > > >
> > > >
> > > > That is not possible using the current toolchains. Let's just go with
> > > Java
> > > > 8. There seems no good reason to hold back
> > > >
> > > >
> > > > >
> > > > > On Tue, Oct 29, 2019 at 8:25 AM Robert Scholte <
> rfscholte@apache.org
> > >
> > > > > wrote:
> > > > >
> > > > > > The outcome is quite clear to me. There no clear 'No' to add this
> > > > > > build/consumer feature into 3.7.0, so we'll add it which implies
> we
> > > > must
> > > > > > move to Java 8 due to new APIs with Java 8 class signatures.
> > > > > >
> > > > > > But first we need to deliver a 3.6.3 regression release.
> > > > > >
> > > > > > Robert
> > > > > >
> > > > > > On 29-10-2019 05:53:25, Romain Manni-Bucau <
> rmannibucau@gmail.com>
> > > > > wrote:
> > > > > > +1, the risk is more or less 0 since we can still use branches
> for
> > > > > > potential fixes for "old" projects using frozen java and maven
> > > versions
> > > > > > anyway
> > > > > >
> > > > > > Guess we can even be very precautionous doing 1. an upgrade to
> > > bytecode
> > > > > > version without any code change (to change the major version in
> > > > > bytecode),
> > > > > > 2. a M1 to let users test it if some still doubt.
> > > > > >
> > > > > > Le mar. 29 oct. 2019 à 04:06, Olivier Lamy a écrit :
> > > > > >
> > > > > > > so what is the status of this?
> > > > > > > will we discuss in 2025 about being able to use java 8 apis or
> do
> > > we
> > > > > have
> > > > > > > to wait 2030?
> > > > > > > Sorry to be sarcastic but not moving forward it's certainly a
> > > reason
> > > > > why
> > > > > > we
> > > > > > > do not have more people participating in the project....
> > > > > > > It is so frustrating to be stuck with old apis...
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Thu, 10 Oct 2019 at 04:36, Tibor Digana wrote:
> > > > > > >
> > > > > > > > I have to fully agree on Michael Osipov. This discussion is
> > > > > > > > contraproductive from the time perspective.
> > > > > > > > He explained the situation in Maven very clearly that we have
> > > over
> > > > > 1800
> > > > > > > > bugs and here we are talking about javac compiler version
> which
> > > > does
> > > > > > not
> > > > > > > > fix these bugs.
> > > > > > > > We know that our community is quite big but we also know that
> > we
> > > > have
> > > > > > > only
> > > > > > > > few several developers who regularily provides fixes for the
> > bug
> > > > and
> > > > > > they
> > > > > > > > do it for free!
> > > > > > > > So my advice is to leave these talks alone about technology
> > lobby
> > > > > (seen
> > > > > > > on
> > > > > > > > ML from outside as well) and rather concentrate on the bug.
> We
> > > have
> > > > > > seen
> > > > > > > > that the users/contributors handled performance issues and
> > fixed
> > > > them
> > > > > > > which
> > > > > > > > means that these contributors got very good proficiency
> level!
> > > > > > > >
> > > > > > > > On Wed, Oct 9, 2019 at 7:56 PM Alexander Ashitkin <>
> > > > > > > ashitkin.alex@gmail.com
> > > > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Totally disagree on the point. Writing java7 code after 8
> > makes
> > > > you
> > > > > > > feel
> > > > > > > > > suffering - because instead of expressive stream based
> > > operations
> > > > > and
> > > > > > > > > lambdas you write pointless iterators and copy collections.
> > > > > > > > > It is purely subjective opinion that lambdas make code less
> > > > > readable
> > > > > > -
> > > > > > > at
> > > > > > > > > least there is an absolutely opposite opinion
> > > > > > > > >
> > > > > > > > > Thank you
> > > > > > > > > Aleks
> > > > > > > > >
> > > > > > > > > On 2019/10/03 12:47:35, Paul Hammant wrote:
> > > > > > > > > > Who codes for 18 months before discovering that qa/prod
> are
> > > not
> > > > > > > > > compatible,
> > > > > > > > > > anymore? Especially if Google ship a use-this-Pom
> starter.
> > > > > > > > > >
> > > > > > > > > > On Thu, Oct 3, 2019 at 1:44 PM Elliotte Rusty Harold <>
> > > > > > > > elharo@ibiblio.org
> > > > > > > > > >
> > > > > > > > > > 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
> <>
> > > > > > > > > elharo@ibiblio.org
> > > > > > > > > > > >
> > > > > > > > > > > > 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 <>
> > > > > > > > > rfscholte@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-unsubscribe@maven.apache.org
> > > > > > > > > > > > > > For additional commands, e-mail:
> > > > > dev-help@maven.apache.org
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > --
> > > > > > > > > > > > > Elliotte Rusty Harold
> > > > > > > > > > > > > elharo@ibiblio.org
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > > > > > > > > > To unsubscribe, e-mail:
> > > dev-unsubscribe@maven.apache.org
> > > > > > > > > > > > > For additional commands, e-mail:
> > > > dev-help@maven.apache.org
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Elliotte Rusty Harold
> > > > > > > > > > > elharo@ibiblio.org
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > > > > > To unsubscribe, e-mail:
> dev-unsubscribe@maven.apache.org
> > > > > > > > > > > For additional commands, e-mail:
> > dev-help@maven.apache.org
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Olivier Lamy
> > > > > > > http://twitter.com/olamy | http://linkedin.com/in/olamy
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Maven 3.7.0

[Tibor Digana <ti...@apache.org>]

Stephen, we are in loop.
Of course I know these technical things.
But I am saying, and I am not alone (Michael Osipov too), that I agree with
sources 1.8, but there must be1.  the Vote with milestones regarding Maven
and another Vote regarding plugins, and 2. written list of pros/cons
regarding J8 and 3. developer guideline for J8 (for devs, consultants,
another professions as well in the team).
You know, with video calls, all these public emails would be gone within
one or two hours, I am sure!
I am also sure that we will have another code preferences and therefore we
should have some guideline. For instance, I like to have clear OOP in the
public class/interfaces and Lambda in private code. And there are a lot of
stuff, like parallel streams ala thread pool of non-daemon threads,
performance of streams (when, how stream is constructed, etc), Date Time
API is new as well.

No benefit for the community with J7 sources but yes with J8 code. Believe
me, this is true. Michael mentioned that as well.

It is also true that we have a lot of bugs, and it is true that Maven needs
to have breakthrough features like reproducible build and User POM, Docker
prefetched cache, etc.
I have no argument against these things. The only problem that I have and
Michael has is the way how this is managed but it is the only trivial
problem that we can solve between us.





On Tue, Oct 29, 2019 at 1:04 PM Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

> You cannot have Java 8 sources produce Java 7 bytecode with the Java 8's
> javac.
>
> -target must be >= -source
>
> So to say:
>
> > So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
>
> Is not possible, you'll get something like:
>
> $ javac Test -source 1.8 -target 1.7
> javac: source release 1.8 requires target release 1.8
>
> While we could use something like https://github.com/luontola/retrolambda
> its usage is not without significant risks. You really need to be very
> careful in how you use it, and the effort is IMHO far exceeding the risk.
> Much better to just say Maven 3.7.0 is requires the runtime JVM be Java 8+,
> use toolchains if you need to compile or unit tests with older JDKs.
>
> We have agreed before that upgrading the Maven minor or major version would
> affect the JREs that Maven can run on. Basically following a one and one
> back for Oracle supported JDKs, thus 3.7.0 per that policy would be forced
> to Java 8 as minimum anyway.... in other words, our users should be
> expecting us to go Java 8 as baseline.
>
> On Tue, 29 Oct 2019 at 10:28, Tibor Digana <ti...@apache.org> wrote:
>
> > Stephen, what issue with current toolchain you mean?
> >
> > On Tue, Oct 29, 2019 at 11:11 AM Stephen Connolly <
> > stephen.alan.connolly@gmail.com> wrote:
> >
> > > On Tue, 29 Oct 2019 at 08:02, Tibor Digana <ti...@apache.org>
> > wrote:
> > >
> > > > Robert, I saw the code. The class has a method which returns Lambda
> > > > function. The whole class was designed with OOP. The OOP is a good
> > thing
> > > > which you should follow and follow this approach and not to return
> the
> > > > labda function. Basically it is a precedense created in the PR saying
> > > that
> > > > now J8 has to be used in the bytecode.
> > > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
> > > >
> > >
> > > That is not possible using the current toolchains. Let's just go with
> > Java
> > > 8. There seems no good reason to hold back
> > >
> > >
> > > >
> > > > On Tue, Oct 29, 2019 at 8:25 AM Robert Scholte <rfscholte@apache.org
> >
> > > > wrote:
> > > >
> > > > > The outcome is quite clear to me. There no clear 'No' to add this
> > > > > build/consumer feature into 3.7.0, so we'll add it which implies we
> > > must
> > > > > move to Java 8 due to new APIs with Java 8 class signatures.
> > > > >
> > > > > But first we need to deliver a 3.6.3 regression release.
> > > > >
> > > > > Robert
> > > > >
> > > > > On 29-10-2019 05:53:25, Romain Manni-Bucau <rm...@gmail.com>
> > > > wrote:
> > > > > +1, the risk is more or less 0 since we can still use branches for
> > > > > potential fixes for "old" projects using frozen java and maven
> > versions
> > > > > anyway
> > > > >
> > > > > Guess we can even be very precautionous doing 1. an upgrade to
> > bytecode
> > > > > version without any code change (to change the major version in
> > > > bytecode),
> > > > > 2. a M1 to let users test it if some still doubt.
> > > > >
> > > > > Le mar. 29 oct. 2019 à 04:06, Olivier Lamy a écrit :
> > > > >
> > > > > > so what is the status of this?
> > > > > > will we discuss in 2025 about being able to use java 8 apis or do
> > we
> > > > have
> > > > > > to wait 2030?
> > > > > > Sorry to be sarcastic but not moving forward it's certainly a
> > reason
> > > > why
> > > > > we
> > > > > > do not have more people participating in the project....
> > > > > > It is so frustrating to be stuck with old apis...
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Thu, 10 Oct 2019 at 04:36, Tibor Digana wrote:
> > > > > >
> > > > > > > I have to fully agree on Michael Osipov. This discussion is
> > > > > > > contraproductive from the time perspective.
> > > > > > > He explained the situation in Maven very clearly that we have
> > over
> > > > 1800
> > > > > > > bugs and here we are talking about javac compiler version which
> > > does
> > > > > not
> > > > > > > fix these bugs.
> > > > > > > We know that our community is quite big but we also know that
> we
> > > have
> > > > > > only
> > > > > > > few several developers who regularily provides fixes for the
> bug
> > > and
> > > > > they
> > > > > > > do it for free!
> > > > > > > So my advice is to leave these talks alone about technology
> lobby
> > > > (seen
> > > > > > on
> > > > > > > ML from outside as well) and rather concentrate on the bug. We
> > have
> > > > > seen
> > > > > > > that the users/contributors handled performance issues and
> fixed
> > > them
> > > > > > which
> > > > > > > means that these contributors got very good proficiency level!
> > > > > > >
> > > > > > > On Wed, Oct 9, 2019 at 7:56 PM Alexander Ashitkin <>
> > > > > > ashitkin.alex@gmail.com
> > > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Totally disagree on the point. Writing java7 code after 8
> makes
> > > you
> > > > > > feel
> > > > > > > > suffering - because instead of expressive stream based
> > operations
> > > > and
> > > > > > > > lambdas you write pointless iterators and copy collections.
> > > > > > > > It is purely subjective opinion that lambdas make code less
> > > > readable
> > > > > -
> > > > > > at
> > > > > > > > least there is an absolutely opposite opinion
> > > > > > > >
> > > > > > > > Thank you
> > > > > > > > Aleks
> > > > > > > >
> > > > > > > > On 2019/10/03 12:47:35, Paul Hammant wrote:
> > > > > > > > > Who codes for 18 months before discovering that qa/prod are
> > not
> > > > > > > > compatible,
> > > > > > > > > anymore? Especially if Google ship a use-this-Pom starter.
> > > > > > > > >
> > > > > > > > > On Thu, Oct 3, 2019 at 1:44 PM Elliotte Rusty Harold <>
> > > > > > > elharo@ibiblio.org
> > > > > > > > >
> > > > > > > > > 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 <>
> > > > > > > > elharo@ibiblio.org
> > > > > > > > > > >
> > > > > > > > > > > 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 <>
> > > > > > > > rfscholte@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-unsubscribe@maven.apache.org
> > > > > > > > > > > > > For additional commands, e-mail:
> > > > dev-help@maven.apache.org
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > --
> > > > > > > > > > > > Elliotte Rusty Harold
> > > > > > > > > > > > elharo@ibiblio.org
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > >
> > > > ---------------------------------------------------------------------
> > > > > > > > > > > > To unsubscribe, e-mail:
> > dev-unsubscribe@maven.apache.org
> > > > > > > > > > > > For additional commands, e-mail:
> > > dev-help@maven.apache.org
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Elliotte Rusty Harold
> > > > > > > > > > elharo@ibiblio.org
> > > > > > > > > >
> > > > > > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > > > > > For additional commands, e-mail:
> dev-help@maven.apache.org
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Olivier Lamy
> > > > > > http://twitter.com/olamy | http://linkedin.com/in/olamy
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Maven 3.7.0

[Stephen Connolly <st...@gmail.com>]

You cannot have Java 8 sources produce Java 7 bytecode with the Java 8's
javac.

-target must be >= -source

So to say:

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

Is not possible, you'll get something like:

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

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

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

On Tue, 29 Oct 2019 at 10:28, Tibor Digana <ti...@apache.org> wrote:

> Stephen, what issue with current toolchain you mean?
>
> On Tue, Oct 29, 2019 at 11:11 AM Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> > On Tue, 29 Oct 2019 at 08:02, Tibor Digana <ti...@apache.org>
> wrote:
> >
> > > Robert, I saw the code. The class has a method which returns Lambda
> > > function. The whole class was designed with OOP. The OOP is a good
> thing
> > > which you should follow and follow this approach and not to return the
> > > labda function. Basically it is a precedense created in the PR saying
> > that
> > > now J8 has to be used in the bytecode.
> > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
> > >
> >
> > That is not possible using the current toolchains. Let's just go with
> Java
> > 8. There seems no good reason to hold back
> >
> >
> > >
> > > On Tue, Oct 29, 2019 at 8:25 AM Robert Scholte <rf...@apache.org>
> > > wrote:
> > >
> > > > The outcome is quite clear to me. There no clear 'No' to add this
> > > > build/consumer feature into 3.7.0, so we'll add it which implies we
> > must
> > > > move to Java 8 due to new APIs with Java 8 class signatures.
> > > >
> > > > But first we need to deliver a 3.6.3 regression release.
> > > >
> > > > Robert
> > > >
> > > > On 29-10-2019 05:53:25, Romain Manni-Bucau <rm...@gmail.com>
> > > wrote:
> > > > +1, the risk is more or less 0 since we can still use branches for
> > > > potential fixes for "old" projects using frozen java and maven
> versions
> > > > anyway
> > > >
> > > > Guess we can even be very precautionous doing 1. an upgrade to
> bytecode
> > > > version without any code change (to change the major version in
> > > bytecode),
> > > > 2. a M1 to let users test it if some still doubt.
> > > >
> > > > Le mar. 29 oct. 2019 à 04:06, Olivier Lamy a écrit :
> > > >
> > > > > so what is the status of this?
> > > > > will we discuss in 2025 about being able to use java 8 apis or do
> we
> > > have
> > > > > to wait 2030?
> > > > > Sorry to be sarcastic but not moving forward it's certainly a
> reason
> > > why
> > > > we
> > > > > do not have more people participating in the project....
> > > > > It is so frustrating to be stuck with old apis...
> > > > >
> > > > >
> > > > >
> > > > > On Thu, 10 Oct 2019 at 04:36, Tibor Digana wrote:
> > > > >
> > > > > > I have to fully agree on Michael Osipov. This discussion is
> > > > > > contraproductive from the time perspective.
> > > > > > He explained the situation in Maven very clearly that we have
> over
> > > 1800
> > > > > > bugs and here we are talking about javac compiler version which
> > does
> > > > not
> > > > > > fix these bugs.
> > > > > > We know that our community is quite big but we also know that we
> > have
> > > > > only
> > > > > > few several developers who regularily provides fixes for the bug
> > and
> > > > they
> > > > > > do it for free!
> > > > > > So my advice is to leave these talks alone about technology lobby
> > > (seen
> > > > > on
> > > > > > ML from outside as well) and rather concentrate on the bug. We
> have
> > > > seen
> > > > > > that the users/contributors handled performance issues and fixed
> > them
> > > > > which
> > > > > > means that these contributors got very good proficiency level!
> > > > > >
> > > > > > On Wed, Oct 9, 2019 at 7:56 PM Alexander Ashitkin <>
> > > > > ashitkin.alex@gmail.com
> > > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Totally disagree on the point. Writing java7 code after 8 makes
> > you
> > > > > feel
> > > > > > > suffering - because instead of expressive stream based
> operations
> > > and
> > > > > > > lambdas you write pointless iterators and copy collections.
> > > > > > > It is purely subjective opinion that lambdas make code less
> > > readable
> > > > -
> > > > > at
> > > > > > > least there is an absolutely opposite opinion
> > > > > > >
> > > > > > > Thank you
> > > > > > > Aleks
> > > > > > >
> > > > > > > On 2019/10/03 12:47:35, Paul Hammant wrote:
> > > > > > > > Who codes for 18 months before discovering that qa/prod are
> not
> > > > > > > compatible,
> > > > > > > > anymore? Especially if Google ship a use-this-Pom starter.
> > > > > > > >
> > > > > > > > On Thu, Oct 3, 2019 at 1:44 PM Elliotte Rusty Harold <>
> > > > > > elharo@ibiblio.org
> > > > > > > >
> > > > > > > > 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 <>
> > > > > > > elharo@ibiblio.org
> > > > > > > > > >
> > > > > > > > > > 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 <>
> > > > > > > rfscholte@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-unsubscribe@maven.apache.org
> > > > > > > > > > > > For additional commands, e-mail:
> > > dev-help@maven.apache.org
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Elliotte Rusty Harold
> > > > > > > > > > > elharo@ibiblio.org
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > > > > > To unsubscribe, e-mail:
> dev-unsubscribe@maven.apache.org
> > > > > > > > > > > For additional commands, e-mail:
> > dev-help@maven.apache.org
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Elliotte Rusty Harold
> > > > > > > > > elharo@ibiblio.org
> > > > > > > > >
> > > > > > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Olivier Lamy
> > > > > http://twitter.com/olamy | http://linkedin.com/in/olamy
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Maven 3.7.0

[Tibor Digana <ti...@apache.org>]

Stephen, what issue with current toolchain you mean?

On Tue, Oct 29, 2019 at 11:11 AM Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

> On Tue, 29 Oct 2019 at 08:02, Tibor Digana <ti...@apache.org> wrote:
>
> > Robert, I saw the code. The class has a method which returns Lambda
> > function. The whole class was designed with OOP. The OOP is a good thing
> > which you should follow and follow this approach and not to return the
> > labda function. Basically it is a precedense created in the PR saying
> that
> > now J8 has to be used in the bytecode.
> > So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
> >
>
> That is not possible using the current toolchains. Let's just go with Java
> 8. There seems no good reason to hold back
>
>
> >
> > On Tue, Oct 29, 2019 at 8:25 AM Robert Scholte <rf...@apache.org>
> > wrote:
> >
> > > The outcome is quite clear to me. There no clear 'No' to add this
> > > build/consumer feature into 3.7.0, so we'll add it which implies we
> must
> > > move to Java 8 due to new APIs with Java 8 class signatures.
> > >
> > > But first we need to deliver a 3.6.3 regression release.
> > >
> > > Robert
> > >
> > > On 29-10-2019 05:53:25, Romain Manni-Bucau <rm...@gmail.com>
> > wrote:
> > > +1, the risk is more or less 0 since we can still use branches for
> > > potential fixes for "old" projects using frozen java and maven versions
> > > anyway
> > >
> > > Guess we can even be very precautionous doing 1. an upgrade to bytecode
> > > version without any code change (to change the major version in
> > bytecode),
> > > 2. a M1 to let users test it if some still doubt.
> > >
> > > Le mar. 29 oct. 2019 à 04:06, Olivier Lamy a écrit :
> > >
> > > > so what is the status of this?
> > > > will we discuss in 2025 about being able to use java 8 apis or do we
> > have
> > > > to wait 2030?
> > > > Sorry to be sarcastic but not moving forward it's certainly a reason
> > why
> > > we
> > > > do not have more people participating in the project....
> > > > It is so frustrating to be stuck with old apis...
> > > >
> > > >
> > > >
> > > > On Thu, 10 Oct 2019 at 04:36, Tibor Digana wrote:
> > > >
> > > > > I have to fully agree on Michael Osipov. This discussion is
> > > > > contraproductive from the time perspective.
> > > > > He explained the situation in Maven very clearly that we have over
> > 1800
> > > > > bugs and here we are talking about javac compiler version which
> does
> > > not
> > > > > fix these bugs.
> > > > > We know that our community is quite big but we also know that we
> have
> > > > only
> > > > > few several developers who regularily provides fixes for the bug
> and
> > > they
> > > > > do it for free!
> > > > > So my advice is to leave these talks alone about technology lobby
> > (seen
> > > > on
> > > > > ML from outside as well) and rather concentrate on the bug. We have
> > > seen
> > > > > that the users/contributors handled performance issues and fixed
> them
> > > > which
> > > > > means that these contributors got very good proficiency level!
> > > > >
> > > > > On Wed, Oct 9, 2019 at 7:56 PM Alexander Ashitkin <>
> > > > ashitkin.alex@gmail.com
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > Totally disagree on the point. Writing java7 code after 8 makes
> you
> > > > feel
> > > > > > suffering - because instead of expressive stream based operations
> > and
> > > > > > lambdas you write pointless iterators and copy collections.
> > > > > > It is purely subjective opinion that lambdas make code less
> > readable
> > > -
> > > > at
> > > > > > least there is an absolutely opposite opinion
> > > > > >
> > > > > > Thank you
> > > > > > Aleks
> > > > > >
> > > > > > On 2019/10/03 12:47:35, Paul Hammant wrote:
> > > > > > > Who codes for 18 months before discovering that qa/prod are not
> > > > > > compatible,
> > > > > > > anymore? Especially if Google ship a use-this-Pom starter.
> > > > > > >
> > > > > > > On Thu, Oct 3, 2019 at 1:44 PM Elliotte Rusty Harold <>
> > > > > elharo@ibiblio.org
> > > > > > >
> > > > > > > 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 <>
> > > > > > elharo@ibiblio.org
> > > > > > > > >
> > > > > > > > > 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 <>
> > > > > > rfscholte@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-unsubscribe@maven.apache.org
> > > > > > > > > > > For additional commands, e-mail:
> > dev-help@maven.apache.org
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Elliotte Rusty Harold
> > > > > > > > > > elharo@ibiblio.org
> > > > > > > > > >
> > > > > > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > > > > > For additional commands, e-mail:
> dev-help@maven.apache.org
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Elliotte Rusty Harold
> > > > > > > > elharo@ibiblio.org
> > > > > > > >
> > > > > > > >
> > > > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Olivier Lamy
> > > > http://twitter.com/olamy | http://linkedin.com/in/olamy
> > > >
> > >
> >
>

Re: [DISCUSS] Maven 3.7.0

[Stephen Connolly <st...@gmail.com>]

On Tue, 29 Oct 2019 at 08:02, Tibor Digana <ti...@apache.org> wrote:

> Robert, I saw the code. The class has a method which returns Lambda
> function. The whole class was designed with OOP. The OOP is a good thing
> which you should follow and follow this approach and not to return the
> labda function. Basically it is a precedense created in the PR saying that
> now J8 has to be used in the bytecode.
> So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
>

That is not possible using the current toolchains. Let's just go with Java
8. There seems no good reason to hold back


>
> On Tue, Oct 29, 2019 at 8:25 AM Robert Scholte <rf...@apache.org>
> wrote:
>
> > The outcome is quite clear to me. There no clear 'No' to add this
> > build/consumer feature into 3.7.0, so we'll add it which implies we must
> > move to Java 8 due to new APIs with Java 8 class signatures.
> >
> > But first we need to deliver a 3.6.3 regression release.
> >
> > Robert
> >
> > On 29-10-2019 05:53:25, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
> > +1, the risk is more or less 0 since we can still use branches for
> > potential fixes for "old" projects using frozen java and maven versions
> > anyway
> >
> > Guess we can even be very precautionous doing 1. an upgrade to bytecode
> > version without any code change (to change the major version in
> bytecode),
> > 2. a M1 to let users test it if some still doubt.
> >
> > Le mar. 29 oct. 2019 à 04:06, Olivier Lamy a écrit :
> >
> > > so what is the status of this?
> > > will we discuss in 2025 about being able to use java 8 apis or do we
> have
> > > to wait 2030?
> > > Sorry to be sarcastic but not moving forward it's certainly a reason
> why
> > we
> > > do not have more people participating in the project....
> > > It is so frustrating to be stuck with old apis...
> > >
> > >
> > >
> > > On Thu, 10 Oct 2019 at 04:36, Tibor Digana wrote:
> > >
> > > > I have to fully agree on Michael Osipov. This discussion is
> > > > contraproductive from the time perspective.
> > > > He explained the situation in Maven very clearly that we have over
> 1800
> > > > bugs and here we are talking about javac compiler version which does
> > not
> > > > fix these bugs.
> > > > We know that our community is quite big but we also know that we have
> > > only
> > > > few several developers who regularily provides fixes for the bug and
> > they
> > > > do it for free!
> > > > So my advice is to leave these talks alone about technology lobby
> (seen
> > > on
> > > > ML from outside as well) and rather concentrate on the bug. We have
> > seen
> > > > that the users/contributors handled performance issues and fixed them
> > > which
> > > > means that these contributors got very good proficiency level!
> > > >
> > > > On Wed, Oct 9, 2019 at 7:56 PM Alexander Ashitkin <>
> > > ashitkin.alex@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > Totally disagree on the point. Writing java7 code after 8 makes you
> > > feel
> > > > > suffering - because instead of expressive stream based operations
> and
> > > > > lambdas you write pointless iterators and copy collections.
> > > > > It is purely subjective opinion that lambdas make code less
> readable
> > -
> > > at
> > > > > least there is an absolutely opposite opinion
> > > > >
> > > > > Thank you
> > > > > Aleks
> > > > >
> > > > > On 2019/10/03 12:47:35, Paul Hammant wrote:
> > > > > > Who codes for 18 months before discovering that qa/prod are not
> > > > > compatible,
> > > > > > anymore? Especially if Google ship a use-this-Pom starter.
> > > > > >
> > > > > > On Thu, Oct 3, 2019 at 1:44 PM Elliotte Rusty Harold <>
> > > > elharo@ibiblio.org
> > > > > >
> > > > > > 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 <>
> > > > > elharo@ibiblio.org
> > > > > > > >
> > > > > > > > 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 <>
> > > > > rfscholte@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-unsubscribe@maven.apache.org
> > > > > > > > > > For additional commands, e-mail:
> dev-help@maven.apache.org
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Elliotte Rusty Harold
> > > > > > > > > elharo@ibiblio.org
> > > > > > > > >
> > > > > > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Elliotte Rusty Harold
> > > > > > > elharo@ibiblio.org
> > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Olivier Lamy
> > > http://twitter.com/olamy | http://linkedin.com/in/olamy
> > >
> >
>

Re: [DISCUSS] Maven 3.7.0

[Tibor Digana <ti...@apache.org>]

Robert, I saw the code. The class has a method which returns Lambda
function. The whole class was designed with OOP. The OOP is a good thing
which you should follow and follow this approach and not to return the
labda function. Basically it is a precedense created in the PR saying that
now J8 has to be used in the bytecode.
So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!

On Tue, Oct 29, 2019 at 8:25 AM Robert Scholte <rf...@apache.org> wrote:

> The outcome is quite clear to me. There no clear 'No' to add this
> build/consumer feature into 3.7.0, so we'll add it which implies we must
> move to Java 8 due to new APIs with Java 8 class signatures.
>
> But first we need to deliver a 3.6.3 regression release.
>
> Robert
>
> On 29-10-2019 05:53:25, Romain Manni-Bucau <rm...@gmail.com> wrote:
> +1, the risk is more or less 0 since we can still use branches for
> potential fixes for "old" projects using frozen java and maven versions
> anyway
>
> Guess we can even be very precautionous doing 1. an upgrade to bytecode
> version without any code change (to change the major version in bytecode),
> 2. a M1 to let users test it if some still doubt.
>
> Le mar. 29 oct. 2019 à 04:06, Olivier Lamy a écrit :
>
> > so what is the status of this?
> > will we discuss in 2025 about being able to use java 8 apis or do we have
> > to wait 2030?
> > Sorry to be sarcastic but not moving forward it's certainly a reason why
> we
> > do not have more people participating in the project....
> > It is so frustrating to be stuck with old apis...
> >
> >
> >
> > On Thu, 10 Oct 2019 at 04:36, Tibor Digana wrote:
> >
> > > I have to fully agree on Michael Osipov. This discussion is
> > > contraproductive from the time perspective.
> > > He explained the situation in Maven very clearly that we have over 1800
> > > bugs and here we are talking about javac compiler version which does
> not
> > > fix these bugs.
> > > We know that our community is quite big but we also know that we have
> > only
> > > few several developers who regularily provides fixes for the bug and
> they
> > > do it for free!
> > > So my advice is to leave these talks alone about technology lobby (seen
> > on
> > > ML from outside as well) and rather concentrate on the bug. We have
> seen
> > > that the users/contributors handled performance issues and fixed them
> > which
> > > means that these contributors got very good proficiency level!
> > >
> > > On Wed, Oct 9, 2019 at 7:56 PM Alexander Ashitkin <>
> > ashitkin.alex@gmail.com
> > > >
> > > wrote:
> > >
> > > > Totally disagree on the point. Writing java7 code after 8 makes you
> > feel
> > > > suffering - because instead of expressive stream based operations and
> > > > lambdas you write pointless iterators and copy collections.
> > > > It is purely subjective opinion that lambdas make code less readable
> -
> > at
> > > > least there is an absolutely opposite opinion
> > > >
> > > > Thank you
> > > > Aleks
> > > >
> > > > On 2019/10/03 12:47:35, Paul Hammant wrote:
> > > > > Who codes for 18 months before discovering that qa/prod are not
> > > > compatible,
> > > > > anymore? Especially if Google ship a use-this-Pom starter.
> > > > >
> > > > > On Thu, Oct 3, 2019 at 1:44 PM Elliotte Rusty Harold <>
> > > elharo@ibiblio.org
> > > > >
> > > > > 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 <>
> > > > elharo@ibiblio.org
> > > > > > >
> > > > > > > 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 <>
> > > > rfscholte@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-unsubscribe@maven.apache.org
> > > > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Elliotte Rusty Harold
> > > > > > > > elharo@ibiblio.org
> > > > > > > >
> > > > > > > >
> > > > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > > > >
> > > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Elliotte Rusty Harold
> > > > > > elharo@ibiblio.org
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> >
> >
> > --
> > Olivier Lamy
> > http://twitter.com/olamy | http://linkedin.com/in/olamy
> >
>

Re: [DISCUSS] Maven 3.7.0

[Robert Scholte <rf...@apache.org>]

The outcome is quite clear to me. There no clear 'No' to add this build/consumer feature into 3.7.0, so we'll add it which implies we must move to Java 8 due to new APIs with Java 8 class signatures.

But first we need to deliver a 3.6.3 regression release.

Robert

On 29-10-2019 05:53:25, Romain Manni-Bucau <rm...@gmail.com> wrote:
+1, the risk is more or less 0 since we can still use branches for
potential fixes for "old" projects using frozen java and maven versions
anyway

Guess we can even be very precautionous doing 1. an upgrade to bytecode
version without any code change (to change the major version in bytecode),
2. a M1 to let users test it if some still doubt.

Le mar. 29 oct. 2019 à 04:06, Olivier Lamy a écrit :

> so what is the status of this?
> will we discuss in 2025 about being able to use java 8 apis or do we have
> to wait 2030?
> Sorry to be sarcastic but not moving forward it's certainly a reason why we
> do not have more people participating in the project....
> It is so frustrating to be stuck with old apis...
>
>
>
> On Thu, 10 Oct 2019 at 04:36, Tibor Digana wrote:
>
> > I have to fully agree on Michael Osipov. This discussion is
> > contraproductive from the time perspective.
> > He explained the situation in Maven very clearly that we have over 1800
> > bugs and here we are talking about javac compiler version which does not
> > fix these bugs.
> > We know that our community is quite big but we also know that we have
> only
> > few several developers who regularily provides fixes for the bug and they
> > do it for free!
> > So my advice is to leave these talks alone about technology lobby (seen
> on
> > ML from outside as well) and rather concentrate on the bug. We have seen
> > that the users/contributors handled performance issues and fixed them
> which
> > means that these contributors got very good proficiency level!
> >
> > On Wed, Oct 9, 2019 at 7:56 PM Alexander Ashitkin <>
> ashitkin.alex@gmail.com
> > >
> > wrote:
> >
> > > Totally disagree on the point. Writing java7 code after 8 makes you
> feel
> > > suffering - because instead of expressive stream based operations and
> > > lambdas you write pointless iterators and copy collections.
> > > It is purely subjective opinion that lambdas make code less readable -
> at
> > > least there is an absolutely opposite opinion
> > >
> > > Thank you
> > > Aleks
> > >
> > > On 2019/10/03 12:47:35, Paul Hammant wrote:
> > > > Who codes for 18 months before discovering that qa/prod are not
> > > compatible,
> > > > anymore? Especially if Google ship a use-this-Pom starter.
> > > >
> > > > On Thu, Oct 3, 2019 at 1:44 PM Elliotte Rusty Harold <>
> > elharo@ibiblio.org
> > > >
> > > > 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 <>
> > > elharo@ibiblio.org
> > > > > >
> > > > > > 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 <>
> > > rfscholte@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-unsubscribe@maven.apache.org
> > > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Elliotte Rusty Harold
> > > > > > > elharo@ibiblio.org
> > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Elliotte Rusty Harold
> > > > > elharo@ibiblio.org
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>
>
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>

Re: [DISCUSS] Maven 3.7.0

[Romain Manni-Bucau <rm...@gmail.com>]

+1, the risk is more or less 0 since we can still use branches for
potential fixes for "old" projects using frozen java and maven versions
anyway

Guess we can even be very precautionous doing 1. an upgrade to bytecode
version without any code change (to change the major version in bytecode),
2. a M1 to let users test it if some still doubt.

Le mar. 29 oct. 2019 à 04:06, Olivier Lamy <ol...@apache.org> a écrit :

> so what is the status of this?
> will we discuss in 2025 about being able to use java 8 apis or do we have
> to wait 2030?
> Sorry to be sarcastic but not moving forward it's certainly a reason why we
> do not have more people participating in the project....
> It is so frustrating to be stuck with old apis...
>
>
>
> On Thu, 10 Oct 2019 at 04:36, Tibor Digana <ti...@apache.org> wrote:
>
> > I have to fully agree on Michael Osipov. This discussion is
> > contraproductive from the time perspective.
> > He explained the situation in Maven very clearly that we have over 1800
> > bugs and here we are talking about javac compiler version which does not
> > fix these bugs.
> > We know that our community is quite big but we also know that we have
> only
> > few several developers who regularily provides fixes for the bug and they
> > do it for free!
> > So my advice is to leave these talks alone about technology lobby (seen
> on
> > ML from outside as well) and rather concentrate on the bug. We have seen
> > that the users/contributors handled performance issues and fixed them
> which
> > means that these contributors got very good proficiency level!
> >
> > On Wed, Oct 9, 2019 at 7:56 PM Alexander Ashitkin <
> ashitkin.alex@gmail.com
> > >
> > wrote:
> >
> > > Totally disagree on the point. Writing java7 code after 8 makes you
> feel
> > > suffering - because instead of expressive stream based operations and
> > > lambdas you write pointless iterators and copy collections.
> > > It is purely subjective opinion that lambdas make code less readable -
> at
> > > least there is an absolutely opposite opinion
> > >
> > > Thank you
> > > Aleks
> > >
> > > On 2019/10/03 12:47:35, Paul Hammant <pa...@hammant.org> wrote:
> > > > Who codes for 18 months before discovering that qa/prod are not
> > > compatible,
> > > > anymore? Especially if Google ship a use-this-Pom starter.
> > > >
> > > > On Thu, Oct 3, 2019 at 1:44 PM Elliotte Rusty Harold <
> > elharo@ibiblio.org
> > > >
> > > > 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 <pa...@hammant.org>
> > 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 <
> > > elharo@ibiblio.org
> > > > > >
> > > > > > 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 <
> > > rfscholte@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-unsubscribe@maven.apache.org
> > > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Elliotte Rusty Harold
> > > > > > > elharo@ibiblio.org
> > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Elliotte Rusty Harold
> > > > > elharo@ibiblio.org
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>
>
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>

Re: [DISCUSS] Maven 3.7.0

[Olivier Lamy <ol...@apache.org>]

so what is the status of this?
will we discuss in 2025 about being able to use java 8 apis or do we have
to wait 2030?
Sorry to be sarcastic but not moving forward it's certainly a reason why we
do not have more people participating in the project....
It is so frustrating to be stuck with old apis...



On Thu, 10 Oct 2019 at 04:36, Tibor Digana <ti...@apache.org> wrote:

> I have to fully agree on Michael Osipov. This discussion is
> contraproductive from the time perspective.
> He explained the situation in Maven very clearly that we have over 1800
> bugs and here we are talking about javac compiler version which does not
> fix these bugs.
> We know that our community is quite big but we also know that we have only
> few several developers who regularily provides fixes for the bug and they
> do it for free!
> So my advice is to leave these talks alone about technology lobby (seen on
> ML from outside as well) and rather concentrate on the bug. We have seen
> that the users/contributors handled performance issues and fixed them which
> means that these contributors got very good proficiency level!
>
> On Wed, Oct 9, 2019 at 7:56 PM Alexander Ashitkin <ashitkin.alex@gmail.com
> >
> wrote:
>
> > Totally disagree on the point. Writing java7 code after 8 makes you feel
> > suffering - because instead of expressive stream based operations and
> > lambdas you write pointless iterators and copy collections.
> > It is purely subjective opinion that lambdas make code less readable - at
> > least there is an absolutely opposite opinion
> >
> > Thank you
> > Aleks
> >
> > On 2019/10/03 12:47:35, Paul Hammant <pa...@hammant.org> wrote:
> > > Who codes for 18 months before discovering that qa/prod are not
> > compatible,
> > > anymore? Especially if Google ship a use-this-Pom starter.
> > >
> > > On Thu, Oct 3, 2019 at 1:44 PM Elliotte Rusty Harold <
> elharo@ibiblio.org
> > >
> > > 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 <pa...@hammant.org>
> 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 <
> > elharo@ibiblio.org
> > > > >
> > > > > 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 <
> > rfscholte@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-unsubscribe@maven.apache.org
> > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Elliotte Rusty Harold
> > > > > > elharo@ibiblio.org
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > >
> > > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Elliotte Rusty Harold
> > > > elharo@ibiblio.org
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>


-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: [DISCUSS] Maven 3.7.0

[Tibor Digana <ti...@apache.org>]

I have to fully agree on Michael Osipov. This discussion is
contraproductive from the time perspective.
He explained the situation in Maven very clearly that we have over 1800
bugs and here we are talking about javac compiler version which does not
fix these bugs.
We know that our community is quite big but we also know that we have only
few several developers who regularily provides fixes for the bug and they
do it for free!
So my advice is to leave these talks alone about technology lobby (seen on
ML from outside as well) and rather concentrate on the bug. We have seen
that the users/contributors handled performance issues and fixed them which
means that these contributors got very good proficiency level!

On Wed, Oct 9, 2019 at 7:56 PM Alexander Ashitkin <as...@gmail.com>
wrote:

> Totally disagree on the point. Writing java7 code after 8 makes you feel
> suffering - because instead of expressive stream based operations and
> lambdas you write pointless iterators and copy collections.
> It is purely subjective opinion that lambdas make code less readable - at
> least there is an absolutely opposite opinion
>
> Thank you
> Aleks
>
> On 2019/10/03 12:47:35, Paul Hammant <pa...@hammant.org> wrote:
> > Who codes for 18 months before discovering that qa/prod are not
> compatible,
> > anymore? Especially if Google ship a use-this-Pom starter.
> >
> > On Thu, Oct 3, 2019 at 1:44 PM Elliotte Rusty Harold <elharo@ibiblio.org
> >
> > 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 <pa...@hammant.org> 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 <
> elharo@ibiblio.org
> > > >
> > > > 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 <
> rfscholte@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-unsubscribe@maven.apache.org
> > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Elliotte Rusty Harold
> > > > > elharo@ibiblio.org
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> > >
> > >
> > >
> > > --
> > > Elliotte Rusty Harold
> > > elharo@ibiblio.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: [DISCUSS] Maven 3.7.0

[Alexander Ashitkin <as...@gmail.com>]

Totally disagree on the point. Writing java7 code after 8 makes you feel suffering - because instead of expressive stream based operations and lambdas you write pointless iterators and copy collections. 
It is purely subjective opinion that lambdas make code less readable - at least there is an absolutely opposite opinion

Thank you
Aleks

On 2019/10/03 12:47:35, Paul Hammant <pa...@hammant.org> wrote: 
> Who codes for 18 months before discovering that qa/prod are not compatible,
> anymore? Especially if Google ship a use-this-Pom starter.
> 
> On Thu, Oct 3, 2019 at 1:44 PM Elliotte Rusty Harold <el...@ibiblio.org>
> 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 <pa...@hammant.org> 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 <elharo@ibiblio.org
> > >
> > > 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 <rf...@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-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > >
> > > >
> > > > --
> > > > Elliotte Rusty Harold
> > > > elharo@ibiblio.org
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> >
> >
> >
> > --
> > Elliotte Rusty Harold
> > elharo@ibiblio.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> 

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

Re: [DISCUSS] Maven 3.7.0

[Paul Hammant <pa...@hammant.org>]

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 <el...@ibiblio.org>
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 <pa...@hammant.org> 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 <elharo@ibiblio.org
> >
> > 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 <rf...@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-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > >
> > >
> > > --
> > > Elliotte Rusty Harold
> > > elharo@ibiblio.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
>
>
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: [DISCUSS] Maven 3.7.0

[Elliotte Rusty Harold <el...@ibiblio.org>]

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 <pa...@hammant.org> 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 <el...@ibiblio.org>
> 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 <rf...@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-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> >
> >
> > --
> > Elliotte Rusty Harold
> > elharo@ibiblio.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >



-- 
Elliotte Rusty Harold
elharo@ibiblio.org

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

Proposal: maven release lifecycle

[Marco Schulz <ma...@outlook.com>]

Hello Maven Dev & Community

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

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

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

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

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

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

[Services]______________________________________________________________________

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

Re: [DISCUSS] Maven 3.7.0

[Paul Hammant <pa...@hammant.org>]

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 <el...@ibiblio.org>
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 <rf...@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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: [DISCUSS] Maven 3.7.0

[Elliotte Rusty Harold <el...@ibiblio.org>]

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


-- 
Elliotte Rusty Harold
elharo@ibiblio.org

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

Re: [DISCUSS] Maven 3.7.0

[Hervé BOUTEMY <he...@free.fr>]

did someone confirm that it is related to Plexus to Tycho switch in MNG-6685?

Regards,

Hervé

Le samedi 28 septembre 2019, 16:42:27 CEST Robert Scholte a écrit :
> https://issues.apache.org/jira/browse/MNG-6765
> 
> I guess it is more about the pom-less part than the tycho-part.
> 
> On Sat, 28 Sep 2019 15:55:28 +0200, Mickael Istria <mi...@redhat.com>
> 
> wrote:
> > On Sat, Sep 28, 2019 at 2:04 PM Robert Scholte <rf...@apache.org>
> > 
> > wrote:
> >> The only one might be tricky is the issue related to Tycho.
> > 
> > What issue is this? Tycho integration-tests are being run against Maven
> > snapshots daily and no issue was spot nor report on Tycho side as far as
> > I
> > know.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org





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

Re: [DISCUSS] Maven 3.7.0

[Robert Scholte <rf...@apache.org>]

https://issues.apache.org/jira/browse/MNG-6765

I guess it is more about the pom-less part than the tycho-part.

On Sat, 28 Sep 2019 15:55:28 +0200, Mickael Istria <mi...@redhat.com>  
wrote:

> On Sat, Sep 28, 2019 at 2:04 PM Robert Scholte <rf...@apache.org>  
> wrote:
>
>> The only one might be tricky is the issue related to Tycho.
>
>
> What issue is this? Tycho integration-tests are being run against Maven
> snapshots daily and no issue was spot nor report on Tycho side as far as  
> I
> know.

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

Re: [DISCUSS] Maven 3.7.0

[Mickael Istria <mi...@redhat.com>]

On Sat, Sep 28, 2019 at 2:04 PM Robert Scholte <rf...@apache.org> wrote:

> The only one might be tricky is the issue related to Tycho.


What issue is this? Tycho integration-tests are being run against Maven
snapshots daily and no issue was spot nor report on Tycho side as far as I
know.