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
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
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
On 25-6-2020 02:03:42, Anton Vodonosov 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
On 24-6-2020 00:48:48, Mark Derricutt 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
On 23-6-2020 23:20:31, Matthieu BROUILLARD 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
Can this work also allow arbitrary property expression in a module ?
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
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
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
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
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
11 matches
Mail list logo
