Le dimanche 12 juillet 2020, 18:10:59 CEST Romain Manni-Bucau 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.
from experience with site lifecycle in parallel to default lifecycle,
interactions between lifecycles are hard to maintain: that's why we have "no-
fork" reports in addition to "fork"
in your docker case, how would be your docker lifecycle be related or not to
default lifecycle?
>
> 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-performance
> >
>
>
> 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-performan
> >> c
> >>
> >> > > > > 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-starter
> >> ->
> >>
> >> > > > > > > server/pom.xml 2.
> >>
> >> https://github.com/Talend/component-runtime/blob/master/documentation/pom
> >> .
> >>
> >> > > > > > > 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-performan
> >>
> >> > > > > > >> 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
