You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Robert Scholte <rf...@apache.org> on 2020/11/12 19:00:21 UTC
[DISCUSS] Next release should a pre Maven 4.0.0
Hi,
It is already several years ago where we started discussing about Maven Next Generations.
Clearly we needed to work on the pom, because over time we're facing more and more limitations.
For (Maven) Central the Model 4.0.0 will be required pom format, there's no discussion about that. So we needed a new architecture where there's a local pom that is transformed to Model 4.0.0 or where it can be generated.
With the implementation of MNG-6656 and the improvement with MNG-6957 we've made the first and important steps based on pom transformation. If this concept proofs itself, we can start thinking about enhancing the pom model.
When talking about Model 5.0.0 it looked like it would be great to introduce it for Maven 5. There was even a period where we thought about skipping Maven 4, just to sync the Model version with the Maven version.
However, we discovered that this would be a huge change, and that we would probably need a couple of Maven 4 releases before moving to Maven 5. Maven 4 would consist of preparation releases.
I've started writing the build/consumer to proof that the it is indeed possible to separate the local pom from the distributed pom, even though they both are currently still Model 4.0.0 compatible.
The original idea was:
Maven 3: build/consumer feature disabled by default
Maven 4: build/consumer feature enabled by default
Maven 5: Model 5
We were worried that this wouldn't give us enough feedback. maven-integration-testing shows that build/consumer does work. There should be enough trust to enable it by default, it shouldn't impact existing projects (the last find by Michael was actually great. It demonstrated the effect when using threads. The fix made sense and Maven was stable again). But it is simply not enough. We need much more feedback.
Meanwhile other improvements have been done, that has impact:
- new behavior of reactor commandline arguments
- upgrade of default versions of plugins per packaging type
- requiring Java 8
- Maven wrapper
- there's a PR waiting that will shift the logic of the ProjectBuilder/ModelBuilder. As this is quite important for more people to understand, I'll record a Q&A with Maarten+Martin soon and share it with you.
There are probably more, but all these already defend my opinion about the next Maven version.
To me it is not a Maven 3 anymore, we're reached a point where we should start calling it Maven 4.
The next release should probably have an alpha suffix, just to give users the chance to do alpha testing.
WDYT?
Robert
Re: [DISCUSS] Next release should a pre Maven 4.0.0
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Thanks and +1
Le dim. 15 nov. 2020 à 20:01, Michael Osipov <mi...@apache.org> a écrit :
> Am 2020-11-15 um 19:51 schrieb Romain Manni-Bucau:
> > Le dim. 15 nov. 2020 à 19:36, Michael Osipov <mi...@apache.org> a
> écrit :
> >
> >> Am 2020-11-15 um 17:26 schrieb Romain Manni-Bucau:
> >>> Do we have some links/pointers on "removing plugins from parent pom"?
> >> Just
> >>> want to ensure it does not fall in user land but something internal.
> >>
> >> There is a JIRA issue and the section has been explicitly marked as
> >> deprecated for years.
> >>
> >
> > Do you have the link? If we speak of <plugins> in a "packaging=pom"
> > pom.xml, ensure it was not deprecated for anyone except a few maven dev
> :s.
> > This is also something we want to keep I guess and not replace directly
> by
> > composition in all cases which duplicates poms for nothing, this is why I
> > ask to precise that point.
>
> https://issues.apache.org/jira/browse/MNG-6054
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [DISCUSS] Next release should a pre Maven 4.0.0
Posted by Michael Osipov <mi...@apache.org>.
Am 2020-11-15 um 19:51 schrieb Romain Manni-Bucau:
> Le dim. 15 nov. 2020 à 19:36, Michael Osipov <mi...@apache.org> a écrit :
>
>> Am 2020-11-15 um 17:26 schrieb Romain Manni-Bucau:
>>> Do we have some links/pointers on "removing plugins from parent pom"?
>> Just
>>> want to ensure it does not fall in user land but something internal.
>>
>> There is a JIRA issue and the section has been explicitly marked as
>> deprecated for years.
>>
>
> Do you have the link? If we speak of <plugins> in a "packaging=pom"
> pom.xml, ensure it was not deprecated for anyone except a few maven dev :s.
> This is also something we want to keep I guess and not replace directly by
> composition in all cases which duplicates poms for nothing, this is why I
> ask to precise that point.
https://issues.apache.org/jira/browse/MNG-6054
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Next release should a pre Maven 4.0.0
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le dim. 15 nov. 2020 à 19:36, Michael Osipov <mi...@apache.org> a écrit :
> Am 2020-11-15 um 17:26 schrieb Romain Manni-Bucau:
> > Do we have some links/pointers on "removing plugins from parent pom"?
> Just
> > want to ensure it does not fall in user land but something internal.
>
> There is a JIRA issue and the section has been explicitly marked as
> deprecated for years.
>
Do you have the link? If we speak of <plugins> in a "packaging=pom"
pom.xml, ensure it was not deprecated for anyone except a few maven dev :s.
This is also something we want to keep I guess and not replace directly by
composition in all cases which duplicates poms for nothing, this is why I
ask to precise that point.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [DISCUSS] Next release should a pre Maven 4.0.0
Posted by Michael Osipov <mi...@apache.org>.
Am 2020-11-15 um 17:26 schrieb Romain Manni-Bucau:
> Do we have some links/pointers on "removing plugins from parent pom"? Just
> want to ensure it does not fall in user land but something internal.
There is a JIRA issue and the section has been explicitly marked as
deprecated for years.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Next release should a pre Maven 4.0.0
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Do we have some links/pointers on "removing plugins from parent pom"? Just
want to ensure it does not fall in user land but something internal.
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 dim. 15 nov. 2020 à 17:03, Hervé BOUTEMY <he...@free.fr> a
écrit :
> Le vendredi 13 novembre 2020, 19:28:20 CET Michael Osipov a écrit :
> > Am 2020-11-13 um 19:24 schrieb Robert Scholte:
> > > Removing release profile should be combined with fail on
> missing/unknown
> > > profile of MNG-6012
> > Agreed, Karl just needs to complete his implementation.
> >
> > > Remove plugin section in super POM should be fine, now that Hervé has
> > > added warnings for it.
> > Correct.
> 2 remarks:
> 1. to better evaluate the impact, we are talking about default version for
> antrun, assembly, dependency and release: the choice of removing that
> default
> version or not can be done per-plugin
> 2. adding a warning if someone uses the version provided by super-pom was
> done
> to permit keeping a default version in super-pom but warning that using it
> is
> not the safest: then avoid bluntly removing the version
>
> >
> > > There should be a default repository: central. I guess you want to
> move it
> > > to conf/settings.xml in the distribution.
> > Exactly!
> >
> > > Robert
> > >
> > > On 13-11-2020 18:23:20, Michael Osipov <mi...@apache.org> wrote:
> > >>From the top of my head:
> > > * Remove release profile
> > > * Remove plugin section in super POM
> > > * Move Central out of Core
> > >
> > > As well as a review of all consistency fixes to dependency resolution
> > > done by Christian Schulte.
> > >
> > > I also agree with maven-compat. This needs to go, currently not
> possible
> > > due to MNG-6561.
> > >
> > > Am 2020-11-13 um 18:11 schrieb Robert Scholte:
> > >> I'm not going to say simply yes, it probably depends. Any specific
> things
> > >> you have in mind? Also, I don't know what to do with maven-compat.
> > >> I would prefer to remove it and introduce maven-compat3 as a bucket
> for
> > >> classes that we don't want to use in Maven 4, but can still be used by
> > >> plugins. Reusing the maven-compat artifactId with a different set of
> > >> classes is most likely a recipe for disaster.
> > >>
> > >> Robert
> > >> On 13-11-2020 17:53:47, Michael Osipov wrote:
> > >> Does this mean that we can finally drop deprecated stuff and even
> break
> > >> compat?
> > >>
> > >> ---------------------------------------------------------------------
> > >> 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
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [DISCUSS] Next release should a pre Maven 4.0.0
Posted by Michael Osipov <mi...@apache.org>.
Am 2020-11-15 um 17:03 schrieb Hervé BOUTEMY:
> Le vendredi 13 novembre 2020, 19:28:20 CET Michael Osipov a écrit :
>> Am 2020-11-13 um 19:24 schrieb Robert Scholte:
>>> Removing release profile should be combined with fail on missing/unknown
>>> profile of MNG-6012
>> Agreed, Karl just needs to complete his implementation.
>>
>>> Remove plugin section in super POM should be fine, now that Hervé has
>>> added warnings for it.
>> Correct.
> 2 remarks:
> 1. to better evaluate the impact, we are talking about default version for
> antrun, assembly, dependency and release: the choice of removing that default
> version or not can be done per-plugin
> 2. adding a warning if someone uses the version provided by super-pom was done
> to permit keeping a default version in super-pom but warning that using it is
> not the safest: then avoid bluntly removing the version
You know what many people do with warnings in a large build? They ignore
them. Also the fix is quite easy: add the plugin to your POM.
Personally, I prefer to fail that use a 5 year old plugin. That is the
first we ask: update the plugin and see whether it still fails.
I see your concerns, but breaking stuff is justified for a major version.
M
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Next release should a pre Maven 4.0.0
Posted by Hervé BOUTEMY <he...@free.fr>.
Le vendredi 13 novembre 2020, 19:28:20 CET Michael Osipov a écrit :
> Am 2020-11-13 um 19:24 schrieb Robert Scholte:
> > Removing release profile should be combined with fail on missing/unknown
> > profile of MNG-6012
> Agreed, Karl just needs to complete his implementation.
>
> > Remove plugin section in super POM should be fine, now that Hervé has
> > added warnings for it.
> Correct.
2 remarks:
1. to better evaluate the impact, we are talking about default version for
antrun, assembly, dependency and release: the choice of removing that default
version or not can be done per-plugin
2. adding a warning if someone uses the version provided by super-pom was done
to permit keeping a default version in super-pom but warning that using it is
not the safest: then avoid bluntly removing the version
>
> > There should be a default repository: central. I guess you want to move it
> > to conf/settings.xml in the distribution.
> Exactly!
>
> > Robert
> >
> > On 13-11-2020 18:23:20, Michael Osipov <mi...@apache.org> wrote:
> >>From the top of my head:
> > * Remove release profile
> > * Remove plugin section in super POM
> > * Move Central out of Core
> >
> > As well as a review of all consistency fixes to dependency resolution
> > done by Christian Schulte.
> >
> > I also agree with maven-compat. This needs to go, currently not possible
> > due to MNG-6561.
> >
> > Am 2020-11-13 um 18:11 schrieb Robert Scholte:
> >> I'm not going to say simply yes, it probably depends. Any specific things
> >> you have in mind? Also, I don't know what to do with maven-compat.
> >> I would prefer to remove it and introduce maven-compat3 as a bucket for
> >> classes that we don't want to use in Maven 4, but can still be used by
> >> plugins. Reusing the maven-compat artifactId with a different set of
> >> classes is most likely a recipe for disaster.
> >>
> >> Robert
> >> On 13-11-2020 17:53:47, Michael Osipov wrote:
> >> Does this mean that we can finally drop deprecated stuff and even break
> >> compat?
> >>
> >> ---------------------------------------------------------------------
> >> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Next release should a pre Maven 4.0.0
Posted by Michael Osipov <mi...@apache.org>.
Am 2020-11-13 um 19:24 schrieb Robert Scholte:
> Removing release profile should be combined with fail on missing/unknown profile of MNG-6012
Agreed, Karl just needs to complete his implementation.
> Remove plugin section in super POM should be fine, now that Hervé has added warnings for it.
Correct.
> There should be a default repository: central. I guess you want to move it to conf/settings.xml in the distribution.
Exactly!
> Robert
> On 13-11-2020 18:23:20, Michael Osipov <mi...@apache.org> wrote:
>>From the top of my head:
>
> * Remove release profile
> * Remove plugin section in super POM
> * Move Central out of Core
>
> As well as a review of all consistency fixes to dependency resolution
> done by Christian Schulte.
>
> I also agree with maven-compat. This needs to go, currently not possible
> due to MNG-6561.
>
> Am 2020-11-13 um 18:11 schrieb Robert Scholte:
>> I'm not going to say simply yes, it probably depends. Any specific things you have in mind?
>> Also, I don't know what to do with maven-compat.
>> I would prefer to remove it and introduce maven-compat3 as a bucket for classes that we don't want to use in Maven 4, but can still be used by plugins.
>> Reusing the maven-compat artifactId with a different set of classes is most likely a recipe for disaster.
>>
>> Robert
>> On 13-11-2020 17:53:47, Michael Osipov wrote:
>> Does this mean that we can finally drop deprecated stuff and even break
>> compat?
>>
>> ---------------------------------------------------------------------
>> 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] Next release should a pre Maven 4.0.0
Posted by Robert Scholte <rf...@apache.org>.
Removing release profile should be combined with fail on missing/unknown profile of MNG-6012
Remove plugin section in super POM should be fine, now that Hervé has added warnings for it.
There should be a default repository: central. I guess you want to move it to conf/settings.xml in the distribution.
Robert
On 13-11-2020 18:23:20, Michael Osipov <mi...@apache.org> wrote:
From the top of my head:
* Remove release profile
* Remove plugin section in super POM
* Move Central out of Core
As well as a review of all consistency fixes to dependency resolution
done by Christian Schulte.
I also agree with maven-compat. This needs to go, currently not possible
due to MNG-6561.
Am 2020-11-13 um 18:11 schrieb Robert Scholte:
> I'm not going to say simply yes, it probably depends. Any specific things you have in mind?
> Also, I don't know what to do with maven-compat.
> I would prefer to remove it and introduce maven-compat3 as a bucket for classes that we don't want to use in Maven 4, but can still be used by plugins.
> Reusing the maven-compat artifactId with a different set of classes is most likely a recipe for disaster.
>
> Robert
> On 13-11-2020 17:53:47, Michael Osipov wrote:
> Does this mean that we can finally drop deprecated stuff and even break
> compat?
>
> ---------------------------------------------------------------------
> 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] Next release should a pre Maven 4.0.0
Posted by Michael Osipov <mi...@apache.org>.
From the top of my head:
* Remove release profile
* Remove plugin section in super POM
* Move Central out of Core
As well as a review of all consistency fixes to dependency resolution
done by Christian Schulte.
I also agree with maven-compat. This needs to go, currently not possible
due to MNG-6561.
Am 2020-11-13 um 18:11 schrieb Robert Scholte:
> I'm not going to say simply yes, it probably depends. Any specific things you have in mind?
> Also, I don't know what to do with maven-compat.
> I would prefer to remove it and introduce maven-compat3 as a bucket for classes that we don't want to use in Maven 4, but can still be used by plugins.
> Reusing the maven-compat artifactId with a different set of classes is most likely a recipe for disaster.
>
> Robert
> On 13-11-2020 17:53:47, Michael Osipov <mi...@apache.org> wrote:
> Does this mean that we can finally drop deprecated stuff and even break
> compat?
>
> ---------------------------------------------------------------------
> 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] Next release should a pre Maven 4.0.0
Posted by Robert Scholte <rf...@apache.org>.
I'm not going to say simply yes, it probably depends. Any specific things you have in mind?
Also, I don't know what to do with maven-compat.
I would prefer to remove it and introduce maven-compat3 as a bucket for classes that we don't want to use in Maven 4, but can still be used by plugins.
Reusing the maven-compat artifactId with a different set of classes is most likely a recipe for disaster.
Robert
On 13-11-2020 17:53:47, Michael Osipov <mi...@apache.org> wrote:
Does this mean that we can finally drop deprecated stuff and even break
compat?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Next release should a pre Maven 4.0.0
Posted by Michael Osipov <mi...@apache.org>.
Does this mean that we can finally drop deprecated stuff and even break
compat?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Next release should a pre Maven 4.0.0
Posted by Hervé BOUTEMY <he...@free.fr>.
very good idea
such an alpha will also be the opportunity to test MNG-5001 = really check
@readonly Mojo parameter, with warning instead of failure, because it seems
there are unexpected side effects for example on maven-site-plugin
Regards,
Hervé
Le jeudi 12 novembre 2020, 20:00:21 CET Robert Scholte a écrit :
> Hi,
>
> It is already several years ago where we started discussing about Maven Next
> Generations. Clearly we needed to work on the pom, because over time we're
> facing more and more limitations. For (Maven) Central the Model 4.0.0 will
> be required pom format, there's no discussion about that. So we needed a
> new architecture where there's a local pom that is transformed to Model
> 4.0.0 or where it can be generated. With the implementation of MNG-6656 and
> the improvement with MNG-6957 we've made the first and important steps
> based on pom transformation. If this concept proofs itself, we can start
> thinking about enhancing the pom model.
>
> When talking about Model 5.0.0 it looked like it would be great to introduce
> it for Maven 5. There was even a period where we thought about skipping
> Maven 4, just to sync the Model version with the Maven version. However, we
> discovered that this would be a huge change, and that we would probably
> need a couple of Maven 4 releases before moving to Maven 5. Maven 4 would
> consist of preparation releases. I've started writing the build/consumer to
> proof that the it is indeed possible to separate the local pom from the
> distributed pom, even though they both are currently still Model 4.0.0
> compatible. The original idea was:
> Maven 3: build/consumer feature disabled by default
> Maven 4: build/consumer feature enabled by default
>
> Maven 5: Model 5
>
> We were worried that this wouldn't give us enough feedback.
> maven-integration-testing shows that build/consumer does work. There should
> be enough trust to enable it by default, it shouldn't impact existing
> projects (the last find by Michael was actually great. It demonstrated the
> effect when using threads. The fix made sense and Maven was stable again).
> But it is simply not enough. We need much more feedback.
>
> Meanwhile other improvements have been done, that has impact:
> - new behavior of reactor commandline arguments
> - upgrade of default versions of plugins per packaging type
> - requiring Java 8
> - Maven wrapper
> - there's a PR waiting that will shift the logic of the
> ProjectBuilder/ModelBuilder. As this is quite important for more people to
> understand, I'll record a Q&A with Maarten+Martin soon and share it with
> you. There are probably more, but all these already defend my opinion about
> the next Maven version.
>
> To me it is not a Maven 3 anymore, we're reached a point where we should
> start calling it Maven 4. The next release should probably have an alpha
> suffix, just to give users the chance to do alpha testing.
>
> WDYT?
> Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Next release should a pre Maven 4.0.0
Posted by Andreas Aronsson <ar...@aron.nu>.
Hi,
as an avid user and writer of plugins.
I strongly prefer smaller releases.
They are easier to adopt.
As an example the first 4.0 to only bring a few potentially breaking
changes looks very good to me.
I understand that the release process involves a significant amount of work.
Many thanks for all the value your hard work brings us!
All the best
Andreas
On Mon, Nov 16, 2020 at 5:15 PM Michael Osipov <mi...@apache.org> wrote:
> Am 2020-11-13 um 18:31 schrieb Karl Heinz Marbaise:
> > Hi,
> >
> > On 12.11.20 20:00, Robert Scholte wrote:
> >> Hi,
> >>
> >> It is already several years ago where we started discussing about
> >> Maven Next Generations.
> >> Clearly we needed to work on the pom, because over time we're facing
> >> more and more limitations.
> >> For (Maven) Central the Model 4.0.0 will be required pom format,
> >> there's no discussion about that. So we needed a new architecture
> >> where there's a local pom that is transformed to Model 4.0.0 or where
> >> it can be generated.
> >> With the implementation of MNG-6656 and the improvement with MNG-6957
> >> we've made the first and important steps based on pom transformation.
> >> If this concept proofs itself, we can start thinking about enhancing
> >> the pom model.
> >>
> >> When talking about Model 5.0.0 it looked like it would be great to
> >> introduce it for Maven 5. There was even a period where we thought
> >> about skipping Maven 4, just to sync the Model version with the Maven
> >> version.
> >> However, we discovered that this would be a huge change, and that we
> >> would probably need a couple of Maven 4 releases before moving to
> >> Maven 5. Maven 4 would consist of preparation releases.
> >> I've started writing the build/consumer to proof that the it is indeed
> >> possible to separate the local pom from the distributed pom, even
> >> though they both are currently still Model 4.0.0 compatible.
> >> The original idea was:
> >> Maven 3: build/consumer feature disabled by default
> >> Maven 4: build/consumer feature enabled by default
> >>
> >> Maven 5: Model 5
> >>
> >> We were worried that this wouldn't give us enough feedback.
> >> maven-integration-testing shows that build/consumer does work. There
> >> should be enough trust to enable it by default, it shouldn't impact
> >> existing projects (the last find by Michael was actually great. It
> >> demonstrated the effect when using threads. The fix made sense and
> >> Maven was stable again). But it is simply not enough. We need much
> >> more feedback.
> >>
> >> Meanwhile other improvements have been done, that has impact:
> >> - new behavior of reactor commandline arguments
> >> - upgrade of default versions of plugins per packaging type
> >> - requiring Java 8
> >> - Maven wrapper
> >> - there's a PR waiting that will shift the logic of the
> >> ProjectBuilder/ModelBuilder. As this is quite important for more
> >> people to understand, I'll record a Q&A with Maarten+Martin soon and
> >> share it with you.
> >
> > it would be nice to have a kind of information here on the dev list to
> > see what kind of consequences this has?
> >
> >> There are probably more, but all these already defend my opinion about
> >> the next Maven version.
> >>
> >> To me it is not a Maven 3 anymore, we're reached a point where we
> >> should start calling it Maven 4.
> >> The next release should probably have an alpha suffix, just to give
> >> users the chance to do alpha testing.
> >
> >
> > With a new major version we start to produce high expectations with 4.X
> >
> > I would suggest to do 3.7.0 first with support:
> >
> > - new behavior of reactor commandline arguments(?) ?
> > - Maven 3: build/consumer feature disabled by default (??)
> > Needs more testing of corse...
> > cause this would help a lot of people... make it easier
> > and get rid of flatten part..
> > - Signing of artifacts etc. needed to solved first.
> > - requiring Java 8 (not a big issue; done for several Maven minor
> > versions before)
> > - Maven wrapper
> >
> > getting all that above working fine... and mark a number of classes /
> > parts/modules as deprecated ... which has not being done yet.
> >
> > Also I suggest to 3.7.0 instead of 4.0.0 for this cause otherise the
> > adoption is more hesitant than for a 4.0.0 which is a major version
> > upgrade....
> >
> >
> > Maven 4.0.0
> > - build/consumer feature enabled by default
> > - Remove old stuff
> > - break things and improve the build pom ...
> > - Remove maven-compat .. ? introducing maven-compat3 ?..
> > - Maybe JDK 11 base? (LTS?) just a thought
> > -
> >
> > Also making a 3.7.0 before so we can learn things related to
> > build-consumer pom before going to Maven 4.0.0 ....where we can break
> > things which we can not in 3.7.0 ...
>
> Hi Karl,
>
> I don't think that that we should press such an amount of changes into a
> minor release. If you want to have a 3.7.0 why not branch off 3.6.3 and
> cherry-pick selected changes....
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Andreas Aronsson
Mobil: +46 704 566 595
http://www.aron.nu
"I'd rather have friends who care than friends who agree with me."
Arlo Guthrie
Re: [DISCUSS] Next release should a pre Maven 4.0.0
Posted by Michael Osipov <mi...@apache.org>.
Please provide two PRs:
1. Update all references from 3.7.0 to 4.0.0 in core
2. Update all references from 3.7.0 to 4.0.0 in ITs
Am 2020-11-26 um 19:42 schrieb Robert Scholte:
> Based on the responses it looks like most agree on moving forward to Maven 4.
> Regarding the concerns of Karl Heinz I agree with Michaels proposal:
> If there is a real need for Maven 3.7.0, let's cherry-pick those commits we want to include.
>
> I'll update the version tomorrow and rename the versions in Jira.
>
> This means we can also have a look at issues that were postponed to Maven 4, because they might break some builds. Would be great if we could clean up those list of branches.
>
> thanks,
> Robert
> On 21-11-2020 02:30:45, Hervé BOUTEMY <he...@free.fr> wrote:
> Le lundi 16 novembre 2020, 17:15:39 CET Michael Osipov a écrit :
>> Am 2020-11-13 um 18:31 schrieb Karl Heinz Marbaise:
>>> Hi,
>>>
>>> On 12.11.20 20:00, Robert Scholte wrote:
>>>> Hi,
>>>>
>>>> It is already several years ago where we started discussing about
>>>> Maven Next Generations.
>>>> Clearly we needed to work on the pom, because over time we're facing
>>>> more and more limitations.
>>>> For (Maven) Central the Model 4.0.0 will be required pom format,
>>>> there's no discussion about that. So we needed a new architecture
>>>> where there's a local pom that is transformed to Model 4.0.0 or where
>>>> it can be generated.
>>>> With the implementation of MNG-6656 and the improvement with MNG-6957
>>>> we've made the first and important steps based on pom transformation.
>>>> If this concept proofs itself, we can start thinking about enhancing
>>>> the pom model.
>>>>
>>>> When talking about Model 5.0.0 it looked like it would be great to
>>>> introduce it for Maven 5. There was even a period where we thought
>>>> about skipping Maven 4, just to sync the Model version with the Maven
>>>> version.
>>>> However, we discovered that this would be a huge change, and that we
>>>> would probably need a couple of Maven 4 releases before moving to
>>>> Maven 5. Maven 4 would consist of preparation releases.
>>>> I've started writing the build/consumer to proof that the it is indeed
>>>> possible to separate the local pom from the distributed pom, even
>>>> though they both are currently still Model 4.0.0 compatible.
>>>> The original idea was:
>>>> Maven 3: build/consumer feature disabled by default
>>>> Maven 4: build/consumer feature enabled by default
>>>>
>>>> Maven 5: Model 5
>>>>
>>>> We were worried that this wouldn't give us enough feedback.
>>>> maven-integration-testing shows that build/consumer does work. There
>>>> should be enough trust to enable it by default, it shouldn't impact
>>>> existing projects (the last find by Michael was actually great. It
>>>> demonstrated the effect when using threads. The fix made sense and
>>>> Maven was stable again). But it is simply not enough. We need much
>>>> more feedback.
>>>>
>>>> Meanwhile other improvements have been done, that has impact:
>>>> - new behavior of reactor commandline arguments
>>>> - upgrade of default versions of plugins per packaging type
>>>> - requiring Java 8
>>>> - Maven wrapper
>>>> - there's a PR waiting that will shift the logic of the
>>>> ProjectBuilder/ModelBuilder. As this is quite important for more
>>>> people to understand, I'll record a Q&A with Maarten+Martin soon and
>>>> share it with you.
>>>
>>> it would be nice to have a kind of information here on the dev list to
>>> see what kind of consequences this has?
>>>
>>>> There are probably more, but all these already defend my opinion about
>>>> the next Maven version.
>>>>
>>>> To me it is not a Maven 3 anymore, we're reached a point where we
>>>> should start calling it Maven 4.
>>>> The next release should probably have an alpha suffix, just to give
>>>> users the chance to do alpha testing.
>>>
>>> With a new major version we start to produce high expectations with 4.X
>>>
>>> I would suggest to do 3.7.0 first with support:
>>>
>>> - new behavior of reactor commandline arguments(?) ?
>>> - Maven 3: build/consumer feature disabled by default (??)
>>>
>>> Needs more testing of corse...
>>> cause this would help a lot of people... make it easier
>>> and get rid of flatten part..
>>> - Signing of artifacts etc. needed to solved first.
>>>
>>> - requiring Java 8 (not a big issue; done for several Maven minor
>>> versions before)
>>> - Maven wrapper
>>>
>>> getting all that above working fine... and mark a number of classes /
>>> parts/modules as deprecated ... which has not being done yet.
>>>
>>> Also I suggest to 3.7.0 instead of 4.0.0 for this cause otherise the
>>> adoption is more hesitant than for a 4.0.0 which is a major version
>>> upgrade....
>>>
>>>
>>> Maven 4.0.0
>>>
>>> - build/consumer feature enabled by default
>>> - Remove old stuff
>>> - break things and improve the build pom ...
>>> - Remove maven-compat .. ? introducing maven-compat3 ?..
>>> - Maybe JDK 11 base? (LTS?) just a thought
>>> -
>>>
>>> Also making a 3.7.0 before so we can learn things related to
>>> build-consumer pom before going to Maven 4.0.0 ....where we can break
>>> things which we can not in 3.7.0 ...
>>
>> Hi Karl,
>>
>> I don't think that that we should press such an amount of changes into a
>> minor release. If you want to have a 3.7.0 why not branch off 3.6.3 and
>> cherry-pick selected changes....
> going to 4.0.0-alpha is a way to avoid additional complexity of feature flags
> and an explicit testing period: even if we feature-flag build/consumer feature,
> there are many changes that require more serious testing IMHO than going
> directly to 3.7.0 with implicit high confidence
>
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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] Next release should a pre Maven 4.0.0
Posted by Robert Scholte <rf...@apache.org>.
Based on the responses it looks like most agree on moving forward to Maven 4.
Regarding the concerns of Karl Heinz I agree with Michaels proposal:
If there is a real need for Maven 3.7.0, let's cherry-pick those commits we want to include.
I'll update the version tomorrow and rename the versions in Jira.
This means we can also have a look at issues that were postponed to Maven 4, because they might break some builds. Would be great if we could clean up those list of branches.
thanks,
Robert
On 21-11-2020 02:30:45, Hervé BOUTEMY <he...@free.fr> wrote:
Le lundi 16 novembre 2020, 17:15:39 CET Michael Osipov a écrit :
> Am 2020-11-13 um 18:31 schrieb Karl Heinz Marbaise:
> > Hi,
> >
> > On 12.11.20 20:00, Robert Scholte wrote:
> >> Hi,
> >>
> >> It is already several years ago where we started discussing about
> >> Maven Next Generations.
> >> Clearly we needed to work on the pom, because over time we're facing
> >> more and more limitations.
> >> For (Maven) Central the Model 4.0.0 will be required pom format,
> >> there's no discussion about that. So we needed a new architecture
> >> where there's a local pom that is transformed to Model 4.0.0 or where
> >> it can be generated.
> >> With the implementation of MNG-6656 and the improvement with MNG-6957
> >> we've made the first and important steps based on pom transformation.
> >> If this concept proofs itself, we can start thinking about enhancing
> >> the pom model.
> >>
> >> When talking about Model 5.0.0 it looked like it would be great to
> >> introduce it for Maven 5. There was even a period where we thought
> >> about skipping Maven 4, just to sync the Model version with the Maven
> >> version.
> >> However, we discovered that this would be a huge change, and that we
> >> would probably need a couple of Maven 4 releases before moving to
> >> Maven 5. Maven 4 would consist of preparation releases.
> >> I've started writing the build/consumer to proof that the it is indeed
> >> possible to separate the local pom from the distributed pom, even
> >> though they both are currently still Model 4.0.0 compatible.
> >> The original idea was:
> >> Maven 3: build/consumer feature disabled by default
> >> Maven 4: build/consumer feature enabled by default
> >>
> >> Maven 5: Model 5
> >>
> >> We were worried that this wouldn't give us enough feedback.
> >> maven-integration-testing shows that build/consumer does work. There
> >> should be enough trust to enable it by default, it shouldn't impact
> >> existing projects (the last find by Michael was actually great. It
> >> demonstrated the effect when using threads. The fix made sense and
> >> Maven was stable again). But it is simply not enough. We need much
> >> more feedback.
> >>
> >> Meanwhile other improvements have been done, that has impact:
> >> - new behavior of reactor commandline arguments
> >> - upgrade of default versions of plugins per packaging type
> >> - requiring Java 8
> >> - Maven wrapper
> >> - there's a PR waiting that will shift the logic of the
> >> ProjectBuilder/ModelBuilder. As this is quite important for more
> >> people to understand, I'll record a Q&A with Maarten+Martin soon and
> >> share it with you.
> >
> > it would be nice to have a kind of information here on the dev list to
> > see what kind of consequences this has?
> >
> >> There are probably more, but all these already defend my opinion about
> >> the next Maven version.
> >>
> >> To me it is not a Maven 3 anymore, we're reached a point where we
> >> should start calling it Maven 4.
> >> The next release should probably have an alpha suffix, just to give
> >> users the chance to do alpha testing.
> >
> > With a new major version we start to produce high expectations with 4.X
> >
> > I would suggest to do 3.7.0 first with support:
> >
> > - new behavior of reactor commandline arguments(?) ?
> > - Maven 3: build/consumer feature disabled by default (??)
> >
> > Needs more testing of corse...
> > cause this would help a lot of people... make it easier
> > and get rid of flatten part..
> > - Signing of artifacts etc. needed to solved first.
> >
> > - requiring Java 8 (not a big issue; done for several Maven minor
> > versions before)
> > - Maven wrapper
> >
> > getting all that above working fine... and mark a number of classes /
> > parts/modules as deprecated ... which has not being done yet.
> >
> > Also I suggest to 3.7.0 instead of 4.0.0 for this cause otherise the
> > adoption is more hesitant than for a 4.0.0 which is a major version
> > upgrade....
> >
> >
> > Maven 4.0.0
> >
> > - build/consumer feature enabled by default
> > - Remove old stuff
> > - break things and improve the build pom ...
> > - Remove maven-compat .. ? introducing maven-compat3 ?..
> > - Maybe JDK 11 base? (LTS?) just a thought
> > -
> >
> > Also making a 3.7.0 before so we can learn things related to
> > build-consumer pom before going to Maven 4.0.0 ....where we can break
> > things which we can not in 3.7.0 ...
>
> Hi Karl,
>
> I don't think that that we should press such an amount of changes into a
> minor release. If you want to have a 3.7.0 why not branch off 3.6.3 and
> cherry-pick selected changes....
going to 4.0.0-alpha is a way to avoid additional complexity of feature flags
and an explicit testing period: even if we feature-flag build/consumer feature,
there are many changes that require more serious testing IMHO than going
directly to 3.7.0 with implicit high confidence
>
>
>
> ---------------------------------------------------------------------
> 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] Next release should a pre Maven 4.0.0
Posted by Hervé BOUTEMY <he...@free.fr>.
Le lundi 16 novembre 2020, 17:15:39 CET Michael Osipov a écrit :
> Am 2020-11-13 um 18:31 schrieb Karl Heinz Marbaise:
> > Hi,
> >
> > On 12.11.20 20:00, Robert Scholte wrote:
> >> Hi,
> >>
> >> It is already several years ago where we started discussing about
> >> Maven Next Generations.
> >> Clearly we needed to work on the pom, because over time we're facing
> >> more and more limitations.
> >> For (Maven) Central the Model 4.0.0 will be required pom format,
> >> there's no discussion about that. So we needed a new architecture
> >> where there's a local pom that is transformed to Model 4.0.0 or where
> >> it can be generated.
> >> With the implementation of MNG-6656 and the improvement with MNG-6957
> >> we've made the first and important steps based on pom transformation.
> >> If this concept proofs itself, we can start thinking about enhancing
> >> the pom model.
> >>
> >> When talking about Model 5.0.0 it looked like it would be great to
> >> introduce it for Maven 5. There was even a period where we thought
> >> about skipping Maven 4, just to sync the Model version with the Maven
> >> version.
> >> However, we discovered that this would be a huge change, and that we
> >> would probably need a couple of Maven 4 releases before moving to
> >> Maven 5. Maven 4 would consist of preparation releases.
> >> I've started writing the build/consumer to proof that the it is indeed
> >> possible to separate the local pom from the distributed pom, even
> >> though they both are currently still Model 4.0.0 compatible.
> >> The original idea was:
> >> Maven 3: build/consumer feature disabled by default
> >> Maven 4: build/consumer feature enabled by default
> >>
> >> Maven 5: Model 5
> >>
> >> We were worried that this wouldn't give us enough feedback.
> >> maven-integration-testing shows that build/consumer does work. There
> >> should be enough trust to enable it by default, it shouldn't impact
> >> existing projects (the last find by Michael was actually great. It
> >> demonstrated the effect when using threads. The fix made sense and
> >> Maven was stable again). But it is simply not enough. We need much
> >> more feedback.
> >>
> >> Meanwhile other improvements have been done, that has impact:
> >> - new behavior of reactor commandline arguments
> >> - upgrade of default versions of plugins per packaging type
> >> - requiring Java 8
> >> - Maven wrapper
> >> - there's a PR waiting that will shift the logic of the
> >> ProjectBuilder/ModelBuilder. As this is quite important for more
> >> people to understand, I'll record a Q&A with Maarten+Martin soon and
> >> share it with you.
> >
> > it would be nice to have a kind of information here on the dev list to
> > see what kind of consequences this has?
> >
> >> There are probably more, but all these already defend my opinion about
> >> the next Maven version.
> >>
> >> To me it is not a Maven 3 anymore, we're reached a point where we
> >> should start calling it Maven 4.
> >> The next release should probably have an alpha suffix, just to give
> >> users the chance to do alpha testing.
> >
> > With a new major version we start to produce high expectations with 4.X
> >
> > I would suggest to do 3.7.0 first with support:
> >
> > - new behavior of reactor commandline arguments(?) ?
> > - Maven 3: build/consumer feature disabled by default (??)
> >
> > Needs more testing of corse...
> > cause this would help a lot of people... make it easier
> > and get rid of flatten part..
> > - Signing of artifacts etc. needed to solved first.
> >
> > - requiring Java 8 (not a big issue; done for several Maven minor
> > versions before)
> > - Maven wrapper
> >
> > getting all that above working fine... and mark a number of classes /
> > parts/modules as deprecated ... which has not being done yet.
> >
> > Also I suggest to 3.7.0 instead of 4.0.0 for this cause otherise the
> > adoption is more hesitant than for a 4.0.0 which is a major version
> > upgrade....
> >
> >
> > Maven 4.0.0
> >
> > - build/consumer feature enabled by default
> > - Remove old stuff
> > - break things and improve the build pom ...
> > - Remove maven-compat .. ? introducing maven-compat3 ?..
> > - Maybe JDK 11 base? (LTS?) just a thought
> > -
> >
> > Also making a 3.7.0 before so we can learn things related to
> > build-consumer pom before going to Maven 4.0.0 ....where we can break
> > things which we can not in 3.7.0 ...
>
> Hi Karl,
>
> I don't think that that we should press such an amount of changes into a
> minor release. If you want to have a 3.7.0 why not branch off 3.6.3 and
> cherry-pick selected changes....
going to 4.0.0-alpha is a way to avoid additional complexity of feature flags
and an explicit testing period: even if we feature-flag build/consumer feature,
there are many changes that require more serious testing IMHO than going
directly to 3.7.0 with implicit high confidence
>
>
>
> ---------------------------------------------------------------------
> 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] Next release should a pre Maven 4.0.0
Posted by Michael Osipov <mi...@apache.org>.
Am 2020-11-13 um 18:31 schrieb Karl Heinz Marbaise:
> Hi,
>
> On 12.11.20 20:00, Robert Scholte wrote:
>> Hi,
>>
>> It is already several years ago where we started discussing about
>> Maven Next Generations.
>> Clearly we needed to work on the pom, because over time we're facing
>> more and more limitations.
>> For (Maven) Central the Model 4.0.0 will be required pom format,
>> there's no discussion about that. So we needed a new architecture
>> where there's a local pom that is transformed to Model 4.0.0 or where
>> it can be generated.
>> With the implementation of MNG-6656 and the improvement with MNG-6957
>> we've made the first and important steps based on pom transformation.
>> If this concept proofs itself, we can start thinking about enhancing
>> the pom model.
>>
>> When talking about Model 5.0.0 it looked like it would be great to
>> introduce it for Maven 5. There was even a period where we thought
>> about skipping Maven 4, just to sync the Model version with the Maven
>> version.
>> However, we discovered that this would be a huge change, and that we
>> would probably need a couple of Maven 4 releases before moving to
>> Maven 5. Maven 4 would consist of preparation releases.
>> I've started writing the build/consumer to proof that the it is indeed
>> possible to separate the local pom from the distributed pom, even
>> though they both are currently still Model 4.0.0 compatible.
>> The original idea was:
>> Maven 3: build/consumer feature disabled by default
>> Maven 4: build/consumer feature enabled by default
>>
>> Maven 5: Model 5
>>
>> We were worried that this wouldn't give us enough feedback.
>> maven-integration-testing shows that build/consumer does work. There
>> should be enough trust to enable it by default, it shouldn't impact
>> existing projects (the last find by Michael was actually great. It
>> demonstrated the effect when using threads. The fix made sense and
>> Maven was stable again). But it is simply not enough. We need much
>> more feedback.
>>
>> Meanwhile other improvements have been done, that has impact:
>> - new behavior of reactor commandline arguments
>> - upgrade of default versions of plugins per packaging type
>> - requiring Java 8
>> - Maven wrapper
>> - there's a PR waiting that will shift the logic of the
>> ProjectBuilder/ModelBuilder. As this is quite important for more
>> people to understand, I'll record a Q&A with Maarten+Martin soon and
>> share it with you.
>
> it would be nice to have a kind of information here on the dev list to
> see what kind of consequences this has?
>
>> There are probably more, but all these already defend my opinion about
>> the next Maven version.
>>
>> To me it is not a Maven 3 anymore, we're reached a point where we
>> should start calling it Maven 4.
>> The next release should probably have an alpha suffix, just to give
>> users the chance to do alpha testing.
>
>
> With a new major version we start to produce high expectations with 4.X
>
> I would suggest to do 3.7.0 first with support:
>
> - new behavior of reactor commandline arguments(?) ?
> - Maven 3: build/consumer feature disabled by default (??)
> Needs more testing of corse...
> cause this would help a lot of people... make it easier
> and get rid of flatten part..
> - Signing of artifacts etc. needed to solved first.
> - requiring Java 8 (not a big issue; done for several Maven minor
> versions before)
> - Maven wrapper
>
> getting all that above working fine... and mark a number of classes /
> parts/modules as deprecated ... which has not being done yet.
>
> Also I suggest to 3.7.0 instead of 4.0.0 for this cause otherise the
> adoption is more hesitant than for a 4.0.0 which is a major version
> upgrade....
>
>
> Maven 4.0.0
> - build/consumer feature enabled by default
> - Remove old stuff
> - break things and improve the build pom ...
> - Remove maven-compat .. ? introducing maven-compat3 ?..
> - Maybe JDK 11 base? (LTS?) just a thought
> -
>
> Also making a 3.7.0 before so we can learn things related to
> build-consumer pom before going to Maven 4.0.0 ....where we can break
> things which we can not in 3.7.0 ...
Hi Karl,
I don't think that that we should press such an amount of changes into a
minor release. If you want to have a 3.7.0 why not branch off 3.6.3 and
cherry-pick selected changes....
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Next release should a pre Maven 4.0.0
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi,
On 12.11.20 20:00, Robert Scholte wrote:
> Hi,
>
> It is already several years ago where we started discussing about Maven Next Generations.
> Clearly we needed to work on the pom, because over time we're facing more and more limitations.
> For (Maven) Central the Model 4.0.0 will be required pom format, there's no discussion about that. So we needed a new architecture where there's a local pom that is transformed to Model 4.0.0 or where it can be generated.
> With the implementation of MNG-6656 and the improvement with MNG-6957 we've made the first and important steps based on pom transformation. If this concept proofs itself, we can start thinking about enhancing the pom model.
>
> When talking about Model 5.0.0 it looked like it would be great to introduce it for Maven 5. There was even a period where we thought about skipping Maven 4, just to sync the Model version with the Maven version.
> However, we discovered that this would be a huge change, and that we would probably need a couple of Maven 4 releases before moving to Maven 5. Maven 4 would consist of preparation releases.
> I've started writing the build/consumer to proof that the it is indeed possible to separate the local pom from the distributed pom, even though they both are currently still Model 4.0.0 compatible.
> The original idea was:
> Maven 3: build/consumer feature disabled by default
> Maven 4: build/consumer feature enabled by default
>
> Maven 5: Model 5
>
> We were worried that this wouldn't give us enough feedback. maven-integration-testing shows that build/consumer does work. There should be enough trust to enable it by default, it shouldn't impact existing projects (the last find by Michael was actually great. It demonstrated the effect when using threads. The fix made sense and Maven was stable again). But it is simply not enough. We need much more feedback.
>
> Meanwhile other improvements have been done, that has impact:
> - new behavior of reactor commandline arguments
> - upgrade of default versions of plugins per packaging type
> - requiring Java 8
> - Maven wrapper
> - there's a PR waiting that will shift the logic of the ProjectBuilder/ModelBuilder. As this is quite important for more people to understand, I'll record a Q&A with Maarten+Martin soon and share it with you.
it would be nice to have a kind of information here on the dev list to
see what kind of consequences this has?
> There are probably more, but all these already defend my opinion about the next Maven version.
>
> To me it is not a Maven 3 anymore, we're reached a point where we should start calling it Maven 4.
> The next release should probably have an alpha suffix, just to give users the chance to do alpha testing.
With a new major version we start to produce high expectations with 4.X
I would suggest to do 3.7.0 first with support:
- new behavior of reactor commandline arguments(?) ?
- Maven 3: build/consumer feature disabled by default (??)
Needs more testing of corse...
cause this would help a lot of people... make it easier
and get rid of flatten part..
- Signing of artifacts etc. needed to solved first.
- requiring Java 8 (not a big issue; done for several Maven minor
versions before)
- Maven wrapper
getting all that above working fine... and mark a number of classes /
parts/modules as deprecated ... which has not being done yet.
Also I suggest to 3.7.0 instead of 4.0.0 for this cause otherise the
adoption is more hesitant than for a 4.0.0 which is a major version
upgrade....
Maven 4.0.0
- build/consumer feature enabled by default
- Remove old stuff
- break things and improve the build pom ...
- Remove maven-compat .. ? introducing maven-compat3 ?..
- Maybe JDK 11 base? (LTS?) just a thought
-
Also making a 3.7.0 before so we can learn things related to
build-consumer pom before going to Maven 4.0.0 ....where we can break
things which we can not in 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] Next release should a pre Maven 4.0.0
Posted by Romain Manni-Bucau <rm...@gmail.com>.
@Robert: agree and we must move forward, just wanted to put a small warning
we shouldn't release just to let it go out but more to ensure it is adopted
in good conditions
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. 13 nov. 2020 à 09:14, Robert Scholte <rf...@apache.org> a
écrit :
> This is a good topic, but I suggest to start a different thread for it, so
> we can focus here on the version.
> Main question is: are there concerns about moving the version of Maven on
> master to 4.0.0?
>
> thanks,
> Robert
> On 13-11-2020 08:20:25, Romain Manni-Bucau <rm...@gmail.com> wrote:
> Hmm, this is used by several testing tools and static analyzis tools so the
> new pom should likely be at least next to this one but not replace it, like
> META-INF/maven/{G}/{A}/pom.original.xml.
> Flattening dependencies will likely speed up some tools parsing poms but
> tools also parse parent gav and module list (for the part I know) to find
> some structure so breaking that part is likely wrong, even for a consumed
> pom, this is meta we should keep IMHO.
> For instance, when Apache Beam moved from Maven to Gradle, they lost that
> and broke some tooling companies had, it requires some effort to compensate
> it so I think we shouldn't be that bad, in particular since it does not
> cost much to keep it working.
>
> Romain Manni-Bucau
> @rmannibucau | Blog
> | Old Blog
> | Github |
> LinkedIn | Book
>
>
>
> Le jeu. 12 nov. 2020 à 22:43, Robert Scholte a
> écrit :
>
> > The pom next to the artifact will be correct and ready to be consumed.
> > Only the /META-INF/maven/{G}/{A}/pom.xml will now be the local pom. If
> you
> > make use of some new features this pom might be incomplete, but AFAIK
> there
> > are only a few cases where this embedded pom is used.
> >
> > Robert
> > On 12-11-2020 22:38:33, Romain Manni-Bucau wrote:
> > Le jeu. 12 nov. 2020 à 22:14, Robert Scholte a
> > écrit :
> >
> > > The discussion is first of all saying the next release should be
> > > 4.0.0-alpha-1 (or something similar), so 3.6.3 was the last of the
> Maven
> > 3
> > > releases unless we need to backport security fixes.
> > > What to add to that release is the next discussion.
> > > Signing is only relevant for releases, but I think most companies don't
> > > sign jars for their internal projects.
> > > For those developers the missing features don't matter, but they can
> > > benefit from a huge amount of improvements.
> > >
> >
> > I disagree, a release is not only about signing but also letting others
> > consume artifacts you produce.
> > Having a proof it works for us is important before considering it can be
> a
> > released feature (on by default).
> > Also agree we shouldnt put a lot of features per release so maybe just
> the
> > pom one in alpha-1? This ensures people can test what we propose and not
> > only something else more shining.
> >
> >
> > > Robert
> > > On 12-11-2020 21:55:51, Romain Manni-Bucau wrote:
> > > Hmm, if it does not work e2e then even an alpha is pointless cause
> nobody
> > > can test it further than a hello world, was my point.
> > >
> > > Le jeu. 12 nov. 2020 à 21:01, Robert Scholte a
> > > écrit :
> > >
> > > > I don't expect that signing will work with the the first alpha, but
> > that
> > > > shouldn't stop us of collecting feedback.
> > > > Also we need to have a look at all plugins that do something with the
> > > pom,
> > > > like every packaging plugin, maven-source-plugin,
> maven-release-plugin
> > to
> > > > ensure the "right" pom is added.
> > > >
> > > > And for Maven 4.0.0 we shouldn't have milestone releases of plugins
> > (even
> > > > though they are stable).
> > > > There's still enough work to reach 4.0.0, but most likely the first
> > > alphas
> > > > are already good enough for the majority.
> > > >
> > > > On 12-11-2020 20:45:09, Romain Manni-Bucau wrote:
> > > > Did we already do mvn or mvn plugins (multimodules) release with the
> > > > consumer/producer pom feature?
> > > > If so +1 to do a v4 with this new feature "for us" and v5 with real
> > user
> > > > features and align it with the xsd.
> > > >
> > > > Le jeu. 12 nov. 2020 à 20:00, Robert Scholte a
> > > > écrit :
> > > >
> > > > > Hi,
> > > > >
> > > > > It is already several years ago where we started discussing about
> > Maven
> > > > > Next Generations.
> > > > > Clearly we needed to work on the pom, because over time we're
> facing
> > > more
> > > > > and more limitations.
> > > > > For (Maven) Central the Model 4.0.0 will be required pom format,
> > > there's
> > > > > no discussion about that. So we needed a new architecture where
> > > there's a
> > > > > local pom that is transformed to Model 4.0.0 or where it can be
> > > > generated.
> > > > > With the implementation of MNG-6656 and the improvement with
> MNG-6957
> > > > > we've made the first and important steps based on pom
> transformation.
> > > If
> > > > > this concept proofs itself, we can start thinking about enhancing
> the
> > > pom
> > > > > model.
> > > > >
> > > > > When talking about Model 5.0.0 it looked like it would be great to
> > > > > introduce it for Maven 5. There was even a period where we thought
> > > about
> > > > > skipping Maven 4, just to sync the Model version with the Maven
> > > version.
> > > > > However, we discovered that this would be a huge change, and that
> we
> > > > would
> > > > > probably need a couple of Maven 4 releases before moving to Maven
> 5.
> > > > Maven
> > > > > 4 would consist of preparation releases.
> > > > > I've started writing the build/consumer to proof that the it is
> > indeed
> > > > > possible to separate the local pom from the distributed pom, even
> > > though
> > > > > they both are currently still Model 4.0.0 compatible.
> > > > > The original idea was:
> > > > > Maven 3: build/consumer feature disabled by default
> > > > > Maven 4: build/consumer feature enabled by default
> > > > >
> > > > > Maven 5: Model 5
> > > > >
> > > > > We were worried that this wouldn't give us enough feedback.
> > > > > maven-integration-testing shows that build/consumer does work.
> There
> > > > should
> > > > > be enough trust to enable it by default, it shouldn't impact
> existing
> > > > > projects (the last find by Michael was actually great. It
> > demonstrated
> > > > the
> > > > > effect when using threads. The fix made sense and Maven was stable
> > > > again).
> > > > > But it is simply not enough. We need much more feedback.
> > > > >
> > > > > Meanwhile other improvements have been done, that has impact:
> > > > > - new behavior of reactor commandline arguments
> > > > > - upgrade of default versions of plugins per packaging type
> > > > > - requiring Java 8
> > > > > - Maven wrapper
> > > > > - there's a PR waiting that will shift the logic of the
> > > > > ProjectBuilder/ModelBuilder. As this is quite important for more
> > people
> > > > to
> > > > > understand, I'll record a Q&A with Maarten+Martin soon and share it
> > > with
> > > > > you.
> > > > > There are probably more, but all these already defend my opinion
> > about
> > > > the
> > > > > next Maven version.
> > > > >
> > > > > To me it is not a Maven 3 anymore, we're reached a point where we
> > > should
> > > > > start calling it Maven 4.
> > > > > The next release should probably have an alpha suffix, just to give
> > > users
> > > > > the chance to do alpha testing.
> > > > >
> > > > > WDYT?
> > > > > Robert
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: [DISCUSS] Next release should a pre Maven 4.0.0
Posted by Robert Scholte <rf...@apache.org>.
This is a good topic, but I suggest to start a different thread for it, so we can focus here on the version.
Main question is: are there concerns about moving the version of Maven on master to 4.0.0?
thanks,
Robert
On 13-11-2020 08:20:25, Romain Manni-Bucau <rm...@gmail.com> wrote:
Hmm, this is used by several testing tools and static analyzis tools so the
new pom should likely be at least next to this one but not replace it, like
META-INF/maven/{G}/{A}/pom.original.xml.
Flattening dependencies will likely speed up some tools parsing poms but
tools also parse parent gav and module list (for the part I know) to find
some structure so breaking that part is likely wrong, even for a consumed
pom, this is meta we should keep IMHO.
For instance, when Apache Beam moved from Maven to Gradle, they lost that
and broke some tooling companies had, it requires some effort to compensate
it so I think we shouldn't be that bad, in particular since it does not
cost much to keep it working.
Romain Manni-Bucau
@rmannibucau | Blog
| Old Blog
| Github |
LinkedIn | Book
Le jeu. 12 nov. 2020 à 22:43, Robert Scholte a
écrit :
> The pom next to the artifact will be correct and ready to be consumed.
> Only the /META-INF/maven/{G}/{A}/pom.xml will now be the local pom. If you
> make use of some new features this pom might be incomplete, but AFAIK there
> are only a few cases where this embedded pom is used.
>
> Robert
> On 12-11-2020 22:38:33, Romain Manni-Bucau wrote:
> Le jeu. 12 nov. 2020 à 22:14, Robert Scholte a
> écrit :
>
> > The discussion is first of all saying the next release should be
> > 4.0.0-alpha-1 (or something similar), so 3.6.3 was the last of the Maven
> 3
> > releases unless we need to backport security fixes.
> > What to add to that release is the next discussion.
> > Signing is only relevant for releases, but I think most companies don't
> > sign jars for their internal projects.
> > For those developers the missing features don't matter, but they can
> > benefit from a huge amount of improvements.
> >
>
> I disagree, a release is not only about signing but also letting others
> consume artifacts you produce.
> Having a proof it works for us is important before considering it can be a
> released feature (on by default).
> Also agree we shouldnt put a lot of features per release so maybe just the
> pom one in alpha-1? This ensures people can test what we propose and not
> only something else more shining.
>
>
> > Robert
> > On 12-11-2020 21:55:51, Romain Manni-Bucau wrote:
> > Hmm, if it does not work e2e then even an alpha is pointless cause nobody
> > can test it further than a hello world, was my point.
> >
> > Le jeu. 12 nov. 2020 à 21:01, Robert Scholte a
> > écrit :
> >
> > > I don't expect that signing will work with the the first alpha, but
> that
> > > shouldn't stop us of collecting feedback.
> > > Also we need to have a look at all plugins that do something with the
> > pom,
> > > like every packaging plugin, maven-source-plugin, maven-release-plugin
> to
> > > ensure the "right" pom is added.
> > >
> > > And for Maven 4.0.0 we shouldn't have milestone releases of plugins
> (even
> > > though they are stable).
> > > There's still enough work to reach 4.0.0, but most likely the first
> > alphas
> > > are already good enough for the majority.
> > >
> > > On 12-11-2020 20:45:09, Romain Manni-Bucau wrote:
> > > Did we already do mvn or mvn plugins (multimodules) release with the
> > > consumer/producer pom feature?
> > > If so +1 to do a v4 with this new feature "for us" and v5 with real
> user
> > > features and align it with the xsd.
> > >
> > > Le jeu. 12 nov. 2020 à 20:00, Robert Scholte a
> > > écrit :
> > >
> > > > Hi,
> > > >
> > > > It is already several years ago where we started discussing about
> Maven
> > > > Next Generations.
> > > > Clearly we needed to work on the pom, because over time we're facing
> > more
> > > > and more limitations.
> > > > For (Maven) Central the Model 4.0.0 will be required pom format,
> > there's
> > > > no discussion about that. So we needed a new architecture where
> > there's a
> > > > local pom that is transformed to Model 4.0.0 or where it can be
> > > generated.
> > > > With the implementation of MNG-6656 and the improvement with MNG-6957
> > > > we've made the first and important steps based on pom transformation.
> > If
> > > > this concept proofs itself, we can start thinking about enhancing the
> > pom
> > > > model.
> > > >
> > > > When talking about Model 5.0.0 it looked like it would be great to
> > > > introduce it for Maven 5. There was even a period where we thought
> > about
> > > > skipping Maven 4, just to sync the Model version with the Maven
> > version.
> > > > However, we discovered that this would be a huge change, and that we
> > > would
> > > > probably need a couple of Maven 4 releases before moving to Maven 5.
> > > Maven
> > > > 4 would consist of preparation releases.
> > > > I've started writing the build/consumer to proof that the it is
> indeed
> > > > possible to separate the local pom from the distributed pom, even
> > though
> > > > they both are currently still Model 4.0.0 compatible.
> > > > The original idea was:
> > > > Maven 3: build/consumer feature disabled by default
> > > > Maven 4: build/consumer feature enabled by default
> > > >
> > > > Maven 5: Model 5
> > > >
> > > > We were worried that this wouldn't give us enough feedback.
> > > > maven-integration-testing shows that build/consumer does work. There
> > > should
> > > > be enough trust to enable it by default, it shouldn't impact existing
> > > > projects (the last find by Michael was actually great. It
> demonstrated
> > > the
> > > > effect when using threads. The fix made sense and Maven was stable
> > > again).
> > > > But it is simply not enough. We need much more feedback.
> > > >
> > > > Meanwhile other improvements have been done, that has impact:
> > > > - new behavior of reactor commandline arguments
> > > > - upgrade of default versions of plugins per packaging type
> > > > - requiring Java 8
> > > > - Maven wrapper
> > > > - there's a PR waiting that will shift the logic of the
> > > > ProjectBuilder/ModelBuilder. As this is quite important for more
> people
> > > to
> > > > understand, I'll record a Q&A with Maarten+Martin soon and share it
> > with
> > > > you.
> > > > There are probably more, but all these already defend my opinion
> about
> > > the
> > > > next Maven version.
> > > >
> > > > To me it is not a Maven 3 anymore, we're reached a point where we
> > should
> > > > start calling it Maven 4.
> > > > The next release should probably have an alpha suffix, just to give
> > users
> > > > the chance to do alpha testing.
> > > >
> > > > WDYT?
> > > > Robert
> > > >
> > > >
> > >
> >
>
Re: [DISCUSS] Next release should a pre Maven 4.0.0
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hmm, this is used by several testing tools and static analyzis tools so the
new pom should likely be at least next to this one but not replace it, like
META-INF/maven/{G}/{A}/pom.original.xml.
Flattening dependencies will likely speed up some tools parsing poms but
tools also parse parent gav and module list (for the part I know) to find
some structure so breaking that part is likely wrong, even for a consumed
pom, this is meta we should keep IMHO.
For instance, when Apache Beam moved from Maven to Gradle, they lost that
and broke some tooling companies had, it requires some effort to compensate
it so I think we shouldn't be that bad, in particular since it does not
cost much to keep it working.
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 jeu. 12 nov. 2020 à 22:43, Robert Scholte <rf...@apache.org> a
écrit :
> The pom next to the artifact will be correct and ready to be consumed.
> Only the /META-INF/maven/{G}/{A}/pom.xml will now be the local pom. If you
> make use of some new features this pom might be incomplete, but AFAIK there
> are only a few cases where this embedded pom is used.
>
> Robert
> On 12-11-2020 22:38:33, Romain Manni-Bucau <rm...@gmail.com> wrote:
> Le jeu. 12 nov. 2020 à 22:14, Robert Scholte a
> écrit :
>
> > The discussion is first of all saying the next release should be
> > 4.0.0-alpha-1 (or something similar), so 3.6.3 was the last of the Maven
> 3
> > releases unless we need to backport security fixes.
> > What to add to that release is the next discussion.
> > Signing is only relevant for releases, but I think most companies don't
> > sign jars for their internal projects.
> > For those developers the missing features don't matter, but they can
> > benefit from a huge amount of improvements.
> >
>
> I disagree, a release is not only about signing but also letting others
> consume artifacts you produce.
> Having a proof it works for us is important before considering it can be a
> released feature (on by default).
> Also agree we shouldnt put a lot of features per release so maybe just the
> pom one in alpha-1? This ensures people can test what we propose and not
> only something else more shining.
>
>
> > Robert
> > On 12-11-2020 21:55:51, Romain Manni-Bucau wrote:
> > Hmm, if it does not work e2e then even an alpha is pointless cause nobody
> > can test it further than a hello world, was my point.
> >
> > Le jeu. 12 nov. 2020 à 21:01, Robert Scholte a
> > écrit :
> >
> > > I don't expect that signing will work with the the first alpha, but
> that
> > > shouldn't stop us of collecting feedback.
> > > Also we need to have a look at all plugins that do something with the
> > pom,
> > > like every packaging plugin, maven-source-plugin, maven-release-plugin
> to
> > > ensure the "right" pom is added.
> > >
> > > And for Maven 4.0.0 we shouldn't have milestone releases of plugins
> (even
> > > though they are stable).
> > > There's still enough work to reach 4.0.0, but most likely the first
> > alphas
> > > are already good enough for the majority.
> > >
> > > On 12-11-2020 20:45:09, Romain Manni-Bucau wrote:
> > > Did we already do mvn or mvn plugins (multimodules) release with the
> > > consumer/producer pom feature?
> > > If so +1 to do a v4 with this new feature "for us" and v5 with real
> user
> > > features and align it with the xsd.
> > >
> > > Le jeu. 12 nov. 2020 à 20:00, Robert Scholte a
> > > écrit :
> > >
> > > > Hi,
> > > >
> > > > It is already several years ago where we started discussing about
> Maven
> > > > Next Generations.
> > > > Clearly we needed to work on the pom, because over time we're facing
> > more
> > > > and more limitations.
> > > > For (Maven) Central the Model 4.0.0 will be required pom format,
> > there's
> > > > no discussion about that. So we needed a new architecture where
> > there's a
> > > > local pom that is transformed to Model 4.0.0 or where it can be
> > > generated.
> > > > With the implementation of MNG-6656 and the improvement with MNG-6957
> > > > we've made the first and important steps based on pom transformation.
> > If
> > > > this concept proofs itself, we can start thinking about enhancing the
> > pom
> > > > model.
> > > >
> > > > When talking about Model 5.0.0 it looked like it would be great to
> > > > introduce it for Maven 5. There was even a period where we thought
> > about
> > > > skipping Maven 4, just to sync the Model version with the Maven
> > version.
> > > > However, we discovered that this would be a huge change, and that we
> > > would
> > > > probably need a couple of Maven 4 releases before moving to Maven 5.
> > > Maven
> > > > 4 would consist of preparation releases.
> > > > I've started writing the build/consumer to proof that the it is
> indeed
> > > > possible to separate the local pom from the distributed pom, even
> > though
> > > > they both are currently still Model 4.0.0 compatible.
> > > > The original idea was:
> > > > Maven 3: build/consumer feature disabled by default
> > > > Maven 4: build/consumer feature enabled by default
> > > >
> > > > Maven 5: Model 5
> > > >
> > > > We were worried that this wouldn't give us enough feedback.
> > > > maven-integration-testing shows that build/consumer does work. There
> > > should
> > > > be enough trust to enable it by default, it shouldn't impact existing
> > > > projects (the last find by Michael was actually great. It
> demonstrated
> > > the
> > > > effect when using threads. The fix made sense and Maven was stable
> > > again).
> > > > But it is simply not enough. We need much more feedback.
> > > >
> > > > Meanwhile other improvements have been done, that has impact:
> > > > - new behavior of reactor commandline arguments
> > > > - upgrade of default versions of plugins per packaging type
> > > > - requiring Java 8
> > > > - Maven wrapper
> > > > - there's a PR waiting that will shift the logic of the
> > > > ProjectBuilder/ModelBuilder. As this is quite important for more
> people
> > > to
> > > > understand, I'll record a Q&A with Maarten+Martin soon and share it
> > with
> > > > you.
> > > > There are probably more, but all these already defend my opinion
> about
> > > the
> > > > next Maven version.
> > > >
> > > > To me it is not a Maven 3 anymore, we're reached a point where we
> > should
> > > > start calling it Maven 4.
> > > > The next release should probably have an alpha suffix, just to give
> > users
> > > > the chance to do alpha testing.
> > > >
> > > > WDYT?
> > > > Robert
> > > >
> > > >
> > >
> >
>
Re: [DISCUSS] Next release should a pre Maven 4.0.0
Posted by Robert Scholte <rf...@apache.org>.
The pom next to the artifact will be correct and ready to be consumed.
Only the /META-INF/maven/{G}/{A}/pom.xml will now be the local pom. If you make use of some new features this pom might be incomplete, but AFAIK there are only a few cases where this embedded pom is used.
Robert
On 12-11-2020 22:38:33, Romain Manni-Bucau <rm...@gmail.com> wrote:
Le jeu. 12 nov. 2020 à 22:14, Robert Scholte a
écrit :
> The discussion is first of all saying the next release should be
> 4.0.0-alpha-1 (or something similar), so 3.6.3 was the last of the Maven 3
> releases unless we need to backport security fixes.
> What to add to that release is the next discussion.
> Signing is only relevant for releases, but I think most companies don't
> sign jars for their internal projects.
> For those developers the missing features don't matter, but they can
> benefit from a huge amount of improvements.
>
I disagree, a release is not only about signing but also letting others
consume artifacts you produce.
Having a proof it works for us is important before considering it can be a
released feature (on by default).
Also agree we shouldnt put a lot of features per release so maybe just the
pom one in alpha-1? This ensures people can test what we propose and not
only something else more shining.
> Robert
> On 12-11-2020 21:55:51, Romain Manni-Bucau wrote:
> Hmm, if it does not work e2e then even an alpha is pointless cause nobody
> can test it further than a hello world, was my point.
>
> Le jeu. 12 nov. 2020 à 21:01, Robert Scholte a
> écrit :
>
> > I don't expect that signing will work with the the first alpha, but that
> > shouldn't stop us of collecting feedback.
> > Also we need to have a look at all plugins that do something with the
> pom,
> > like every packaging plugin, maven-source-plugin, maven-release-plugin to
> > ensure the "right" pom is added.
> >
> > And for Maven 4.0.0 we shouldn't have milestone releases of plugins (even
> > though they are stable).
> > There's still enough work to reach 4.0.0, but most likely the first
> alphas
> > are already good enough for the majority.
> >
> > On 12-11-2020 20:45:09, Romain Manni-Bucau wrote:
> > Did we already do mvn or mvn plugins (multimodules) release with the
> > consumer/producer pom feature?
> > If so +1 to do a v4 with this new feature "for us" and v5 with real user
> > features and align it with the xsd.
> >
> > Le jeu. 12 nov. 2020 à 20:00, Robert Scholte a
> > écrit :
> >
> > > Hi,
> > >
> > > It is already several years ago where we started discussing about Maven
> > > Next Generations.
> > > Clearly we needed to work on the pom, because over time we're facing
> more
> > > and more limitations.
> > > For (Maven) Central the Model 4.0.0 will be required pom format,
> there's
> > > no discussion about that. So we needed a new architecture where
> there's a
> > > local pom that is transformed to Model 4.0.0 or where it can be
> > generated.
> > > With the implementation of MNG-6656 and the improvement with MNG-6957
> > > we've made the first and important steps based on pom transformation.
> If
> > > this concept proofs itself, we can start thinking about enhancing the
> pom
> > > model.
> > >
> > > When talking about Model 5.0.0 it looked like it would be great to
> > > introduce it for Maven 5. There was even a period where we thought
> about
> > > skipping Maven 4, just to sync the Model version with the Maven
> version.
> > > However, we discovered that this would be a huge change, and that we
> > would
> > > probably need a couple of Maven 4 releases before moving to Maven 5.
> > Maven
> > > 4 would consist of preparation releases.
> > > I've started writing the build/consumer to proof that the it is indeed
> > > possible to separate the local pom from the distributed pom, even
> though
> > > they both are currently still Model 4.0.0 compatible.
> > > The original idea was:
> > > Maven 3: build/consumer feature disabled by default
> > > Maven 4: build/consumer feature enabled by default
> > >
> > > Maven 5: Model 5
> > >
> > > We were worried that this wouldn't give us enough feedback.
> > > maven-integration-testing shows that build/consumer does work. There
> > should
> > > be enough trust to enable it by default, it shouldn't impact existing
> > > projects (the last find by Michael was actually great. It demonstrated
> > the
> > > effect when using threads. The fix made sense and Maven was stable
> > again).
> > > But it is simply not enough. We need much more feedback.
> > >
> > > Meanwhile other improvements have been done, that has impact:
> > > - new behavior of reactor commandline arguments
> > > - upgrade of default versions of plugins per packaging type
> > > - requiring Java 8
> > > - Maven wrapper
> > > - there's a PR waiting that will shift the logic of the
> > > ProjectBuilder/ModelBuilder. As this is quite important for more people
> > to
> > > understand, I'll record a Q&A with Maarten+Martin soon and share it
> with
> > > you.
> > > There are probably more, but all these already defend my opinion about
> > the
> > > next Maven version.
> > >
> > > To me it is not a Maven 3 anymore, we're reached a point where we
> should
> > > start calling it Maven 4.
> > > The next release should probably have an alpha suffix, just to give
> users
> > > the chance to do alpha testing.
> > >
> > > WDYT?
> > > Robert
> > >
> > >
> >
>
Re: [DISCUSS] Next release should a pre Maven 4.0.0
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le jeu. 12 nov. 2020 à 22:14, Robert Scholte <rf...@apache.org> a
écrit :
> The discussion is first of all saying the next release should be
> 4.0.0-alpha-1 (or something similar), so 3.6.3 was the last of the Maven 3
> releases unless we need to backport security fixes.
> What to add to that release is the next discussion.
> Signing is only relevant for releases, but I think most companies don't
> sign jars for their internal projects.
> For those developers the missing features don't matter, but they can
> benefit from a huge amount of improvements.
>
I disagree, a release is not only about signing but also letting others
consume artifacts you produce.
Having a proof it works for us is important before considering it can be a
released feature (on by default).
Also agree we shouldnt put a lot of features per release so maybe just the
pom one in alpha-1? This ensures people can test what we propose and not
only something else more shining.
> Robert
> On 12-11-2020 21:55:51, Romain Manni-Bucau <rm...@gmail.com> wrote:
> Hmm, if it does not work e2e then even an alpha is pointless cause nobody
> can test it further than a hello world, was my point.
>
> Le jeu. 12 nov. 2020 à 21:01, Robert Scholte a
> écrit :
>
> > I don't expect that signing will work with the the first alpha, but that
> > shouldn't stop us of collecting feedback.
> > Also we need to have a look at all plugins that do something with the
> pom,
> > like every packaging plugin, maven-source-plugin, maven-release-plugin to
> > ensure the "right" pom is added.
> >
> > And for Maven 4.0.0 we shouldn't have milestone releases of plugins (even
> > though they are stable).
> > There's still enough work to reach 4.0.0, but most likely the first
> alphas
> > are already good enough for the majority.
> >
> > On 12-11-2020 20:45:09, Romain Manni-Bucau wrote:
> > Did we already do mvn or mvn plugins (multimodules) release with the
> > consumer/producer pom feature?
> > If so +1 to do a v4 with this new feature "for us" and v5 with real user
> > features and align it with the xsd.
> >
> > Le jeu. 12 nov. 2020 à 20:00, Robert Scholte a
> > écrit :
> >
> > > Hi,
> > >
> > > It is already several years ago where we started discussing about Maven
> > > Next Generations.
> > > Clearly we needed to work on the pom, because over time we're facing
> more
> > > and more limitations.
> > > For (Maven) Central the Model 4.0.0 will be required pom format,
> there's
> > > no discussion about that. So we needed a new architecture where
> there's a
> > > local pom that is transformed to Model 4.0.0 or where it can be
> > generated.
> > > With the implementation of MNG-6656 and the improvement with MNG-6957
> > > we've made the first and important steps based on pom transformation.
> If
> > > this concept proofs itself, we can start thinking about enhancing the
> pom
> > > model.
> > >
> > > When talking about Model 5.0.0 it looked like it would be great to
> > > introduce it for Maven 5. There was even a period where we thought
> about
> > > skipping Maven 4, just to sync the Model version with the Maven
> version.
> > > However, we discovered that this would be a huge change, and that we
> > would
> > > probably need a couple of Maven 4 releases before moving to Maven 5.
> > Maven
> > > 4 would consist of preparation releases.
> > > I've started writing the build/consumer to proof that the it is indeed
> > > possible to separate the local pom from the distributed pom, even
> though
> > > they both are currently still Model 4.0.0 compatible.
> > > The original idea was:
> > > Maven 3: build/consumer feature disabled by default
> > > Maven 4: build/consumer feature enabled by default
> > >
> > > Maven 5: Model 5
> > >
> > > We were worried that this wouldn't give us enough feedback.
> > > maven-integration-testing shows that build/consumer does work. There
> > should
> > > be enough trust to enable it by default, it shouldn't impact existing
> > > projects (the last find by Michael was actually great. It demonstrated
> > the
> > > effect when using threads. The fix made sense and Maven was stable
> > again).
> > > But it is simply not enough. We need much more feedback.
> > >
> > > Meanwhile other improvements have been done, that has impact:
> > > - new behavior of reactor commandline arguments
> > > - upgrade of default versions of plugins per packaging type
> > > - requiring Java 8
> > > - Maven wrapper
> > > - there's a PR waiting that will shift the logic of the
> > > ProjectBuilder/ModelBuilder. As this is quite important for more people
> > to
> > > understand, I'll record a Q&A with Maarten+Martin soon and share it
> with
> > > you.
> > > There are probably more, but all these already defend my opinion about
> > the
> > > next Maven version.
> > >
> > > To me it is not a Maven 3 anymore, we're reached a point where we
> should
> > > start calling it Maven 4.
> > > The next release should probably have an alpha suffix, just to give
> users
> > > the chance to do alpha testing.
> > >
> > > WDYT?
> > > Robert
> > >
> > >
> >
>
Re: [DISCUSS] Next release should a pre Maven 4.0.0
Posted by Robert Scholte <rf...@apache.org>.
The discussion is first of all saying the next release should be 4.0.0-alpha-1 (or something similar), so 3.6.3 was the last of the Maven 3 releases unless we need to backport security fixes.
What to add to that release is the next discussion.
Signing is only relevant for releases, but I think most companies don't sign jars for their internal projects.
For those developers the missing features don't matter, but they can benefit from a huge amount of improvements.
Robert
On 12-11-2020 21:55:51, Romain Manni-Bucau <rm...@gmail.com> wrote:
Hmm, if it does not work e2e then even an alpha is pointless cause nobody
can test it further than a hello world, was my point.
Le jeu. 12 nov. 2020 à 21:01, Robert Scholte a
écrit :
> I don't expect that signing will work with the the first alpha, but that
> shouldn't stop us of collecting feedback.
> Also we need to have a look at all plugins that do something with the pom,
> like every packaging plugin, maven-source-plugin, maven-release-plugin to
> ensure the "right" pom is added.
>
> And for Maven 4.0.0 we shouldn't have milestone releases of plugins (even
> though they are stable).
> There's still enough work to reach 4.0.0, but most likely the first alphas
> are already good enough for the majority.
>
> On 12-11-2020 20:45:09, Romain Manni-Bucau wrote:
> Did we already do mvn or mvn plugins (multimodules) release with the
> consumer/producer pom feature?
> If so +1 to do a v4 with this new feature "for us" and v5 with real user
> features and align it with the xsd.
>
> Le jeu. 12 nov. 2020 à 20:00, Robert Scholte a
> écrit :
>
> > Hi,
> >
> > It is already several years ago where we started discussing about Maven
> > Next Generations.
> > Clearly we needed to work on the pom, because over time we're facing more
> > and more limitations.
> > For (Maven) Central the Model 4.0.0 will be required pom format, there's
> > no discussion about that. So we needed a new architecture where there's a
> > local pom that is transformed to Model 4.0.0 or where it can be
> generated.
> > With the implementation of MNG-6656 and the improvement with MNG-6957
> > we've made the first and important steps based on pom transformation. If
> > this concept proofs itself, we can start thinking about enhancing the pom
> > model.
> >
> > When talking about Model 5.0.0 it looked like it would be great to
> > introduce it for Maven 5. There was even a period where we thought about
> > skipping Maven 4, just to sync the Model version with the Maven version.
> > However, we discovered that this would be a huge change, and that we
> would
> > probably need a couple of Maven 4 releases before moving to Maven 5.
> Maven
> > 4 would consist of preparation releases.
> > I've started writing the build/consumer to proof that the it is indeed
> > possible to separate the local pom from the distributed pom, even though
> > they both are currently still Model 4.0.0 compatible.
> > The original idea was:
> > Maven 3: build/consumer feature disabled by default
> > Maven 4: build/consumer feature enabled by default
> >
> > Maven 5: Model 5
> >
> > We were worried that this wouldn't give us enough feedback.
> > maven-integration-testing shows that build/consumer does work. There
> should
> > be enough trust to enable it by default, it shouldn't impact existing
> > projects (the last find by Michael was actually great. It demonstrated
> the
> > effect when using threads. The fix made sense and Maven was stable
> again).
> > But it is simply not enough. We need much more feedback.
> >
> > Meanwhile other improvements have been done, that has impact:
> > - new behavior of reactor commandline arguments
> > - upgrade of default versions of plugins per packaging type
> > - requiring Java 8
> > - Maven wrapper
> > - there's a PR waiting that will shift the logic of the
> > ProjectBuilder/ModelBuilder. As this is quite important for more people
> to
> > understand, I'll record a Q&A with Maarten+Martin soon and share it with
> > you.
> > There are probably more, but all these already defend my opinion about
> the
> > next Maven version.
> >
> > To me it is not a Maven 3 anymore, we're reached a point where we should
> > start calling it Maven 4.
> > The next release should probably have an alpha suffix, just to give users
> > the chance to do alpha testing.
> >
> > WDYT?
> > Robert
> >
> >
>
Re: [DISCUSS] Next release should a pre Maven 4.0.0
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hmm, if it does not work e2e then even an alpha is pointless cause nobody
can test it further than a hello world, was my point.
Le jeu. 12 nov. 2020 à 21:01, Robert Scholte <rf...@apache.org> a
écrit :
> I don't expect that signing will work with the the first alpha, but that
> shouldn't stop us of collecting feedback.
> Also we need to have a look at all plugins that do something with the pom,
> like every packaging plugin, maven-source-plugin, maven-release-plugin to
> ensure the "right" pom is added.
>
> And for Maven 4.0.0 we shouldn't have milestone releases of plugins (even
> though they are stable).
> There's still enough work to reach 4.0.0, but most likely the first alphas
> are already good enough for the majority.
>
> On 12-11-2020 20:45:09, Romain Manni-Bucau <rm...@gmail.com> wrote:
> Did we already do mvn or mvn plugins (multimodules) release with the
> consumer/producer pom feature?
> If so +1 to do a v4 with this new feature "for us" and v5 with real user
> features and align it with the xsd.
>
> Le jeu. 12 nov. 2020 à 20:00, Robert Scholte a
> écrit :
>
> > Hi,
> >
> > It is already several years ago where we started discussing about Maven
> > Next Generations.
> > Clearly we needed to work on the pom, because over time we're facing more
> > and more limitations.
> > For (Maven) Central the Model 4.0.0 will be required pom format, there's
> > no discussion about that. So we needed a new architecture where there's a
> > local pom that is transformed to Model 4.0.0 or where it can be
> generated.
> > With the implementation of MNG-6656 and the improvement with MNG-6957
> > we've made the first and important steps based on pom transformation. If
> > this concept proofs itself, we can start thinking about enhancing the pom
> > model.
> >
> > When talking about Model 5.0.0 it looked like it would be great to
> > introduce it for Maven 5. There was even a period where we thought about
> > skipping Maven 4, just to sync the Model version with the Maven version.
> > However, we discovered that this would be a huge change, and that we
> would
> > probably need a couple of Maven 4 releases before moving to Maven 5.
> Maven
> > 4 would consist of preparation releases.
> > I've started writing the build/consumer to proof that the it is indeed
> > possible to separate the local pom from the distributed pom, even though
> > they both are currently still Model 4.0.0 compatible.
> > The original idea was:
> > Maven 3: build/consumer feature disabled by default
> > Maven 4: build/consumer feature enabled by default
> >
> > Maven 5: Model 5
> >
> > We were worried that this wouldn't give us enough feedback.
> > maven-integration-testing shows that build/consumer does work. There
> should
> > be enough trust to enable it by default, it shouldn't impact existing
> > projects (the last find by Michael was actually great. It demonstrated
> the
> > effect when using threads. The fix made sense and Maven was stable
> again).
> > But it is simply not enough. We need much more feedback.
> >
> > Meanwhile other improvements have been done, that has impact:
> > - new behavior of reactor commandline arguments
> > - upgrade of default versions of plugins per packaging type
> > - requiring Java 8
> > - Maven wrapper
> > - there's a PR waiting that will shift the logic of the
> > ProjectBuilder/ModelBuilder. As this is quite important for more people
> to
> > understand, I'll record a Q&A with Maarten+Martin soon and share it with
> > you.
> > There are probably more, but all these already defend my opinion about
> the
> > next Maven version.
> >
> > To me it is not a Maven 3 anymore, we're reached a point where we should
> > start calling it Maven 4.
> > The next release should probably have an alpha suffix, just to give users
> > the chance to do alpha testing.
> >
> > WDYT?
> > Robert
> >
> >
>
Re: [DISCUSS] Next release should a pre Maven 4.0.0
Posted by Robert Scholte <rf...@apache.org>.
The Dependency Resolution Strategy must exist somewhere Maven Artifact Resolver, my guess is the org.eclipse.aether.collection package.
On 12-11-2020 21:41:57, Andres Almiray <aa...@gmail.com> wrote:
Hi Robert,
Understood. I remember our discussion at JAlba last year about the
resolution strategy options at hand.
Do you think it would be possible to expose the resolution strategy hooks
in a way that may be overridden by an extension/plugin?
That way alternate RS can be prototyped and tested during 4's lifespan
before changing the core RS in 5.
Cheers,
Andres
-------------------------------------------
Java Champion; Groovy Enthusiast
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.
On Thu, Nov 12, 2020 at 9:33 PM Robert Scholte wrote:
> Hi Andres,
>
> BanDuplicatePomDependencyVersions is easy to add. IIRC now it is a
> warning, I don't mind changing it to make it break the build.
>
> DependencyConvergence is way too difficult to achieve with the larger
> projects.
>
> RequireUpperBoundDeps sounds reasonable as warning, although I'm sure if
> the ModelValidator has enough context.
> Instead I would prefer to change the resolution strategy from Nearest to
> DirectOverHighest (or something similar), but that's definitely 5.0.0.
>
>
> thanks,
> Robert
> On 12-11-2020 21:08:35, Andres Almiray wrote:
> Woohoo!
>
> While I'd love for Maven moving forward to 4 I was hoping to see the
> enforcer plugin (or at least some of its rules) baked into core, for
> example
>
> BanDuplicatePomDependencyVersions
> DependencyConvergence
> RequireUpperBoundDeps
>
> I'm sure that enabling these rules by default will break thousands of
> builds upon upgrade, but at the very least having the behavior available
> with a simple turn of a switch/flag is better than having to configure the
> enforcer plugin by hand.
> I'm also aware that there are those among this group that are not fond of
> enforcer, so yeah.
>
> So, if this behavior can't be added to 4, at least put it in the bucket for
> 5 ;-)
>
> Cheers,
> Andres
>
> -------------------------------------------
> Java Champion; Groovy Enthusiast
> http://andresalmiray.com
> http://www.linkedin.com/in/aalmiray
> --
> What goes up, must come down. Ask any system administrator.
> There are 10 types of people in the world: Those who understand binary, and
> those who don't.
> To understand recursion, we must first understand recursion.
>
>
> On Thu, Nov 12, 2020 at 9:00 PM Robert Scholte wrote:
>
> > I don't expect that signing will work with the the first alpha, but that
> > shouldn't stop us of collecting feedback.
> > Also we need to have a look at all plugins that do something with the
> pom,
> > like every packaging plugin, maven-source-plugin, maven-release-plugin to
> > ensure the "right" pom is added.
> >
> > And for Maven 4.0.0 we shouldn't have milestone releases of plugins (even
> > though they are stable).
> > There's still enough work to reach 4.0.0, but most likely the first
> alphas
> > are already good enough for the majority.
> >
> > On 12-11-2020 20:45:09, Romain Manni-Bucau wrote:
> > Did we already do mvn or mvn plugins (multimodules) release with the
> > consumer/producer pom feature?
> > If so +1 to do a v4 with this new feature "for us" and v5 with real user
> > features and align it with the xsd.
> >
> > Le jeu. 12 nov. 2020 à 20:00, Robert Scholte a
> > écrit :
> >
> > > Hi,
> > >
> > > It is already several years ago where we started discussing about Maven
> > > Next Generations.
> > > Clearly we needed to work on the pom, because over time we're facing
> more
> > > and more limitations.
> > > For (Maven) Central the Model 4.0.0 will be required pom format,
> there's
> > > no discussion about that. So we needed a new architecture where
> there's a
> > > local pom that is transformed to Model 4.0.0 or where it can be
> > generated.
> > > With the implementation of MNG-6656 and the improvement with MNG-6957
> > > we've made the first and important steps based on pom transformation.
> If
> > > this concept proofs itself, we can start thinking about enhancing the
> pom
> > > model.
> > >
> > > When talking about Model 5.0.0 it looked like it would be great to
> > > introduce it for Maven 5. There was even a period where we thought
> about
> > > skipping Maven 4, just to sync the Model version with the Maven
> version.
> > > However, we discovered that this would be a huge change, and that we
> > would
> > > probably need a couple of Maven 4 releases before moving to Maven 5.
> > Maven
> > > 4 would consist of preparation releases.
> > > I've started writing the build/consumer to proof that the it is indeed
> > > possible to separate the local pom from the distributed pom, even
> though
> > > they both are currently still Model 4.0.0 compatible.
> > > The original idea was:
> > > Maven 3: build/consumer feature disabled by default
> > > Maven 4: build/consumer feature enabled by default
> > >
> > > Maven 5: Model 5
> > >
> > > We were worried that this wouldn't give us enough feedback.
> > > maven-integration-testing shows that build/consumer does work. There
> > should
> > > be enough trust to enable it by default, it shouldn't impact existing
> > > projects (the last find by Michael was actually great. It demonstrated
> > the
> > > effect when using threads. The fix made sense and Maven was stable
> > again).
> > > But it is simply not enough. We need much more feedback.
> > >
> > > Meanwhile other improvements have been done, that has impact:
> > > - new behavior of reactor commandline arguments
> > > - upgrade of default versions of plugins per packaging type
> > > - requiring Java 8
> > > - Maven wrapper
> > > - there's a PR waiting that will shift the logic of the
> > > ProjectBuilder/ModelBuilder. As this is quite important for more people
> > to
> > > understand, I'll record a Q&A with Maarten+Martin soon and share it
> with
> > > you.
> > > There are probably more, but all these already defend my opinion about
> > the
> > > next Maven version.
> > >
> > > To me it is not a Maven 3 anymore, we're reached a point where we
> should
> > > start calling it Maven 4.
> > > The next release should probably have an alpha suffix, just to give
> users
> > > the chance to do alpha testing.
> > >
> > > WDYT?
> > > Robert
> > >
> > >
> >
>
Re: [DISCUSS] Next release should a pre Maven 4.0.0
Posted by Andres Almiray <aa...@gmail.com>.
Hi Robert,
Understood. I remember our discussion at JAlba last year about the
resolution strategy options at hand.
Do you think it would be possible to expose the resolution strategy hooks
in a way that may be overridden by an extension/plugin?
That way alternate RS can be prototyped and tested during 4's lifespan
before changing the core RS in 5.
Cheers,
Andres
-------------------------------------------
Java Champion; Groovy Enthusiast
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.
On Thu, Nov 12, 2020 at 9:33 PM Robert Scholte <rf...@apache.org> wrote:
> Hi Andres,
>
> BanDuplicatePomDependencyVersions is easy to add. IIRC now it is a
> warning, I don't mind changing it to make it break the build.
>
> DependencyConvergence is way too difficult to achieve with the larger
> projects.
>
> RequireUpperBoundDeps sounds reasonable as warning, although I'm sure if
> the ModelValidator has enough context.
> Instead I would prefer to change the resolution strategy from Nearest to
> DirectOverHighest (or something similar), but that's definitely 5.0.0.
>
>
> thanks,
> Robert
> On 12-11-2020 21:08:35, Andres Almiray <aa...@gmail.com> wrote:
> Woohoo!
>
> While I'd love for Maven moving forward to 4 I was hoping to see the
> enforcer plugin (or at least some of its rules) baked into core, for
> example
>
> BanDuplicatePomDependencyVersions
> DependencyConvergence
> RequireUpperBoundDeps
>
> I'm sure that enabling these rules by default will break thousands of
> builds upon upgrade, but at the very least having the behavior available
> with a simple turn of a switch/flag is better than having to configure the
> enforcer plugin by hand.
> I'm also aware that there are those among this group that are not fond of
> enforcer, so yeah.
>
> So, if this behavior can't be added to 4, at least put it in the bucket for
> 5 ;-)
>
> Cheers,
> Andres
>
> -------------------------------------------
> Java Champion; Groovy Enthusiast
> http://andresalmiray.com
> http://www.linkedin.com/in/aalmiray
> --
> What goes up, must come down. Ask any system administrator.
> There are 10 types of people in the world: Those who understand binary, and
> those who don't.
> To understand recursion, we must first understand recursion.
>
>
> On Thu, Nov 12, 2020 at 9:00 PM Robert Scholte wrote:
>
> > I don't expect that signing will work with the the first alpha, but that
> > shouldn't stop us of collecting feedback.
> > Also we need to have a look at all plugins that do something with the
> pom,
> > like every packaging plugin, maven-source-plugin, maven-release-plugin to
> > ensure the "right" pom is added.
> >
> > And for Maven 4.0.0 we shouldn't have milestone releases of plugins (even
> > though they are stable).
> > There's still enough work to reach 4.0.0, but most likely the first
> alphas
> > are already good enough for the majority.
> >
> > On 12-11-2020 20:45:09, Romain Manni-Bucau wrote:
> > Did we already do mvn or mvn plugins (multimodules) release with the
> > consumer/producer pom feature?
> > If so +1 to do a v4 with this new feature "for us" and v5 with real user
> > features and align it with the xsd.
> >
> > Le jeu. 12 nov. 2020 à 20:00, Robert Scholte a
> > écrit :
> >
> > > Hi,
> > >
> > > It is already several years ago where we started discussing about Maven
> > > Next Generations.
> > > Clearly we needed to work on the pom, because over time we're facing
> more
> > > and more limitations.
> > > For (Maven) Central the Model 4.0.0 will be required pom format,
> there's
> > > no discussion about that. So we needed a new architecture where
> there's a
> > > local pom that is transformed to Model 4.0.0 or where it can be
> > generated.
> > > With the implementation of MNG-6656 and the improvement with MNG-6957
> > > we've made the first and important steps based on pom transformation.
> If
> > > this concept proofs itself, we can start thinking about enhancing the
> pom
> > > model.
> > >
> > > When talking about Model 5.0.0 it looked like it would be great to
> > > introduce it for Maven 5. There was even a period where we thought
> about
> > > skipping Maven 4, just to sync the Model version with the Maven
> version.
> > > However, we discovered that this would be a huge change, and that we
> > would
> > > probably need a couple of Maven 4 releases before moving to Maven 5.
> > Maven
> > > 4 would consist of preparation releases.
> > > I've started writing the build/consumer to proof that the it is indeed
> > > possible to separate the local pom from the distributed pom, even
> though
> > > they both are currently still Model 4.0.0 compatible.
> > > The original idea was:
> > > Maven 3: build/consumer feature disabled by default
> > > Maven 4: build/consumer feature enabled by default
> > >
> > > Maven 5: Model 5
> > >
> > > We were worried that this wouldn't give us enough feedback.
> > > maven-integration-testing shows that build/consumer does work. There
> > should
> > > be enough trust to enable it by default, it shouldn't impact existing
> > > projects (the last find by Michael was actually great. It demonstrated
> > the
> > > effect when using threads. The fix made sense and Maven was stable
> > again).
> > > But it is simply not enough. We need much more feedback.
> > >
> > > Meanwhile other improvements have been done, that has impact:
> > > - new behavior of reactor commandline arguments
> > > - upgrade of default versions of plugins per packaging type
> > > - requiring Java 8
> > > - Maven wrapper
> > > - there's a PR waiting that will shift the logic of the
> > > ProjectBuilder/ModelBuilder. As this is quite important for more people
> > to
> > > understand, I'll record a Q&A with Maarten+Martin soon and share it
> with
> > > you.
> > > There are probably more, but all these already defend my opinion about
> > the
> > > next Maven version.
> > >
> > > To me it is not a Maven 3 anymore, we're reached a point where we
> should
> > > start calling it Maven 4.
> > > The next release should probably have an alpha suffix, just to give
> users
> > > the chance to do alpha testing.
> > >
> > > WDYT?
> > > Robert
> > >
> > >
> >
>
Re: [DISCUSS] Next release should a pre Maven 4.0.0
Posted by Robert Scholte <rf...@apache.org>.
Hi Andres,
BanDuplicatePomDependencyVersions is easy to add. IIRC now it is a warning, I don't mind changing it to make it break the build.
DependencyConvergence is way too difficult to achieve with the larger projects.
RequireUpperBoundDeps sounds reasonable as warning, although I'm sure if the ModelValidator has enough context.
Instead I would prefer to change the resolution strategy from Nearest to DirectOverHighest (or something similar), but that's definitely 5.0.0.
thanks,
Robert
On 12-11-2020 21:08:35, Andres Almiray <aa...@gmail.com> wrote:
Woohoo!
While I'd love for Maven moving forward to 4 I was hoping to see the
enforcer plugin (or at least some of its rules) baked into core, for
example
BanDuplicatePomDependencyVersions
DependencyConvergence
RequireUpperBoundDeps
I'm sure that enabling these rules by default will break thousands of
builds upon upgrade, but at the very least having the behavior available
with a simple turn of a switch/flag is better than having to configure the
enforcer plugin by hand.
I'm also aware that there are those among this group that are not fond of
enforcer, so yeah.
So, if this behavior can't be added to 4, at least put it in the bucket for
5 ;-)
Cheers,
Andres
-------------------------------------------
Java Champion; Groovy Enthusiast
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.
On Thu, Nov 12, 2020 at 9:00 PM Robert Scholte wrote:
> I don't expect that signing will work with the the first alpha, but that
> shouldn't stop us of collecting feedback.
> Also we need to have a look at all plugins that do something with the pom,
> like every packaging plugin, maven-source-plugin, maven-release-plugin to
> ensure the "right" pom is added.
>
> And for Maven 4.0.0 we shouldn't have milestone releases of plugins (even
> though they are stable).
> There's still enough work to reach 4.0.0, but most likely the first alphas
> are already good enough for the majority.
>
> On 12-11-2020 20:45:09, Romain Manni-Bucau wrote:
> Did we already do mvn or mvn plugins (multimodules) release with the
> consumer/producer pom feature?
> If so +1 to do a v4 with this new feature "for us" and v5 with real user
> features and align it with the xsd.
>
> Le jeu. 12 nov. 2020 à 20:00, Robert Scholte a
> écrit :
>
> > Hi,
> >
> > It is already several years ago where we started discussing about Maven
> > Next Generations.
> > Clearly we needed to work on the pom, because over time we're facing more
> > and more limitations.
> > For (Maven) Central the Model 4.0.0 will be required pom format, there's
> > no discussion about that. So we needed a new architecture where there's a
> > local pom that is transformed to Model 4.0.0 or where it can be
> generated.
> > With the implementation of MNG-6656 and the improvement with MNG-6957
> > we've made the first and important steps based on pom transformation. If
> > this concept proofs itself, we can start thinking about enhancing the pom
> > model.
> >
> > When talking about Model 5.0.0 it looked like it would be great to
> > introduce it for Maven 5. There was even a period where we thought about
> > skipping Maven 4, just to sync the Model version with the Maven version.
> > However, we discovered that this would be a huge change, and that we
> would
> > probably need a couple of Maven 4 releases before moving to Maven 5.
> Maven
> > 4 would consist of preparation releases.
> > I've started writing the build/consumer to proof that the it is indeed
> > possible to separate the local pom from the distributed pom, even though
> > they both are currently still Model 4.0.0 compatible.
> > The original idea was:
> > Maven 3: build/consumer feature disabled by default
> > Maven 4: build/consumer feature enabled by default
> >
> > Maven 5: Model 5
> >
> > We were worried that this wouldn't give us enough feedback.
> > maven-integration-testing shows that build/consumer does work. There
> should
> > be enough trust to enable it by default, it shouldn't impact existing
> > projects (the last find by Michael was actually great. It demonstrated
> the
> > effect when using threads. The fix made sense and Maven was stable
> again).
> > But it is simply not enough. We need much more feedback.
> >
> > Meanwhile other improvements have been done, that has impact:
> > - new behavior of reactor commandline arguments
> > - upgrade of default versions of plugins per packaging type
> > - requiring Java 8
> > - Maven wrapper
> > - there's a PR waiting that will shift the logic of the
> > ProjectBuilder/ModelBuilder. As this is quite important for more people
> to
> > understand, I'll record a Q&A with Maarten+Martin soon and share it with
> > you.
> > There are probably more, but all these already defend my opinion about
> the
> > next Maven version.
> >
> > To me it is not a Maven 3 anymore, we're reached a point where we should
> > start calling it Maven 4.
> > The next release should probably have an alpha suffix, just to give users
> > the chance to do alpha testing.
> >
> > WDYT?
> > Robert
> >
> >
>
Re: [DISCUSS] Next release should a pre Maven 4.0.0
Posted by Andres Almiray <aa...@gmail.com>.
Woohoo!
While I'd love for Maven moving forward to 4 I was hoping to see the
enforcer plugin (or at least some of its rules) baked into core, for
example
BanDuplicatePomDependencyVersions
DependencyConvergence
RequireUpperBoundDeps
I'm sure that enabling these rules by default will break thousands of
builds upon upgrade, but at the very least having the behavior available
with a simple turn of a switch/flag is better than having to configure the
enforcer plugin by hand.
I'm also aware that there are those among this group that are not fond of
enforcer, so yeah.
So, if this behavior can't be added to 4, at least put it in the bucket for
5 ;-)
Cheers,
Andres
-------------------------------------------
Java Champion; Groovy Enthusiast
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.
On Thu, Nov 12, 2020 at 9:00 PM Robert Scholte <rf...@apache.org> wrote:
> I don't expect that signing will work with the the first alpha, but that
> shouldn't stop us of collecting feedback.
> Also we need to have a look at all plugins that do something with the pom,
> like every packaging plugin, maven-source-plugin, maven-release-plugin to
> ensure the "right" pom is added.
>
> And for Maven 4.0.0 we shouldn't have milestone releases of plugins (even
> though they are stable).
> There's still enough work to reach 4.0.0, but most likely the first alphas
> are already good enough for the majority.
>
> On 12-11-2020 20:45:09, Romain Manni-Bucau <rm...@gmail.com> wrote:
> Did we already do mvn or mvn plugins (multimodules) release with the
> consumer/producer pom feature?
> If so +1 to do a v4 with this new feature "for us" and v5 with real user
> features and align it with the xsd.
>
> Le jeu. 12 nov. 2020 à 20:00, Robert Scholte a
> écrit :
>
> > Hi,
> >
> > It is already several years ago where we started discussing about Maven
> > Next Generations.
> > Clearly we needed to work on the pom, because over time we're facing more
> > and more limitations.
> > For (Maven) Central the Model 4.0.0 will be required pom format, there's
> > no discussion about that. So we needed a new architecture where there's a
> > local pom that is transformed to Model 4.0.0 or where it can be
> generated.
> > With the implementation of MNG-6656 and the improvement with MNG-6957
> > we've made the first and important steps based on pom transformation. If
> > this concept proofs itself, we can start thinking about enhancing the pom
> > model.
> >
> > When talking about Model 5.0.0 it looked like it would be great to
> > introduce it for Maven 5. There was even a period where we thought about
> > skipping Maven 4, just to sync the Model version with the Maven version.
> > However, we discovered that this would be a huge change, and that we
> would
> > probably need a couple of Maven 4 releases before moving to Maven 5.
> Maven
> > 4 would consist of preparation releases.
> > I've started writing the build/consumer to proof that the it is indeed
> > possible to separate the local pom from the distributed pom, even though
> > they both are currently still Model 4.0.0 compatible.
> > The original idea was:
> > Maven 3: build/consumer feature disabled by default
> > Maven 4: build/consumer feature enabled by default
> >
> > Maven 5: Model 5
> >
> > We were worried that this wouldn't give us enough feedback.
> > maven-integration-testing shows that build/consumer does work. There
> should
> > be enough trust to enable it by default, it shouldn't impact existing
> > projects (the last find by Michael was actually great. It demonstrated
> the
> > effect when using threads. The fix made sense and Maven was stable
> again).
> > But it is simply not enough. We need much more feedback.
> >
> > Meanwhile other improvements have been done, that has impact:
> > - new behavior of reactor commandline arguments
> > - upgrade of default versions of plugins per packaging type
> > - requiring Java 8
> > - Maven wrapper
> > - there's a PR waiting that will shift the logic of the
> > ProjectBuilder/ModelBuilder. As this is quite important for more people
> to
> > understand, I'll record a Q&A with Maarten+Martin soon and share it with
> > you.
> > There are probably more, but all these already defend my opinion about
> the
> > next Maven version.
> >
> > To me it is not a Maven 3 anymore, we're reached a point where we should
> > start calling it Maven 4.
> > The next release should probably have an alpha suffix, just to give users
> > the chance to do alpha testing.
> >
> > WDYT?
> > Robert
> >
> >
>
Re: [DISCUSS] Next release should a pre Maven 4.0.0
Posted by Robert Scholte <rf...@apache.org>.
I don't expect that signing will work with the the first alpha, but that shouldn't stop us of collecting feedback.
Also we need to have a look at all plugins that do something with the pom, like every packaging plugin, maven-source-plugin, maven-release-plugin to ensure the "right" pom is added.
And for Maven 4.0.0 we shouldn't have milestone releases of plugins (even though they are stable).
There's still enough work to reach 4.0.0, but most likely the first alphas are already good enough for the majority.
On 12-11-2020 20:45:09, Romain Manni-Bucau <rm...@gmail.com> wrote:
Did we already do mvn or mvn plugins (multimodules) release with the
consumer/producer pom feature?
If so +1 to do a v4 with this new feature "for us" and v5 with real user
features and align it with the xsd.
Le jeu. 12 nov. 2020 à 20:00, Robert Scholte a
écrit :
> Hi,
>
> It is already several years ago where we started discussing about Maven
> Next Generations.
> Clearly we needed to work on the pom, because over time we're facing more
> and more limitations.
> For (Maven) Central the Model 4.0.0 will be required pom format, there's
> no discussion about that. So we needed a new architecture where there's a
> local pom that is transformed to Model 4.0.0 or where it can be generated.
> With the implementation of MNG-6656 and the improvement with MNG-6957
> we've made the first and important steps based on pom transformation. If
> this concept proofs itself, we can start thinking about enhancing the pom
> model.
>
> When talking about Model 5.0.0 it looked like it would be great to
> introduce it for Maven 5. There was even a period where we thought about
> skipping Maven 4, just to sync the Model version with the Maven version.
> However, we discovered that this would be a huge change, and that we would
> probably need a couple of Maven 4 releases before moving to Maven 5. Maven
> 4 would consist of preparation releases.
> I've started writing the build/consumer to proof that the it is indeed
> possible to separate the local pom from the distributed pom, even though
> they both are currently still Model 4.0.0 compatible.
> The original idea was:
> Maven 3: build/consumer feature disabled by default
> Maven 4: build/consumer feature enabled by default
>
> Maven 5: Model 5
>
> We were worried that this wouldn't give us enough feedback.
> maven-integration-testing shows that build/consumer does work. There should
> be enough trust to enable it by default, it shouldn't impact existing
> projects (the last find by Michael was actually great. It demonstrated the
> effect when using threads. The fix made sense and Maven was stable again).
> But it is simply not enough. We need much more feedback.
>
> Meanwhile other improvements have been done, that has impact:
> - new behavior of reactor commandline arguments
> - upgrade of default versions of plugins per packaging type
> - requiring Java 8
> - Maven wrapper
> - there's a PR waiting that will shift the logic of the
> ProjectBuilder/ModelBuilder. As this is quite important for more people to
> understand, I'll record a Q&A with Maarten+Martin soon and share it with
> you.
> There are probably more, but all these already defend my opinion about the
> next Maven version.
>
> To me it is not a Maven 3 anymore, we're reached a point where we should
> start calling it Maven 4.
> The next release should probably have an alpha suffix, just to give users
> the chance to do alpha testing.
>
> WDYT?
> Robert
>
>
Re: [DISCUSS] Next release should a pre Maven 4.0.0
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Did we already do mvn or mvn plugins (multimodules) release with the
consumer/producer pom feature?
If so +1 to do a v4 with this new feature "for us" and v5 with real user
features and align it with the xsd.
Le jeu. 12 nov. 2020 à 20:00, Robert Scholte <rf...@apache.org> a
écrit :
> Hi,
>
> It is already several years ago where we started discussing about Maven
> Next Generations.
> Clearly we needed to work on the pom, because over time we're facing more
> and more limitations.
> For (Maven) Central the Model 4.0.0 will be required pom format, there's
> no discussion about that. So we needed a new architecture where there's a
> local pom that is transformed to Model 4.0.0 or where it can be generated.
> With the implementation of MNG-6656 and the improvement with MNG-6957
> we've made the first and important steps based on pom transformation. If
> this concept proofs itself, we can start thinking about enhancing the pom
> model.
>
> When talking about Model 5.0.0 it looked like it would be great to
> introduce it for Maven 5. There was even a period where we thought about
> skipping Maven 4, just to sync the Model version with the Maven version.
> However, we discovered that this would be a huge change, and that we would
> probably need a couple of Maven 4 releases before moving to Maven 5. Maven
> 4 would consist of preparation releases.
> I've started writing the build/consumer to proof that the it is indeed
> possible to separate the local pom from the distributed pom, even though
> they both are currently still Model 4.0.0 compatible.
> The original idea was:
> Maven 3: build/consumer feature disabled by default
> Maven 4: build/consumer feature enabled by default
>
> Maven 5: Model 5
>
> We were worried that this wouldn't give us enough feedback.
> maven-integration-testing shows that build/consumer does work. There should
> be enough trust to enable it by default, it shouldn't impact existing
> projects (the last find by Michael was actually great. It demonstrated the
> effect when using threads. The fix made sense and Maven was stable again).
> But it is simply not enough. We need much more feedback.
>
> Meanwhile other improvements have been done, that has impact:
> - new behavior of reactor commandline arguments
> - upgrade of default versions of plugins per packaging type
> - requiring Java 8
> - Maven wrapper
> - there's a PR waiting that will shift the logic of the
> ProjectBuilder/ModelBuilder. As this is quite important for more people to
> understand, I'll record a Q&A with Maarten+Martin soon and share it with
> you.
> There are probably more, but all these already defend my opinion about the
> next Maven version.
>
> To me it is not a Maven 3 anymore, we're reached a point where we should
> start calling it Maven 4.
> The next release should probably have an alpha suffix, just to give users
> the chance to do alpha testing.
>
> WDYT?
> Robert
>
>