You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Robert Scholte <rf...@apache.org> on 2020/06/22 21:18:15 UTC
Maven moving to the next level: the build/consumer pom
Hi,
One of my long standing wishes has made it to the master branch of Maven: the support for build/consumer pom.
With this we can finally start improving the pom without breaking the Maven eco system.
Up until now the pom.xml has been distributed (installed/deployed) as is to both local and remote repositories.
The good thing is that is it fast and there is no magic.
However, it sometimes implies adding redundant information and it also blocks any chance of improvement for Maven
The challenge is to make it possible to have an locally an improved "build" pom while distributing a model 4.0.0 compatible "consumer" pom.
The whole architecture of Maven was built upon an immutable pom.xml, so it took a while to split this, but I managed to solve this.
And to confirm that it works, some transformations have been added for the next Maven release
The local pom it still model 4.0.0 compatible, but some redundant elements are not required anymore.
- in case the <parent/> is located at its relativePath (default: ../pom.xml), the version can be removed. groupId and artifactId are still required to ensure it is being matched with the right parent.
- dependencies that are part of the reactor don't need a version anymore
These are implemented steps to get from the file model to the raw model, where the required versions are added.
When distributing the pom, the previous transformations are done, but also:
- cifriendly placeholders in versions (${sha1}, ${revision}, ${changelist}) will be resolved.
- <modules> from <project> will be removed
- <relativePath> from <parent> will be removed
These cleanups are context aware, if they appear in some configuration, they won't be touched.
One of our integration-tests[1] demonstrates how new poms in a multimodule project might look like.
Even though the latter steps look quite small (removing elements with relative paths), it should give us enough feedback about the whole process.
The status is that it is ready to be embedded in supporting tools like IDEs.
We should give them time to work on this and share feedback.
It might require some adjustments in Maven to improve user experience.
In the meantime we need to work on plugins that will have impact by these changes.
Most significant is are signing maven plugins such as the maven-gpg-plugin, which needs to work with the distributed pom instead of the local pom.
Also all packaging plugin that can include the pom.xml and pom.properties in their archive should switch to the distributed pom.
The maven-shade-plugin was marked as well, but at first glance this looks fine.
In the end all our plugins must be verified, just to be sure.
So there's enough to work on.
In general I avoid giving timelines about how fast a new release will be available.
Due to the overhead, the small amount of available time of the few volunteers working on Maven, I prefer to have a worth set of changes.
In this case the impact of the changes can be huge, and I want to have enough faith that we won't introduce irreversible mistakes.
Don't expect a new official release in the 3 next months, however we might have alpha or beta releases.
There is a wiki page that explains this topic in more detail[2]
It is still a draft, as there are still parts where we need to reach consensus.
This page is intended as a base for discussions by Maven developers, users and related projects, such as IDEs, Repository Managers, CI Servers, etc.
Looking forward for any feedback,
Robert Scholte
Apache Maven project
[1] https://github.com/apache/maven-integration-testing/tree/master/core-it-suite/src/test/resources/mng-6656-buildconsumer
[2] https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
Re: Maven moving to the next level: the build/consumer pom
Posted by Robert Scholte <rf...@apache.org>.
Just confirmed that I won't need these specific implementations, getting the XMLReader via XMLReaderFactory is good enough.
Will commit this as part of MNG-6946.
Robert
On 24-6-2020 16:23:16, Elliotte Rusty Harold <el...@ibiblio.org> wrote:
The XML handling code in this work is running into some common design
flaws in the JDK XML classes, in particular in the Factories class.
First, you probably shouldn't use SAXParserFactory or SAXParser at
all. They were added to the JDK to support SAX 1.0, and haven't been
needed for since SAX 2 was released (about 20 years ago). Modern code
should use XMLReader and XMLReaderFactory instead.
If you do stick with SAXParser, it's important to call
setNamespaceAware(true), since it's false by default, a legacy of its
use with the non-namespace supporting SAX 1.
On Mon, Jun 22, 2020 at 5:18 PM Robert Scholte wrote:
>
> Hi,
>
> One of my long standing wishes has made it to the master branch of Maven: the support for build/consumer pom.
> With this we can finally start improving the pom without breaking the Maven eco system.
>
> Up until now the pom.xml has been distributed (installed/deployed) as is to both local and remote repositories.
> The good thing is that is it fast and there is no magic.
> However, it sometimes implies adding redundant information and it also blocks any chance of improvement for Maven
>
> The challenge is to make it possible to have an locally an improved "build" pom while distributing a model 4.0.0 compatible "consumer" pom.
>
> The whole architecture of Maven was built upon an immutable pom.xml, so it took a while to split this, but I managed to solve this.
> And to confirm that it works, some transformations have been added for the next Maven release
> The local pom it still model 4.0.0 compatible, but some redundant elements are not required anymore.
> - in case the is located at its relativePath (default: ../pom.xml), the version can be removed. groupId and artifactId are still required to ensure it is being matched with the right parent.
>
> - dependencies that are part of the reactor don't need a version anymore
> These are implemented steps to get from the file model to the raw model, where the required versions are added.
>
> When distributing the pom, the previous transformations are done, but also:
> - cifriendly placeholders in versions (${sha1}, ${revision}, ${changelist}) will be resolved.
> - from will be removed
> - from will be removed
> These cleanups are context aware, if they appear in some configuration, they won't be touched.
> One of our integration-tests[1] demonstrates how new poms in a multimodule project might look like.
>
> Even though the latter steps look quite small (removing elements with relative paths), it should give us enough feedback about the whole process.
>
> The status is that it is ready to be embedded in supporting tools like IDEs.
> We should give them time to work on this and share feedback.
> It might require some adjustments in Maven to improve user experience.
>
> In the meantime we need to work on plugins that will have impact by these changes.
> Most significant is are signing maven plugins such as the maven-gpg-plugin, which needs to work with the distributed pom instead of the local pom.
> Also all packaging plugin that can include the pom.xml and pom.properties in their archive should switch to the distributed pom.
> The maven-shade-plugin was marked as well, but at first glance this looks fine.
> In the end all our plugins must be verified, just to be sure.
> So there's enough to work on.
>
> In general I avoid giving timelines about how fast a new release will be available.
> Due to the overhead, the small amount of available time of the few volunteers working on Maven, I prefer to have a worth set of changes.
> In this case the impact of the changes can be huge, and I want to have enough faith that we won't introduce irreversible mistakes.
> Don't expect a new official release in the 3 next months, however we might have alpha or beta releases.
>
> There is a wiki page that explains this topic in more detail[2]
> It is still a draft, as there are still parts where we need to reach consensus.
> This page is intended as a base for discussions by Maven developers, users and related projects, such as IDEs, Repository Managers, CI Servers, etc.
>
> Looking forward for any feedback,
>
> Robert Scholte
> Apache Maven project
>
> [1] https://github.com/apache/maven-integration-testing/tree/master/core-it-suite/src/test/resources/mng-6656-buildconsumer
> [2] https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven moving to the next level: the build/consumer pom
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
The XML handling code in this work is running into some common design
flaws in the JDK XML classes, in particular in the Factories class.
First, you probably shouldn't use SAXParserFactory or SAXParser at
all. They were added to the JDK to support SAX 1.0, and haven't been
needed for since SAX 2 was released (about 20 years ago). Modern code
should use XMLReader and XMLReaderFactory instead.
If you do stick with SAXParser, it's important to call
setNamespaceAware(true), since it's false by default, a legacy of its
use with the non-namespace supporting SAX 1.
On Mon, Jun 22, 2020 at 5:18 PM Robert Scholte <rf...@apache.org> wrote:
>
> Hi,
>
> One of my long standing wishes has made it to the master branch of Maven: the support for build/consumer pom.
> With this we can finally start improving the pom without breaking the Maven eco system.
>
> Up until now the pom.xml has been distributed (installed/deployed) as is to both local and remote repositories.
> The good thing is that is it fast and there is no magic.
> However, it sometimes implies adding redundant information and it also blocks any chance of improvement for Maven
>
> The challenge is to make it possible to have an locally an improved "build" pom while distributing a model 4.0.0 compatible "consumer" pom.
>
> The whole architecture of Maven was built upon an immutable pom.xml, so it took a while to split this, but I managed to solve this.
> And to confirm that it works, some transformations have been added for the next Maven release
> The local pom it still model 4.0.0 compatible, but some redundant elements are not required anymore.
> - in case the <parent/> is located at its relativePath (default: ../pom.xml), the version can be removed. groupId and artifactId are still required to ensure it is being matched with the right parent.
>
> - dependencies that are part of the reactor don't need a version anymore
> These are implemented steps to get from the file model to the raw model, where the required versions are added.
>
> When distributing the pom, the previous transformations are done, but also:
> - cifriendly placeholders in versions (${sha1}, ${revision}, ${changelist}) will be resolved.
> - <modules> from <project> will be removed
> - <relativePath> from <parent> will be removed
> These cleanups are context aware, if they appear in some configuration, they won't be touched.
> One of our integration-tests[1] demonstrates how new poms in a multimodule project might look like.
>
> Even though the latter steps look quite small (removing elements with relative paths), it should give us enough feedback about the whole process.
>
> The status is that it is ready to be embedded in supporting tools like IDEs.
> We should give them time to work on this and share feedback.
> It might require some adjustments in Maven to improve user experience.
>
> In the meantime we need to work on plugins that will have impact by these changes.
> Most significant is are signing maven plugins such as the maven-gpg-plugin, which needs to work with the distributed pom instead of the local pom.
> Also all packaging plugin that can include the pom.xml and pom.properties in their archive should switch to the distributed pom.
> The maven-shade-plugin was marked as well, but at first glance this looks fine.
> In the end all our plugins must be verified, just to be sure.
> So there's enough to work on.
>
> In general I avoid giving timelines about how fast a new release will be available.
> Due to the overhead, the small amount of available time of the few volunteers working on Maven, I prefer to have a worth set of changes.
> In this case the impact of the changes can be huge, and I want to have enough faith that we won't introduce irreversible mistakes.
> Don't expect a new official release in the 3 next months, however we might have alpha or beta releases.
>
> There is a wiki page that explains this topic in more detail[2]
> It is still a draft, as there are still parts where we need to reach consensus.
> This page is intended as a base for discussions by Maven developers, users and related projects, such as IDEs, Repository Managers, CI Servers, etc.
>
> Looking forward for any feedback,
>
> Robert Scholte
> Apache Maven project
>
> [1] https://github.com/apache/maven-integration-testing/tree/master/core-it-suite/src/test/resources/mng-6656-buildconsumer
> [2] https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven moving to the next level: the build/consumer pom
Posted by Robert Scholte <rf...@apache.org>.
On 23-6-2020 23:20:31, Matthieu BROUILLARD <ma...@brouillard.fr> wrote:
Hi Robert,
congrats this looks like a great achievement.
I presume that the consumer pom means the end of the flatten plugin or is
there still some benefit in using flatten plugin?
Robert Scholte:
The flatten-maven-plugin was introduced when the installAtEnd/deployAtEnd was introduced and users couldn't define their own pom anymore.
In the meantime it has a lot of configurable filters to manipulate the pom, not sure if everything will be possible.
> dependencies that are part of the reactor don't need a version anymore
What is meant here ? Is it that in a multimodule project a dependency from
a module to another of the same multimodule does not need the version ? For
example when having an api and impl in the same multimodule, the impl will
not require the version of the api?
Robert Scholte:
Exactly, you don't need to specify it in the local pom, the distributed pom will be enriched with the correct version.
> These are implemented steps to get from the file model to the raw model,
where the required versions are added.
Are those replacements still part of the pom loading by ModelProcessor?
I'll give it a try especially to see the compliance with my existing core
extensions.
Robert Scholte:
Yes, I've tried to implement it without need of changes for plugins and extensions.
Matthieu Brouillard
On Mon, Jun 22, 2020 at 11:18 PM Robert Scholte
wrote:
> Hi,
>
> One of my long standing wishes has made it to the master branch of Maven:
> the support for build/consumer pom.
> With this we can finally start improving the pom without breaking the
> Maven eco system.
>
> Up until now the pom.xml has been distributed (installed/deployed) as is
> to both local and remote repositories.
> The good thing is that is it fast and there is no magic.
> However, it sometimes implies adding redundant information and it also
> blocks any chance of improvement for Maven
>
> The challenge is to make it possible to have an locally an improved
> "build" pom while distributing a model 4.0.0 compatible "consumer" pom.
>
> The whole architecture of Maven was built upon an immutable pom.xml, so it
> took a while to split this, but I managed to solve this.
> And to confirm that it works, some transformations have been added for the
> next Maven release
> The local pom it still model 4.0.0 compatible, but some redundant elements
> are not required anymore.
> - in case the is located at its relativePath (default:
> ../pom.xml), the version can be removed. groupId and artifactId are still
> required to ensure it is being matched with the right parent.
>
> - dependencies that are part of the reactor don't need a version anymore
> These are implemented steps to get from the file model to the raw model,
> where the required versions are added.
>
> When distributing the pom, the previous transformations are done, but also:
> - cifriendly placeholders in versions (${sha1}, ${revision},
> ${changelist}) will be resolved.
> - from will be removed
> - from will be removed
> These cleanups are context aware, if they appear in some configuration,
> they won't be touched.
> One of our integration-tests[1] demonstrates how new poms in a multimodule
> project might look like.
>
> Even though the latter steps look quite small (removing elements with
> relative paths), it should give us enough feedback about the whole process.
>
> The status is that it is ready to be embedded in supporting tools like
> IDEs.
> We should give them time to work on this and share feedback.
> It might require some adjustments in Maven to improve user experience.
>
> In the meantime we need to work on plugins that will have impact by these
> changes.
> Most significant is are signing maven plugins such as the
> maven-gpg-plugin, which needs to work with the distributed pom instead of
> the local pom.
> Also all packaging plugin that can include the pom.xml and pom.properties
> in their archive should switch to the distributed pom.
> The maven-shade-plugin was marked as well, but at first glance this looks
> fine.
> In the end all our plugins must be verified, just to be sure.
> So there's enough to work on.
>
> In general I avoid giving timelines about how fast a new release will be
> available.
> Due to the overhead, the small amount of available time of the few
> volunteers working on Maven, I prefer to have a worth set of changes.
> In this case the impact of the changes can be huge, and I want to have
> enough faith that we won't introduce irreversible mistakes.
> Don't expect a new official release in the 3 next months, however we might
> have alpha or beta releases.
>
> There is a wiki page that explains this topic in more detail[2]
> It is still a draft, as there are still parts where we need to reach
> consensus.
> This page is intended as a base for discussions by Maven developers, users
> and related projects, such as IDEs, Repository Managers, CI Servers, etc.
>
> Looking forward for any feedback,
>
> Robert Scholte
> Apache Maven project
>
> [1]
> https://github.com/apache/maven-integration-testing/tree/master/core-it-suite/src/test/resources/mng-6656-buildconsumer
> [2]
> https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
Re: Maven moving to the next level: the build/consumer pom
Posted by Robert Scholte <rf...@apache.org>.
On 23-6-2020 23:20:31, Matthieu BROUILLARD <ma...@brouillard.fr> wrote:
Hi Robert,
congrats this looks like a great achievement.
I presume that the consumer pom means the end of the flatten plugin or is
there still some benefit in using flatten plugin?
Robert Scholte:
The flatten-maven-plugin was introduced when the installAtEnd/deployAtEnd was introduced and users couldn't define their own pom anymore.
In the meantime it has a lot of configurable filters to manipulate the pom, not sure if everything will be possible.
> dependencies that are part of the reactor don't need a version anymore
What is meant here ? Is it that in a multimodule project a dependency from
a module to another of the same multimodule does not need the version ? For
example when having an api and impl in the same multimodule, the impl will
not require the version of the api?
Robert Scholte:
Exactly, you don't need to specify it in the local pom, the distributed pom will be enriched with the correct version.
> These are implemented steps to get from the file model to the raw model,
where the required versions are added.
Are those replacements still part of the pom loading by ModelProcessor?
I'll give it a try especially to see the compliance with my existing core
extensions.
Robert Scholte:
Yes, I've tried to implement it without need of changes for plugins and extensions.
Matthieu Brouillard
On Mon, Jun 22, 2020 at 11:18 PM Robert Scholte
wrote:
> Hi,
>
> One of my long standing wishes has made it to the master branch of Maven:
> the support for build/consumer pom.
> With this we can finally start improving the pom without breaking the
> Maven eco system.
>
> Up until now the pom.xml has been distributed (installed/deployed) as is
> to both local and remote repositories.
> The good thing is that is it fast and there is no magic.
> However, it sometimes implies adding redundant information and it also
> blocks any chance of improvement for Maven
>
> The challenge is to make it possible to have an locally an improved
> "build" pom while distributing a model 4.0.0 compatible "consumer" pom.
>
> The whole architecture of Maven was built upon an immutable pom.xml, so it
> took a while to split this, but I managed to solve this.
> And to confirm that it works, some transformations have been added for the
> next Maven release
> The local pom it still model 4.0.0 compatible, but some redundant elements
> are not required anymore.
> - in case the is located at its relativePath (default:
> ../pom.xml), the version can be removed. groupId and artifactId are still
> required to ensure it is being matched with the right parent.
>
> - dependencies that are part of the reactor don't need a version anymore
> These are implemented steps to get from the file model to the raw model,
> where the required versions are added.
>
> When distributing the pom, the previous transformations are done, but also:
> - cifriendly placeholders in versions (${sha1}, ${revision},
> ${changelist}) will be resolved.
> - from will be removed
> - from will be removed
> These cleanups are context aware, if they appear in some configuration,
> they won't be touched.
> One of our integration-tests[1] demonstrates how new poms in a multimodule
> project might look like.
>
> Even though the latter steps look quite small (removing elements with
> relative paths), it should give us enough feedback about the whole process.
>
> The status is that it is ready to be embedded in supporting tools like
> IDEs.
> We should give them time to work on this and share feedback.
> It might require some adjustments in Maven to improve user experience.
>
> In the meantime we need to work on plugins that will have impact by these
> changes.
> Most significant is are signing maven plugins such as the
> maven-gpg-plugin, which needs to work with the distributed pom instead of
> the local pom.
> Also all packaging plugin that can include the pom.xml and pom.properties
> in their archive should switch to the distributed pom.
> The maven-shade-plugin was marked as well, but at first glance this looks
> fine.
> In the end all our plugins must be verified, just to be sure.
> So there's enough to work on.
>
> In general I avoid giving timelines about how fast a new release will be
> available.
> Due to the overhead, the small amount of available time of the few
> volunteers working on Maven, I prefer to have a worth set of changes.
> In this case the impact of the changes can be huge, and I want to have
> enough faith that we won't introduce irreversible mistakes.
> Don't expect a new official release in the 3 next months, however we might
> have alpha or beta releases.
>
> There is a wiki page that explains this topic in more detail[2]
> It is still a draft, as there are still parts where we need to reach
> consensus.
> This page is intended as a base for discussions by Maven developers, users
> and related projects, such as IDEs, Repository Managers, CI Servers, etc.
>
> Looking forward for any feedback,
>
> Robert Scholte
> Apache Maven project
>
> [1]
> https://github.com/apache/maven-integration-testing/tree/master/core-it-suite/src/test/resources/mng-6656-buildconsumer
> [2]
> https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
Re: Maven moving to the next level: the build/consumer pom
Posted by Robert Scholte <rf...@apache.org>.
On 23-6-2020 23:20:31, Matthieu BROUILLARD <ma...@brouillard.fr> wrote:
Hi Robert,
congrats this looks like a great achievement.
I presume that the consumer pom means the end of the flatten plugin or is
there still some benefit in using flatten plugin?
Robert Scholte:
The flatten-maven-plugin was introduced when the installAtEnd/deployAtEnd was introduced and users couldn't define their own pom anymore.
In the meantime it has a lot of configurable filters to manipulate the pom, not sure if everything will be possible.
> dependencies that are part of the reactor don't need a version anymore
What is meant here ? Is it that in a multimodule project a dependency from
a module to another of the same multimodule does not need the version ? For
example when having an api and impl in the same multimodule, the impl will
not require the version of the api?
Robert Scholte:
Exactly, you don't need to specify it in the local pom, the distributed pom will be enriched with the correct version.
> These are implemented steps to get from the file model to the raw model,
where the required versions are added.
Are those replacements still part of the pom loading by ModelProcessor?
I'll give it a try especially to see the compliance with my existing core
extensions.
Robert Scholte:
Yes, I've tried to implement it without need of changes for plugins and extensions.
Matthieu Brouillard
On Mon, Jun 22, 2020 at 11:18 PM Robert Scholte
wrote:
> Hi,
>
> One of my long standing wishes has made it to the master branch of Maven:
> the support for build/consumer pom.
> With this we can finally start improving the pom without breaking the
> Maven eco system.
>
> Up until now the pom.xml has been distributed (installed/deployed) as is
> to both local and remote repositories.
> The good thing is that is it fast and there is no magic.
> However, it sometimes implies adding redundant information and it also
> blocks any chance of improvement for Maven
>
> The challenge is to make it possible to have an locally an improved
> "build" pom while distributing a model 4.0.0 compatible "consumer" pom.
>
> The whole architecture of Maven was built upon an immutable pom.xml, so it
> took a while to split this, but I managed to solve this.
> And to confirm that it works, some transformations have been added for the
> next Maven release
> The local pom it still model 4.0.0 compatible, but some redundant elements
> are not required anymore.
> - in case the is located at its relativePath (default:
> ../pom.xml), the version can be removed. groupId and artifactId are still
> required to ensure it is being matched with the right parent.
>
> - dependencies that are part of the reactor don't need a version anymore
> These are implemented steps to get from the file model to the raw model,
> where the required versions are added.
>
> When distributing the pom, the previous transformations are done, but also:
> - cifriendly placeholders in versions (${sha1}, ${revision},
> ${changelist}) will be resolved.
> - from will be removed
> - from will be removed
> These cleanups are context aware, if they appear in some configuration,
> they won't be touched.
> One of our integration-tests[1] demonstrates how new poms in a multimodule
> project might look like.
>
> Even though the latter steps look quite small (removing elements with
> relative paths), it should give us enough feedback about the whole process.
>
> The status is that it is ready to be embedded in supporting tools like
> IDEs.
> We should give them time to work on this and share feedback.
> It might require some adjustments in Maven to improve user experience.
>
> In the meantime we need to work on plugins that will have impact by these
> changes.
> Most significant is are signing maven plugins such as the
> maven-gpg-plugin, which needs to work with the distributed pom instead of
> the local pom.
> Also all packaging plugin that can include the pom.xml and pom.properties
> in their archive should switch to the distributed pom.
> The maven-shade-plugin was marked as well, but at first glance this looks
> fine.
> In the end all our plugins must be verified, just to be sure.
> So there's enough to work on.
>
> In general I avoid giving timelines about how fast a new release will be
> available.
> Due to the overhead, the small amount of available time of the few
> volunteers working on Maven, I prefer to have a worth set of changes.
> In this case the impact of the changes can be huge, and I want to have
> enough faith that we won't introduce irreversible mistakes.
> Don't expect a new official release in the 3 next months, however we might
> have alpha or beta releases.
>
> There is a wiki page that explains this topic in more detail[2]
> It is still a draft, as there are still parts where we need to reach
> consensus.
> This page is intended as a base for discussions by Maven developers, users
> and related projects, such as IDEs, Repository Managers, CI Servers, etc.
>
> Looking forward for any feedback,
>
> Robert Scholte
> Apache Maven project
>
> [1]
> https://github.com/apache/maven-integration-testing/tree/master/core-it-suite/src/test/resources/mng-6656-buildconsumer
> [2]
> https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
Re: Maven moving to the next level: the build/consumer pom
Posted by Robert Scholte <rf...@apache.org>.
On 24-6-2020 00:48:48, Mark Derricutt <ma...@talios.com> wrote:
Love the work here - I'll definitely be keen on trying this out and see how it interacts with our tiles-maven-plugin.
Regarding this "reactor" bit tho - just because a module is in the reactor, doesn't always mean it has the same parent - the version of the dependency could be elided if the parent version matched AND that dependency is part of the reactor.
Robert Scholte:
The parent isn't used to resolve the version. If a dependency is missing a version, Maven will look up the version by finding the reactor module based on the groupId and artifactId.
However, I have seem people use reactors purely as build-coordinators, and not always used. I'd much rather seeing them stay - esp. if using version ranges ( we force [] ranges for instance ).
Robert Scholte:
Current behavior shouldn't change, there's just an extra option: don't include the version and let Maven embed the right value.
Mark
On 24/06/20, 9:20 AM, "Matthieu BROUILLARD" wrote:
> dependencies that are part of the reactor don't need a version anymore
What is meant here ? Is it that in a multimodule project a dependency from
a module to another of the same multimodule does not need the version ? For
example when having an api and impl in the same multimodule, the impl will
not require the version of the api?
B�KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB�� [��X��ܚX�KK[XZ[� \�\��][��X��ܚX�PX]�[��\X�K�ܙ�B��܈Y][ۘ[��[X[� �K[XZ[� \�\��Z[ X]�[��\X�K�ܙ�B
Re: Maven moving to the next level: the build/consumer pom
Posted by Mark Derricutt <ma...@talios.com>.
Love the work here - I'll definitely be keen on trying this out and see how it interacts with our tiles-maven-plugin.
Regarding this "reactor" bit tho - just because a module is in the reactor, doesn't always mean it has the same parent - the version of the dependency could be elided if the parent version matched AND that dependency is part of the reactor.
However, I have seem people use reactors purely as build-coordinators, and not always used. I'd much rather seeing them stay - esp. if using version ranges ( we force [] ranges for instance ).
Mark
On 24/06/20, 9:20 AM, "Matthieu BROUILLARD" <ma...@brouillard.fr> wrote:
> dependencies that are part of the reactor don't need a version anymore
What is meant here ? Is it that in a multimodule project a dependency from
a module to another of the same multimodule does not need the version ? For
example when having an api and impl in the same multimodule, the impl will
not require the version of the api?
Re: Maven moving to the next level: the build/consumer pom
Posted by Matthieu BROUILLARD <ma...@brouillard.fr>.
Hi Robert,
congrats this looks like a great achievement.
I presume that the consumer pom means the end of the flatten plugin or is
there still some benefit in using flatten plugin?
> dependencies that are part of the reactor don't need a version anymore
What is meant here ? Is it that in a multimodule project a dependency from
a module to another of the same multimodule does not need the version ? For
example when having an api and impl in the same multimodule, the impl will
not require the version of the api?
> These are implemented steps to get from the file model to the raw model,
where the required versions are added.
Are those replacements still part of the pom loading by ModelProcessor?
I'll give it a try especially to see the compliance with my existing core
extensions.
Matthieu Brouillard
On Mon, Jun 22, 2020 at 11:18 PM Robert Scholte <rf...@apache.org>
wrote:
> Hi,
>
> One of my long standing wishes has made it to the master branch of Maven:
> the support for build/consumer pom.
> With this we can finally start improving the pom without breaking the
> Maven eco system.
>
> Up until now the pom.xml has been distributed (installed/deployed) as is
> to both local and remote repositories.
> The good thing is that is it fast and there is no magic.
> However, it sometimes implies adding redundant information and it also
> blocks any chance of improvement for Maven
>
> The challenge is to make it possible to have an locally an improved
> "build" pom while distributing a model 4.0.0 compatible "consumer" pom.
>
> The whole architecture of Maven was built upon an immutable pom.xml, so it
> took a while to split this, but I managed to solve this.
> And to confirm that it works, some transformations have been added for the
> next Maven release
> The local pom it still model 4.0.0 compatible, but some redundant elements
> are not required anymore.
> - in case the <parent/> is located at its relativePath (default:
> ../pom.xml), the version can be removed. groupId and artifactId are still
> required to ensure it is being matched with the right parent.
>
> - dependencies that are part of the reactor don't need a version anymore
> These are implemented steps to get from the file model to the raw model,
> where the required versions are added.
>
> When distributing the pom, the previous transformations are done, but also:
> - cifriendly placeholders in versions (${sha1}, ${revision},
> ${changelist}) will be resolved.
> - <modules> from <project> will be removed
> - <relativePath> from <parent> will be removed
> These cleanups are context aware, if they appear in some configuration,
> they won't be touched.
> One of our integration-tests[1] demonstrates how new poms in a multimodule
> project might look like.
>
> Even though the latter steps look quite small (removing elements with
> relative paths), it should give us enough feedback about the whole process.
>
> The status is that it is ready to be embedded in supporting tools like
> IDEs.
> We should give them time to work on this and share feedback.
> It might require some adjustments in Maven to improve user experience.
>
> In the meantime we need to work on plugins that will have impact by these
> changes.
> Most significant is are signing maven plugins such as the
> maven-gpg-plugin, which needs to work with the distributed pom instead of
> the local pom.
> Also all packaging plugin that can include the pom.xml and pom.properties
> in their archive should switch to the distributed pom.
> The maven-shade-plugin was marked as well, but at first glance this looks
> fine.
> In the end all our plugins must be verified, just to be sure.
> So there's enough to work on.
>
> In general I avoid giving timelines about how fast a new release will be
> available.
> Due to the overhead, the small amount of available time of the few
> volunteers working on Maven, I prefer to have a worth set of changes.
> In this case the impact of the changes can be huge, and I want to have
> enough faith that we won't introduce irreversible mistakes.
> Don't expect a new official release in the 3 next months, however we might
> have alpha or beta releases.
>
> There is a wiki page that explains this topic in more detail[2]
> It is still a draft, as there are still parts where we need to reach
> consensus.
> This page is intended as a base for discussions by Maven developers, users
> and related projects, such as IDEs, Repository Managers, CI Servers, etc.
>
> Looking forward for any feedback,
>
> Robert Scholte
> Apache Maven project
>
> [1]
> https://github.com/apache/maven-integration-testing/tree/master/core-it-suite/src/test/resources/mng-6656-buildconsumer
> [2]
> https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
Re: Maven moving to the next level: the build/consumer pom
Posted by Robert Scholte <rf...@apache.org>.
On 25-6-2020 02:03:42, Anton Vodonosov <av...@yandex.ru> wrote:
Can this work also allow arbitrary property expression in a module ?
Robert Scholte:
Currently only the ci-friendly version placeholders are supported.
Currently, this practice is discouraged because the deployed pom with property
expression is meaningless.
The flatten-maven-plugin can produce correct poms for deployment,
with all properties resolved; despite maven prints the hardcoded warning
"'version' contains an expression but should be a constant".
Robert Scholte:
The statement is still that versions should be constants and not expressions. It is likely that this is one of the next things that will be implemented.
This announcement is especially for tools needing to read the new local pom.xml
There's a small set of features added, so they can investigate if it works.
It would be a huge waste of time if we discover that the current implementation makes it impossible for IDEs to embed Maven.
Links on the topic:
http://mail-archives.apache.org/mod_mbox/maven-users/201201.mbox/%3CCA+nPnMyb_W4Ldrg5zTn5NX3F2kcrPXDefS4gjzz3OE0cUy1rXw@mail.gmail.com%3E
https://issues.apache.org/jira/browse/MNG-4715
https://stackoverflow.com/questions/19123013/maven-version-with-a-property/19123130
Why I'm interested in property expressions for versions is because I want to generate
versions automatically as a hash code of all sources and dependencies.
And also skip building of modules whose has-version has not changed.
That way the large multi-module project can vary significantly improve build speed
and reduce the artifact storage consumption. Similar to what build caches
give for gradle and bazel, only a bit simplified, less granular - caching done
on the level of final artifacts, but not for intermediate outputs
(compiled file, generated resources).
If would be very convenient if maven-flatten-plugin become unnecessary
and maven supported property expressions in version spec out of box.
Robert Scholte:
The flatten-maven-plugin was written because there was a direct need for manipulating poms that could not be solved easily inside Maven itself.
This is one step into the right direction.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven moving to the next level: the build/consumer pom
Posted by Robert Scholte <rf...@apache.org>.
On 25-6-2020 02:03:42, Anton Vodonosov <av...@yandex.ru> wrote:
Can this work also allow arbitrary property expression in a module ?
Robert Scholte:
Currently only the ci-friendly version placeholders are supported.
Currently, this practice is discouraged because the deployed pom with property
expression is meaningless.
The flatten-maven-plugin can produce correct poms for deployment,
with all properties resolved; despite maven prints the hardcoded warning
"'version' contains an expression but should be a constant".
Robert Scholte:
The statement is still that versions should be constants and not expressions. It is likely that this is one of the next things that will be implemented.
This announcement is especially for tools needing to read the new local pom.xml
There's a small set of features added, so they can investigate if it works.
It would be a huge waste of time if we discover that the current implementation makes it impossible for IDEs to embed Maven.
Links on the topic:
http://mail-archives.apache.org/mod_mbox/maven-users/201201.mbox/%3CCA+nPnMyb_W4Ldrg5zTn5NX3F2kcrPXDefS4gjzz3OE0cUy1rXw@mail.gmail.com%3E
https://issues.apache.org/jira/browse/MNG-4715
https://stackoverflow.com/questions/19123013/maven-version-with-a-property/19123130
Why I'm interested in property expressions for versions is because I want to generate
versions automatically as a hash code of all sources and dependencies.
And also skip building of modules whose has-version has not changed.
That way the large multi-module project can vary significantly improve build speed
and reduce the artifact storage consumption. Similar to what build caches
give for gradle and bazel, only a bit simplified, less granular - caching done
on the level of final artifacts, but not for intermediate outputs
(compiled file, generated resources).
If would be very convenient if maven-flatten-plugin become unnecessary
and maven supported property expressions in version spec out of box.
Robert Scholte:
The flatten-maven-plugin was written because there was a direct need for manipulating poms that could not be solved easily inside Maven itself.
This is one step into the right direction.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven moving to the next level: the build/consumer pom
Posted by Robert Scholte <rf...@apache.org>.
On 25-6-2020 02:03:42, Anton Vodonosov <av...@yandex.ru> wrote:
Can this work also allow arbitrary property expression in a module ?
Robert Scholte:
Currently only the ci-friendly version placeholders are supported.
Currently, this practice is discouraged because the deployed pom with property
expression is meaningless.
The flatten-maven-plugin can produce correct poms for deployment,
with all properties resolved; despite maven prints the hardcoded warning
"'version' contains an expression but should be a constant".
Robert Scholte:
The statement is still that versions should be constants and not expressions. It is likely that this is one of the next things that will be implemented.
This announcement is especially for tools needing to read the new local pom.xml
There's a small set of features added, so they can investigate if it works.
It would be a huge waste of time if we discover that the current implementation makes it impossible for IDEs to embed Maven.
Links on the topic:
http://mail-archives.apache.org/mod_mbox/maven-users/201201.mbox/%3CCA+nPnMyb_W4Ldrg5zTn5NX3F2kcrPXDefS4gjzz3OE0cUy1rXw@mail.gmail.com%3E
https://issues.apache.org/jira/browse/MNG-4715
https://stackoverflow.com/questions/19123013/maven-version-with-a-property/19123130
Why I'm interested in property expressions for versions is because I want to generate
versions automatically as a hash code of all sources and dependencies.
And also skip building of modules whose has-version has not changed.
That way the large multi-module project can vary significantly improve build speed
and reduce the artifact storage consumption. Similar to what build caches
give for gradle and bazel, only a bit simplified, less granular - caching done
on the level of final artifacts, but not for intermediate outputs
(compiled file, generated resources).
If would be very convenient if maven-flatten-plugin become unnecessary
and maven supported property expressions in version spec out of box.
Robert Scholte:
The flatten-maven-plugin was written because there was a direct need for manipulating poms that could not be solved easily inside Maven itself.
This is one step into the right direction.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven moving to the next level: the build/consumer pom
Posted by Anton Vodonosov <av...@yandex.ru>.
Can this work also allow arbitrary property expression in a module <version>?
Currently, this practice is discouraged because the deployed pom with property
expression is meaningless.
The flatten-maven-plugin can produce correct poms for deployment,
with all properties resolved; despite maven prints the hardcoded warning
"'version' contains an expression but should be a constant".
Links on the topic:
http://mail-archives.apache.org/mod_mbox/maven-users/201201.mbox/%3CCA+nPnMyb_W4Ldrg5zTn5NX3F2kcrPXDefS4gjzz3OE0cUy1rXw@mail.gmail.com%3E
https://issues.apache.org/jira/browse/MNG-4715
https://stackoverflow.com/questions/19123013/maven-version-with-a-property/19123130
Why I'm interested in property expressions for versions is because I want to generate
versions automatically as a hash code of all sources and dependencies.
And also skip building of modules whose has-version has not changed.
That way the large multi-module project can vary significantly improve build speed
and reduce the artifact storage consumption. Similar to what build caches
give for gradle and bazel, only a bit simplified, less granular - caching done
on the level of final artifacts, but not for intermediate outputs
(compiled file, generated resources).
If would be very convenient if maven-flatten-plugin become unnecessary
and maven supported property expressions in version spec out of box.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Maven moving to the next level: the build/consumer pom
Posted by Stephen Connolly <st...@gmail.com>.
On Mon 6 Jul 2020 at 17:48, Hervé BOUTEMY <he...@free.fr> wrote:
> Le lundi 6 juillet 2020, 11:33:05 CEST Mark Derricutt a écrit :
> > Hervé,
> >
> > If you configure IntelliJ (projecting much Mark?) to use Maven
> > 3.7.0-SNAPSHOT as it’s maven version, does that work?
> keeping internal Maven version was giving an impression of working,
> probably
> due to cache given updates in parent pom version were not reflected
> updating to 3.7.0-SNAPSHOT just made the import fail...
>
> honestly, given the new pom.xml was an invalid pom.xml with previous
> version,
> I doubt any IDE will work with the new pom.xml without some rework
AIUI netbeans might. But eclipse will not and IntelliJ most certainly will
not as it doesn’t even use Maven to parse the model and is consequently
completely unaware of custom packaging types producing classpath relevant
artifact’s.
>
> Regards,
>
> Hervé
>
> >
> > I tend to configure my IJ to use my built SNAPSHOT when testing out Maven
> > releases.
> >
> > Mark
> >
> > On 6 July 2020 at 8:21:57 PM, Hervé BOUTEMY (herve.boutemy@free.fr)
> wrote:
> >
> > What is expected is IDE maintainers to check what they need to do at IDE
> > level to support these new POMs that only build with Maven
> 3.7.0-SNAPSHOT.
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
> --
Sent from my phone
Re: Maven moving to the next level: the build/consumer pom
Posted by Hervé BOUTEMY <he...@free.fr>.
Le lundi 6 juillet 2020, 11:33:05 CEST Mark Derricutt a écrit :
> Hervé,
>
> If you configure IntelliJ (projecting much Mark?) to use Maven
> 3.7.0-SNAPSHOT as it’s maven version, does that work?
keeping internal Maven version was giving an impression of working, probably
due to cache given updates in parent pom version were not reflected
updating to 3.7.0-SNAPSHOT just made the import fail...
honestly, given the new pom.xml was an invalid pom.xml with previous version,
I doubt any IDE will work with the new pom.xml without some rework
Regards,
Hervé
>
> I tend to configure my IJ to use my built SNAPSHOT when testing out Maven
> releases.
>
> Mark
>
> On 6 July 2020 at 8:21:57 PM, Hervé BOUTEMY (herve.boutemy@free.fr) wrote:
>
> What is expected is IDE maintainers to check what they need to do at IDE
> level to support these new POMs that only build with Maven 3.7.0-SNAPSHOT.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven moving to the next level: the build/consumer pom
Posted by Mark Derricutt <ma...@talios.com>.
Hervé,
If you configure IntelliJ (projecting much Mark?) to use Maven
3.7.0-SNAPSHOT as it’s maven version, does that work?
I tend to configure my IJ to use my built SNAPSHOT when testing out Maven
releases.
Mark
On 6 July 2020 at 8:21:57 PM, Hervé BOUTEMY (herve.boutemy@free.fr) wrote:
What is expected is IDE maintainers to check what they need to do at IDE
level to support these new POMs that only build with Maven 3.7.0-SNAPSHOT.
Re: Maven moving to the next level: the build/consumer pom
Posted by Hervé BOUTEMY <he...@free.fr>.
I just created a "buildconsumer" branch in Doxia [1] to have a live example of the new simplified build POM that Maven 3.7.0 will allow [2]
As expected, this branch can't build with Maven 3.6.3, but can with Maven 3.7.0-SNAPSHOT.
And in my favorite IDE, as expected, dependency resolution does not work because of missing info in pom.xml (which is now a build pom, with removed tags, then was not a valid POM until now)
What is expected is IDE maintainers to check what they need to do at IDE level to support these new POMs that only build with Maven 3.7.0-SNAPSHOT.
Regards,
Hervé
[1] https://github.com/apache/maven-doxia/tree/buildconsumer
[2] https://github.com/apache/maven-doxia/commit/15e3de1a97bf48a394cb566783cac851c0728d98
Le samedi 4 juillet 2020, 07:35:37 CEST Jaroslav Tulach a écrit :
> Hello Robert,
> I am not sure how to deal with your announcement and given no reaction on
> the dev@netbeans mailing list, I am probably not alone. Can you formulate
> your issue as a bug report? E.g. have you tried to use your new Maven with
> NetBeans and did you face a problem? Having steps to reproduce would make
> it more real for the NetBeans community to take action.
>
> -jt
>
> po 22. 6. 2020 v 23:18 odesílatel Robert Scholte <rf...@apache.org>
>
> napsal:
> > Hi,
> >
> > One of my long standing wishes has made it to the master branch of Maven:
> > the support for build/consumer pom.
> > With this we can finally start improving the pom without breaking the
> > Maven eco system.
> >
> > Up until now the pom.xml has been distributed (installed/deployed) as is
> > to both local and remote repositories.
> > The good thing is that is it fast and there is no magic.
> > However, it sometimes implies adding redundant information and it also
> > blocks any chance of improvement for Maven
> >
> > The challenge is to make it possible to have an locally an improved
> > "build" pom while distributing a model 4.0.0 compatible "consumer" pom.
> >
> > The whole architecture of Maven was built upon an immutable pom.xml, so it
> > took a while to split this, but I managed to solve this.
> > And to confirm that it works, some transformations have been added for the
> > next Maven release
> > The local pom it still model 4.0.0 compatible, but some redundant elements
> > are not required anymore.
> > - in case the <parent/> is located at its relativePath (default:
> > ../pom.xml), the version can be removed. groupId and artifactId are still
> > required to ensure it is being matched with the right parent.
> >
> > - dependencies that are part of the reactor don't need a version anymore
> > These are implemented steps to get from the file model to the raw model,
> > where the required versions are added.
> >
> > When distributing the pom, the previous transformations are done, but
> > also:
> > - cifriendly placeholders in versions (${sha1}, ${revision},
> > ${changelist}) will be resolved.
> > - <modules> from <project> will be removed
> > - <relativePath> from <parent> will be removed
> > These cleanups are context aware, if they appear in some configuration,
> > they won't be touched.
> > One of our integration-tests[1] demonstrates how new poms in a multimodule
> > project might look like.
> >
> > Even though the latter steps look quite small (removing elements with
> > relative paths), it should give us enough feedback about the whole
> > process.
> >
> > The status is that it is ready to be embedded in supporting tools like
> > IDEs.
> > We should give them time to work on this and share feedback.
> > It might require some adjustments in Maven to improve user experience.
> >
> > In the meantime we need to work on plugins that will have impact by these
> > changes.
> > Most significant is are signing maven plugins such as the
> > maven-gpg-plugin, which needs to work with the distributed pom instead of
> > the local pom.
> > Also all packaging plugin that can include the pom.xml and pom.properties
> > in their archive should switch to the distributed pom.
> > The maven-shade-plugin was marked as well, but at first glance this looks
> > fine.
> > In the end all our plugins must be verified, just to be sure.
> > So there's enough to work on.
> >
> > In general I avoid giving timelines about how fast a new release will be
> > available.
> > Due to the overhead, the small amount of available time of the few
> > volunteers working on Maven, I prefer to have a worth set of changes.
> > In this case the impact of the changes can be huge, and I want to have
> > enough faith that we won't introduce irreversible mistakes.
> > Don't expect a new official release in the 3 next months, however we might
> > have alpha or beta releases.
> >
> > There is a wiki page that explains this topic in more detail[2]
> > It is still a draft, as there are still parts where we need to reach
> > consensus.
> > This page is intended as a base for discussions by Maven developers, users
> > and related projects, such as IDEs, Repository Managers, CI Servers, etc.
> >
> > Looking forward for any feedback,
> >
> > Robert Scholte
> > Apache Maven project
> >
> > [1]
> > https://github.com/apache/maven-integration-testing/tree/master/core-it-su
> > ite/src/test/resources/mng-6656-buildconsumer [2]
> > https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Maven moving to the next level: the build/consumer pom
Posted by Hervé BOUTEMY <he...@free.fr>.
I just created "buildconsumer" branch for Maven Archetype:
https://github.com/apache/maven-archetype/tree/buildconsumer
CLI building with Maven 3.6.3 expectedly breaks:
$ mvn verify -Drevlist=test
[INFO] Scanning for projects...
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[FATAL] 'parent.version' is missing. @ line 26, column 11
[FATAL] 'parent.version' is missing. @ line 26, column 11
[FATAL] 'parent.version' is missing. @ line 26, column 11
[FATAL] 'parent.version' is missing. @ line 25, column 11
@
[ERROR] The build could not read 4 projects -> [Help 1]
[ERROR]
[ERROR] The project org.apache.maven.archetype:archetype-models:[unknown-version] (/home/herve/projets/maven/sources/plugins/tools/archetype/archetype-models/pom.xml) has 1 error
[ERROR] 'parent.version' is missing. @ line 26, column 11
[ERROR]
[ERROR] The project org.apache.maven.archetype:archetype-common:[unknown-version] (/home/herve/projets/maven/sources/plugins/tools/archetype/archetype-common/pom.xml) has 1 error
[ERROR] 'parent.version' is missing. @ line 26, column 11
[ERROR]
[ERROR] The project org.apache.maven.plugins:maven-archetype-plugin:[unknown-version] (/home/herve/projets/maven/sources/plugins/tools/archetype/maven-archetype-plugin/pom.xml) has 1 error
[ERROR] 'parent.version' is missing. @ line 26, column 11
[ERROR]
[ERROR] The project org.apache.maven.archetype:archetype-packaging:[unknown-version] (/home/herve/projets/maven/sources/plugins/tools/archetype/archetype-packaging/pom.xml) has 1 error
[ERROR] 'parent.version' is missing. @ line 25, column 11
With 3.7.0-SNAPSHOT, most issues are gone, but 1 remains:
$ mvn verify -Drevlist=test
[INFO] Scanning for projects...
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[ERROR] 'dependencies.dependency.version' for org.apache.maven.archetype:archetype-packaging:jar is missing. @ org.apache.maven.plugins:maven-archetype-plugin:[unknown-version], /home/herve/projets/maven/sources/plugins/tools/archetype/maven-archetype-plugin/pom.xml, line 81, column 17
@
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]
[ERROR] The project org.apache.maven.plugins:maven-archetype-plugin:3.2.0-SNAPSHOT (/home/herve/projets/maven/sources/plugins/tools/archetype/maven-archetype-plugin/pom.xml) has 1 error
[ERROR] 'dependencies.dependency.version' for org.apache.maven.archetype:archetype-packaging:jar is missing. @ org.apache.maven.plugins:maven-archetype-plugin:[unknown-version], /home/herve/projets/maven/sources/plugins/tools/archetype/maven-archetype-plugin/pom.xml, line 81, column 17
I suppose it is because of the test-scoped dependency that is not covered...
I'll try creating such branch on other Maven multi-module builds to check if they build with CLI
Then it will be about checking in IDE how well it work or not...
Regards,
Hervé
Le dimanche 5 juillet 2020, 11:07:56 CEST Hervé BOUTEMY a écrit :
> idea: why not create a branch in one or multiple Maven multi-module builds
> that will show the new features (no parent version, no version for reactor,
> and I don't know what else)
>
> I suppose creating such branches in maven-archetype, maven-plugin-tools,
> Maven core itself, would not be hard and would bring examples to test both
> on CLI (I expect the build to fail if the experimental feature is not
> enabled), then in IDE
>
> Regards,
>
> Hervé
>
> Le samedi 4 juillet 2020, 10:12:24 CEST Robert Scholte a écrit :
> > On 4-7-2020 08:08:00, Mark Derricutt <ma...@talios.com> wrote:
> > I thought I’d responded - this has been a long time coming, and has been
> > discussed numerous times over the past few years, and I’m quite excited to
> > give it a bash, and see how well it works, and see if/what any
> > implications
> > this has for our tiles-maven-plugin.
> >
> > I still need to find time to dig into this.
> >
> > Robert - is there anything specific one does to “enable” this currently -
> > or is the current merge simply the machinery to take the build pom (even
> > if
> > its a 4.0.0 model) and produce the consumer pom.
> > Robert Scholte:
> > There is a feature toggle, see
> > https://github.com/apache/maven/blob/master/maven-model-builder/src/main/j
> > av a/org/apache/maven/feature/Features.java#L34
> >
> > Here you see the name, which is still part of discussion because it is not
> > that experimental anymore, and its default value.
> >
> >
> > Currently I don’t see any diffs between my pom.xml, and the pom.xml that
> > gets included inside the .jar file, I tried doing a “mvn deploy” to check
> > the version that got deployed, but yields an missing class exception using
> > 2.8.2:
> >
> > Robert Scholte:
> > That is one one the next important steps that needs to be implemented: the
> > archiver should include the consumer pom.xml, not the local pom.
> >
> > [ERROR] Failed to execute goal
> > org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy)
> > on project smx3.reporting: Execution default-deploy of goal
> > org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy failed: A
> > required class was missing while executing
> > org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy:
> > org/eclipse/aether/transform/FileTransformer
> > [ERROR] -----------------------------------------------------
> > [ERROR] realm = plugin>org.apache.maven.plugins:maven-deploy-plugin:2.8.2
> >
> > Robert Scholte:
> > Does this mean that the install:install did work?
> > That would be interesting.
> > I am not aware of that issue. Is there already a JIRA ticket for it,
> > because this must be solved before the next release.
> >
> >
> > (I’m unable to currently use 3.0.0-M1 for the same reason either).
> >
> > Hrm.
> > Mark
> >
> >
> > From: Jaroslav Tulach
> >
> > Reply: Maven Developers List
> > Date: 4 July 2020 at 5:35:37 PM
> > To: dev
> > Cc: dev@maven.apache.org ,
> > users@maven.apache.org ,
> > m2e-dev@eclipse.org ,
> > opencode@microsoft.com
> > Subject: Re: Maven moving to the next level: the build/consumer pom
> >
> > Hello Robert,
> > I am not sure how to deal with your announcement and given no reaction on
> > the dev@netbeans mailing list, I am probably not alone. Can you formulate
>
> ---------------------------------------------------------------------
> 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: Maven moving to the next level: the build/consumer pom
Posted by Robert Scholte <rf...@apache.org>.
That is actually the first reference of my original e-mail: simple-parent with the simple-weather + simple-webapp.
I've added as an integration-test to ensure all these features work as expected.
The expected-folder contains what I expect to be installed to the local repository.
Robert
[1] https://github.com/apache/maven-integration-testing/tree/master/core-it-suite/src/test/resources/mng-6656-buildconsumer [https://github.com/apache/maven-integration-testing/tree/master/core-it-suite/src/test/resources/mng-6656-buildconsumer]
On 5-7-2020 11:08:03, Hervé BOUTEMY <he...@free.fr> wrote:
idea: why not create a branch in one or multiple Maven multi-module builds
that will show the new features (no parent version, no version for reactor,
and I don't know what else)
I suppose creating such branches in maven-archetype, maven-plugin-tools, Maven
core itself, would not be hard and would bring examples to test both on CLI (I
expect the build to fail if the experimental feature is not enabled), then in
IDE
Regards,
Hervé
Le samedi 4 juillet 2020, 10:12:24 CEST Robert Scholte a écrit :
> On 4-7-2020 08:08:00, Mark Derricutt wrote:
> I thought I’d responded - this has been a long time coming, and has been
> discussed numerous times over the past few years, and I’m quite excited to
> give it a bash, and see how well it works, and see if/what any implications
> this has for our tiles-maven-plugin.
>
> I still need to find time to dig into this.
>
> Robert - is there anything specific one does to “enable” this currently -
> or is the current merge simply the machinery to take the build pom (even if
> its a 4.0.0 model) and produce the consumer pom.
> Robert Scholte:
> There is a feature toggle, see
> https://github.com/apache/maven/blob/master/maven-model-builder/src/main/jav
> a/org/apache/maven/feature/Features.java#L34
>
> Here you see the name, which is still part of discussion because it is not
> that experimental anymore, and its default value.
>
>
> Currently I don’t see any diffs between my pom.xml, and the pom.xml that
> gets included inside the .jar file, I tried doing a “mvn deploy” to check
> the version that got deployed, but yields an missing class exception using
> 2.8.2:
>
> Robert Scholte:
> That is one one the next important steps that needs to be implemented: the
> archiver should include the consumer pom.xml, not the local pom.
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy)
> on project smx3.reporting: Execution default-deploy of goal
> org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy failed: A
> required class was missing while executing
> org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy:
> org/eclipse/aether/transform/FileTransformer
> [ERROR] -----------------------------------------------------
> [ERROR] realm = plugin>org.apache.maven.plugins:maven-deploy-plugin:2.8.2
>
> Robert Scholte:
> Does this mean that the install:install did work?
> That would be interesting.
> I am not aware of that issue. Is there already a JIRA ticket for it, because
> this must be solved before the next release.
>
>
> (I’m unable to currently use 3.0.0-M1 for the same reason either).
>
> Hrm.
> Mark
>
>
> From: Jaroslav Tulach
>
> Reply: Maven Developers List
> Date: 4 July 2020 at 5:35:37 PM
> To: dev
> Cc: dev@maven.apache.org ,
> users@maven.apache.org ,
> m2e-dev@eclipse.org ,
> opencode@microsoft.com
> Subject: Re: Maven moving to the next level: the build/consumer pom
>
> Hello Robert,
> I am not sure how to deal with your announcement and given no reaction on
> the dev@netbeans mailing list, I am probably not alone. Can you formulate
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven moving to the next level: the build/consumer pom
Posted by Hervé BOUTEMY <he...@free.fr>.
idea: why not create a branch in one or multiple Maven multi-module builds
that will show the new features (no parent version, no version for reactor,
and I don't know what else)
I suppose creating such branches in maven-archetype, maven-plugin-tools, Maven
core itself, would not be hard and would bring examples to test both on CLI (I
expect the build to fail if the experimental feature is not enabled), then in
IDE
Regards,
Hervé
Le samedi 4 juillet 2020, 10:12:24 CEST Robert Scholte a écrit :
> On 4-7-2020 08:08:00, Mark Derricutt <ma...@talios.com> wrote:
> I thought I’d responded - this has been a long time coming, and has been
> discussed numerous times over the past few years, and I’m quite excited to
> give it a bash, and see how well it works, and see if/what any implications
> this has for our tiles-maven-plugin.
>
> I still need to find time to dig into this.
>
> Robert - is there anything specific one does to “enable” this currently -
> or is the current merge simply the machinery to take the build pom (even if
> its a 4.0.0 model) and produce the consumer pom.
> Robert Scholte:
> There is a feature toggle, see
> https://github.com/apache/maven/blob/master/maven-model-builder/src/main/jav
> a/org/apache/maven/feature/Features.java#L34
>
> Here you see the name, which is still part of discussion because it is not
> that experimental anymore, and its default value.
>
>
> Currently I don’t see any diffs between my pom.xml, and the pom.xml that
> gets included inside the .jar file, I tried doing a “mvn deploy” to check
> the version that got deployed, but yields an missing class exception using
> 2.8.2:
>
> Robert Scholte:
> That is one one the next important steps that needs to be implemented: the
> archiver should include the consumer pom.xml, not the local pom.
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy)
> on project smx3.reporting: Execution default-deploy of goal
> org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy failed: A
> required class was missing while executing
> org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy:
> org/eclipse/aether/transform/FileTransformer
> [ERROR] -----------------------------------------------------
> [ERROR] realm = plugin>org.apache.maven.plugins:maven-deploy-plugin:2.8.2
>
> Robert Scholte:
> Does this mean that the install:install did work?
> That would be interesting.
> I am not aware of that issue. Is there already a JIRA ticket for it, because
> this must be solved before the next release.
>
>
> (I’m unable to currently use 3.0.0-M1 for the same reason either).
>
> Hrm.
> Mark
>
>
> From: Jaroslav Tulach
>
> Reply: Maven Developers List
> Date: 4 July 2020 at 5:35:37 PM
> To: dev
> Cc: dev@maven.apache.org ,
> users@maven.apache.org ,
> m2e-dev@eclipse.org ,
> opencode@microsoft.com
> Subject: Re: Maven moving to the next level: the build/consumer pom
>
> Hello Robert,
> I am not sure how to deal with your announcement and given no reaction on
> the dev@netbeans mailing list, I am probably not alone. Can you formulate
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven moving to the next level: the build/consumer pom
Posted by Mark Derricutt <ma...@talios.com>.
Robert Scholte:
There is a feature toggle, see
https://github.com/apache/maven/blob/master/maven-model-builder/src/main/java/org/apache/maven/feature/Features.java#L34
Awesome - I’ll get that a play and report back.
Does this mean that the install:install did work?
That would be interesting.
I am not aware of that issue. Is there already a JIRA ticket for it,
because this must be solved before the next release.
Install worked fine, just the deploy - we do have a custom mojo that has a
dependency on aether/maven-resolver, so may be I’ll need to update that,
altho I assume that should be in different class loaders.
I’ll try with a totally clean project, and introduce things we have in our
builds piece by piece and try make a minimum test case.
Mark
Re: Maven moving to the next level: the build/consumer pom
Posted by Robert Scholte <rf...@apache.org>.
On 4-7-2020 08:08:00, Mark Derricutt <ma...@talios.com> wrote:
I thought I’d responded - this has been a long time coming, and has been
discussed numerous times over the past few years, and I’m quite excited to
give it a bash, and see how well it works, and see if/what any implications
this has for our tiles-maven-plugin.
I still need to find time to dig into this.
Robert - is there anything specific one does to “enable” this currently -
or is the current merge simply the machinery to take the build pom (even if
its a 4.0.0 model) and produce the consumer pom.
Robert Scholte:
There is a feature toggle, see
https://github.com/apache/maven/blob/master/maven-model-builder/src/main/java/org/apache/maven/feature/Features.java#L34
Here you see the name, which is still part of discussion because it is not that experimental anymore, and its default value.
Currently I don’t see any diffs between my pom.xml, and the pom.xml that
gets included inside the .jar file, I tried doing a “mvn deploy” to check
the version that got deployed, but yields an missing class exception using
2.8.2:
Robert Scholte:
That is one one the next important steps that needs to be implemented: the archiver should include the consumer pom.xml, not the local pom.
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy)
on project smx3.reporting: Execution default-deploy of goal
org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy failed: A
required class was missing while executing
org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy:
org/eclipse/aether/transform/FileTransformer
[ERROR] -----------------------------------------------------
[ERROR] realm = plugin>org.apache.maven.plugins:maven-deploy-plugin:2.8.2
Robert Scholte:
Does this mean that the install:install did work?
That would be interesting.
I am not aware of that issue. Is there already a JIRA ticket for it, because this must be solved before the next release.
(I’m unable to currently use 3.0.0-M1 for the same reason either).
Hrm.
Mark
From: Jaroslav Tulach
Reply: Maven Developers List
Date: 4 July 2020 at 5:35:37 PM
To: dev
Cc: dev@maven.apache.org ,
users@maven.apache.org ,
m2e-dev@eclipse.org ,
opencode@microsoft.com
Subject: Re: Maven moving to the next level: the build/consumer pom
Hello Robert,
I am not sure how to deal with your announcement and given no reaction on
the dev@netbeans mailing list, I am probably not alone. Can you formulate
Re: Maven moving to the next level: the build/consumer pom
Posted by Mark Derricutt <ma...@talios.com>.
I thought I’d responded - this has been a long time coming, and has been
discussed numerous times over the past few years, and I’m quite excited to
give it a bash, and see how well it works, and see if/what any implications
this has for our tiles-maven-plugin.
I still need to find time to dig into this.
Robert - is there anything specific one does to “enable” this currently -
or is the current merge simply the machinery to take the build pom (even if
its a 4.0.0 model) and produce the consumer pom.
Currently I don’t see any diffs between my pom.xml, and the pom.xml that
gets included inside the .jar file, I tried doing a “mvn deploy” to check
the version that got deployed, but yields an missing class exception using
2.8.2:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy)
on project smx3.reporting: Execution default-deploy of goal
org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy failed: A
required class was missing while executing
org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy:
org/eclipse/aether/transform/FileTransformer
[ERROR] -----------------------------------------------------
[ERROR] realm = plugin>org.apache.maven.plugins:maven-deploy-plugin:2.8.2
(I’m unable to currently use 3.0.0-M1 for the same reason either).
Hrm.
Mark
From: Jaroslav Tulach <ja...@gmail.com>
<ja...@gmail.com>
Reply: Maven Developers List <de...@maven.apache.org> <de...@maven.apache.org>
Date: 4 July 2020 at 5:35:37 PM
To: dev <de...@netbeans.apache.org> <de...@netbeans.apache.org>
Cc: dev@maven.apache.org <de...@maven.apache.org> <de...@maven.apache.org>,
users@maven.apache.org <us...@maven.apache.org> <us...@maven.apache.org>,
m2e-dev@eclipse.org <m2...@eclipse.org> <m2...@eclipse.org>,
opencode@microsoft.com <op...@microsoft.com> <op...@microsoft.com>
Subject: Re: Maven moving to the next level: the build/consumer pom
Hello Robert,
I am not sure how to deal with your announcement and given no reaction on
the dev@netbeans mailing list, I am probably not alone. Can you formulate
Re: Maven moving to the next level: the build/consumer pom
Posted by Robert Scholte <rf...@apache.org>.
Hello Jaroslav,
I might have missed the message on the dev@netbeans mailinglist. Based on the responses in ponymail[1] I think I've answered them all (I don't know which one came from netbeans).
I haven't tried it with any IDE, my main goal is that Maven itself keeps working as expected and I've found some edge cases that need improvement.
This pre-announcement was intended as a reach out, so hopefully nobody would be surprised once these features are in the next release of Maven.
In this case I added explicitly 4 buildtools (I had bcc-ed private jetbrains adresses), but there are more.
I don't know if and how every change might impact every IDE, hence I'll announce such using the available maven mailinglists.
If there is a need for an explicit mailinglist regarding these topics, let me know.
thanks,
Robert
[1] https://lists.apache.org/list.html?dev@netbeans.apache.org:lte=1M:consumer
On 4-7-2020 07:35:59, Jaroslav Tulach <ja...@gmail.com> wrote:
Hello Robert,
I am not sure how to deal with your announcement and given no reaction on
the dev@netbeans mailing list, I am probably not alone. Can you formulate
your issue as a bug report? E.g. have you tried to use your new Maven with
NetBeans and did you face a problem? Having steps to reproduce would make
it more real for the NetBeans community to take action.
-jt
po 22. 6. 2020 v 23:18 odesílatel Robert Scholte
napsal:
> Hi,
>
> One of my long standing wishes has made it to the master branch of Maven:
> the support for build/consumer pom.
> With this we can finally start improving the pom without breaking the
> Maven eco system.
>
> Up until now the pom.xml has been distributed (installed/deployed) as is
> to both local and remote repositories.
> The good thing is that is it fast and there is no magic.
> However, it sometimes implies adding redundant information and it also
> blocks any chance of improvement for Maven
>
> The challenge is to make it possible to have an locally an improved
> "build" pom while distributing a model 4.0.0 compatible "consumer" pom.
>
> The whole architecture of Maven was built upon an immutable pom.xml, so it
> took a while to split this, but I managed to solve this.
> And to confirm that it works, some transformations have been added for the
> next Maven release
> The local pom it still model 4.0.0 compatible, but some redundant elements
> are not required anymore.
> - in case the is located at its relativePath (default:
> ../pom.xml), the version can be removed. groupId and artifactId are still
> required to ensure it is being matched with the right parent.
>
> - dependencies that are part of the reactor don't need a version anymore
> These are implemented steps to get from the file model to the raw model,
> where the required versions are added.
>
> When distributing the pom, the previous transformations are done, but also:
> - cifriendly placeholders in versions (${sha1}, ${revision},
> ${changelist}) will be resolved.
> - from will be removed
> - from will be removed
> These cleanups are context aware, if they appear in some configuration,
> they won't be touched.
> One of our integration-tests[1] demonstrates how new poms in a multimodule
> project might look like.
>
> Even though the latter steps look quite small (removing elements with
> relative paths), it should give us enough feedback about the whole process.
>
> The status is that it is ready to be embedded in supporting tools like
> IDEs.
> We should give them time to work on this and share feedback.
> It might require some adjustments in Maven to improve user experience.
>
> In the meantime we need to work on plugins that will have impact by these
> changes.
> Most significant is are signing maven plugins such as the
> maven-gpg-plugin, which needs to work with the distributed pom instead of
> the local pom.
> Also all packaging plugin that can include the pom.xml and pom.properties
> in their archive should switch to the distributed pom.
> The maven-shade-plugin was marked as well, but at first glance this looks
> fine.
> In the end all our plugins must be verified, just to be sure.
> So there's enough to work on.
>
> In general I avoid giving timelines about how fast a new release will be
> available.
> Due to the overhead, the small amount of available time of the few
> volunteers working on Maven, I prefer to have a worth set of changes.
> In this case the impact of the changes can be huge, and I want to have
> enough faith that we won't introduce irreversible mistakes.
> Don't expect a new official release in the 3 next months, however we might
> have alpha or beta releases.
>
> There is a wiki page that explains this topic in more detail[2]
> It is still a draft, as there are still parts where we need to reach
> consensus.
> This page is intended as a base for discussions by Maven developers, users
> and related projects, such as IDEs, Repository Managers, CI Servers, etc.
>
> Looking forward for any feedback,
>
> Robert Scholte
> Apache Maven project
>
> [1]
> https://github.com/apache/maven-integration-testing/tree/master/core-it-suite/src/test/resources/mng-6656-buildconsumer
> [2]
> https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
Re: Maven moving to the next level: the build/consumer pom
Posted by Hervé BOUTEMY <he...@free.fr>.
I just created a "buildconsumer" branch in Doxia [1] to have a live example of the new simplified build POM that Maven 3.7.0 will allow [2]
As expected, this branch can't build with Maven 3.6.3, but can with Maven 3.7.0-SNAPSHOT.
And in my favorite IDE, as expected, dependency resolution does not work because of missing info in pom.xml (which is now a build pom, with removed tags, then was not a valid POM until now)
What is expected is IDE maintainers to check what they need to do at IDE level to support these new POMs that only build with Maven 3.7.0-SNAPSHOT.
Regards,
Hervé
[1] https://github.com/apache/maven-doxia/tree/buildconsumer
[2] https://github.com/apache/maven-doxia/commit/15e3de1a97bf48a394cb566783cac851c0728d98
Le samedi 4 juillet 2020, 07:35:37 CEST Jaroslav Tulach a écrit :
> Hello Robert,
> I am not sure how to deal with your announcement and given no reaction on
> the dev@netbeans mailing list, I am probably not alone. Can you formulate
> your issue as a bug report? E.g. have you tried to use your new Maven with
> NetBeans and did you face a problem? Having steps to reproduce would make
> it more real for the NetBeans community to take action.
>
> -jt
>
> po 22. 6. 2020 v 23:18 odesílatel Robert Scholte <rf...@apache.org>
>
> napsal:
> > Hi,
> >
> > One of my long standing wishes has made it to the master branch of Maven:
> > the support for build/consumer pom.
> > With this we can finally start improving the pom without breaking the
> > Maven eco system.
> >
> > Up until now the pom.xml has been distributed (installed/deployed) as is
> > to both local and remote repositories.
> > The good thing is that is it fast and there is no magic.
> > However, it sometimes implies adding redundant information and it also
> > blocks any chance of improvement for Maven
> >
> > The challenge is to make it possible to have an locally an improved
> > "build" pom while distributing a model 4.0.0 compatible "consumer" pom.
> >
> > The whole architecture of Maven was built upon an immutable pom.xml, so it
> > took a while to split this, but I managed to solve this.
> > And to confirm that it works, some transformations have been added for the
> > next Maven release
> > The local pom it still model 4.0.0 compatible, but some redundant elements
> > are not required anymore.
> > - in case the <parent/> is located at its relativePath (default:
> > ../pom.xml), the version can be removed. groupId and artifactId are still
> > required to ensure it is being matched with the right parent.
> >
> > - dependencies that are part of the reactor don't need a version anymore
> > These are implemented steps to get from the file model to the raw model,
> > where the required versions are added.
> >
> > When distributing the pom, the previous transformations are done, but
> > also:
> > - cifriendly placeholders in versions (${sha1}, ${revision},
> > ${changelist}) will be resolved.
> > - <modules> from <project> will be removed
> > - <relativePath> from <parent> will be removed
> > These cleanups are context aware, if they appear in some configuration,
> > they won't be touched.
> > One of our integration-tests[1] demonstrates how new poms in a multimodule
> > project might look like.
> >
> > Even though the latter steps look quite small (removing elements with
> > relative paths), it should give us enough feedback about the whole
> > process.
> >
> > The status is that it is ready to be embedded in supporting tools like
> > IDEs.
> > We should give them time to work on this and share feedback.
> > It might require some adjustments in Maven to improve user experience.
> >
> > In the meantime we need to work on plugins that will have impact by these
> > changes.
> > Most significant is are signing maven plugins such as the
> > maven-gpg-plugin, which needs to work with the distributed pom instead of
> > the local pom.
> > Also all packaging plugin that can include the pom.xml and pom.properties
> > in their archive should switch to the distributed pom.
> > The maven-shade-plugin was marked as well, but at first glance this looks
> > fine.
> > In the end all our plugins must be verified, just to be sure.
> > So there's enough to work on.
> >
> > In general I avoid giving timelines about how fast a new release will be
> > available.
> > Due to the overhead, the small amount of available time of the few
> > volunteers working on Maven, I prefer to have a worth set of changes.
> > In this case the impact of the changes can be huge, and I want to have
> > enough faith that we won't introduce irreversible mistakes.
> > Don't expect a new official release in the 3 next months, however we might
> > have alpha or beta releases.
> >
> > There is a wiki page that explains this topic in more detail[2]
> > It is still a draft, as there are still parts where we need to reach
> > consensus.
> > This page is intended as a base for discussions by Maven developers, users
> > and related projects, such as IDEs, Repository Managers, CI Servers, etc.
> >
> > Looking forward for any feedback,
> >
> > Robert Scholte
> > Apache Maven project
> >
> > [1]
> > https://github.com/apache/maven-integration-testing/tree/master/core-it-su
> > ite/src/test/resources/mng-6656-buildconsumer [2]
> > https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven moving to the next level: the build/consumer pom
Posted by Hervé BOUTEMY <he...@free.fr>.
I just created a "buildconsumer" branch in Doxia [1] to have a live example of the new simplified build POM that Maven 3.7.0 will allow [2]
As expected, this branch can't build with Maven 3.6.3, but can with Maven 3.7.0-SNAPSHOT.
And in my favorite IDE, as expected, dependency resolution does not work because of missing info in pom.xml (which is now a build pom, with removed tags, then was not a valid POM until now)
What is expected is IDE maintainers to check what they need to do at IDE level to support these new POMs that only build with Maven 3.7.0-SNAPSHOT.
Regards,
Hervé
[1] https://github.com/apache/maven-doxia/tree/buildconsumer
[2] https://github.com/apache/maven-doxia/commit/15e3de1a97bf48a394cb566783cac851c0728d98
Le samedi 4 juillet 2020, 07:35:37 CEST Jaroslav Tulach a écrit :
> Hello Robert,
> I am not sure how to deal with your announcement and given no reaction on
> the dev@netbeans mailing list, I am probably not alone. Can you formulate
> your issue as a bug report? E.g. have you tried to use your new Maven with
> NetBeans and did you face a problem? Having steps to reproduce would make
> it more real for the NetBeans community to take action.
>
> -jt
>
> po 22. 6. 2020 v 23:18 odesílatel Robert Scholte <rf...@apache.org>
>
> napsal:
> > Hi,
> >
> > One of my long standing wishes has made it to the master branch of Maven:
> > the support for build/consumer pom.
> > With this we can finally start improving the pom without breaking the
> > Maven eco system.
> >
> > Up until now the pom.xml has been distributed (installed/deployed) as is
> > to both local and remote repositories.
> > The good thing is that is it fast and there is no magic.
> > However, it sometimes implies adding redundant information and it also
> > blocks any chance of improvement for Maven
> >
> > The challenge is to make it possible to have an locally an improved
> > "build" pom while distributing a model 4.0.0 compatible "consumer" pom.
> >
> > The whole architecture of Maven was built upon an immutable pom.xml, so it
> > took a while to split this, but I managed to solve this.
> > And to confirm that it works, some transformations have been added for the
> > next Maven release
> > The local pom it still model 4.0.0 compatible, but some redundant elements
> > are not required anymore.
> > - in case the <parent/> is located at its relativePath (default:
> > ../pom.xml), the version can be removed. groupId and artifactId are still
> > required to ensure it is being matched with the right parent.
> >
> > - dependencies that are part of the reactor don't need a version anymore
> > These are implemented steps to get from the file model to the raw model,
> > where the required versions are added.
> >
> > When distributing the pom, the previous transformations are done, but
> > also:
> > - cifriendly placeholders in versions (${sha1}, ${revision},
> > ${changelist}) will be resolved.
> > - <modules> from <project> will be removed
> > - <relativePath> from <parent> will be removed
> > These cleanups are context aware, if they appear in some configuration,
> > they won't be touched.
> > One of our integration-tests[1] demonstrates how new poms in a multimodule
> > project might look like.
> >
> > Even though the latter steps look quite small (removing elements with
> > relative paths), it should give us enough feedback about the whole
> > process.
> >
> > The status is that it is ready to be embedded in supporting tools like
> > IDEs.
> > We should give them time to work on this and share feedback.
> > It might require some adjustments in Maven to improve user experience.
> >
> > In the meantime we need to work on plugins that will have impact by these
> > changes.
> > Most significant is are signing maven plugins such as the
> > maven-gpg-plugin, which needs to work with the distributed pom instead of
> > the local pom.
> > Also all packaging plugin that can include the pom.xml and pom.properties
> > in their archive should switch to the distributed pom.
> > The maven-shade-plugin was marked as well, but at first glance this looks
> > fine.
> > In the end all our plugins must be verified, just to be sure.
> > So there's enough to work on.
> >
> > In general I avoid giving timelines about how fast a new release will be
> > available.
> > Due to the overhead, the small amount of available time of the few
> > volunteers working on Maven, I prefer to have a worth set of changes.
> > In this case the impact of the changes can be huge, and I want to have
> > enough faith that we won't introduce irreversible mistakes.
> > Don't expect a new official release in the 3 next months, however we might
> > have alpha or beta releases.
> >
> > There is a wiki page that explains this topic in more detail[2]
> > It is still a draft, as there are still parts where we need to reach
> > consensus.
> > This page is intended as a base for discussions by Maven developers, users
> > and related projects, such as IDEs, Repository Managers, CI Servers, etc.
> >
> > Looking forward for any feedback,
> >
> > Robert Scholte
> > Apache Maven project
> >
> > [1]
> > https://github.com/apache/maven-integration-testing/tree/master/core-it-su
> > ite/src/test/resources/mng-6656-buildconsumer [2]
> > https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven moving to the next level: the build/consumer pom
Posted by Robert Scholte <rf...@apache.org>.
Hello Jaroslav,
I might have missed the message on the dev@netbeans mailinglist. Based on the responses in ponymail[1] I think I've answered them all (I don't know which one came from netbeans).
I haven't tried it with any IDE, my main goal is that Maven itself keeps working as expected and I've found some edge cases that need improvement.
This pre-announcement was intended as a reach out, so hopefully nobody would be surprised once these features are in the next release of Maven.
In this case I added explicitly 4 buildtools (I had bcc-ed private jetbrains adresses), but there are more.
I don't know if and how every change might impact every IDE, hence I'll announce such using the available maven mailinglists.
If there is a need for an explicit mailinglist regarding these topics, let me know.
thanks,
Robert
[1] https://lists.apache.org/list.html?dev@netbeans.apache.org:lte=1M:consumer
On 4-7-2020 07:35:59, Jaroslav Tulach <ja...@gmail.com> wrote:
Hello Robert,
I am not sure how to deal with your announcement and given no reaction on
the dev@netbeans mailing list, I am probably not alone. Can you formulate
your issue as a bug report? E.g. have you tried to use your new Maven with
NetBeans and did you face a problem? Having steps to reproduce would make
it more real for the NetBeans community to take action.
-jt
po 22. 6. 2020 v 23:18 odesílatel Robert Scholte
napsal:
> Hi,
>
> One of my long standing wishes has made it to the master branch of Maven:
> the support for build/consumer pom.
> With this we can finally start improving the pom without breaking the
> Maven eco system.
>
> Up until now the pom.xml has been distributed (installed/deployed) as is
> to both local and remote repositories.
> The good thing is that is it fast and there is no magic.
> However, it sometimes implies adding redundant information and it also
> blocks any chance of improvement for Maven
>
> The challenge is to make it possible to have an locally an improved
> "build" pom while distributing a model 4.0.0 compatible "consumer" pom.
>
> The whole architecture of Maven was built upon an immutable pom.xml, so it
> took a while to split this, but I managed to solve this.
> And to confirm that it works, some transformations have been added for the
> next Maven release
> The local pom it still model 4.0.0 compatible, but some redundant elements
> are not required anymore.
> - in case the is located at its relativePath (default:
> ../pom.xml), the version can be removed. groupId and artifactId are still
> required to ensure it is being matched with the right parent.
>
> - dependencies that are part of the reactor don't need a version anymore
> These are implemented steps to get from the file model to the raw model,
> where the required versions are added.
>
> When distributing the pom, the previous transformations are done, but also:
> - cifriendly placeholders in versions (${sha1}, ${revision},
> ${changelist}) will be resolved.
> - from will be removed
> - from will be removed
> These cleanups are context aware, if they appear in some configuration,
> they won't be touched.
> One of our integration-tests[1] demonstrates how new poms in a multimodule
> project might look like.
>
> Even though the latter steps look quite small (removing elements with
> relative paths), it should give us enough feedback about the whole process.
>
> The status is that it is ready to be embedded in supporting tools like
> IDEs.
> We should give them time to work on this and share feedback.
> It might require some adjustments in Maven to improve user experience.
>
> In the meantime we need to work on plugins that will have impact by these
> changes.
> Most significant is are signing maven plugins such as the
> maven-gpg-plugin, which needs to work with the distributed pom instead of
> the local pom.
> Also all packaging plugin that can include the pom.xml and pom.properties
> in their archive should switch to the distributed pom.
> The maven-shade-plugin was marked as well, but at first glance this looks
> fine.
> In the end all our plugins must be verified, just to be sure.
> So there's enough to work on.
>
> In general I avoid giving timelines about how fast a new release will be
> available.
> Due to the overhead, the small amount of available time of the few
> volunteers working on Maven, I prefer to have a worth set of changes.
> In this case the impact of the changes can be huge, and I want to have
> enough faith that we won't introduce irreversible mistakes.
> Don't expect a new official release in the 3 next months, however we might
> have alpha or beta releases.
>
> There is a wiki page that explains this topic in more detail[2]
> It is still a draft, as there are still parts where we need to reach
> consensus.
> This page is intended as a base for discussions by Maven developers, users
> and related projects, such as IDEs, Repository Managers, CI Servers, etc.
>
> Looking forward for any feedback,
>
> Robert Scholte
> Apache Maven project
>
> [1]
> https://github.com/apache/maven-integration-testing/tree/master/core-it-suite/src/test/resources/mng-6656-buildconsumer
> [2]
> https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
Re: Maven moving to the next level: the build/consumer pom
Posted by Robert Scholte <rf...@apache.org>.
Hello Jaroslav,
I might have missed the message on the dev@netbeans mailinglist. Based on the responses in ponymail[1] I think I've answered them all (I don't know which one came from netbeans).
I haven't tried it with any IDE, my main goal is that Maven itself keeps working as expected and I've found some edge cases that need improvement.
This pre-announcement was intended as a reach out, so hopefully nobody would be surprised once these features are in the next release of Maven.
In this case I added explicitly 4 buildtools (I had bcc-ed private jetbrains adresses), but there are more.
I don't know if and how every change might impact every IDE, hence I'll announce such using the available maven mailinglists.
If there is a need for an explicit mailinglist regarding these topics, let me know.
thanks,
Robert
[1] https://lists.apache.org/list.html?dev@netbeans.apache.org:lte=1M:consumer
On 4-7-2020 07:35:59, Jaroslav Tulach <ja...@gmail.com> wrote:
Hello Robert,
I am not sure how to deal with your announcement and given no reaction on
the dev@netbeans mailing list, I am probably not alone. Can you formulate
your issue as a bug report? E.g. have you tried to use your new Maven with
NetBeans and did you face a problem? Having steps to reproduce would make
it more real for the NetBeans community to take action.
-jt
po 22. 6. 2020 v 23:18 odesílatel Robert Scholte
napsal:
> Hi,
>
> One of my long standing wishes has made it to the master branch of Maven:
> the support for build/consumer pom.
> With this we can finally start improving the pom without breaking the
> Maven eco system.
>
> Up until now the pom.xml has been distributed (installed/deployed) as is
> to both local and remote repositories.
> The good thing is that is it fast and there is no magic.
> However, it sometimes implies adding redundant information and it also
> blocks any chance of improvement for Maven
>
> The challenge is to make it possible to have an locally an improved
> "build" pom while distributing a model 4.0.0 compatible "consumer" pom.
>
> The whole architecture of Maven was built upon an immutable pom.xml, so it
> took a while to split this, but I managed to solve this.
> And to confirm that it works, some transformations have been added for the
> next Maven release
> The local pom it still model 4.0.0 compatible, but some redundant elements
> are not required anymore.
> - in case the is located at its relativePath (default:
> ../pom.xml), the version can be removed. groupId and artifactId are still
> required to ensure it is being matched with the right parent.
>
> - dependencies that are part of the reactor don't need a version anymore
> These are implemented steps to get from the file model to the raw model,
> where the required versions are added.
>
> When distributing the pom, the previous transformations are done, but also:
> - cifriendly placeholders in versions (${sha1}, ${revision},
> ${changelist}) will be resolved.
> - from will be removed
> - from will be removed
> These cleanups are context aware, if they appear in some configuration,
> they won't be touched.
> One of our integration-tests[1] demonstrates how new poms in a multimodule
> project might look like.
>
> Even though the latter steps look quite small (removing elements with
> relative paths), it should give us enough feedback about the whole process.
>
> The status is that it is ready to be embedded in supporting tools like
> IDEs.
> We should give them time to work on this and share feedback.
> It might require some adjustments in Maven to improve user experience.
>
> In the meantime we need to work on plugins that will have impact by these
> changes.
> Most significant is are signing maven plugins such as the
> maven-gpg-plugin, which needs to work with the distributed pom instead of
> the local pom.
> Also all packaging plugin that can include the pom.xml and pom.properties
> in their archive should switch to the distributed pom.
> The maven-shade-plugin was marked as well, but at first glance this looks
> fine.
> In the end all our plugins must be verified, just to be sure.
> So there's enough to work on.
>
> In general I avoid giving timelines about how fast a new release will be
> available.
> Due to the overhead, the small amount of available time of the few
> volunteers working on Maven, I prefer to have a worth set of changes.
> In this case the impact of the changes can be huge, and I want to have
> enough faith that we won't introduce irreversible mistakes.
> Don't expect a new official release in the 3 next months, however we might
> have alpha or beta releases.
>
> There is a wiki page that explains this topic in more detail[2]
> It is still a draft, as there are still parts where we need to reach
> consensus.
> This page is intended as a base for discussions by Maven developers, users
> and related projects, such as IDEs, Repository Managers, CI Servers, etc.
>
> Looking forward for any feedback,
>
> Robert Scholte
> Apache Maven project
>
> [1]
> https://github.com/apache/maven-integration-testing/tree/master/core-it-suite/src/test/resources/mng-6656-buildconsumer
> [2]
> https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
Re: Maven moving to the next level: the build/consumer pom
Posted by Jaroslav Tulach <ja...@gmail.com>.
Hello Robert,
I am not sure how to deal with your announcement and given no reaction on
the dev@netbeans mailing list, I am probably not alone. Can you formulate
your issue as a bug report? E.g. have you tried to use your new Maven with
NetBeans and did you face a problem? Having steps to reproduce would make
it more real for the NetBeans community to take action.
-jt
po 22. 6. 2020 v 23:18 odesílatel Robert Scholte <rf...@apache.org>
napsal:
> Hi,
>
> One of my long standing wishes has made it to the master branch of Maven:
> the support for build/consumer pom.
> With this we can finally start improving the pom without breaking the
> Maven eco system.
>
> Up until now the pom.xml has been distributed (installed/deployed) as is
> to both local and remote repositories.
> The good thing is that is it fast and there is no magic.
> However, it sometimes implies adding redundant information and it also
> blocks any chance of improvement for Maven
>
> The challenge is to make it possible to have an locally an improved
> "build" pom while distributing a model 4.0.0 compatible "consumer" pom.
>
> The whole architecture of Maven was built upon an immutable pom.xml, so it
> took a while to split this, but I managed to solve this.
> And to confirm that it works, some transformations have been added for the
> next Maven release
> The local pom it still model 4.0.0 compatible, but some redundant elements
> are not required anymore.
> - in case the <parent/> is located at its relativePath (default:
> ../pom.xml), the version can be removed. groupId and artifactId are still
> required to ensure it is being matched with the right parent.
>
> - dependencies that are part of the reactor don't need a version anymore
> These are implemented steps to get from the file model to the raw model,
> where the required versions are added.
>
> When distributing the pom, the previous transformations are done, but also:
> - cifriendly placeholders in versions (${sha1}, ${revision},
> ${changelist}) will be resolved.
> - <modules> from <project> will be removed
> - <relativePath> from <parent> will be removed
> These cleanups are context aware, if they appear in some configuration,
> they won't be touched.
> One of our integration-tests[1] demonstrates how new poms in a multimodule
> project might look like.
>
> Even though the latter steps look quite small (removing elements with
> relative paths), it should give us enough feedback about the whole process.
>
> The status is that it is ready to be embedded in supporting tools like
> IDEs.
> We should give them time to work on this and share feedback.
> It might require some adjustments in Maven to improve user experience.
>
> In the meantime we need to work on plugins that will have impact by these
> changes.
> Most significant is are signing maven plugins such as the
> maven-gpg-plugin, which needs to work with the distributed pom instead of
> the local pom.
> Also all packaging plugin that can include the pom.xml and pom.properties
> in their archive should switch to the distributed pom.
> The maven-shade-plugin was marked as well, but at first glance this looks
> fine.
> In the end all our plugins must be verified, just to be sure.
> So there's enough to work on.
>
> In general I avoid giving timelines about how fast a new release will be
> available.
> Due to the overhead, the small amount of available time of the few
> volunteers working on Maven, I prefer to have a worth set of changes.
> In this case the impact of the changes can be huge, and I want to have
> enough faith that we won't introduce irreversible mistakes.
> Don't expect a new official release in the 3 next months, however we might
> have alpha or beta releases.
>
> There is a wiki page that explains this topic in more detail[2]
> It is still a draft, as there are still parts where we need to reach
> consensus.
> This page is intended as a base for discussions by Maven developers, users
> and related projects, such as IDEs, Repository Managers, CI Servers, etc.
>
> Looking forward for any feedback,
>
> Robert Scholte
> Apache Maven project
>
> [1]
> https://github.com/apache/maven-integration-testing/tree/master/core-it-suite/src/test/resources/mng-6656-buildconsumer
> [2]
> https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
Re: Maven moving to the next level: the build/consumer pom
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
The XML handling code in this work is running into some common design
flaws in the JDK XML classes, in particular in the Factories class.
First, you probably shouldn't use SAXParserFactory or SAXParser at
all. They were added to the JDK to support SAX 1.0, and haven't been
needed for since SAX 2 was released (about 20 years ago). Modern code
should use XMLReader and XMLReaderFactory instead.
If you do stick with SAXParser, it's important to call
setNamespaceAware(true), since it's false by default, a legacy of its
use with the non-namespace supporting SAX 1.
On Mon, Jun 22, 2020 at 5:18 PM Robert Scholte <rf...@apache.org> wrote:
>
> Hi,
>
> One of my long standing wishes has made it to the master branch of Maven: the support for build/consumer pom.
> With this we can finally start improving the pom without breaking the Maven eco system.
>
> Up until now the pom.xml has been distributed (installed/deployed) as is to both local and remote repositories.
> The good thing is that is it fast and there is no magic.
> However, it sometimes implies adding redundant information and it also blocks any chance of improvement for Maven
>
> The challenge is to make it possible to have an locally an improved "build" pom while distributing a model 4.0.0 compatible "consumer" pom.
>
> The whole architecture of Maven was built upon an immutable pom.xml, so it took a while to split this, but I managed to solve this.
> And to confirm that it works, some transformations have been added for the next Maven release
> The local pom it still model 4.0.0 compatible, but some redundant elements are not required anymore.
> - in case the <parent/> is located at its relativePath (default: ../pom.xml), the version can be removed. groupId and artifactId are still required to ensure it is being matched with the right parent.
>
> - dependencies that are part of the reactor don't need a version anymore
> These are implemented steps to get from the file model to the raw model, where the required versions are added.
>
> When distributing the pom, the previous transformations are done, but also:
> - cifriendly placeholders in versions (${sha1}, ${revision}, ${changelist}) will be resolved.
> - <modules> from <project> will be removed
> - <relativePath> from <parent> will be removed
> These cleanups are context aware, if they appear in some configuration, they won't be touched.
> One of our integration-tests[1] demonstrates how new poms in a multimodule project might look like.
>
> Even though the latter steps look quite small (removing elements with relative paths), it should give us enough feedback about the whole process.
>
> The status is that it is ready to be embedded in supporting tools like IDEs.
> We should give them time to work on this and share feedback.
> It might require some adjustments in Maven to improve user experience.
>
> In the meantime we need to work on plugins that will have impact by these changes.
> Most significant is are signing maven plugins such as the maven-gpg-plugin, which needs to work with the distributed pom instead of the local pom.
> Also all packaging plugin that can include the pom.xml and pom.properties in their archive should switch to the distributed pom.
> The maven-shade-plugin was marked as well, but at first glance this looks fine.
> In the end all our plugins must be verified, just to be sure.
> So there's enough to work on.
>
> In general I avoid giving timelines about how fast a new release will be available.
> Due to the overhead, the small amount of available time of the few volunteers working on Maven, I prefer to have a worth set of changes.
> In this case the impact of the changes can be huge, and I want to have enough faith that we won't introduce irreversible mistakes.
> Don't expect a new official release in the 3 next months, however we might have alpha or beta releases.
>
> There is a wiki page that explains this topic in more detail[2]
> It is still a draft, as there are still parts where we need to reach consensus.
> This page is intended as a base for discussions by Maven developers, users and related projects, such as IDEs, Repository Managers, CI Servers, etc.
>
> Looking forward for any feedback,
>
> Robert Scholte
> Apache Maven project
>
> [1] https://github.com/apache/maven-integration-testing/tree/master/core-it-suite/src/test/resources/mng-6656-buildconsumer
> [2] https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Maven moving to the next level: the build/consumer pom
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
The XML handling code in this work is running into some common design
flaws in the JDK XML classes, in particular in the Factories class.
First, you probably shouldn't use SAXParserFactory or SAXParser at
all. They were added to the JDK to support SAX 1.0, and haven't been
needed for since SAX 2 was released (about 20 years ago). Modern code
should use XMLReader and XMLReaderFactory instead.
If you do stick with SAXParser, it's important to call
setNamespaceAware(true), since it's false by default, a legacy of its
use with the non-namespace supporting SAX 1.
On Mon, Jun 22, 2020 at 5:18 PM Robert Scholte <rf...@apache.org> wrote:
>
> Hi,
>
> One of my long standing wishes has made it to the master branch of Maven: the support for build/consumer pom.
> With this we can finally start improving the pom without breaking the Maven eco system.
>
> Up until now the pom.xml has been distributed (installed/deployed) as is to both local and remote repositories.
> The good thing is that is it fast and there is no magic.
> However, it sometimes implies adding redundant information and it also blocks any chance of improvement for Maven
>
> The challenge is to make it possible to have an locally an improved "build" pom while distributing a model 4.0.0 compatible "consumer" pom.
>
> The whole architecture of Maven was built upon an immutable pom.xml, so it took a while to split this, but I managed to solve this.
> And to confirm that it works, some transformations have been added for the next Maven release
> The local pom it still model 4.0.0 compatible, but some redundant elements are not required anymore.
> - in case the <parent/> is located at its relativePath (default: ../pom.xml), the version can be removed. groupId and artifactId are still required to ensure it is being matched with the right parent.
>
> - dependencies that are part of the reactor don't need a version anymore
> These are implemented steps to get from the file model to the raw model, where the required versions are added.
>
> When distributing the pom, the previous transformations are done, but also:
> - cifriendly placeholders in versions (${sha1}, ${revision}, ${changelist}) will be resolved.
> - <modules> from <project> will be removed
> - <relativePath> from <parent> will be removed
> These cleanups are context aware, if they appear in some configuration, they won't be touched.
> One of our integration-tests[1] demonstrates how new poms in a multimodule project might look like.
>
> Even though the latter steps look quite small (removing elements with relative paths), it should give us enough feedback about the whole process.
>
> The status is that it is ready to be embedded in supporting tools like IDEs.
> We should give them time to work on this and share feedback.
> It might require some adjustments in Maven to improve user experience.
>
> In the meantime we need to work on plugins that will have impact by these changes.
> Most significant is are signing maven plugins such as the maven-gpg-plugin, which needs to work with the distributed pom instead of the local pom.
> Also all packaging plugin that can include the pom.xml and pom.properties in their archive should switch to the distributed pom.
> The maven-shade-plugin was marked as well, but at first glance this looks fine.
> In the end all our plugins must be verified, just to be sure.
> So there's enough to work on.
>
> In general I avoid giving timelines about how fast a new release will be available.
> Due to the overhead, the small amount of available time of the few volunteers working on Maven, I prefer to have a worth set of changes.
> In this case the impact of the changes can be huge, and I want to have enough faith that we won't introduce irreversible mistakes.
> Don't expect a new official release in the 3 next months, however we might have alpha or beta releases.
>
> There is a wiki page that explains this topic in more detail[2]
> It is still a draft, as there are still parts where we need to reach consensus.
> This page is intended as a base for discussions by Maven developers, users and related projects, such as IDEs, Repository Managers, CI Servers, etc.
>
> Looking forward for any feedback,
>
> Robert Scholte
> Apache Maven project
>
> [1] https://github.com/apache/maven-integration-testing/tree/master/core-it-suite/src/test/resources/mng-6656-buildconsumer
> [2] https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven moving to the next level: the build/consumer pom
Posted by Anton Vodonosov <av...@yandex.ru>.
Can this work also allow arbitrary property expression in a module <version>?
Currently, this practice is discouraged because the deployed pom with property
expression is meaningless.
The flatten-maven-plugin can produce correct poms for deployment,
with all properties resolved; despite maven prints the hardcoded warning
"'version' contains an expression but should be a constant".
Links on the topic:
http://mail-archives.apache.org/mod_mbox/maven-users/201201.mbox/%3CCA+nPnMyb_W4Ldrg5zTn5NX3F2kcrPXDefS4gjzz3OE0cUy1rXw@mail.gmail.com%3E
https://issues.apache.org/jira/browse/MNG-4715
https://stackoverflow.com/questions/19123013/maven-version-with-a-property/19123130
Why I'm interested in property expressions for versions is because I want to generate
versions automatically as a hash code of all sources and dependencies.
And also skip building of modules whose has-version has not changed.
That way the large multi-module project can vary significantly improve build speed
and reduce the artifact storage consumption. Similar to what build caches
give for gradle and bazel, only a bit simplified, less granular - caching done
on the level of final artifacts, but not for intermediate outputs
(compiled file, generated resources).
If would be very convenient if maven-flatten-plugin become unnecessary
and maven supported property expressions in version spec out of box.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven moving to the next level: the build/consumer pom
Posted by Jaroslav Tulach <ja...@gmail.com>.
Hello Robert,
I am not sure how to deal with your announcement and given no reaction on
the dev@netbeans mailing list, I am probably not alone. Can you formulate
your issue as a bug report? E.g. have you tried to use your new Maven with
NetBeans and did you face a problem? Having steps to reproduce would make
it more real for the NetBeans community to take action.
-jt
po 22. 6. 2020 v 23:18 odesílatel Robert Scholte <rf...@apache.org>
napsal:
> Hi,
>
> One of my long standing wishes has made it to the master branch of Maven:
> the support for build/consumer pom.
> With this we can finally start improving the pom without breaking the
> Maven eco system.
>
> Up until now the pom.xml has been distributed (installed/deployed) as is
> to both local and remote repositories.
> The good thing is that is it fast and there is no magic.
> However, it sometimes implies adding redundant information and it also
> blocks any chance of improvement for Maven
>
> The challenge is to make it possible to have an locally an improved
> "build" pom while distributing a model 4.0.0 compatible "consumer" pom.
>
> The whole architecture of Maven was built upon an immutable pom.xml, so it
> took a while to split this, but I managed to solve this.
> And to confirm that it works, some transformations have been added for the
> next Maven release
> The local pom it still model 4.0.0 compatible, but some redundant elements
> are not required anymore.
> - in case the <parent/> is located at its relativePath (default:
> ../pom.xml), the version can be removed. groupId and artifactId are still
> required to ensure it is being matched with the right parent.
>
> - dependencies that are part of the reactor don't need a version anymore
> These are implemented steps to get from the file model to the raw model,
> where the required versions are added.
>
> When distributing the pom, the previous transformations are done, but also:
> - cifriendly placeholders in versions (${sha1}, ${revision},
> ${changelist}) will be resolved.
> - <modules> from <project> will be removed
> - <relativePath> from <parent> will be removed
> These cleanups are context aware, if they appear in some configuration,
> they won't be touched.
> One of our integration-tests[1] demonstrates how new poms in a multimodule
> project might look like.
>
> Even though the latter steps look quite small (removing elements with
> relative paths), it should give us enough feedback about the whole process.
>
> The status is that it is ready to be embedded in supporting tools like
> IDEs.
> We should give them time to work on this and share feedback.
> It might require some adjustments in Maven to improve user experience.
>
> In the meantime we need to work on plugins that will have impact by these
> changes.
> Most significant is are signing maven plugins such as the
> maven-gpg-plugin, which needs to work with the distributed pom instead of
> the local pom.
> Also all packaging plugin that can include the pom.xml and pom.properties
> in their archive should switch to the distributed pom.
> The maven-shade-plugin was marked as well, but at first glance this looks
> fine.
> In the end all our plugins must be verified, just to be sure.
> So there's enough to work on.
>
> In general I avoid giving timelines about how fast a new release will be
> available.
> Due to the overhead, the small amount of available time of the few
> volunteers working on Maven, I prefer to have a worth set of changes.
> In this case the impact of the changes can be huge, and I want to have
> enough faith that we won't introduce irreversible mistakes.
> Don't expect a new official release in the 3 next months, however we might
> have alpha or beta releases.
>
> There is a wiki page that explains this topic in more detail[2]
> It is still a draft, as there are still parts where we need to reach
> consensus.
> This page is intended as a base for discussions by Maven developers, users
> and related projects, such as IDEs, Repository Managers, CI Servers, etc.
>
> Looking forward for any feedback,
>
> Robert Scholte
> Apache Maven project
>
> [1]
> https://github.com/apache/maven-integration-testing/tree/master/core-it-suite/src/test/resources/mng-6656-buildconsumer
> [2]
> https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
Re: Maven moving to the next level: the build/consumer pom
Posted by Anton Vodonosov <av...@yandex.ru>.
Can this work also allow arbitrary property expression in a module <version>?
Currently, this practice is discouraged because the deployed pom with property
expression is meaningless.
The flatten-maven-plugin can produce correct poms for deployment,
with all properties resolved; despite maven prints the hardcoded warning
"'version' contains an expression but should be a constant".
Links on the topic:
http://mail-archives.apache.org/mod_mbox/maven-users/201201.mbox/%3CCA+nPnMyb_W4Ldrg5zTn5NX3F2kcrPXDefS4gjzz3OE0cUy1rXw@mail.gmail.com%3E
https://issues.apache.org/jira/browse/MNG-4715
https://stackoverflow.com/questions/19123013/maven-version-with-a-property/19123130
Why I'm interested in property expressions for versions is because I want to generate
versions automatically as a hash code of all sources and dependencies.
And also skip building of modules whose has-version has not changed.
That way the large multi-module project can vary significantly improve build speed
and reduce the artifact storage consumption. Similar to what build caches
give for gradle and bazel, only a bit simplified, less granular - caching done
on the level of final artifacts, but not for intermediate outputs
(compiled file, generated resources).
If would be very convenient if maven-flatten-plugin become unnecessary
and maven supported property expressions in version spec out of box.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven moving to the next level: the build/consumer pom
Posted by Jaroslav Tulach <ja...@gmail.com>.
Hello Robert,
I am not sure how to deal with your announcement and given no reaction on
the dev@netbeans mailing list, I am probably not alone. Can you formulate
your issue as a bug report? E.g. have you tried to use your new Maven with
NetBeans and did you face a problem? Having steps to reproduce would make
it more real for the NetBeans community to take action.
-jt
po 22. 6. 2020 v 23:18 odesílatel Robert Scholte <rf...@apache.org>
napsal:
> Hi,
>
> One of my long standing wishes has made it to the master branch of Maven:
> the support for build/consumer pom.
> With this we can finally start improving the pom without breaking the
> Maven eco system.
>
> Up until now the pom.xml has been distributed (installed/deployed) as is
> to both local and remote repositories.
> The good thing is that is it fast and there is no magic.
> However, it sometimes implies adding redundant information and it also
> blocks any chance of improvement for Maven
>
> The challenge is to make it possible to have an locally an improved
> "build" pom while distributing a model 4.0.0 compatible "consumer" pom.
>
> The whole architecture of Maven was built upon an immutable pom.xml, so it
> took a while to split this, but I managed to solve this.
> And to confirm that it works, some transformations have been added for the
> next Maven release
> The local pom it still model 4.0.0 compatible, but some redundant elements
> are not required anymore.
> - in case the <parent/> is located at its relativePath (default:
> ../pom.xml), the version can be removed. groupId and artifactId are still
> required to ensure it is being matched with the right parent.
>
> - dependencies that are part of the reactor don't need a version anymore
> These are implemented steps to get from the file model to the raw model,
> where the required versions are added.
>
> When distributing the pom, the previous transformations are done, but also:
> - cifriendly placeholders in versions (${sha1}, ${revision},
> ${changelist}) will be resolved.
> - <modules> from <project> will be removed
> - <relativePath> from <parent> will be removed
> These cleanups are context aware, if they appear in some configuration,
> they won't be touched.
> One of our integration-tests[1] demonstrates how new poms in a multimodule
> project might look like.
>
> Even though the latter steps look quite small (removing elements with
> relative paths), it should give us enough feedback about the whole process.
>
> The status is that it is ready to be embedded in supporting tools like
> IDEs.
> We should give them time to work on this and share feedback.
> It might require some adjustments in Maven to improve user experience.
>
> In the meantime we need to work on plugins that will have impact by these
> changes.
> Most significant is are signing maven plugins such as the
> maven-gpg-plugin, which needs to work with the distributed pom instead of
> the local pom.
> Also all packaging plugin that can include the pom.xml and pom.properties
> in their archive should switch to the distributed pom.
> The maven-shade-plugin was marked as well, but at first glance this looks
> fine.
> In the end all our plugins must be verified, just to be sure.
> So there's enough to work on.
>
> In general I avoid giving timelines about how fast a new release will be
> available.
> Due to the overhead, the small amount of available time of the few
> volunteers working on Maven, I prefer to have a worth set of changes.
> In this case the impact of the changes can be huge, and I want to have
> enough faith that we won't introduce irreversible mistakes.
> Don't expect a new official release in the 3 next months, however we might
> have alpha or beta releases.
>
> There is a wiki page that explains this topic in more detail[2]
> It is still a draft, as there are still parts where we need to reach
> consensus.
> This page is intended as a base for discussions by Maven developers, users
> and related projects, such as IDEs, Repository Managers, CI Servers, etc.
>
> Looking forward for any feedback,
>
> Robert Scholte
> Apache Maven project
>
> [1]
> https://github.com/apache/maven-integration-testing/tree/master/core-it-suite/src/test/resources/mng-6656-buildconsumer
> [2]
> https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
Re: Maven moving to the next level: the build/consumer pom
Posted by Matthieu BROUILLARD <ma...@brouillard.fr>.
Hi Robert,
congrats this looks like a great achievement.
I presume that the consumer pom means the end of the flatten plugin or is
there still some benefit in using flatten plugin?
> dependencies that are part of the reactor don't need a version anymore
What is meant here ? Is it that in a multimodule project a dependency from
a module to another of the same multimodule does not need the version ? For
example when having an api and impl in the same multimodule, the impl will
not require the version of the api?
> These are implemented steps to get from the file model to the raw model,
where the required versions are added.
Are those replacements still part of the pom loading by ModelProcessor?
I'll give it a try especially to see the compliance with my existing core
extensions.
Matthieu Brouillard
On Mon, Jun 22, 2020 at 11:18 PM Robert Scholte <rf...@apache.org>
wrote:
> Hi,
>
> One of my long standing wishes has made it to the master branch of Maven:
> the support for build/consumer pom.
> With this we can finally start improving the pom without breaking the
> Maven eco system.
>
> Up until now the pom.xml has been distributed (installed/deployed) as is
> to both local and remote repositories.
> The good thing is that is it fast and there is no magic.
> However, it sometimes implies adding redundant information and it also
> blocks any chance of improvement for Maven
>
> The challenge is to make it possible to have an locally an improved
> "build" pom while distributing a model 4.0.0 compatible "consumer" pom.
>
> The whole architecture of Maven was built upon an immutable pom.xml, so it
> took a while to split this, but I managed to solve this.
> And to confirm that it works, some transformations have been added for the
> next Maven release
> The local pom it still model 4.0.0 compatible, but some redundant elements
> are not required anymore.
> - in case the <parent/> is located at its relativePath (default:
> ../pom.xml), the version can be removed. groupId and artifactId are still
> required to ensure it is being matched with the right parent.
>
> - dependencies that are part of the reactor don't need a version anymore
> These are implemented steps to get from the file model to the raw model,
> where the required versions are added.
>
> When distributing the pom, the previous transformations are done, but also:
> - cifriendly placeholders in versions (${sha1}, ${revision},
> ${changelist}) will be resolved.
> - <modules> from <project> will be removed
> - <relativePath> from <parent> will be removed
> These cleanups are context aware, if they appear in some configuration,
> they won't be touched.
> One of our integration-tests[1] demonstrates how new poms in a multimodule
> project might look like.
>
> Even though the latter steps look quite small (removing elements with
> relative paths), it should give us enough feedback about the whole process.
>
> The status is that it is ready to be embedded in supporting tools like
> IDEs.
> We should give them time to work on this and share feedback.
> It might require some adjustments in Maven to improve user experience.
>
> In the meantime we need to work on plugins that will have impact by these
> changes.
> Most significant is are signing maven plugins such as the
> maven-gpg-plugin, which needs to work with the distributed pom instead of
> the local pom.
> Also all packaging plugin that can include the pom.xml and pom.properties
> in their archive should switch to the distributed pom.
> The maven-shade-plugin was marked as well, but at first glance this looks
> fine.
> In the end all our plugins must be verified, just to be sure.
> So there's enough to work on.
>
> In general I avoid giving timelines about how fast a new release will be
> available.
> Due to the overhead, the small amount of available time of the few
> volunteers working on Maven, I prefer to have a worth set of changes.
> In this case the impact of the changes can be huge, and I want to have
> enough faith that we won't introduce irreversible mistakes.
> Don't expect a new official release in the 3 next months, however we might
> have alpha or beta releases.
>
> There is a wiki page that explains this topic in more detail[2]
> It is still a draft, as there are still parts where we need to reach
> consensus.
> This page is intended as a base for discussions by Maven developers, users
> and related projects, such as IDEs, Repository Managers, CI Servers, etc.
>
> Looking forward for any feedback,
>
> Robert Scholte
> Apache Maven project
>
> [1]
> https://github.com/apache/maven-integration-testing/tree/master/core-it-suite/src/test/resources/mng-6656-buildconsumer
> [2]
> https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM