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
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 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/sample > [2] > https://github.com/rmannibucau/custom-lifecycle-extension/blob/master/sample > /pom.xml#L10 [3] > https://github.com/rmannibucau/custom-lifecycle-extension/blob/master/sample > /.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-performance > > > > > Le dim. 12 juil. 2020 à 18:10, Romain Manni-Bucau <[email protected]> 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 <[email protected]> > > > > a écrit : > >> Le dim. 12 juil. 2020 à 11:26, Hervé BOUTEMY <[email protected]> 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 <[email protected]> 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 < > >>> > >>> [email protected]> 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 < > >>> > > > >>> > > [email protected]> > >>> > > > >>> > > > > 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 > >>> > > > > > > <[email protected]> > >>> > > > >>> > > 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 < > >>> > > > > > >> > > >>> > > > > > >> > [email protected]> a écrit : > >>> > > > > > >> > > On Sat 4 Jul 2020 at 16:54, Romain Manni-Bucau < > >>> > > > > > >>> > > > > [email protected] > >>> > > > > > >>> > > > > > >> > > wrote: > >>> > > > > > >> > > > Le sam. 4 juil. 2020 à 16:38, Stephen Connolly < > >>> > > > > > >> > > > > >>> > > > > > >> > > > [email protected]> a écrit : > >>> > > > > > >> > > > > On Sat 4 Jul 2020 at 10:21, Romain Manni-Bucau < > >>> > > > > > >> > >>> > > > > > >> [email protected]> > >>> > > > > > >> > >>> > > > > > >> > > > > 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 < > >>> > > > > > >> > >>> > > > > > >> [email protected]> > >>> > > > > > >> > >>> > > > > > >> > > 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 < > >>> > > > > > >> > >>> > > > > > >> [email protected]> > >>> > > > > > >> > >>> > > > > > >> > > > > 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: > >>> > > > > [email protected] > >>> > > > > > >>> > > > > > >> > > > > > > > For additional commands, e-mail: > >>> > > > > [email protected] > >>> > > > > > >>> > > > > > >> > > > > -- > >>> > > > > > >> > > > > Sent from my phone > >>> > > > > > >> > > > >>> > > > > > >> > > -- > >>> > > > > > >> > > Sent from my phone > >>> > > > >>> > > -------------------------------------------------------------------- > >>> > > - > >>> > > > >>> > > > > > >> To unsubscribe, e-mail: [email protected] > >>> > > > > > >> For additional commands, e-mail: [email protected] > >>> > >>> --------------------------------------------------------------------- > >>> > >>> > > > > To unsubscribe, e-mail: [email protected] > >>> > > > > For additional commands, e-mail: [email protected] > >>> > > > >>> > > -------------------------------------------------------------------- > >>> > > - > >>> > > To unsubscribe, e-mail: [email protected] > >>> > > For additional commands, e-mail: [email protected] > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [email protected] > >>> For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
