Hi Tamás,
Is there an Maven issue out there to track this issue (and your fix for it)? I
haven’t been able to get access to the Maven Jira project so have not been able
to raise the issue myself.
Thanks,
Joe
On 2024/02/08 10:09:31 Tamás Cservenák wrote:
> Seems we are on track with this. To
Hey,
Yeah, exactly: ideally we want module-b to be resolved in different ways within
the same reactor. I noticed that this kind of already happens (albeit in a
simpler way): In my reproducer testing if you play with the test timeouts to
dictate the module build order then with the same modules
Howdy,
Well, sadly, Maven currently has no means to make one module "this and
that" at the same time.
It is either in the reactor or is out of it.
To me, it sounds like you want one reactor, but where module-b is "out" and
'in", at the same time (within same session)
T
On Thu, Feb 8, 2024 at
Hey,
We don't need the module-b jar built in the reactor to be included in the war
if the changes made in module-b won't affect the war. Instead, in this
scenario, we're fine with using a jar resolved from the local repository. The
requisites for this scenario are:
* Any change made to
Hej,
yes, basically the "hack" is well described by you:
- it retains "full' reactor project
- introduces "needs build" on project
- when it comes to building, it skips the project if flag set
This results that module-b -> app link is not lost.
And as for your parallelization request: the truth
Hi Tamás,
Thank you for hacking around this so rapidly. I am not familiar with the maven
code base, so let me know if I have misinterpreted the change: Is your hack to:
1. Retain the full multi-module build dependency graph such that the build
graph always remains consistent regardless of
