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