Hi Guillaume,
[3] is definitely different from your original problem, but it should
explain (together with [2]) why [1] did not remove the second "compile" in
your problem case.
I wanted to understand why MNG-6566 didn't apply to it. I agree that if it
would have applied (removing 2nd compile in "
I implemented a simple locking mechanism which seems to work correctly for
parallel builds:
https://github.com/apache/maven/pull/476/
Le mar. 1 juin 2021 à 18:19, Guillaume Nodet a écrit :
>
> Le sam. 29 mai 2021 à 10:13, Martin Kanters a
> écrit :
>
>> So we took a look at this. First we wan
Le sam. 29 mai 2021 à 10:13, Martin Kanters a
écrit :
> So we took a look at this. First we wanted to know why the forked
> goals were executed multiple times, while MNG-6566 [1] should have taken
> care of that. But it seems that that only optimizes duplicate goals in the
> context of one projec
So we took a look at this. First we wanted to know why the forked goals
were executed multiple times, while MNG-6566 [1] should have taken care of
that. But it seems that that only optimizes duplicate goals in the context
of one project. I attempted to explain that [2]. We created a ticket for
opti
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
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
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
I've raised https://issues.apache.org/jira/browse/MNG-7156
Le mer. 12 mai 2021 à 17:57, Falko Modler a écrit :
> Hi Guillaume,
>
> aggregation goals and parallel builds in combination are a bit of a
> mess, e.g.:
>
> - https://issues.apache.org/jira/browse/MNG-6843
> - https://github.com/apache/
Hi Guillaume,
aggregation goals and parallel builds in combination are a bit of a
mess, e.g.:
- https://issues.apache.org/jira/browse/MNG-6843
- https://github.com/apache/maven/pull/413
- https://www.mail-archive.com/dev@maven.apache.org/msg123439.html
Cheers,
Falko
Am 12.05.2021 um 17:25 sch
Hi
I've analyzed a bug reported on mvnd this afternoon (
https://github.com/mvndaemon/mvnd/issues/408). It appears that the parent
pom executes the javadoc aggregate goal, which forks the lifecycle of the
children modules in order to compile the sources. In a traditional build,
this does not cau
11 matches
Mail list logo
