Le dim. 11 sept. 2022 à 09:05, Christoph Läubrich <m...@laeubi-soft.de> a écrit :
> > 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. > For me it means the user knows the dep as any generating plugin can imply deps (like jaxws implies jaxb for ex even if module is jaxb free with that plugin). Last note would that we already support what you want to do with a maven extension overwriting (decorating) the scheduler+executor but still looks ackward and breaking well known tooling like IDE to not use an explicit graph with the dep trick IMHO. > > 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 > >
