> Sounds like it breaks concurrency uofront scheduling no?
For sure it will interfere with what the scheduler think is the best
strategy, but not be a concern of the scheduler as it was explicitly
request to change the build order.
> When I had to do that I was referencing projects between them in deps
Two problems:
1) Users don't want to do that (because "the framework" already knows)
2) Users probably don't know this (Why X requires Y?)
So from the users point of view, there is no (known) dependency between
two reactor projects A + B and thus we can assume they are listed in the
modules as A, B and as there are no other relation maven chooses the
same order here an builds A, B
Now A is running and e.g. generates some code where it finds out that B
produces some kind of artifact that will be required for a later phase
(e.g. compile, package, ...) then it would be required to halt at the
current phase and wait until B is finished building.
Am 11.09.22 um 08:49 schrieb Romain Manni-Bucau:
Hi
Sounds like it breaks concurrency uofront scheduling no?
When I had to do that I was referencing projects between them in deps to
enforce the scheduling to be right even if deps wefe dynamic, is it an
option?
Le dim. 11 sept. 2022 à 07:43, Christoph Läubrich <m...@laeubi-soft.de> a
écrit :
I'd like to discuss a certain problem I recently came across and if it
might could be considered as an enhancement:
Currently there are two components that influence when a certain reactor
project is build:
1) GraphBuilder computes the Project relation graph
2) Builder executes the Graph of projects (either serial or in parallel)
While this works most of the time (and one can enhance these strategies
by a core-extension) I came across some situations where I need to
influence this while the build is running to enforce some not known in
advance dependencies in a local manner.
So I came across the idea if it would be possible to have a method in
the Builder (or a new interface) called "buildProject(MavenProject)" (or
similar) that triggers/wait for the specified project before returning.
It should simply work the following way:
- If the project was already executed before, simply return
- If the project is currently executing (e.g. in another thread) wait
until it is finished
- If the project was not yet scheduled for execution, execute it in the
current thread
That way it would be possible to even executes "dynamic" project
dependencies, e.g ones that are only discovered in the generate-sources
phase but would be required in the compile/test phase as well as
requirements where I for example want to make sure all projects with a
certain property are executed before I take several actions without
encoding this in the dependencies of a project directly.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
