Le ven. 17 juil. 2020 à 09:31, Hervé BOUTEMY <herve.bout...@free.fr> a
écrit :
> Le vendredi 17 juillet 2020, 08:22:10 CEST Romain Manni-Bucau a écrit :
> > Le ven. 17 juil. 2020 à 00:03, Hervé BOUTEMY <herve.bout...@free.fr> a
>
> > > I don't get what "mvn my-test" means: there is no "my-test" phase
> > > and I don't understand how your custom lifecycle shares some phases
> with
> > > default lifecycle, but has some specific ones: I fear there will be
> > > conflicts
> >
> > There is a my-test in the custom binding defined in the sample.
> > In current flavor it replaces default one so no issue.
> I don't understand yet, I'll dig into that
>
>
> > > and it's not a "fake" module: it's a module to define the "series of
> > > plugins
> > > executions that are expected to be able to be composed
> > > yes, it's not a pure internal module, not producing by itself any code
> > > compilation
> >
> > Ok, then it defeats one of the original goal (to not modify the reactor
> and
> > add a module on the critical path of the project).
> >
> > > > So IMHO this is not an option for one of the original goals to not
> > > > modify
> > > > the user reactor.
> > >
> > > there is a goal to not modify the user reactor? why?
> >
> > Cause:
> > 1. it slows down the overall build significatively compared to an
> extension
> > 2. it makes the project more noisy in all env (console can be ok but IDE
> > too - don't think 1 module project but ~30 modules ones, if you add 5
> > modules for that, it is a lot of noise for nothing)
> > 3. keep in mind we enrich maven setup so we inject something already
> > "built" virtually, we don't need to be in the build itself
> > 4. from a design perspective, it is not part of the build so shouldn't be
> > there
> > 5. it shouldn't be installed + deployed and it shouldn't require to fake
> > the distribution management to something like target
> thanks for taking time to write such detailed analysis: I better
> understand
> what you want to avoid
>
> I'll add one key aspect to me: putting in a pom is a way to reuse. I hope
> aggregation solution will not only permit ad-hoc configuration.
>
Hmm, technically al these solutions are strictly equivalent:
1. using an extension to read files "somewhere"
2. using a plugin and injecting all the needing conf (extremely we can say
give part of maven IoC control) in <configuration>) in <configuration>
3. using a pom as a template ("import")
But agree that having a built-in solution is saner so I suppose we should
find how to do it in Maven N+1 and backport it as possible with
modelversion=4.
>
> FYI, when working on build vs consumer POM, one conclusion was that most
> POMs
> in a repository are consumer POM = POMs of libraries that will be used as
> dependencies, but a few ones are build POM:
> - parent POM
> - BOM POM, to permit dependencyManagement import
> that's not a surprise that reusable plugin/pluginManagement configuration
> would
> require to publish a build POM to the repository
> But I see your point that in an ad-hoc non-reusable configuration, this
> extra
> build POM currently costs a build module, which should be avoided
>
Thinking out loud - another time sorry, a custom packaging - as a marker -
can enable to handle it in maybe more cleanly (overriding or patching some
component):
<packaging>build</packaging>
This would let maven know it is a build module then the lifecycle can be -
hope we can bypass reuse of existing plugin to make it faster and avoid a
tons of mojo instantiation:
1. if only descriptors -> inject them and bypass most of module handling
2. if java code -> build and add it as an exploded extension (directly in
maven-core)? (nice to have, likely just a thought and not needed for this
thread topic but I see cases it can enable in the future)
The advantage is that this wouldn't be a real reactor module but strictly
equivalent to an extension.
Limitation will be that it will not be able to use all the pom strength
(same limitation than afterMavenProjectRead hook more or less) but I think
it is more than enough for this kind of need already.
Also sounds like a way to do it today and tomorrow without much breaking
change.
Think it enables to really define custom phases and therefore to handle
plugin list merge properly (as being global).
Finally it avoids to have to predefine a tons of phases "in case of"
because you can add the phases you need when required and not upfront so
build can stay lean.
>
> > >
> > > the fact that we need more phases is another issue: I was not trying to
> > > solve
> > > that one, that is IMHO completely orthogonal to the build composition
> > > objective
> > > of course, mixing build composition and additional phases brings a lot
> of
> > > power
> >
> > Yes and no.
> > Yes cause technically you are right - but see you start stacking
> solutions
> > instead of having one and since it is user facing it sounds wrong and
> > overcomplex.
> > No because as an user you don't care there are bindings, lifecycles and
> > packaging, you only care about your build graph, anything outside this
> > primary concept is internal and shouldn't be exposed (in the extension).
> IMHO, there are 2 levels of users: pure user, who only build and don't
> want to
> understand, and more power user who adds new build structure
> the second type of users has to see some inernals: but I get your point,
> he
> should not see too much
> He's not a plugin developer...
>
Agree, think the <packaging>build</> kind of move in that direction.
>
> FYI, I'll be out for a few days, so may not answer: this is not because of
> lack of interest, but lack of connectivity :)
>
> And I'll now need some time to dig, test, propose test implementations...
>
> Nice discussion, I hope others can follow and we'll end up with something
> to
> merge
>
> Regards,
>
> Hervé
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
