Re: Investigate mvn4 large graph performance regression; was: Re: Maven 4.0.0 Release - Thoughts?

well I found the reason(s)! I pushed several prs to maven and maven-resolver. the final score is about 2/3 - 1/2 time usage than before the refining. please have a look(especially the pr in maven-resolver, which is the most severe one.). Xeno Amess 于2025年6月14日周六 14:54写道： > Weather here is bad in

Re: Investigate mvn4 large graph performance regression; was: Re: Maven 4.0.0 Release - Thoughts?

Weather here is bad in my city...just suffering from typhoon days. I would give several pr about my investigations on Sergey Chernov's demo repo this weekend. Most of them be minor/medium level performance refinements.

Investigate mvn4 large graph performance regression; was: Re: Maven 4.0.0 Release - Thoughts?

excellent! looks like the hash code paths were only part of the puzzle. I added some screenshots to this issue https://github.com/apache/maven/issues/2481, since it is easier to share graphs there compared to mail attachments. unfortunately the weather is nice so I am not sure how much time I

Re: Maven 4.0.0 Release - Thoughts?

Coolio, kudos Sergey! My numbers are (OS name: "linux", version: "6.14.9-300.fc42.x86_64", arch: "amd64", family: "unix", Java version: 21.0.7, vendor: Eclipse Adoptium): mvn 3.9.10: 0:39 mvn4 master + R2.0.9: 1:36 mvn4 master + R2.0.10-SNAPSHOT: 1:42 The "R" is Resolver, and 2.0.10 contains this

Re: Maven 4.0.0 Release - Thoughts?

I made a simple multi-module project generator which has some size parameters. Please see project description here https://github.com/maven-turbo-reactor/maven-multiproject-generator The good news is that it highlights the performance problem in comparison between Maven3 and Maven4. The generated

Re: Maven 4.0.0 Release - Thoughts?

On Thu, Jun 12, 2025 at 1:48 AM Michael Bien wrote: > If there is a public project which hits this bottleneck I could take a > look and play > with some ideas to try to make this scale better. (I don't really want to > spam this thread > too much) > You could take a look at https://github.com/wi

Re: Maven 4.0.0 Release - Thoughts?

On 6/11/25 08:54, Michael Bien wrote: > Hi, > > 3/4 stack traces you posted contained the constructor frame with the > Objects.hash() call.  > > Hash code over so many collections can scale badly once the collections grow: > https://github.com/apache/maven-resolver/blob/145588be6d5b2c0111b5f367787

Re: Maven 4.0.0 Release - Thoughts?

Hi, 3/4 stack traces you posted contained the constructor frame with the Objects.hash() call.  Hash code over so many collections can scale badly once the collections grow: https://github.com/apache/maven-resolver/blob/145588be6d5b2c0111b5f367787d4c9347c326da/maven-resolver-util/src/main/java/or

Re: Maven 4.0.0 Release - Thoughts?

I was able to run the Maven build (~900 modules) with the profiler. Used `Apache Maven 4.0.0-rc-3` and the simplest possible command `mvn initialize` which demonstrates reproducible degradation, the build is using 6 worker threads. Maven 3 runs this command in 5 sec, Maven 4 - 6 minutes (no mistake

Re: Maven 4.0.0 Release - Thoughts?

@Guillaume Nodet [MNG-8510] Avoid duplicate Utils classes (#2173) https://github.com/JetBrains/intellij-community/blob/4054fd36584fb2bbb1ed983d7d36cefca040c2cf/plugins/maven/maven40-server-impl/src/com/intellij/maven/server/m40/Maven40ServerEmbedderImpl.java#L74 yes we can release the version 4.0.

Re: Maven 4.0.0 Release - Thoughts?

all running with skipTests log4j both success, mvn3 2:00 mvn4 1:50 dubbo both success, mvn3 3:08 mvn4 3:19 hadoop failed due to network reason(for yarn frontend, well considering about where I'm living it is normal...) for structs 2, 90%+ time is wasted on antrun for docs generation in struts2-

Re: Maven 4.0.0 Release - Thoughts?

nope. neither can the github master latest. Xeno Amess 于2025年5月29日周四 14:40写道： > I used apache-maven-4.0.0-rc-3 btw. I would have a try at the latest > github code version... > > Xeno Amess 于2025年5月29日周四 14:39写道： > >> jetty is a good example. >> mvn3 can build but mvn4 cannot. >> >> maven-assemb

Re: Maven 4.0.0 Release - Thoughts?

I used apache-maven-4.0.0-rc-3 btw. I would have a try at the latest github code version... Xeno Amess 于2025年5月29日周四 14:39写道： > jetty is a good example. > mvn3 can build but mvn4 cannot. > > maven-assembly-plugin:3.7.1 wrongly invoking a bom sub-project > > [INFO] ---< org.eclipse.je

Re: Maven 4.0.0 Release - Thoughts?

jetty is a good example. mvn3 can build but mvn4 cannot. maven-assembly-plugin:3.7.1 wrongly invoking a bom sub-project [INFO] ---< org.eclipse.jetty.ee10:jetty-ee10-bom > [INFO] Building EE10 :: BOM 12.0.22-SNAPSHOT [90/354] [INFO] from jetty-ee10/jetty-ee10-bom/pom

Re: Maven 4.0.0 Release - Thoughts?

Hey, Delany. I will look into this. Also to avoid confusion let's continue this discussion in the proper thread as it's not related to maven 4 release On Wed, May 28, 2025 at 4:22 PM Delany wrote: > Hi Sergei, > > I'm running with this extension going forward. I don't use the build cache > (yet)

Re: Maven 4.0.0 Release - Thoughts?

Hi Sergei, I'm running with this extension going forward. I don't use the build cache (yet) so that's not an issue. When trying to promote unit tests to a company that's resistant its helpful to be able to say the tests won't slow down the build. We have one huge module though (project we're call

Re: Maven 4.0.0 Release - Thoughts?

Jetty is a good one as well: https://github.com/jetty/jetty.project Gary On Wed, May 28, 2025, 08:55 Sergey Chernov wrote: > Guillaume, that's awesome. It's good that there is no rush with it. > Once I'll have insights, I'll share them. > > Xeno, the project I'm checking is private unfortunatel

Re: Maven 4.0.0 Release - Thoughts?

I tested log4j2 an hour ago. on my computer mvn3 use 2:00(min), mvn4 use 1:53(min) no much difference. would try test your examples later. Sergey Chernov 于2025年5月28日周三 20:55写道： > Guillaume, that's awesome. It's good that there is no rush with it. > Once I'll have insights, I'll share them. > > X

Re: Maven 4.0.0 Release - Thoughts?

Guillaume, that's awesome. It's good that there is no rush with it. Once I'll have insights, I'll share them. Xeno, the project I'm checking is private unfortunately. Also this can be quite challenging to find a good Maven multi-module project as a reference for performance testing and compatibili

Re: Maven 4.0.0 Release - Thoughts?

After considering the concerns about API stability, plugin compatibility, and the performance issues reported by Sergey (4x slower in rc3), I agree with Sylwester, Benjamin, and Elliotte that we should opt for an rc4 to address these issues. My proposal is to release a final release candidate (rc4)

Re: Maven 4.0.0 Release - Thoughts?

the biggest I found yet is https://github.com/apache/logging-log4j2.git Xeno Amess 于2025年5月28日周三 17:17写道： > IMO LinkedHashSet can work, no need to use LinkedHashMap directly... > but I still think it better to see the bottle-neck through real-world > running. so let's just find some really biggy

Re: Maven 4.0.0 Release - Thoughts?

IMO LinkedHashSet can work, no need to use LinkedHashMap directly... but I still think it better to see the bottle-neck through real-world running. so let's just find some really biggy open source java projects using maven(if can't, maybe we have to craft one?) Martin Desruisseaux 于2025年5月28日周三

Re: Maven 4.0.0 Release - Thoughts?

yep, you can try with jprofiler/jetbrains-profiler/something else and see what be the bottleneck. if the project is...open source, we can have a try too... Xeno Amess 于2025年5月28日周三 17:09写道： > @Sergey Chernov > could you please give a link about the test suites you be using > > Sergey Chernov 于

Re: Maven 4.0.0 Release - Thoughts?

@Sergey Chernov could you please give a link about the test suites you be using Sergey Chernov 于2025年5月27日周二 04:56写道： > Just tried the 4.0.0-rc-3 comparing with 3.9.9, it's 4x times slower (!) on > a project of ~900 modules (700 of them are jar). > Maven 3 builds it in 2m57s, while Maven 4 in 1

Re: Maven 4.0.0 Release - Thoughts?

That's interesting. I can try to inspect this with a profiler to find "hot" stack traces. On Tue, May 27, 2025 at 9:52 PM Martin Desruisseaux < martin.desruisse...@geomatys.com> wrote: > Hello > > Le 2025-05-26 à 22 h 55, Sergey Chernov a écrit : > > > Just tried the 4.0.0-rc-3 comparing with 3.

Re: Maven 4.0.0 Release - Thoughts?

Hello Le 2025-05-26 à 22 h 55, Sergey Chernov a écrit : Just tried the 4.0.0-rc-3 comparing with 3.9.9, it's 4x times slower (!) on a project of ~900 modules (700 of them are jar). Regarding performance, some months ago I noticed that Maven contains loops over elements of a list with a call

Re: Maven 4.0.0 Release - Thoughts?

Some plugins are known to cause important slow downs when executing in Maven 4. This is the case for example of https://github.com/tisonkun/os-detector which can be easily replaced with https://github.com/maveniverse/nisse. But I suppose there are other plugins that could cause the same behavior.

Re: Maven 4.0.0 Release - Thoughts?

We cannot do that. We'd have to cut a new release and vote on it. If the goal is to evaluate the release, we need to start voting a 4.0.0, open the vote, if any issue is considered blocking, cancel the vote, fix the issue and cut another 4.0.0 release. If the issue is not blocking, we can do a 4.0.

Re: Maven 4.0.0 Release - Thoughts?

Just tried the 4.0.0-rc-3 comparing with 3.9.9, it's 4x times slower (!) on a project of ~900 modules (700 of them are jar). Maven 3 builds it in 2m57s, while Maven 4 in 11m48s (reproducible, with all m2 caches). No build cache solutions enabled to compare pure build time. Project is nothing specia

Re: Maven 4.0.0 Release - Thoughts?

Totally agree! I'm not trying to advocate "no more RC's", I'm trying to advocate "last RC should be as close as possible to the final product". And given what has happened between the last RC and today, I don't think we can cut 4.0.0 *today*. The diff is quite large IMO. Thanks, Maarten On

Re: Maven 4.0.0 Release - Thoughts?

On Mon, May 26, 2025 at 2:25 PM Maarten Mulders wrote: > > That definition makes a lot of sense to me. If we would adhere to it, we > should discipline ourselves after "a" next RC and *not* accept any code > changes *except* for fixing critical uses. Be careful not to let the tail wag the dog. if

Re: Maven 4.0.0 Release - Thoughts?

That definition makes a lot of sense to me. If we would adhere to it, we should discipline ourselves after "a" next RC and *not* accept any code changes *except* for fixing critical uses. I think there have been too many changes since last RC to cut a 4.0.0 today. Maarten On 26/05/2025 14:14

Re: Maven 4.0.0 Release - Thoughts?

I believe having a "Release Candidate" is a good idea As long as it is indeed a candidate: a version that is exactly the same as a release, except for discovered critical issues and version numbers. I wonder if promoting a candidate to a GA without any code changes requires modification of existin

Re: Maven 4.0.0 Release - Thoughts?

I think we need to clarify that 1. Maven 3 plugins should work with Maven 4 (eventually require a recent update that fixes small compatibility issues), 2. and this is still the main expected way to use plugins with Maven 4 Maven 4 - specific plugins, using the still experimental Maven 4 API, is s

Re: Maven 4.0.0 Release - Thoughts?

Plugin developers aren’t forced to migrate. I’m using Maven 4 daily and I don’t use a single plugin that uses the new api. So while I agree that stability is required, the stability is provided by the Maven 3 api, mostly supported unchanged in Maven 4. Le dim. 25 mai 2025 à 12:26, Elliotte Rusty

Re: Maven 4.0.0 Release - Thoughts?

On Sat, May 24, 2025 at 1:23 PM Guillaume Nodet wrote: > > I don't think they're talking about the Maven 4 API when they expect > API stability. > They rather refer to user-facing API such as schema changes, etc..., > rather than dev-facing API. Plugin developers need API stability though. -- E

Re: Maven 4.0.0 Release - Thoughts?

I don't think they're talking about the Maven 4 API when they expect API stability. They rather refer to user-facing API such as schema changes, etc..., rather than dev-facing API. We did introduce new features in the RC, but afaik, they're not using the maven 4 API, I could be wrong though. Le sa

Re: Maven 4.0.0 Release - Thoughts?

-1. I'm fine with feature freeze, but the codebase and API have not reached a stable and reliable state that I'm comfortable committing to. In particular, there is a lot of API still marked experimental, and I think we need to make decisions on all of that before pushing a release version out the

Re: Maven 4.0.0 Release - Thoughts?

Do we have the list of planned API changes? Most changes can likely be limited using a "request/response object" pattern (so we can add data without breaking instead of passing N parameters), new methods dont break, so ultimately we are not worse than 3.9.x in terms of stability if we respect that

Re: Maven 4.0.0 Release - Thoughts?

-1 for release, +1 for rc4. Reason: What Sylwester said, plus Nikita from JetBrains asking nicely. They (JB) would love to see API stability so they can ship an IntelliJ IDEA release in time with Maven 4. This of course applies to all other IDEs. Nikita is on #maven in slack, maybe also subscribed

Re: Maven 4.0.0 Release - Thoughts?

I would go for rc4 because we still have API changes after rc3 and our plugins needs adjustments that could again require another, smaller changes. With current state of plugins 4.x they can't be used with latest (master) version so we could offer only 3.x for Maven 4. Not so big issue for many use

Re: Maven 4.0.0 Release - Thoughts?

Sounds like a good plan! On Wed, 21 May 2025 at 4:12 pm, Guillaume Nodet wrote: > Hey Maven Devs, > > We're gearing up to release a new version from the master branch. I'm > thinking we should go for 4.0.0 instead of rc-4. What do you all think? Any > feedback or ideas on the versioning or relea

Re: Maven 4.0.0 Release - Thoughts?

Le jeudi 22 mai 2025, 17:30:20 CEST Matthias Bünger a écrit : > Am 22.05.2025 um 09:23 schrieb Hervé Boutemy: > > yes to try to make sure Maven 4.0.0 will run smoothly on Java 24 > > > > on tying Maven 4.0.0 release to Jira to GH Issues migration: is there a > > strong reason for coupling these 2

Re: Maven 4.0.0 Release - Thoughts?

Am 22.05.2025 um 09:23 schrieb Hervé Boutemy: yes to try to make sure Maven 4.0.0 will run smoothly on Java 24 on tying Maven 4.0.0 release to Jira to GH Issues migration: is there a strong reason for coupling these 2 huge beasts? Hi Hervè, TLDR: No strong reason ;) Long version: Maybe I w

Re: Maven 4.0.0 Release - Thoughts?

On Thu, 22 May 2025 at 09:24, Hervé Boutemy wrote: > yes to try to make sure Maven 4.0.0 will run smoothly on Java 24 > > on tying Maven 4.0.0 release to Jira to GH Issues migration: is there a > strong > reason for coupling these 2 huge beasts? > > > longer analysis: > > Jira to GH Issues migrat

Re: Maven 4.0.0 Release - Thoughts?

yes to try to make sure Maven 4.0.0 will run smoothly on Java 24 on tying Maven 4.0.0 release to Jira to GH Issues migration: is there a strong reason for coupling these 2 huge beasts? longer analysis: Jira to GH Issues migration has started everywhere (66 as of now, if tracking is accurate [

Re: Maven 4.0.0 Release - Thoughts?

Le jeudi 22 mai 2025, 08:49:20 CEST Mark Derricutt a écrit : > On 22 May 2025 at 6:19:26 PM, Hervé Boutemy wrote: > > I don't get what plugin updates are expected: are there Maven 3 plugins > > known > > to fail on Maven 4? If yes, are they so many? > > That I’m not sure - since we can’t run our

Re: Maven 4.0.0 Release - Thoughts?

On 2025/05/21 09:05:07 Guillaume Nodet wrote: > Hi all, > > I have several significant features waiting as PRs (mixins and > cascading profiles), but I’ve decided to postpone them until 4.1.0. > For what it’s worth, several people, including the IntelliJ team, have > expressed concerns about 4.0.0

Re: Maven 4.0.0 Release - Thoughts?

On 22 May 2025 at 6:19:26 PM, Hervé Boutemy wrote: > I don't get what plugin updates are expected: are there Maven 3 plugins > known > to fail on Maven 4? If yes, are they so many? > That I’m not sure - since we can’t run our builds under Maven 4 (tiles, mixins, the problems of my ownn makings)

Re: Maven 4.0.0 Release - Thoughts?

+1 we need a release before adding new changes > world as well - or more than likely, a raft of third-party plugin updates. I don't get what plugin updates are expected: are there Maven 3 plugins known to fail on Maven 4? If yes, are they so many? I hope releasing Maven 4 will help clarify which

Re: Maven 4.0.0 Release - Thoughts?

Big +1 to that. The maven 4 cycle has stretched for a long time and having an actual release which can be targeted by the tool vendors would be a great thing. -h On Wed, May 21, 2025 at 2:05 AM Guillaume Nodet wrote: > Hi all, > > I have several significant features waiting as PRs (mixins and

Re: Maven 4.0.0 Release - Thoughts?

Hey, I‘ve lost the overview to the java 24 issues, but if I got it right the sisu 0.94 can handle it. So if we are fine on running on java 24 and our 4.x plugins (there are some in beta etc, look at the update parent to 44 of source-p for example) are final too, I think we are good to go. Why

Re: Maven 4.0.0 Release - Thoughts?

On 21 May 2025 at 9:05:07 PM, Guillaume Nodet wrote: I’d prefer to release 4.0.0 with a limited set of new features to > ensure stability and reserve the larger changes for 4.1.0, which we > could target for the end of year. This could also include the upgrade > to JDK 21 since JDK 25 should be

Re: Maven 4.0.0 Release - Thoughts?

Hi all, I have several significant features waiting as PRs (mixins and cascading profiles), but I’ve decided to postpone them until 4.1.0. For what it’s worth, several people, including the IntelliJ team, have expressed concerns about 4.0.0 being a moving target due to the continuous addition of n

Re: Maven 4.0.0 Release - Thoughts?

On 2025/05/21 06:11:42 Guillaume Nodet wrote: > Hey Maven Devs, > > We're gearing up to release a new version from the master branch. I'm > thinking we should go for 4.0.0 instead of rc-4. What do you all think? Any > feedback or ideas on the versioning or release plan? Let’s hear it! Slawek is w

Re: Maven 4.0.0 Release - Thoughts?

+1 (nb) Greatest release of them all! On Wed, May 21, 2025 at 08:21 Romain Manni-Bucau wrote: > +1 > > Romain Manni-Bucau > @rmannibucau | .NET Blog > | Blog > | Old > Blog

Re: Maven 4.0.0 Release - Thoughts?

+1 Romain Manni-Bucau @rmannibucau | .NET Blog | Blog | Old Blog | Github | LinkedIn | Book <

Re: Maven 4.0.0-rc-2 and m-install-p 4.0.0-beta-1

Right. I just thought that there was an exception to m-install-p (and m-deploy-p) that they needed to be v4 as there has been changes to build/consumer pom which they need to know about. That not being the case is nicely done! /Anders On Thu, Jan 23, 2025 at 8:43 PM Tamás Cservenák wrote: > htt

Re: Maven 4.0.0-rc-2 and m-install-p 4.0.0-beta-1

https://gist.github.com/cstamas/b0605a9fad09de4adcbd888baa4c This above is just to get the idea: so Maven N will support Maven Plugin N-1, or in other words, Maven 4 will fully support Maven 3 plugins (but not Maven2 plugins). T On Thu, Jan 23, 2025 at 8:15 PM Anders Hammar wrote: > > OK. I

Re: Maven 4.0.0-rc-2 and m-install-p 4.0.0-beta-1

OK. I incorrectly thought that I needed to use m-install-p v4 with Maven 4. I just tested with m-install-p 3.1.1 and see that it works. Thanks for clarifying! /Anders On Thu, Jan 23, 2025 at 11:35 AM Tamás Cservenák wrote: > Howdy, > > Yes, plugins are lagging, as we currently focus on core. >

Re: Maven 4.0.0-rc-2 and m-install-p 4.0.0-beta-1

Howdy, Yes, plugins are lagging, as we currently focus on core. Given it works with Maven 3 plugins as well... you can still use Maven 4 w/ Maven 3 plugins. T On Thu, Jan 23, 2025 at 10:23 AM Anders Hammar wrote: > > It seems in fact that m-install-p 4.0.0-beta-1 is incompatible with Maven > 4.

Re: Maven 4.0.0-rc-2 and m-install-p 4.0.0-beta-1

It seems in fact that m-install-p 4.0.0-beta-1 is incompatible with Maven 4.0.0 RCs. Using m-install-p 4.0.0-beta-2-SNAPSHOT from master seems to work though. m-install-p 4.0.0-beta-1 has a dependency to Maven 4.0.0-beta-2 and there have been some API changes since. So IMHO there is currently no e

Re: maven 4.0.0 new XML stuff

> Created https://issues.apache.org/jira/browse/MNG-7067 to start, now we have an umbrella let's refine the description if needed. Excellent and thanks. > regarding jgitver ... Do you have a stacktrace for this? there is no error/problem because it dumps the model manually to a pom.xml file and re

Re: maven 4.0.0 new XML stuff

Created https://issues.apache.org/jira/browse/MNG-7067 to start, now we have an umbrella let's refine the description if needed. Romain Manni-Bucau @rmannibucau | Blog | Old Blog | Github

Re: maven 4.0.0 new XML stuff

Thank you, now we have something to work on. polyglot should still work, but it looks like it is getting the wrong set of options. So that needs to be fixed. Please create an issue[1] regarding jgitver and don't see an issue at first glance. It is using MavenXpp3Reader, which is low level, no in

Re: maven 4.0.0 new XML stuff

Robert, Point is that without using in memory pom model, produced pom will always require rework to be properly consumed. We must avoid it I think and do what you said: read pom -> extend it -> make it immutable (optional for me) -> dump *this* model. This is what makes a consumable feature otherwi

Re: maven 4.0.0 new XML stuff

> You both keep talking about extensions, but I haven't touched that part. > I suggest to test current Maven 4 first and to find cases where those extensions don't work anymore. I do not know the exact internals of polyglot but for jgitver, in order to produce a pom-4.0.0.xml compliant file, either

Re: maven 4.0.0 new XML stuff

You both keep talking about extensions, but I haven't touched that part. I suggest to test current Maven 4 first and to find cases where those extensions don't work anymore. Next we can see if this makes sense or not and how to solve it. Robert On 5-1-2021 12:28:59, Matthieu Brouillard wrote: >

Re: maven 4.0.0 new XML stuff

> Currently the model is mutable and this causes issues. For me it is not the root cause, it does not help for sure but IMO the problem is more that there are currently several sources of trust : the POM & the pom.xml. Personally (only my opinion) I see no other way for the future of maven than t

Re: maven 4.0.0 new XML stuff

Hmm, extensions define this kind of lifecycle, at least the afterModelRead which is a hook before it could be immutable no? So not sure how it changes the issue, or do you push to drop extensions support? Romain Manni-Bucau @rmannibucau | Blog

Re: maven 4.0.0 new XML stuff

Currently the model is mutable and this causes issues. Instead I would like to see that once the BuildPlan is finished, the model becomes immutable. To give a concrete example: It must be possible for code generating goals to add dependencies.  Now, when using modello readers/writers you often

Re: maven 4.0.0 new XML stuff

So it seems we must enhance that read/write logic with these elements to make them usable: 1. Make it extension/Maven-IoC (even without extensions you can have the same issue with just guice components) friendly (code showing the bug is in a previous response) 2. Decide what is the produced pom, e

Re: maven 4.0.0 new XML stuff

> Can you give an example? Like Romain has shown: dynamically added dependencies or a version computation. > Most important is the support for CI-friendly versions But if extensions dynamically compute and set the versions in the POM using the API, the changes will not be reflected. That's why tod

Re: maven 4.0.0 new XML stuff

answers are below. Robert On 4-1-2021 16:52:23, Matthieu Brouillard wrote: @Robert nothing is broken atm, the changes for consumer/build are currently behind your feature flag. Robert Scholte:  It is active by default, so it is actually not hidden. But as I feared previously, and as Romain po

Re: maven 4.0.0 new XML stuff

@Robert nothing is broken atm, the changes for consumer/build are currently behind your feature flag. But as I feared previously, and as Romain pointed it, by working at XML level (and not at POM level) the produced consumer pom does not reflect changes from extensions. I really thought that all t

Re: maven 4.0.0 new XML stuff

Hmm, I don't get a few things of this IT: 1. the formatting seems not expected even if valid (the comments are finishing with the first tag for example "--> { final Dependency dependency = new Dependency(); dependency.setGroupId("junit"); dependency.setArtifactI

Re: maven 4.0.0 new XML stuff

https://github.com/apache/maven-integration-testing/tree/master/core-it-suite/src/test/resources/mng-6957-buildconsumer is the most complete IT On 4-1-2021 12:59:51, Romain Manni-Bucau wrote: Le lun. 4 janv. 2021 à 12:36, Robert Scholte a écrit : > There's just one thing I want to say: > I'm ha

Re: maven 4.0.0 new XML stuff

Le lun. 4 janv. 2021 à 12:36, Robert Scholte a écrit : > There's just one thing I want to say: > I'm having trouble with the term "broken". > Well, literally meant broken as decorelated from the user intent and extension model. Anyway, didn't intend to blame but more identify the blockers for a

Re: maven 4.0.0 new XML stuff

There's just one thing I want to say: I'm having trouble with the term "broken". If a Maven project could be built with M3.6.3, it can still be built with M4. If not, it is either regression (MNG-6957, MNG-7063) which must be fixed, or it requires changes to a plugin for understandable reasons (ma

Re: maven 4.0.0 new XML stuff

Le dim. 3 janv. 2021 à 19:04, Robert Scholte a écrit : > I don't remember all those details anymore, because I hit those in the > beginning. > Trying things over and over again I decided that this is probably the most > successful approach. > > > What of the goals was to keep the pom.xml as is as

Re: maven 4.0.0 new XML stuff

I don't remember all those details anymore, because I hit those in the beginning. Trying things over and over again I decided that this is probably the most successful approach. What of the goals was to keep the pom.xml as is as much as possible. We can only decide for the specific Maven elemen

Re: maven 4.0.0 new XML stuff

Le dim. 3 janv. 2021 à 16:18, Robert Scholte a écrit : > > So what I was expecting was: raw xml model -> converted to unified > consumed model -> extensions -> model processing. > > This is only the build pom part. You're missing the consume part, where > the xml is distributed. > Yes but with p

Re: maven 4.0.0 new XML stuff

> So what I was expecting was: raw xml model -> converted to unified consumed >model -> extensions -> model processing. This is only the build pom part. You're missing the consume part, where the xml is distributed. Build is raw + enrich, consumer is raw + enrich + reduce (removing relativePath

Re: maven 4.0.0 new XML stuff

Hi all, I kind of join Matthieu thoughts there, there is no point to work at xml level to create the consumed pom - comments is not a point since it can commonly/easily refer to a dropped part of the pom so they should be stripped. Current extension model got proven adapted and adopted, using a lo

Re: maven 4.0.0 new XML stuff

Hi Matthieu, As you understand, something had to be changed to move Maven forward. I've decided to pick up that challenge and came up with the current solution. My main concerns was that I wanted to keep the fileModel as much as is. That includes the license, comments and element order.  This inf

Re: maven 4.0.0 new XML stuff

Thanks Robert for the video link. I fully understand the rationales behind the separation of build/consumer pom and the video provides some insights on it and you explain the actual implementation to introduce this change. Still I do not fully understand why it was decided to work on top of XML by

Re: maven 4.0.0 new XML stuff

Yes, I think so. Per artifact, if it includes the POM, we need to decide which one to include. It should never be the raw one (e.g. it might miss the version to its parent), most of the time the consumer POM, but sometimes the build POM. Robert On 1-1-2021 15:14:52, Gary Gregory wrote: Great ide

Re: maven 4.0.0 new XML stuff

Great idea to record this video, TY! I would guess that the javadoc plugin would change in the same way the source plugin needs to change, right? Gary On Thu, Dec 31, 2020, 13:01 Robert Scholte wrote: > I've made a recording[1] about it, which hopefully answers most questions. > > Robert > > [

Re: maven 4.0.0 new XML stuff

I've made a recording[1] about it, which hopefully answers most questions. Robert [1] https://youtu.be/KDAmlNKZJto On 31-12-2020 16:18:57, Matthieu Brouillard wrote: > Not exactly sure what work you mean everything related to maven-xml: Build/ConsumerPomXMLFilterxxx, Build/ConsumerModelSourcexx

Re: maven 4.0.0 new XML stuff

> Not exactly sure what work you mean everything related to maven-xml: Build/ConsumerPomXMLFilterxxx, Build/ConsumerModelSource and the transformer stuff. Especially, when looking at classes like CiFriendlyXMLFilter, I would have thought that such things could have been done elsewhere, working

Re: maven 4.0.0 new XML stuff

Hello, Not exactly sure what work you mean and I fully agree that using a core model should still be the API for plugins and extensions to work with, however specifically the consumer POM integrates with so many external ecosystems, I would expect it to be defined in terms of XML Schema with ex

Re: Maven 4.0.0

I would like to have SCM Hook from CI or SCM Agent. Maven 4 should run only changed modules similar to "mvn -pl...". If we get a list of changed files, the Eclipse compiler might be faster and then only tests for changed classes will run. Then I would like to have clean and site executed on entire

Re: Maven 4.0.0

Hi Jörg, fully unrelated (cross topic). About tycho I often end up doing a custom script hacking the resolvedArtifacts and using a local cache (m2 fake repo) because tycho plugin is way to slow in practise. It can look like https://github.com/Talend/component-runtime/blob/master/component-studio-in

Re: Maven 4.0.0

Hi Romain, Am Thu, 09 Nov 2017 09:32:12 +0100 schrieb Romain Manni-Bucau: > FYI opened https://github.com/apache/maven/pull/136 for the MNG-6302 > (guess we can switch from thread to discuss it now?) How is this issue related with my topic regarding improved Tycho support in Maven 4.0.0? Regar

Re: Maven 4.0.0

On 12 Nov 2017, at 23:06, Stephen Connolly wrote: > That could end up duplicating the local repo cache... unless we default the > cache to ~/.m2/repository anyway... otoh a concurrency safe local repo > cache may mandate a new location... but double the downloads for inter-op > with older Maven in

Re: Maven 4.0.0

Keep in mind, Maven is not the only pom consumer. Expression changes outside the pom are probably fine. Expression changes inside the pom will probably require the 4.0.0 (optional scope) feature to bring flatten Maven plugin type features to first class core support (ie deploy the pom with new prop

Re: Maven 4.0.0

On Sun 12 Nov 2017 at 07:41, Chris Graham wrote: > required: > - *everything* in settings.xml can be put in a profile section in > settings.xml. > > I often move around/between projects and having to redo mirrors section, > and unable to add servers into the profile section for clarity is a pain

Re: Maven 4.0.0

One more: Better support for classifiers. ideally be able to reference them via a {$project.classifier} type of construct, esp so I can use/reference them in assemble transformations. This might be able to be done without bumping to V4 though. On Sun, Nov 12, 2017 at 6:41 PM, Chris Graham wrot

Re: Maven 4.0.0

required: - *everything* in settings.xml can be put in a profile section in settings.xml. I often move around/between projects and having to redo mirrors section, and unable to add servers into the profile section for clarity is a pain. For me, it's just a matter of convienence. On Sat, Nov 4,

Re: Maven 4.0.0

FYI opened https://github.com/apache/maven/pull/136 for the MNG-6302 (guess we can switch from thread to discuss it now?) Romain Manni-Bucau @rmannibucau | Blog | Old Blog | Github | LinkedIn 2017-11-09 9:30 GMT+01:00 Jörg Schaible : > Hi, > > one wish: Better integration with pom-less Tycho pr

  1   2   >