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
>
>

Reply via email to