Le mardi 14 juillet 2020, 20:36:38 CEST Romain Manni-Bucau a écrit : > Le mar. 14 juil. 2020 à 20:01, Hervé BOUTEMY <herve.bout...@free.fr> a > > écrit : > > in this example, you strictly define a new "my-mapping" packaging, like > > done in Maven core for every default packagings [1] with documentation in > > [2]: don't call it bindings, but simply "packaging-bindings.xml" and it's > > more clear > > Nop, the packaging is declined in a lifecycle implicitly (which enables to > do "mvn my-test") otherwise it wouldn't work with just a packaging. uh, a trick :/ is it different from full lifecycle definition with plugin bindings, like site and clean lifecycles? https://github.com/apache/maven/blob/master/maven-core/src/main/resources/META-INF/plexus/components.xml#L66
> > > the more I think about it, the more I feel that what we need is > > pluginManagement and eventually plugins import, like we did in the past > > for > > dependencyManagement [3] > > > > This would permit: > > - to import plugins versions form an external source, > > - share plugins configurations and executions either in the reactor, > > either from outside > > > > I still don't know if this import should be triggered as a > > dependencyManagement scope, like "import" scope was added > > Well, yes and no because it still relies on the inheritance compared to the > composition which keeps the big drawback to easily break (just add a new > module needing something a little bit different, or just try to exclude one > of the plugins automatically imported - it is in dependency model but not > in plugin one). inheritance? no, aggregation: the plugin or pluginManagement import can be done by aggregation in any POM, not through parent > It would also require to be able to import a chain of plugins and not just > a plugin from a management block or all plugin from the same block (as done > with the packaging in the sample), otherwise you are back to redefining all > plugins in your new module or to be forced to define a new parent to > isolate the children from this shared declarations. plugin import would import every plugin from the imported POM: no per-plugin import > I'm also not sure how you would merge plugins (let say I import > frontend-plugins and java-plugins, how do I define their order in main and > test phases)? Back to the lifecycle merge issue, no? I still don't see any issue here, but just choice of phases that match required order > > So it can be about defining a new <lifecycleManagement> section containing > this mix of packaging+binding definition (the overlap is certain so we > shouldnt force to define both IMHO) but it also means waiting for another > major and does not change much the design which is about being able to > define a new binding+packaging. The part which can be smoother though is > the fact to patch an existing packaging even if I'm not yet seeing it > working. > The more I'm thinking about it, more I think the patch option is about > defining edges of the build graph (frontend:npm-build "runs after" > "process-classes" for example) patching will require to define the language or configuration to set the order: not sure it is reasonable > whereas the packaging+binding option is > about defining the global graph (of one new module type) explicitly. you're defining a new lifecycle with its plugin bindings: let's call it like it is, please your extension is about being able to do it directly in reactor, instead of creating an extension in a separate build > > > Or if we could do something at dependencyManagement and/or dependency > > level. > > Given "extensions" is a boolean represented as a String (for inheritance > > reasons), why not use this String to have support > > <extensions>import</extensions> that imports content? > > > > Regards, > > > > Hervé > > > > > > [1] https://maven.apache.org/ref/3.6.3/maven-core/default-bindings.html > > > > [2] https://maven.apache.org/ref/3.6.3/maven-core/default-bindings.html > > > > [3] https://maven.apache.org/ref/3.6.3/maven-core/default-bindings.html > > > > Le dimanche 12 juillet 2020, 19:27:28 CEST Romain Manni-Bucau a écrit : > > > Just to illustrate the proposal - likely to rework on config side to > > > > avoid > > > > > to kind of expose maven IoC (as we were playing with application > > > contexts > > > 10 years ago ;)) here is a small repo: > > > https://github.com/rmannibucau/custom-lifecycle-extension. > > > > > > A sample project ([1]) defines a custom packaging ([2]) which takes its > > > definition in mappings.xml ([3]). This sample just renames some phase > > > and > > > replace one plugin by another for demo purposes but it is what I had in > > > mind to give the user enough flexibility for its build. > > > A complete alternative which works too - = achieves the same goal - is > > > to > > > enable the user to define the build chain somewhere (like <plugins> but > > > order is the straight definition order for example) and autowire > > > > everything > > > > > as expected through an extension to avoid all the headaches associated > > > > with > > > > > the inheritance and other indirections making the pom execution hard to > > > follow. The issue with this one is to lose the aliasing feature. > > > > > > [1] > > > > https://github.com/rmannibucau/custom-lifecycle-extension/tree/master/samp > > le> > > > [2] > > > > https://github.com/rmannibucau/custom-lifecycle-extension/blob/master/samp > > le> > > > /pom.xml#L10 [3] > > > > https://github.com/rmannibucau/custom-lifecycle-extension/blob/master/samp > > le> > > > /.extensions/custom/mappings.xml > > > > > > Romain Manni-Bucau > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > > <https://rmannibucau.metawerx.net/> | Old Blog > > > <http://rmannibucau.wordpress.com> | Github < > > > > https://github.com/rmannibucau> > > > > > | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > > > > > < > > > > https://www.packtpub.com/application-development/java-ee-8-high-performanc > > e > > > > > Le dim. 12 juil. 2020 à 18:10, Romain Manni-Bucau > > > <rmannibu...@gmail.com> > > > > a > > > > > écrit : > > > > Side topic - still thinking out loud - which is also covered by custom > > > > lifecycles: aliases. A common need is to alias a complex command ("mvn > > > > docker" executing "mvn dependency:build-classpath git-commit:generate > > > > docker:bundle docker-java:cds" to give an idea), with default or > > > > merged > > > > lifecycles it is hard to make relevant. Indeed, an option is a custom > > > > plugin or extension reading aliases somewhere and hacking > > > > lifecycleStater > > > > > > to stash/pop the real goal to execute it, works but is a workaround > > > > whereas > > > > custom lifecycle gives a proper solution to that. > > > > > > > > What I'm unsure today is if the custom lifecycle must be fully > > > > explicit or > > > > > > can insert phases and goals in an existing lifecycle ("patch mode"), > > > > not > > > > > > sure what is the simplest for users. > > > > > > > > Romain Manni-Bucau > > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > > > <https://rmannibucau.metawerx.net/> | Old Blog > > > > <http://rmannibucau.wordpress.com> | Github > > > > <https://github.com/rmannibucau> | LinkedIn > > > > <https://www.linkedin.com/in/rmannibucau> | Book > > > > < > > > > https://www.packtpub.com/application-development/java-ee-8-high-performan > > > > > > ce> > > > > > > > > > > > > Le dim. 12 juil. 2020 à 11:58, Romain Manni-Bucau < > > > > rmannibu...@gmail.com> > > > > > > a écrit : > > > >> Le dim. 12 juil. 2020 à 11:26, Hervé BOUTEMY <herve.bout...@free.fr> > > > > a > > > > > >> écrit : > > > >>> Le dimanche 12 juillet 2020, 10:37:36 CEST Romain Manni-Bucau a > > > > écrit : > > > >>> > Le sam. 11 juil. 2020 à 23:01, Hervé BOUTEMY < > > > > herve.bout...@free.fr> a > > > > > >>> > écrit : > > > >>> > > Le samedi 11 juillet 2020, 12:55:37 CEST Romain Manni-Bucau a > > > > écrit : > > > >>> > > > Le sam. 11 juil. 2020 à 12:09, Hervé BOUTEMY < > > > >>> > > > >>> herve.bout...@free.fr> a > > > >>> > > > >>> > > > écrit : > > > >>> > > > > are really your plugin bindings so specific to your build > > > > that > > > > > >>> they > > > >>> > > > >>> > > could > > > >>> > > > > > >>> > > > > not be reused and need full ad-hoc definition? > > > >>> > > > > > > >>> > > > Think so > > > >>> > > > > > > >>> > > > > I imagined to provide composite packaging: > > > >>> > > > > <packaging>war+front+living-doc+docker</packaging> > > > >>> > > > > > > > >>> > > > > in fact, "front", "living-doc", "docker" could provide > > > > secondary > > > > > >>> sets > > > >>> > > > >>> > > of > > > >>> > > > > > >>> > > > > reusable plugins bindings: each build would compose (with > > > > "+") > > > > > >>> based > > > >>> > > > >>> > > > > on > > > >>> > > > > his > > > >>> > > > > requirements > > > >>> > > > > > > >>> > > > Ok but "front" means already 5-6 different bindings at least > > > >>> > > > > > >>> > > nice, that proves that this "sub-packaging" is useful: what > > > > would be > > > > > >>> the > > > >>> > > > >>> > > bindings, please, to make this case very concrete? > > > >>> > > > > > >>> > > > and > > > >>> > > > "living-doc" is per project by design (depends your stack, > > > > leads > > > > > >>> > > > to > > > >>> > > > different set of plugins). > > > >>> > > > > > >>> > > let's dig a little bit: can you provide a few examples of stacks > > > > and > > > > > >>> > > corresponding bindings, please? > > > >>> > > perhaps "living-doc" is too generic, and should be more specific > > > > per > > > > > >>> stack > > > >>> > > > >>> > Jar+front=jar lifecycle + frontend:npm-install + > > > >>> > frontend:npm-build > > > >>> > > > >>> in such a case, where it's only 1 single plugin, we don't even need > > > > the > > > > > >>> "sub- > > > >>> packaging" feature: adding the plugin will use its default bindings > > > >>> (just tell > > > >>> if that one is not clear: I'm not sure if this is clearly > > > >>> documented) > > > >> > > > >> For all these plugins there is no default binding or it does nuot > > > > match > > > > > >> mentionned lifecycle so it must still be customized. > > > >> Can be done in a pom but in multimodule it is still nice to be able > > > >> to > > > >> share it between 3-4 modules - this is why the proposed extension > > > > helps a > > > > > >> lot and enables to migrate tooling (yarn to npm for ex) trivially. > > > >> To rephrase it: it is to make maven align on modern dev where > > > > inheritance > > > > > >> is dropped in favor of composition because it is more flexible and > > > > easy > > > > > >> to > > > >> maintain. > > > >> > > > >>> > Then you can add openapi.json generation with > > > >>> > > > >>> geronimo-openapi-maven-plugin > > > >>> same as before: adding a plugin should do the job of default goal > > > >>> bindings > > > >> > > > >> When used in 1 module yes, otherwise it enforce to either create a > > > > fake > > > > > >> parent (broken design imho) or duplicate the plugin instead of being > > > > able > > > > > >> to reuse a standard *project specific* way of doing (which is super > > > >> important for consistency). > > > >> > > > >>> > You have the same with a war instead of a jar. > > > >>> > > > >>> thisis why "sub-packaging" is useful: it can be used whatever the > > > > main > > > > > >>> packaging is. And default goal bindings when is a plugin is added is > > > >>> also > > > >>> independant of the packaging > > > >>> > > > >>> > Ablut living doc it can be several exec + openapi patch (either > > > > with a > > > > > >>> json > > > >>> > > > >>> > plugin or something else like ant or even another exec or > > > >>> > > > >>> gplus:execute for > > > >>> > > > >>> > what I saw). Add github-page or cms deployment, jira chabgelog > > > >>> > > > >>> generation > > > >>> > > > >>> > (saw it with public and private plugins) and doc content itself > > > > can be > > > > > >>> home > > > >>> > > > >>> > made (exec), jbake based, antora based (frontend but not the same > > > >>> > > > >>> config > > > >>> > > > >>> > than build one) or even jekyll based for what I saw. > > > >>> > > > >>> parent POM, or reactor pom is already there for that: I don't > > > > understand > > > > > >>> what > > > >>> a new configuration file will add > > > >>> > > > >>> > Indeed npm can be yarn too and you can add npm-test and > > > >>> > potentially > > > >>> > > > >>> npm-e2e > > > >>> > > > >>> > to the combinations > > > >>> > > > > >>> > > > I envision a reusable solution can be a thing but it is way > > > > more > > > > > >>> complex > > > >>> > > > >>> > > > than having these dynamic bindings which are straight forward > > > > on > > > > > >>> user > > > >>> > > > >>> > > side > > > >>> > > > > > >>> > > > so I prefer to let the user adapt maven to his need rather > > > >>> > > > than > > > >>> > > > the > > > >>> > > > opposite. > > > >>> > > > > > > >>> > > > Also note that your proposal makes us moving one step forward > > > > but > > > > > >>> we > > > >>> > > > >>> > > > stay > > > >>> > > > blocked: how do you merge phases and plugin order? This can > > > > also > > > > > >>> depends > > > >>> > > > >>> > > on > > > >>> > > > > > >>> > > > projetcs and "+" only allows one order whereas order can be > > > >>> > > > >>> different > > > >>> > > > >>> > > > between main and test plugins so you would need a complete > > > >>> > > > dsl, > > > >>> > > > >>> not that > > > >>> > > > >>> > > > easy compared to being explicit imo. > > > >>> > > > > > >>> > > sure, this part is only one step > > > >>> > > I need examples of such "merge phase" and order requirements to > > > >>> > > > >>> better see > > > >>> > > > >>> > > what mechanisms would be useful > > > >>> > > > > >>> > Start by what i mentionned just before, jar+frontend which can be > > > >>> > simpkified by > > > >>> > > > > >>> > Compile-class+npm-run+test-java+npm-test > > > >>> > > > > >>> > Compile-class runs before test-java > > > >>> > Npm-run runs before npm-test > > > >>> > All combinations respecting that are used (if one phase generates > > > > code > > > > > >>> for > > > >>> > > > >>> > the other using typescript-generator plugin or the opposite). > > > >>> > > > >>> classical phases are sufficient: I don't get what is missing > > > >> > > > >> No, this is sufficient when you add one or two plugins without > > > > profiles, > > > > > >> otherwise you can do it but it is a mess - and to be honest, even if > > > >> I > > > >> know > > > >> how it works and I made it working, I always reworked my build to > > > > bypass > > > > > >> maven and add my own substeps in such cases cause in terms of > > > >> maintainance > > > >> it is too costly and rigid. > > > >> > > > >> Stephen proposal was helping even if priorities are not explicit > > > > enough > > > > > >> IMO -a chain is saner for me - but was a nice workaround to have it > > > > today > > > > > >> without breaking pom versioning. > > > >> > > > >> If I want to solve it cleanly today i would do a packaging extension > > > > with > > > > > >> some autoconfig extension based on properties. > > > >> This thread is just about avoiding to create an useless project with > > > >> a > > > >> different lifecycle just for that purpose and enable it to be done > > > > inline > > > > > >> in the project. > > > >> > > > >> But thinking out loud, it can be done with a plugin extension too and > > > > be > > > > > >> defined in the plugin conf too instead of another folder. > > > >> > > > >>> > > > > this could be injected by the LifecycleBindingsInjector [1] > > > >>> > > > > > > > >>> > > > > WDYT? > > > >>> > > > > > > > >>> > > > > Regards, > > > >>> > > > > > > > >>> > > > > Hervé > > > >>> > > > > > > > >>> > > > > [1] > > > > https://github.com/apache/maven/blob/master/maven-core/src/main/java/org > > > > > >>> /a > > > >>> > > > >>> > > > >>> pache/maven/model/plugin/DefaultLifecycleBindingsInjector.java#L63> > > > >>> > > > >>> > > > > Le vendredi 10 juillet 2020, 19:33:35 CEST Romain > > > > Manni-Bucau a > > > > > >>> écrit > > > >>> > > > >>> > > > > > Looked a bit on how to impl this kind of extension and it > > > >>> > > > >>> would help > > > >>> > > > >>> > > if > > > >>> > > > > > >>> > > > > > maven wouldn't assume everything is hardcoded in > > > >>> > > > >>> components.xml (or > > > >>> > > > >>> > > eq) > > > >>> > > > > > >>> > > > > or > > > >>> > > > > > > > >>> > > > > > if sisu would enable to reuse its plexus scanner which has > > > > a > > > > > >>> very > > > >>> > > > >>> > > > > > low > > > >>> > > > > > visibility today. It is also weird to not have access to > > > > the > > > > > >>> guice > > > >>> > > > >>> > > > > injector > > > >>> > > > > > > > >>> > > > > > in components and have to go through the plexuscontainer > > > >>> > > > > > to > > > >>> > > > >>> lookup > > > >>> > > > >>> > > > > > beans. > > > >>> > > > > > > > > >>> > > > > > As code often says more than words, here a small hello > > > > world > > > > > >>> showing > > > >>> > > > >>> > > > > > that > > > >>> > > > > > reusing this part of maven "core" is not that trivial: > > > >>> > > > > > > > > >>> > > > > > @Component(role = AbstractMavenLifecycleParticipant.class) > > > >>> > > > > > public class CustomLifecycleExtension extends > > > >>> > > > > > AbstractMavenLifecycleParticipant { > > > >>> > > > > > > > > >>> > > > > > @Inject > > > >>> > > > > > private PlexusContainer container; > > > >>> > > > > > > > > >>> > > > > > @Override > > > >>> > > > > > public void afterProjectsRead(final MavenSession > > > > session) > > > > > >>> throws > > > >>> > > > >>> > > > > > MavenExecutionException { > > > >>> > > > > > > > > >>> > > > > > final Path root = > > > > session.getRequest().getMultiModuleProjectDirectory().toPath() > > > > > >>> > > > > > ; > > > >>> > > > > > > > > >>> > > > > > final Path configFolder = > > > >>> > > > > > root.resolve(".extensions/custom"); > > > >>> > > > > > > > > >>> > > > > > final Path mappings = > > > >>> > > > >>> configFolder.resolve("mappings.xml"); > > > >>> > > > >>> > > > > > if (Files.exists(mappings)) { > > > >>> > > > > > > > > >>> > > > > > final ComponentSetDescriptor componentSet = > > > >>> > > > > > > > > >>> > > > > > readAs(mappings, ComponentSetDescriptor.class, null); > > > >>> > > > > > > > > >>> > > > > > System.out.println(componentSet); > > > >>> > > > > > > > > >>> > > > > > } > > > >>> > > > > > > > > >>> > > > > > super.afterProjectsRead(session); > > > >>> > > > > > > > > >>> > > > > > } > > > >>> > > > > > > > > >>> > > > > > private <T> T readAs(final Path path, final Class<T> > > > > type, > > > > > >>> final > > > >>> > > > >>> > > > > > String wrapper) { > > > >>> > > > > > > > > >>> > > > > > try { > > > >>> > > > > > > > > >>> > > > > > final ClassRealm container = > > > >>> > > > > > > > >>> > > > > this.container.getContainerRealm(); > > > >>> > > > > > > > >>> > > > > > final Class<?> converterType = container > > > >>> > > > > > > > > >>> > > > > > .loadClass("org.eclipse.sisu.plexus.PlexusBeanConverter"); > > > >>> > > > >>> final > > > >>> > > > >>> > > > > > Class<?> > > > >>> > > > > > typeLiteralType = container > > > >>> > > > >>> .loadClass("com.google.inject.TypeLiteral"); > > > >>> > > > >>> > > > > > final Object converter = > > > >>> > > > > > > > >>> > > > > this.container.lookup(converterType); > > > >>> > > > > > > > >>> > > > > > return > > > >>> > > > > > type.cast(converterType.getMethod("convert", > > > >>> > > > > > > > > >>> > > > > > typeLiteralType, String.class).invoke( > > > >>> > > > > > > > > >>> > > > > > converter, > > > >>> > > > > > typeLiteralType.getMethod("get", > > > >>> > > > > > > > > >>> > > > > > Class.class).invoke(null, type), > > > >>> > > > > > > > > >>> > > > > > (wrapper != null ? "<" + wrapper + ">" > > > >>> > > > >>> "") + > > > >>> > > > >>> > > > > > new > > > >>> > > > >>> String(Files.readAllBytes(path), > > > >>> > > > >>> > > > > > StandardCharsets.UTF_8) > > > >>> > > > >>> .replaceFirst("<\\?[^>]+\\?>", > > > >>> > > > >>> > > > > > "").trim() + (wrapper != null ? "</" + wrapper + ">" : > > ""))); > > > > > >>> > > > > > } > > > >>> > > > > > catch > > > >>> > > > > > (final Exception e) { > > > >>> > > > > > > > > >>> > > > > > throw new IllegalStateException(e); > > > >>> > > > > > > > > >>> > > > > > } > > > >>> > > > > > > > > >>> > > > > > } > > > >>> > > > > > > > > >>> > > > > > } > > > >>> > > > > > > > > >>> > > > > > Indeed it can't work since componentsetdescriptor uses > > > >>> > > > > > > > >>> > > > > plexusconfiguration > > > >>> > > > > > > > >>> > > > > > which is not instantiable but it shows the workarounds > > > > needed > > > > > >>> to > > > >>> > > > >>> > > > > > just > > > >>> > > > > > lookup plexus converter and reuse plexus xml binding. > > > >>> > > > > > > > > >>> > > > > > The code should just look like that IMHO: > > > >>> > > > > > > > > >>> > > > > > @Component(role = AbstractMavenLifecycleParticipant.class) > > > >>> > > > > > public class CustomLifecycleExtension extends > > > >>> > > > > > AbstractMavenLifecycleParticipant { > > > >>> > > > > > > > > >>> > > > > > @Inject > > > >>> > > > > > private PlexusBeanConverter converter; > > > >>> > > > > > > > > >>> > > > > > @Override > > > >>> > > > > > public void afterProjectsRead(final MavenSession > > > > session) > > > > > >>> throws > > > >>> > > > >>> > > > > > MavenExecutionException { > > > >>> > > > > > > > > >>> > > > > > final Path root = > > > > session.getRequest().getMultiModuleProjectDirectory().toPath() > > > > > >>> > > > > > ; > > > >>> > > > > > > > > >>> > > > > > final Path configFolder = > > > >>> > > > > > root.resolve(".extensions/custom"); > > > >>> > > > > > > > > >>> > > > > > final Path mappings = > > > >>> > > > >>> configFolder.resolve("mappings.xml"); > > > >>> > > > >>> > > > > > if (Files.exists(mappings)) { > > > >>> > > > > > > > > >>> > > > > > final ComponentSetDescriptor componentSet = > > > >>> > > > > > > > > >>> > > > > > readAs(mappings, ComponentSetDescriptor.class, null); > > > >>> > > > > > > > > >>> > > > > > System.out.println(componentSet); > > > >>> > > > > > > > > >>> > > > > > } > > > >>> > > > > > > > > >>> > > > > > super.afterProjectsRead(session); > > > >>> > > > > > > > > >>> > > > > > } > > > >>> > > > > > > > > >>> > > > > > private <T> T readAs(final Path path, final Class<T> > > > > type, > > > > > >>> final > > > >>> > > > >>> > > > > > String wrapper) { > > > >>> > > > > > > > > >>> > > > > > try { > > > >>> > > > > > > > > >>> > > > > > return type.cast( > > > > converter.convert(TypeLiteral.get(type), > > > > > >>> > > > > > (wrapper != null ? "<" + > > > > wrapper + > > > > > >>> ">" : > > > >>> > > "") > > > >>> > > > > > >>> > > > > + > > > >>> > > > > > > > >>> > > > > > new > > > >>> > > > > > > > > >>> > > > > > String(Files.readAllBytes(path), StandardCharsets.UTF_8) > > > >>> > > > > > > > > >>> > > > > > .replaceFirst("<\\?[^>]+\\?>", "").trim() + > > > >>> > > > > > > > > >>> > > > > > (wrapper != null ? > > > > "</" + > > > > > >>> > > > > > wrapper > > > >>> > > > > > > > > >>> > > > > > + ">" : ""))); > > > >>> > > > > > > > > >>> > > > > > } catch (final Exception e) { > > > >>> > > > > > > > > >>> > > > > > throw new IllegalStateException(e); > > > >>> > > > > > > > > >>> > > > > > } > > > >>> > > > > > > > > >>> > > > > > } > > > >>> > > > > > > > > >>> > > > > > } > > > >>> > > > > > > > > >>> > > > > > Once this part is fixed (using a custom parser) the next > > > > one > > > > > >>> is how > > > >>> > > > >>> > > to > > > >>> > > > > > >>> > > > > > contribute global components from an extension. > > > >>> > > > > > > > > >>> > > > > > I'll ignore the parsing - currently I have a custom sax > > > > parser > > > > > >>> but I > > > >>> > > > >>> > > > > > hope > > > >>> > > > > > to be able to drop it soon - it is quite easy to > > > >>> > > > > > contribute > > > >>> > > > >>> back the > > > >>> > > > >>> > > new > > > >>> > > > > > >>> > > > > > mapping - note i dropped the lifecycle particupant which > > > > does > > > > > >>> not > > > >>> > > > >>> > > really > > > >>> > > > > > >>> > > > > > help there cause only contributing mappings when the > > > > extension > > > > > >>> is > > > >>> > > > >>> > > > > > created > > > >>> > > > > > makes sense: > > > >>> > > > > > > > > >>> > > > > > @Component(role = StartupContributor.class, > > > >>> > > > >>> instantiationStrategy = > > > >>> > > > >>> > > > > > Strategies.LOAD_ON_START) > > > >>> > > > > > public class StartupContributor { > > > >>> > > > > > > > > >>> > > > > > @Inject > > > >>> > > > > > private MavenSession session; > > > >>> > > > > > > > > >>> > > > > > @Inject > > > >>> > > > > > private PlexusContainer container; > > > >>> > > > > > > > > >>> > > > > > @PostConstruct > > > >>> > > > > > public void init() { > > > >>> > > > > > > > > >>> > > > > > final Path root = > > > > session.getRequest().getMultiModuleProjectDirectory().toPath() > > > > > >>> > > > > > ; > > > >>> > > > > > > > > >>> > > > > > final Path configFolder = > > > >>> > > > > > root.resolve(".extensions/custom"); > > > >>> > > > > > > > > >>> > > > > > final Path mappings = > > > >>> > > > >>> configFolder.resolve("mappings.xml"); > > > >>> > > > >>> > > > > > if (Files.exists(mappings)) { > > > >>> > > > > > > > > >>> > > > > > final DefaultLifecycleMapping mapping = > > > >>> > > > > > > > > >>> > > > > > *loadOrParse(*mappings*)*; > > > >>> > > > > > > > > >>> > > > > > container.addComponent(mapping, > > > >>> > > > >>> LifecycleMapping.class, > > > >>> > > > >>> > > > > > "my-mapping"); > > > >>> > > > > > > > > >>> > > > > > } > > > >>> > > > > > > > > >>> > > > > > } > > > >>> > > > > > > > > >>> > > > > > } > > > >>> > > > > > > > > >>> > > > > > Then we can put the new mapping as packaging and voilà :). > > > >>> > > > > > > > > >>> > > > > > If you have tips for the parsing it is welcomed otherwise > > > > I'll > > > > > >>> > > continue > > > >>> > > > > > >>> > > > > to > > > >>> > > > > > > > >>> > > > > > play with my custom parser. > > > >>> > > > > > > > > >>> > > > > > Romain Manni-Bucau > > > >>> > > > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > > >>> > > > > > <https://rmannibucau.metawerx.net/> | Old Blog > > > >>> > > > > > <http://rmannibucau.wordpress.com> | Github < > > > >>> > > > > > > > >>> > > > > https://github.com/rmannibucau> > > > >>> > > > > > > > >>> > > > > > | LinkedIn <https://www.linkedin.com/in/rmannibucau> | > > > > Book > > > > > >>> > > > > > < > > > > https://www.packtpub.com/application-development/java-ee-8-high-performa > > > > > >>> nc > > > >>> > > > >>> > > > > e > > > >>> > > > > > > > >>> > > > > > Le dim. 5 juil. 2020 à 11:09, Romain Manni-Bucau < > > > >>> > > > > > >>> > > rmannibu...@gmail.com> > > > >>> > > > > > >>> > > > > a > > > >>> > > > > > > > >>> > > > > > écrit : > > > >>> > > > > > > Here is a sample public build: > > > >>> > > > > https://github.com/talend/component-runtime > > > >>> > > > > > > > >>> > > > > > > Interesting modules are - just listing one per type - if > > > >>> > > > >>> master > > > >>> > > > >>> > > looks > > > >>> > > > > > >>> > > > > > > weird tag 1.1.19 can be a fallback: > > > >>> > > > > > > > > > >>> > > > > > > 1. > > > > https://github.com/Talend/component-runtime/blob/master/component-starte > > > > > >>> r-> > > > >>> > > > >>> > > > > > > server/pom.xml 2. > > > > https://github.com/Talend/component-runtime/blob/master/documentation/po > > > > > >>> m > > > >>> . > > > >>> > > > >>> > > > > > > xml 3. > > > > https://github.com/Talend/component-runtime/blob/master/images/component > > > > > >>> -s > > > >>> > > > >>> > > > > > > erver-image/pom.xml > > > >>> > > > > > > > > > >>> > > > > > > Side note being some other - private :( - module do all > > > > the > > > > > >>> > > > > > > 3 > > > >>> > > > > > >>> > > things > > > >>> > > > > > >>> > > > > in a > > > >>> > > > > > > > >>> > > > > > > single module - and indeed faking module for build > > > >>> > > > >>> constraints is > > > >>> > > > >>> > > not > > > >>> > > > > > >>> > > > > an > > > >>> > > > > > > > >>> > > > > > > option. > > > >>> > > > > > > > > > >>> > > > > > > Hope it helps. > > > >>> > > > > > > > > > >>> > > > > > > Le dim. 5 juil. 2020 à 11:02, Hervé BOUTEMY > > > >>> > > > > > > <herve.bout...@free.fr> > > > >>> > > > > > >>> > > a > > > >>> > > > > > >>> > > > > > > écrit : > > > >>> > > > > > >> Le samedi 4 juillet 2020, 23:15:19 CEST Romain > > > > Manni-Bucau > > > > > >>> > > > > > >> a > > > >>> > > > > > >>> > > écrit : > > > >>> > > > > > >> > Le sam. 4 juil. 2020 à 18:09, Stephen Connolly < > > > >>> > > > > > >> > > > > >>> > > > > > >> > stephen.alan.conno...@gmail.com> a écrit : > > > >>> > > > > > >> > > On Sat 4 Jul 2020 at 16:54, Romain Manni-Bucau < > > > >>> > > > > > > > >>> > > > > rmannibu...@gmail.com > > > >>> > > > > > > > >>> > > > > > >> > > wrote: > > > >>> > > > > > >> > > > Le sam. 4 juil. 2020 à 16:38, Stephen Connolly < > > > >>> > > > > > >> > > > > > > >>> > > > > > >> > > > stephen.alan.conno...@gmail.com> a écrit : > > > >>> > > > > > >> > > > > On Sat 4 Jul 2020 at 10:21, Romain Manni-Bucau > > > >>> > > > > > >> > > > > < > > > >>> > > > > > >> > > > >>> > > > > > >> rmannibu...@gmail.com> > > > >>> > > > > > >> > > > >>> > > > > > >> > > > > wrote: > > > >>> > > > > > >> > > > > > Well, there are two points I'd like to > > > > emphasis: > > > >>> > > > > > >> > > > > > 1. I dont think we should wait for 2 majors > > > >>> > > > > > >> > > > > > to > > > >>> > > > >>> get that > > > >>> > > > >>> > > as > > > >>> > > > > > >>> > > > > > >> > > > > > a > > > >>> > > > > > >> > > > > > feature, > > > >>> > > > > > >> > > > > > > > >>> > > > > > >> > > > > would > > > >>> > > > > > >> > > > > > > > >>> > > > > > >> > > > > > be too late IMHO > > > >>> > > > > > >> > > > > > > > >>> > > > > > >> > > > > Well does my dynamic phases PR do what you > > > >>> > > > > > >> > > > > need? > > > >>> > > > > > >> > > > > > > >>> > > > > > >> > > > Partly if you think to priority one, it moves the > > > >>> > > > >>> issue a > > > >>> > > > >>> > > bit > > > >>> > > > > > >>> > > > > > >> further > > > >>> > > > > > >> > > > >>> > > > > > >> > > > due > > > >>> > > > > > >> > > > to priority usage which is not great in practice > > > >>> > > > >>> compare to > > > >>> > > > >>> > > > > names + > > > >>> > > > > > > > >>> > > > > > >> > > > requires to use 100, 200 etc to be able to inject > > > >>> > > > >>> plugin > > > >>> > > > >>> > > > > > >> > > > between > > > >>> > > > > > >> > > > two > > > >>> > > > > > >> > > > > > >>> > > > > > >> > > others > > > >>> > > > > > >> > > > > > >>> > > > > > >> > > > in children with the project becoming more > > > > complex. > > > > > >>> Think > > > >>> > > > >>> > > > > > >> > > > we > > > >>> > > > > > > > >>> > > > > must > > > >>> > > > > > > > >>> > > > > > >> have > > > >>> > > > > > >> > > > >>> > > > > > >> > > > an > > > >>> > > > > > >> > > > explicit control here even with complex > > > > hierarchies. > > > > > >>> > > > > > >> > > If you need that much control then you’re doing > > > >>> > > > >>> something > > > >>> > > > >>> > > wrong. > > > >>> > > > > > >>> > > > > > >> > > How often do you need more than 3-4 plugin > > > > executions > > > > > >>> > > > > > >> > > in > > > >>> > > > > > >>> > > strict > > > >>> > > > > > >>> > > > > > >> ordered > > > >>> > > > > > >> > > > >>> > > > > > >> > > succession? > > > >>> > > > > > >> > > > > >>> > > > > > >> > All my projects not being libraries since ~7 years. > > > >>> > > > >>> Frontend is > > > >>> > > > >>> > > > > often 3 > > > >>> > > > > > > > >>> > > > > > >> > exec, living doc is often 4-5 exec, docker is often > > > > 3-4 > > > > > >>> exec > > > >>> > > > >>> > > > > > >> > too > > > >>> > > > > > > > >>> > > > > (needs > > > >>> > > > > > > > >>> > > > > > >> > some computation steps for cds or build time > > > >>> > > > >>> precomputation > > > >>> > > > >>> > > things) > > > >>> > > > > > >>> > > > > > >> > plus > > > >>> > > > > > >> > custom resources, git integration meta, custom > > > > artifact > > > > > >>> > > > > > >> > attachement, > > > >>> > > > > > >> > > > >>> > > > > > >> etc... > > > >>> > > > > > >> I like this approach: can we share a demo project to > > > > have a > > > > > >>> > > concrete > > > >>> > > > > > >>> > > > > > >> case? > > > >>> > > > > > >> > > > >>> > > > > > >> > These are very common use cases today in the same > > > > build. > > > > > >>> It is > > > >>> > > > >>> > > key > > > >>> > > > > > >>> > > > > to > > > >>> > > > > > > > >>> > > > > > >> keep > > > >>> > > > > > >> > > > >>> > > > > > >> > a single build orchestrator (mvn) for team sharing > > > > and CI > > > > > >>> > > > > > >> > industrialization. Issue being each project set it up > > > >>> > > > > > >>> > > differently > > > >>> > > > > > >>> > > > > and > > > >>> > > > > > > > >>> > > > > > >> > making it generic is often overcomplex (living doc > > > > can be > > > > > >>> jbake > > > >>> > > > >>> > > > > plugin > > > >>> > > > > > > > >>> > > > > > >> or a > > > >>> > > > > > >> > > > >>> > > > > > >> > plain mvn exec:java or a groovy script etc... > > > > depending > > > > > >>> doc > > > >>> > > > >>> > > output > > > >>> > > > > > >>> > > > > and > > > >>> > > > > > > > >>> > > > > > >> > reusability of the code+libs). With software > > > >>> > > > > > >> > lifecycle > > > >>> > > > >>> passing > > > >>> > > > >>> > > from > > > >>> > > > > > >>> > > > > > >> years > > > >>> > > > > > >> > > > >>> > > > > > >> > to months we are in a more dynamic and changing > > > > ecosystem > > > > > >>> our > > > >>> > > > >>> > > > > beloved > > > >>> > > > > > > > >>> > > > > > >> build > > > >>> > > > > > >> > > > >>> > > > > > >> > tool should align on IMHO. > > > >>> > > > > > >> > > > >>> > > > > > >> I suppose we all agree from very high level point of > > > > view: > > > >>> IMHO, > > > >>> > > > >>> > > we > > > >>> > > > > > >>> > > > > now > > > >>> > > > > > > > >>> > > > > > >> need > > > >>> > > > > > >> to dig a little more in detail on typical cases, with > > > >>> > > > >>> sample demo > > > >>> > > > >>> > > > > builds. > > > >>> > > > > > > > >>> > > > > > >> Then > > > >>> > > > > > >> we'll work on solutions. > > > >>> > > > > > >> > > > >>> > > > > > >> > > That sounds like a dedicated plugin use case > > > >>> > > > > > >> > > > > >>> > > > > > >> > This is why i want a generic extension as solution, > > > > each > > > > > >>> > > > > > >> > project > > > >>> > > > > > > > >>> > > > > have > > > >>> > > > > > > > >>> > > > > > >> its > > > >>> > > > > > >> > > > >>> > > > > > >> > specificities and standardizing it is hard and likely > > > >>> > > > >>> adds too > > > >>> > > > >>> > > much > > > >>> > > > > > >>> > > > > > >> > complexity compared to let the user enriching default > > > >>> > > > >>> phases > > > >>> > > > >>> > > (can > > > >>> > > > > > >>> > > > > be a > > > >>> > > > > > > > >>> > > > > > >> > merge of 2 packagings instead of a new one fully > > > >>> > > > > > >> > defined). > > > >>> > > > > > >> > > > >>> > > > > > >> yes, looks like adding "sub-packaging"s for additional > > > >>> > > > > > >> build > > > >>> > > > > > >>> > > aspects > > > >>> > > > > > >>> > > > > > >> (frontend, living doc, container, ...), taking care of > > > >>> > > > >>> eventual > > > >>> > > > >>> > > > > > >> interactions > > > >>> > > > > > >> between each one > > > >>> > > > > > >> > > > >>> > > > > > >> > If I stick to plain maven and want a clean build > > > > without > > > > > >>> > > > > workarounds I > > > >>> > > > > > > > >>> > > > > > >> must > > > >>> > > > > > >> > > > >>> > > > > > >> > write plugins+extensions for each of the apps - > > > > plugins > > > > > >>> and ext > > > >>> > > > >>> > > > > must be > > > >>> > > > > > > > >>> > > > > > >> > reusable or not be IMHO, sounds not great whereas > > > > maven > > > > > >>> > > backbone is > > > >>> > > > > > >>> > > > > > >> > very > > > >>> > > > > > >> > good, this is why I want to push it to the next step > > > > to > > > > > >>> keep a > > > >>> > > > >>> > > high > > > >>> > > > > > >>> > > > > > >> quality > > > >>> > > > > > >> > > > >>> > > > > > >> > unique (in terms of #tools) build for projects. > > > >>> > > > > > >> > > > > >>> > > > > > >> > I dont have big blockers to do it without patching > > > > maven > > > > > >>> itself > > > >>> > > > >>> > > so > > > >>> > > > > > >>> > > > > will > > > >>> > > > > > > > >>> > > > > > >> not > > > >>> > > > > > >> > > > >>> > > > > > >> > spend much energy if idea is not liked but I hope > > > > maven > > > > > >>> tackles > > > >>> > > > >>> > > it > > > >>> > > > > > >>> > > > > some > > > >>> > > > > > > > >>> > > > > > >> day > > > >>> > > > > > >> > > > >>> > > > > > >> > in a built in fashion (which means better IDE and > > > >>> > > > >>> ecosystem > > > >>> > > > >>> > > > > integration > > > >>> > > > > > > > >>> > > > > > >> > even if personally I dont abuse of that). > > > >>> > > > > > >> > > > >>> > > > > > >> from experience, sharing a solution before sharing > > > > issues > > > > > >>> that > > > >>> > > > >>> > > > > > >> the > > > >>> > > > > > >> solution is > > > >>> > > > > > >> expected to solve makes it hard to get consensus. > > > >>> > > > > > >> You shared the high level issue: that's great. > > > >>> > > > > > >> Now we must share sample builds. > > > >>> > > > > > >> And work on solutions. > > > >>> > > > > > >> I'm all in > > > >>> > > > > > >> > > > >>> > > > > > >> Regards, > > > >>> > > > > > >> > > > >>> > > > > > >> Hervé > > > >>> > > > > > >> > > > >>> > > > > > >> > > > > > 2. Pom model is based on inheritance whereas > > > >>> > > > > > >> > > > > > years > > > >>> > > > > > >>> > > showed > > > >>> > > > > > >>> > > > > > >> > > > > > composition > > > >>> > > > > > >> > > > > > > >>> > > > > > >> > > > and > > > >>> > > > > > >> > > > > > > >>> > > > > > >> > > > > > reuse is saner so IMHO it does not belong to > > > > pom > > > > > >>> but > > > >>> > > > >>> > > .mvn > > > >>> > > > > > >>> > > > > > >> > > > > Your proposal would only work if all projects > > > >>> > > > >>> shared the > > > >>> > > > >>> > > same > > > >>> > > > > > >>> > > > > > >> > > > > packaging > > > >>> > > > > > >> > > > > > > >>> > > > > > >> > > > as > > > >>> > > > > > >> > > > > > > >>> > > > > > >> > > > > Hervé pointed out that the lifecycle is pulled > > > > in > > > > > >>> based > > > >>> > > > >>> > > > > > >> > > > > on > > > >>> > > > > > >> > > > >>> > > > > > >> packaging. > > > >>> > > > > > >> > > > >>> > > > > > >> > > > No cause you define the packaging to use in the > > > > pom > > > > > >>> > > already - > > > >>> > > > > > >>> > > > > > >> > > > since > > > >>> > > > > > >> > > > > > >>> > > > > > >> > > maven > > > >>> > > > > > >> > > > > > >>> > > > > > >> > > > 2 IIRC - so you can define as much packagings as > > > > you > > > > > >>> want > > > >>> > > > >>> > > > > > >> > > > in > > > >>> > > > > > > > >>> > > > > .mvn. > > > >>> > > > > > > > >>> > > > > > >> To be > > > >>> > > > > > >> > > > >>> > > > > > >> > > > concrete, it just enables to have an exploded > > > >>> > > > >>> extension in > > > >>> > > > >>> > > the > > > >>> > > > > > >>> > > > > > >> project > > > >>> > > > > > >> > > > >>> > > > > > >> > > > instead of requiring it to be packaged as a jar. > > > > Does > > > > > >>> not > > > >>> > > > >>> > > > > reinvent > > > >>> > > > > > > > >>> > > > > > >> the > > > >>> > > > > > >> > > > >>> > > > > > >> > > > wheel ;). > > > >>> > > > > > >> > > > > > > >>> > > > > > >> > > > > What you probably want is > > > >>> > > > >>> .mvn/${packaging}/lifecycle.xml > > > >>> > > > >>> > > so > > > >>> > > > > > >>> > > > > you > > > >>> > > > > > > > >>> > > > > > >> can > > > >>> > > > > > >> > > > >>> > > > > > >> > > > > override custom > > > >>> > > > > > >> > > > > > > > >>> > > > > > >> > > > > A bug you may encounter is where phase names > > > >>> > > > > > >> > > > > are > > > >>> > > > > > >> > > > > not > > > >>> > > > > > >>> > > common > > > >>> > > > > > >>> > > > > > >> across the > > > >>> > > > > > >> > > > >>> > > > > > >> > > > > reactor > > > >>> > > > > > >> > > > > > > >>> > > > > > >> > > > Yep, build/extension must enforce common > > > > checkpoints > > > > > >>> > > (package, > > > >>> > > > > > >>> > > > > > >> install, > > > >>> > > > > > >> > > > >>> > > > > > >> > > > deploy out of my head) for all modules. Not a big > > > >>> > > > >>> deal if > > > >>> > > > >>> > > > > validated > > > >>> > > > > > > > >>> > > > > > >> > > during > > > >>> > > > > > >> > > > > > >>> > > > > > >> > > > initialize phase I think. > > > >>> > > > > > >> > > > > > > >>> > > > > > >> > > > > > Le sam. 4 juil. 2020 à 10:19, Robert Scholte > > > >>> > > > > > >> > > > > > < > > > >>> > > > > > >> > > > >>> > > > > > >> rfscho...@apache.org> > > > >>> > > > > > >> > > > >>> > > > > > >> > > a > > > >>> > > > > > >> > > > > > >>> > > > > > >> > > > > > écrit : > > > >>> > > > > > >> > > > > > > Stephen had an idea for it in Model > > > > 5.0.0[1], > > > > > >>> and > > > >>> > > > >>> > > IIRC I > > > >>> > > > > > >>> > > > > > >> still had > > > >>> > > > > > >> > > > >>> > > > > > >> > > my > > > >>> > > > > > >> > > > > > >>> > > > > > >> > > > > > > concerns. > > > >>> > > > > > >> > > > > > > It is still a draft with a lot of ideas, > > > > that > > > > > >>> hasn't > > > >>> > > > >>> > > > > really > > > >>> > > > > > > > >>> > > > > > >> been > > > >>> > > > > > >> > > > >>> > > > > > >> > > > > > discussed > > > >>> > > > > > >> > > > > > > > > >>> > > > > > >> > > > > > > yet, because it was still out of reach. > > > >>> > > > > > >> > > > > > > However, we're getting closer > > > >>> > > > > > >> > > > > > > > > > >>> > > > > > >> > > > > > > Robert > > > >>> > > > > > >> > > > > > > > > > >>> > > > > > >> > > > > > > > > > >>> > > > > > >> > > > > > > [1] > > > > https://cwiki.apache.org/confluence/display/MAVEN/POM+Model+Version+5.0. > > > > > >>> 0 > > > >>> > > > >>> > > > > > >> # > > > >>> > > > > > >> > > > >>> > > > > > >> > > POMModelVersion5.0.0-%3Cproject%3Eelement> > > > >>> > > > > > >> > > > > > >>> > > > > > >> > > > > > > On 4-7-2020 09:03:08, Romain Manni-Bucau < > > > >>> > > > > > >> > > > >>> > > > > > >> rmannibu...@gmail.com> > > > >>> > > > > > >> > > > >>> > > > > > >> > > > > wrote: > > > >>> > > > > > >> > > > > > > I agree I mixed both in my > > > > explanation....cause > > > > > >>> they > > > >>> > > > >>> > > only > > > >>> > > > > > >>> > > > > > >> > > > > > > make > > > >>> > > > > > >> > > > > > >>> > > > > > >> > > sense > > > >>> > > > > > >> > > > > > >>> > > > > > >> > > > > > > together for a build as shown by the > > > > pre/post > > > > > >>> > > recurrent > > > >>> > > > > > >>> > > > > > >> request > > > >>> > > > > > >> > > > >>> > > > > > >> > > which > > > >>> > > > > > >> > > > > > >>> > > > > > >> > > > > > aims > > > >>> > > > > > >> > > > > > > > > >>> > > > > > >> > > > > > > to enrich the lifecycle to bind custom > > > > plugins. > > > > > >>> > > > > > >> > > > > > > Today projects are no more just about > > > > creating > > > > > >>> a jar > > > >>> > > > >>> > > > > > >> > > > > > > - > > > >>> > > > > > >> > > > > > > war > > > >>> > > > > > >> > > > >>> > > > > > >> are no > > > >>> > > > > > >> > > > >>> > > > > > >> > > > more > > > >>> > > > > > >> > > > > > > >>> > > > > > >> > > > > > > about java etc... - most of the time > > > > (frontend, > > > > > >>> > > > > > >> > > > > > > living > > > >>> > > > > > > > >>> > > > > doc, > > > >>> > > > > > > > >>> > > > > > >> build > > > >>> > > > > > >> > > > >>> > > > > > >> > > > time > > > >>> > > > > > >> > > > > > > >>> > > > > > >> > > > > > > generation, security validation, ....). > > > > Indeed > > > > > >>> you > > > >>> > > > >>> > > > > > >> > > > > > > can > > > >>> > > > > > > > >>> > > > > force > > > >>> > > > > > > > >>> > > > > > >> to > > > >>> > > > > > >> > > > >>> > > > > > >> > > bind > > > >>> > > > > > >> > > > > > >>> > > > > > >> > > > > > > plugins to existing phases but it is quite > > > >>> > > > > > >> > > > > > > hard, > > > >>> > > > > > >>> > > unatural > > > >>> > > > > > >>> > > > > and > > > >>> > > > > > > > >>> > > > > > >> > > rarely > > > >>> > > > > > >> > > > > > >>> > > > > > >> > > > > > > maintainable in time: whatever you do, you > > > > want > > > > > >>> a > > > >>> > > > >>> > > custom > > > >>> > > > > > >>> > > > > > >> packaging > > > >>> > > > > > >> > > > >>> > > > > > >> > > > > using > > > >>> > > > > > >> > > > > > > > >>> > > > > > >> > > > > > a > > > >>> > > > > > >> > > > > > > > > >>> > > > > > >> > > > > > > custom lifecycle (to be able to run > > > > separately > > > > > >>> phases > > > >>> > > > >>> > > of > > > >>> > > > > > >>> > > > > the > > > >>> > > > > > > > >>> > > > > > >> build > > > >>> > > > > > >> > > > >>> > > > > > >> > > - > > > >>> > > > > > >> > > > > > >>> > > > > > >> > > > > and > > > >>> > > > > > >> > > > > > > > >>> > > > > > >> > > > > > > sometimes independently, mvn frontend not > > > >>> > > > >>> depending > > > >>> > > > >>> > > > > > >> > > > > > > of > > > >>> > > > > > >> > > > > > > mvn > > > >>> > > > > > >> > > > >>> > > > > > >> package > > > >>> > > > > > >> > > > >>> > > > > > >> > > or > > > >>> > > > > > >> > > > > > >>> > > > > > >> > > > > mvn > > > >>> > > > > > >> > > > > > > > >>> > > > > > >> > > > > > > compile would be neat but not required for > > > > me). > > > > > >>> > > > > > >> > > > > > > So the extension i have in mind will handle > > > >>> > > > >>> both or > > > >>> > > > >>> > > > > wouldnt > > > >>> > > > > > > > >>> > > > > > >> > > > > > > be > > > >>> > > > > > >> > > > > > > >>> > > > > > >> > > > usable. > > > >>> > > > > > >> > > > > > > >>> > > > > > >> > > > > > > About loosing the convention, after > > > >>> > > > > > >> > > > > > > fighting > > > >>> > > > >>> for 7 > > > >>> > > > >>> > > years > > > >>> > > > > > >>> > > > > to > > > >>> > > > > > > > >>> > > > > > >> not > > > >>> > > > > > >> > > > >>> > > > > > >> > > > respect > > > >>> > > > > > >> > > > > > > >>> > > > > > >> > > > > > it, > > > >>> > > > > > >> > > > > > > > > >>> > > > > > >> > > > > > > I think the ecosystem changed and we must > > > >>> > > > >>> accept it > > > >>> > > > >>> > > > > > >> > > > > > > as > > > >>> > > > > > > > >>> > > > > bazel > > > >>> > > > > > > > >>> > > > > > >> and > > > >>> > > > > > >> > > > >>> > > > > > >> > > > gradle > > > >>> > > > > > >> > > > > > > >>> > > > > > >> > > > > > do. > > > >>> > > > > > >> > > > > > > > > >>> > > > > > >> > > > > > > Does not mean we break ourself, we keep our > > > >>> > > > >>> default, > > > >>> > > > >>> > > it > > > >>> > > > > > >>> > > > > just > > > >>> > > > > > > > >>> > > > > > >> means > > > >>> > > > > > >> > > > >>> > > > > > >> > > an > > > >>> > > > > > >> > > > > > >>> > > > > > >> > > > > > > application must be able to redefining its > > > > own > > > > > >>> > > > > > >> lifecycle+packaging > > > >>> > > > > > >> > > > >>> > > > > > >> > > > > (which > > > >>> > > > > > >> > > > > > > > >>> > > > > > >> > > > > > > is a pair named a build ;)). > > > >>> > > > > > >> > > > > > > > > > >>> > > > > > >> > > > > > > Think we can't stack plugin on a single > > > > phase > > > > > >>> > > > > > >> > > > > > > anymore, > > > >>> > > > > > > > >>> > > > > having > > > >>> > > > > > > > >>> > > > > > >> 5+ > > > >>> > > > > > >> > > > >>> > > > > > >> > > > > plugins > > > >>> > > > > > >> > > > > > > > >>> > > > > > >> > > > > > on > > > >>> > > > > > >> > > > > > > > > >>> > > > > > >> > > > > > > pre-package is very hard to maintain and > > > > share > > > > > >>> in a > > > >>> > > > >>> > > team > > > >>> > > > > > >>> > > > > > >> > > > > > > - > > > >>> > > > > > >> > > > >>> > > > > > >> plus it > > > >>> > > > > > >> > > > >>> > > > > > >> > > > > doesnt > > > >>> > > > > > >> > > > > > > > >>> > > > > > >> > > > > > > really makes sense on a build point of > > > >>> > > > > > >> > > > > > > view. > > > >>> > > > > > >> > > > > > > > > > >>> > > > > > >> > > > > > > Indeed we can add phases as we have process > > > >>> > > > >>> classes > > > >>> > > > >>> > > after > > > >>> > > > > > >>> > > > > > >> compile, > > > >>> > > > > > >> > > > >>> > > > > > >> > > > > > > prepackage before package etc.. but it > > > >>> > > > > > >> > > > > > > stays > > > >>> > > > > > >> > > > > > > arbitrary > > > >>> > > > > > >> > > > > > > for > > > >>> > > > > > >> > > > >>> > > > > > >> maven > > > >>> > > > > > >> > > > >>> > > > > > >> > > > > project > > > >>> > > > > > >> > > > > > > > >>> > > > > > >> > > > > > > dev and does not reflect the agility > > > > projects > > > > > >>> take > > > >>> > > > >>> > > these > > > >>> > > > > > >>> > > > > days > > > >>> > > > > > > > >>> > > > > > >> IMHO > > > >>> > > > > > >> > > > >>> > > > > > >> > > > and > > > >>> > > > > > >> > > > > > > >>> > > > > > >> > > > > if > > > >>> > > > > > >> > > > > > > > >>> > > > > > >> > > > > > > done in our core delivery it would slow > > > >>> > > > > > >> > > > > > > down > > > >>> > > > >>> most > > > >>> > > > >>> > > build > > > >>> > > > > > >>> > > > > for > > > >>> > > > > > > > >>> > > > > > >> > > > > > > no > > > >>> > > > > > >> > > > > > > gain > > > >>> > > > > > >> > > > > > > >>> > > > > > >> > > > so > > > >>> > > > > > >> > > > > > > >>> > > > > > >> > > > > it > > > >>> > > > > > >> > > > > > > > >>> > > > > > >> > > > > > > must be in user land IMHO. > > > >>> > > > > > >> > > > > > > > > > >>> > > > > > >> > > > > > > Hope it makes more sense presented this > > > >>> > > > > > >> > > > > > > way. > > > >>> > > > > > >> > > > > > > > > > >>> > > > > > >> > > > > > > > > > >>> > > > > > >> > > > > > > > > > >>> > > > > > >> > > > > > > Le sam. 4 juil. 2020 à 05:28, Hervé BOUTEMY > > > > a > > > > > >>> > > > > > >> > > > > > > écrit : > > > >>> > > > > > >> > > > > > > > first: thanks for sharing > > > >>> > > > > > >> > > > > > > > > > > >>> > > > > > >> > > > > > > > from a high level point of view, the risk > > > > I > > > > > >>> see is > > > >>> > > > >>> > > to > > > >>> > > > > > >>> > > > > loose > > > >>> > > > > > > > >>> > > > > > >> our > > > >>> > > > > > >> > > > >>> > > > > > >> > > > > > > > conventions. > > > >>> > > > > > >> > > > > > > > But let's try and see before judging > > > >>> > > > > > >> > > > > > > > > > > >>> > > > > > >> > > > > > > > I think there are 2 topics currently > > > > mixed: > > > >>> > > > > > >> > > > > > > > - default lifecycle phases: > > > >>> > > > > > >> > > > > > > > do you want to add or remove phases? [1] > > > >>> > > > > > >> > > > > > > > - default plugin bindings: > > > >>> > > > > > >> > > > > > > > clearly, you want to have specific > > > >>> > > > > > >> > > > > > > > default > > > >>> > > > > > >>> > > bindings. On > > > >>> > > > > > >>> > > > > > >> default > > > >>> > > > > > >> > > > >>> > > > > > >> > > > > > > > bindings, as > > > >>> > > > > > >> > > > > > > > they are defined per-packaging [2] > > > >>> > > > > > >> > > > > > > > (that's > > > >>> > > > >>> what is > > > >>> > > > >>> > > > > > >> > > > > > > > triggered > > > >>> > > > > > >> > > > > > >>> > > > > > >> > > behind > > > >>> > > > > > >> > > > > > >>> > > > > > >> > > > > > > > packaging > > > >>> > > > > > >> > > > > > > > in pom.xml) > > > >>> > > > > > >> > > > > > > > > > > >>> > > > > > >> > > > > > > > Regards, > > > >>> > > > > > >> > > > > > > > > > > >>> > > > > > >> > > > > > > > Hervé > > > >>> > > > > > >> > > > > > > > > > > >>> > > > > > >> > > > > > > > [1] > > > >>> > > > >>> https://maven.apache.org/ref/3.6.3/maven-core/lifecycles.html > > > >>> > > > >>> > > > > > >> > > > > > > > [2] > > > > https://maven.apache.org/ref/3.6.3/maven-core/default-bindings.html > > > > > >>> > > > > > >> > > > > > > > Le vendredi 3 juillet 2020, 09:20:25 CEST > > > >>> > > > >>> Romain > > > >>> > > > >>> > > > > > >> Manni-Bucau a > > > >>> > > > > > >> > > > >>> > > > > > >> > > > écrit > > > >>> > > > > > >> > > > > > > >>> > > > > > >> > > > > > > > > Hi everyone, > > > >>> > > > > > >> > > > > > > > > > > > >>> > > > > > >> > > > > > > > > Wonder if we already discussed defining > > > > the > > > > > >>> > > lifecycle > > > >>> > > > > > >>> > > > > in > > > >>> > > > > > > > >>> > > > > > >> the > > > >>> > > > > > >> > > > >>> > > > > > >> > > > > project > > > >>> > > > > > >> > > > > > > > >>> > > > > > >> > > > > > > > (maybe > > > >>> > > > > > >> > > > > > > > > > > >>> > > > > > >> > > > > > > > > in $root/.mvn). > > > >>> > > > > > >> > > > > > > > > High level the need is to be able to > > > > change > > > > > >>> the > > > >>> > > > >>> > > > > default > > > >>> > > > > > > > >>> > > > > > >> > > lifecycle > > > >>> > > > > > >> > > > > > >>> > > > > > >> > > > > in > > > >>> > > > > > >> > > > > > > > >>> > > > > > >> > > > > > > the > > > >>> > > > > > >> > > > > > > > > > >>> > > > > > >> > > > > > > > > root pom without having to define a > > > > custom > > > > > >>> > > extension > > > >>> > > > > > >>> > > > > - in > > > >>> > > > > > > > >>> > > > > > >> > > > > > > > > other > > > >>> > > > > > >> > > > > > > > >>> > > > > > >> > > > > words > > > >>> > > > > > >> > > > > > > > >>> > > > > > >> > > > > > > it > > > >>> > > > > > >> > > > > > > > > > >>> > > > > > >> > > > > > > > is > > > >>> > > > > > >> > > > > > > > > > > >>> > > > > > >> > > > > > > > > about having a built-in extension. > > > >>> > > > > > >> > > > > > > > > The typical need is to add a mojo in > > > >>> > > > > > >> > > > > > > > > the > > > >>> > > > >>> default > > > >>> > > > >>> > > > > > >> > > > > > > > > lifecycle > > > >>> > > > > > >> > > > > > > > > (add > > > >>> > > > > > >> > > > > > > > > > >>> > > > > > >> > > > > > > frontend > > > >>> > > > > > >> > > > > > > > > > >>> > > > > > >> > > > > > > > > magement for ex) or replace some > > > > plugins by > > > > > >>> > > > > > >> > > > > > > > > others > > > >>> > > > > > > > >>> > > > > (for > > > >>> > > > > > > > >>> > > > > > >> > > > > > > > > example > > > >>> > > > > > >> > > > > > > > > > >>> > > > > > >> > > > > > > compiler > > > >>> > > > > > >> > > > > > > > > > >>> > > > > > >> > > > > > > > by > > > >>> > > > > > >> > > > > > > > > > > >>> > > > > > >> > > > > > > > > scalac plugin, surefire by spec2 plugin > > > > for > > > > > >>> a > > > >>> > > > >>> > > scala > > > >>> > > > > > >>> > > > > based > > > >>> > > > > > > > >>> > > > > > >> > > project > > > >>> > > > > > >> > > > > > >>> > > > > > >> > > > > > > > etc...). > > > >>> > > > > > >> > > > > > > > > > > >>> > > > > > >> > > > > > > > > The way I'm seeing it is to let the xml > > > >>> > > > >>> defining > > > >>> > > > >>> > > the > > > >>> > > > > > >>> > > > > > >> lifecycle > > > >>> > > > > > >> > > > >>> > > > > > >> > > be > > > >>> > > > > > >> > > > > > >>> > > > > > >> > > > > put > > > >>> > > > > > >> > > > > > > > >>> > > > > > >> > > > > > > in > > > >>> > > > > > >> > > > > > > > > > >>> > > > > > >> > > > > > > > > .mvn/default-lifecycle.xml - I don't > > > > know > > > > > >>> if we > > > >>> > > > >>> > > want > > > >>> > > > > > >>> > > > > to > > > >>> > > > > > > > >>> > > > > > >> use > > > >>> > > > > > >> > > > >>> > > > > > >> > > > > > > > > the > > > >>> > > > > > >> > > > > > > > > >>> > > > > > >> > > > > > prefix > > > >>> > > > > > >> > > > > > > > > >>> > > > > > >> > > > > > > > > (default here) as a reference you can > > > > put > > > > > >>> in the > > > >>> > > > >>> > > pom > > > >>> > > > > > >>> > > > > but > > > >>> > > > > > > > >>> > > > > > >> at > > > >>> > > > > > >> > > > >>> > > > > > >> > > least > > > >>> > > > > > >> > > > > > >>> > > > > > >> > > > > > > default > > > >>> > > > > > >> > > > > > > > > > >>> > > > > > >> > > > > > > > > makes sense IMO. > > > >>> > > > > > >> > > > > > > > > The lifecycle.xml itself would likely > > > >>> > > > > > >> > > > > > > > > be > > > >>> > > > >>> extended > > > >>> > > > >>> > > to > > > >>> > > > > > >>> > > > > add > > > >>> > > > > > > > >>> > > > > > >> some > > > >>> > > > > > >> > > > >>> > > > > > >> > > > > > > > precondition > > > >>> > > > > > >> > > > > > > > > > > >>> > > > > > >> > > > > > > > > to each plugin (if src/main/frontend > > > > exists > > > > > >>> then > > > >>> > > > >>> > > add > > > >>> > > > > > >>> > > > > > >> > > frontend:npm > > > >>> > > > > > >> > > > > > >>> > > > > > >> > > > > for > > > >>> > > > > > >> > > > > > > > >>> > > > > > >> > > > > > > > ex). > > > >>> > > > > > >> > > > > > > > > > > >>> > > > > > >> > > > > > > > > I know it is a quite common need I have > > > > and > > > > > >>> not > > > >>> > > > >>> > > > > something > > > >>> > > > > > > > >>> > > > > > >> I > > > >>> > > > > > >> > > > >>> > > > > > >> > > would > > > >>> > > > > > >> > > > > > >>> > > > > > >> > > > > put > > > >>> > > > > > >> > > > > > > > >>> > > > > > >> > > > > > > in > > > >>> > > > > > >> > > > > > > > > > >>> > > > > > >> > > > > > > > a > > > >>> > > > > > >> > > > > > > > > > > >>> > > > > > >> > > > > > > > > custom extension because it is very "by > > > >>> > > > >>> project" > > > >>> > > > >>> > > and > > > >>> > > > > > >>> > > > > not > > > >>> > > > > > > > >>> > > > > > >> > > > shareable > > > >>> > > > > > >> > > > > > > >>> > > > > > >> > > > > > so a > > > >>> > > > > > >> > > > > > > > > >>> > > > > > >> > > > > > > > > shared extension does not make sense > > > >>> > > > > > >> > > > > > > > > and > > > >>> > > > > > >>> > > packaging a > > > >>> > > > > > >>> > > > > > >> > > > > plugin/extension > > > >>> > > > > > >> > > > > > > > >>> > > > > > >> > > > > > > > for a > > > >>> > > > > > >> > > > > > > > > > > >>> > > > > > >> > > > > > > > > single project is bothering for > > > >>> > > > > > >> > > > > > > > > nothing. > > > >>> > > > > > >> > > > > > > > > > > > >>> > > > > > >> > > > > > > > > I'm planning to give a try with a > > > >>> > > > > > >> > > > > > > > > custom > > > >>> > > > > > >>> > > extension in > > > >>> > > > > > >>> > > > > the > > > >>> > > > > > > > >>> > > > > > >> > > summer > > > >>> > > > > > >> > > > > > >>> > > > > > >> > > > > but > > > >>> > > > > > >> > > > > > > > >>> > > > > > >> > > > > > > > > thought it can be worth some discussion > > > >>> > > > >>> there > > > >>> > > > >>> > > > > > >> > > > > > > > > too. > > > >>> > > > > > >> > > > > > > > > > > > >>> > > > > > >> > > > > > > > > Wdyt? > > > >>> > > > > > >> > > > > > > > > > > > >>> > > > > > >> > > > > > > > > Romain Manni-Bucau > > > >>> > > > > > >> > > > > > > > > @rmannibucau | Blog > > > >>> > > > > > >> > > > > > > > > > > > >>> > > > > > >> > > > > > > > > | Old Blog > > > >>> > > > > > >> > > > > > > > > | Github > > > >>> > > > > > >> > > > > > > > > > > >>> > > > > > >> > > > > > > > https://github.com/rmannibucau> > > > >>> > > > > > >> > > > > > > > > > > >>> > > > > > >> > > > > > > > > | LinkedIn | Book > > > > https://www.packtpub.com/application-development/java-ee-8-high-performa > > > > > >>> n > > > >>> > > > >>> > > > > > >> c > > > >>> > > > > > >> > > > >>> > > > > > >> > > e > > > > -------------------------------------------------------------------- > > > > > >>> > > - > > > >>> > > > > > >>> > > > > > >> > > > > > > > To unsubscribe, e-mail: > > > >>> > > > > dev-unsubscr...@maven.apache.org > > > >>> > > > > > > > >>> > > > > > >> > > > > > > > For additional commands, e-mail: > > > >>> > > > > dev-h...@maven.apache.org > > > >>> > > > > > > > >>> > > > > > >> > > > > -- > > > >>> > > > > > >> > > > > Sent from my phone > > > >>> > > > > > >> > > > > > >>> > > > > > >> > > -- > > > >>> > > > > > >> > > Sent from my phone > > > > -------------------------------------------------------------------- > > > > > >>> > > - > > > >>> > > > > > >>> > > > > > >> 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 > > > >>> > > > >>> -------------------------------------------------------------------- > > > >>> - > > > >>> 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
