Le dim. 11 sept. 2022 à 11:24, Christoph Läubrich <m...@laeubi-soft.de> a écrit :
> > 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). > > This will only work if the dependencies are static and can not come from > the reactor and can be determined *before* the data is actually generated. > > Currently the data is generating beforehand, then the dynamic > dependencies are injected, and then the actual build starts, where the > data is then possibly used, but that has several drawbacks: > > 1) If I execute a phase that actually will never execute the generate > phase (e.g. validate) data still needs to be processed > 2) Build is blocked until computation completes and can not proceed > beforehand > 3) it is not possible to depend on data generated during the build as > everything is required to be present before the build start > > > Last note would that we already support what you want to do with > > a maven extension overwriting (decorating) the scheduler+executor > > You can not really decorate plexus components (or I don't know about > it), also an extension has the drawback here that it requires/forces all > projects in the reactor to use that new strategy and can't be declared > in the pom. > An extension gives you the power to change all maven ioc so you can for sure even if not always trivial. > > still looks ackward and breaking well known tooling like IDE to not > use an explicit > > I don't get the point about IDEs as they usually either call maven or do > build the projects by other means. > Nop, only one of the 3 well known ide and likely the least used ;). > > > Am 11.09.22 um 10:30 schrieb Romain Manni-Bucau: > > 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 > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >