Ah, too bad. I thought it was relevant. Perhaps I can take a look at this
with Maarten Mulders, but that will not be in the coming week at least.
Op di 18 mei 2021 om 21:34 schreef Guillaume Nodet :
> I just tried with master and the problem is the same.
> The reason is that in my use case, the f
I just tried with master and the problem is the same.
The reason is that in my use case, the forked goals are executed before the
standard executions, and not even in the same project.
Le mar. 18 mai 2021 à 20:41, Martin Kanters a
écrit :
> Not sure how I've missed this post. Have you tried this
Hi,
We solved 28 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317529&version=12346637&styleName=Text
There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317529%20AND%20resolution%20%3D%20Unresolved%20ORDER%20B
Not sure how I've missed this post. Have you tried this build with the
master build of Maven?
MNG-6566 [1] should prevent any unnecessary double executions, thus
optimizing the buildplan.
I'm interested if this will solve the problem at hand.
Martin
[1] https://issues.apache.org/jira/browse/MNG-6
Maybe not that many people are using parallel builds...
Imho, the PR should be merged. I've created
https://issues.apache.org/jira/browse/MNG-7157 to provide a better API
and deprecate the getArtifacts() method which is flawed (see discussion on
the PR https://github.com/apache/maven/pull/413#issu
I'm looking a bit at aggregator goals.
At first glance, it seems most of the problem comes from the fact that the
build ordering is done mostly per-project. This causes obvious problems
for aggregators when a mojo needs a given phase to be executed for all
children before it can run (for example t
