Re: custom default lifecycle per project

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: custom default lifecycle per project

Hervé BOUTEMY
are really your plugin bindings so specific to your build that they could not be reused and need full ad-hoc definition?

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

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/apache/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-performance
> >
>
>
> Le dim. 5 juil. 2020 à 11:09, Romain Manni-Bucau <[hidden email]> 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 <[hidden email]> 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 <
> >> >
> >> > [hidden email]> a écrit :
> >> > > On Sat 4 Jul 2020 at 16:54, Romain Manni-Bucau <[hidden email]
> >> > >
> >> > > wrote:
> >> > > > Le sam. 4 juil. 2020 à 16:38, Stephen Connolly <
> >> > > >
> >> > > > [hidden email]> a écrit :
> >> > > > > On Sat 4 Jul 2020 at 10:21, Romain Manni-Bucau <
> >>
> >> [hidden email]>
> >>
> >> > > > > 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 <
> >>
> >> [hidden email]>
> >>
> >> > > 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 <
> >>
> >> [hidden email]>
> >>
> >> > > > > 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: [hidden email]
> >> > > > > > > > For additional commands, e-mail: [hidden email]
> >> > > > >
> >> > > > > --
> >> > > > > Sent from my phone
> >> > >
> >> > > --
> >> > > Sent from my phone
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: custom default lifecycle per project

Hervé BOUTEMY
Le samedi 11 juillet 2020, 12:55:37 CEST Romain Manni-Bucau a écrit :

> Le sam. 11 juil. 2020 à 12:09, Hervé BOUTEMY <[hidden email]> 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

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

>
> > 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-performanc
> > e
> >
> > > Le dim. 5 juil. 2020 à 11:09, Romain Manni-Bucau <[hidden email]>
> >
> > 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 <[hidden email]> 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 <
> > > >> >
> > > >> > [hidden email]> a écrit :
> > > >> > > On Sat 4 Jul 2020 at 16:54, Romain Manni-Bucau <
> >
> > [hidden email]
> >
> > > >> > > wrote:
> > > >> > > > Le sam. 4 juil. 2020 à 16:38, Stephen Connolly <
> > > >> > > >
> > > >> > > > [hidden email]> a écrit :
> > > >> > > > > On Sat 4 Jul 2020 at 10:21, Romain Manni-Bucau <
> > > >>
> > > >> [hidden email]>
> > > >>
> > > >> > > > > 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 <
> > > >>
> > > >> [hidden email]>
> > > >>
> > > >> > > 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 <
> > > >>
> > > >> [hidden email]>
> > > >>
> > > >> > > > > 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:
> > [hidden email]
> >
> > > >> > > > > > > > For additional commands, e-mail:
> > [hidden email]
> >
> > > >> > > > > --
> > > >> > > > > Sent from my phone
> > > >> > >
> > > >> > > --
> > > >> > > Sent from my phone
> > > >>
> > > >> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: [hidden email]
> > > >> For additional commands, e-mail: [hidden email]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: custom default lifecycle per project

Hervé BOUTEMY
In reply to this post by Hervé BOUTEMY
Le jeudi 16 juillet 2020, 07:50:52 CEST Romain Manni-Bucau a écrit :

> Le jeu. 16 juil. 2020 à 00:09, Hervé BOUTEMY <[hidden email]> a
>
> écrit :
> > Le mardi 14 juillet 2020, 20:36:38 CEST Romain Manni-Bucau a écrit :
> > > Le mar. 14 juil. 2020 à 20:01, Hervé BOUTEMY <[hidden email]> a
> > >
> > > écrit :
> > > > in this example, you strictly define a new "my-mapping" packaging,
> > > > like
> > > > done in Maven core for every default packagings [1] with documentation
> >
> > in
> >
> > > > [2]: don't call it bindings, but simply "packaging-bindings.xml" and
> >
> > it's
> >
> > > > more clear
> > >
> > > Nop, the packaging is declined in a lifecycle implicitly (which enables
> >
> > to
> >
> > > do "mvn my-test") otherwise it wouldn't work with just a packaging.
> >
> > uh, a trick :/
> > is it different from full lifecycle definition with plugin bindings, like
> > site and clean lifecycles?
> >
> > https://github.com/apache/maven/blob/master/maven-core/src/main/resources/
> > META-INF/plexus/components.xml#L66
> Yep, can work too but I'd like to avoid duplicating what can be and
> lifecycle was not matching that well.
I don't get what "mvn my-test" means: there is no "my-test" phase
and I don't understand how your custom lifecycle shares some phases with
default lifecycle, but has some specific ones: I fear there will be conflicts

> Maybe it needs a new "config API" (<phase ... default="true">....</>?).
> Let's keep the config part for the end, this one is important but not
> structural IMHO.
>
> > > > the more I think about it, the more I feel that what we need is
> > > > pluginManagement and eventually plugins import, like we did in the
> > > > past
> > > > for
> > > > dependencyManagement [3]
> > > >
> > > > This would permit:
> > > > - to import plugins versions form an external source,
> > > > - share plugins configurations and executions either in the reactor,
> > > > either from outside
> > > >
> > > > I still don't know if this import should be triggered as a
> > > > dependencyManagement scope, like "import" scope was added
> > >
> > > Well, yes and no because it still relies on the inheritance compared to
> >
> > the
> >
> > > composition which keeps the big drawback to easily break (just add a new
> > > module needing something a little bit different, or just try to exclude
> >
> > one
> >
> > > of the plugins automatically imported - it is in dependency model but
> > > not
> > > in plugin one).
> >
> > inheritance? no, aggregation: the plugin or pluginManagement import can be
> > done by aggregation in any POM, not through parent
>
> Hmm, you assume users will define a pom per lifecycle/binding whereas it
> defeats the fact to not create any fake module, no?
I don't understand what you mean by "per lifecycle/binding": a pom will be
defined per series of plugins executions that are expected to be able to be
composed

and it's not a "fake" module: it's a module to define the "series of plugins
executions that are expected to be able to be composed
yes, it's not a pure internal module, not producing by itself any code
compilation

> So IMHO this is not an option for one of the original goals to not modify
> the user reactor.
there is a goal to not modify the user reactor? why?
to me, the goal was to avoid copy/pasting in multiple POM a common build
aspect that should be defined once and injected by composition when needed
I don't see which issue if the definition defined once requires a pom

>
> > > It would also require to be able to import a chain of plugins and not
> >
> > just
> >
> > > a plugin from a management block or all plugin from the same block (as
> >
> > done
> >
> > > with the packaging in the sample), otherwise you are back to redefining
> >
> > all
> >
> > > plugins in your new module or to be forced to define a new parent to
> > > isolate the children from this shared declarations.
> >
> > plugin import would import every plugin from the imported POM: no
> > per-plugin import
> >
> > > I'm also not sure how you would merge plugins (let say I import
> > > frontend-plugins and java-plugins, how do I define their order in main
> >
> > and
> >
> > > test phases)? Back to the lifecycle merge issue, no?
> >
> > I still don't see any issue here, but just choice of phases that match
> > required order
>
> if your import 1 is: front:run[phase compile] front:test[phase test]
> if your import 2 is: java:compile[phase compile] java:test[phase test]
>
> How do I make the complete lifecycle be: java:compile front:run front:test
> java:test ?
the fact that we need more phases is another issue: I was not trying to solve
that one, that is IMHO completely orthogonal to the build composition
objective
of course, mixing build composition and additional phases brings a lot of
power

>
> > > So it can be about defining a new <lifecycleManagement> section
> >
> > containing
> >
> > > this mix of packaging+binding definition (the overlap is certain so we
> > > shouldnt force to define both IMHO) but it also means waiting for
> > > another
> > > major and does not change much the design which is about being able to
> > > define a new binding+packaging. The part which can be smoother though is
> > > the fact to patch an existing packaging even if I'm not yet seeing it
> > > working.
> > > The more I'm thinking about it, more I think the patch option is about
> > > defining edges of the build graph (frontend:npm-build "runs after"
> > > "process-classes" for example)
> >
> > patching will require to define the language or configuration to set the
> > order: not sure it is reasonable
> >
> > > whereas the packaging+binding option is
> > > about defining the global graph (of one new module type) explicitly.
> >
> > you're defining a new lifecycle with its plugin bindings: let's call it
> > like it is, please
> > your extension is about being able to do it directly in reactor, instead
> > of creating an extension in a separate build
>
> Yep + avoid the packaging (was not explicit but adding a "build" module to
> the reactor was would down the build too much if not diff well enough and
> would add a reactor on the critical path for concurrent builds, don't think
> it id desired so the fully configured and exploded solution is likely
> desired)
>
> > > > Or if we could do something at dependencyManagement and/or dependency
> > > > level.
> > > > Given "extensions" is a boolean represented as a String (for
> >
> > inheritance
> >
> > > > reasons), why not use this String to have support
> > > > <extensions>import</extensions> that imports content?
> > > >
> > > > Regards,
> > > >
> > > > Hervé
> > > >
> > > >
> > > > [1]
> >
> > https://maven.apache.org/ref/3.6.3/maven-core/default-bindings.html
> >
> > > > [2]
> >
> > https://maven.apache.org/ref/3.6.3/maven-core/default-bindings.html
> >
> > > > [3]
> >
> > https://maven.apache.org/ref/3.6.3/maven-core/default-bindings.html
> >
> > > > Le dimanche 12 juillet 2020, 19:27:28 CEST Romain Manni-Bucau a écrit
:

> > > > > Just to illustrate the proposal - likely to rework on config side to
> > > >
> > > > avoid
> > > >
> > > > > to kind of expose maven IoC (as we were playing with application
> > > > > contexts
> > > > > 10 years ago ;)) here is a small repo:
> > > > > https://github.com/rmannibucau/custom-lifecycle-extension.
> > > > >
> > > > > A sample project ([1]) defines a custom packaging ([2]) which takes
> >
> > its
> >
> > > > > definition in mappings.xml ([3]). This sample just renames some
> > > > > phase
> > > > > and
> > > > > replace one plugin by another for demo purposes but it is what I had
> >
> > in
> >
> > > > > mind to give the user enough flexibility for its build.
> > > > > A complete alternative which works too - = achieves the same goal -
> >
> > is
> >
> > > > > to
> > > > > enable the user to define the build chain somewhere (like <plugins>
> >
> > but
> >
> > > > > order is the straight definition order for example) and autowire
> > > >
> > > > everything
> > > >
> > > > > as expected through an extension to avoid all the headaches
> >
> > associated
> >
> > > > with
> > > >
> > > > > the inheritance and other indirections making the pom execution hard
> >
> > to
> >
> > > > > follow. The issue with this one is to lose the aliasing feature.
> > > > >
> > > > > [1]
> >
> > https://github.com/rmannibucau/custom-lifecycle-extension/tree/master/samp
> >
> > > > le>
> > > >
> > > > > [2]
> >
> > https://github.com/rmannibucau/custom-lifecycle-extension/blob/master/samp
> >
> > > > le>
> > > >
> > > > > /pom.xml#L10 [3]
> >
> > https://github.com/rmannibucau/custom-lifecycle-extension/blob/master/samp
> >
> > > > le>
> > > >
> > > > > /.extensions/custom/mappings.xml
> > > > >
> > > > > Romain Manni-Bucau
> > > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > > <http://rmannibucau.wordpress.com> | Github <
> > > >
> > > > https://github.com/rmannibucau>
> > > >
> > > > > | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > >
> > > > > <
> >
> > https://www.packtpub.com/application-development/java-ee-8-high-performanc
> >
> > > > e
> > > >
> > > > > Le dim. 12 juil. 2020 à 18:10, Romain Manni-Bucau
> > > > > <[hidden email]>
> > > >
> > > > 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 <
> > > >
> > > > [hidden email]>
> > > >
> > > > > > a écrit :
> > > > > >> Le dim. 12 juil. 2020 à 11:26, Hervé BOUTEMY <
> >
> > [hidden email]>
> >
> > > > 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 <
> > > >
> > > > [hidden email]> 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 <
> > > > > >>>
> > > > > >>> [hidden email]> 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 <
> > > > > >>> > >
> > > > > >>> > > [hidden email]>
> > > > > >>> > >
> > > > > >>> > > > > 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
> > > > > >>> > > > > > > <[hidden email]>
> > > > > >>> > >
> > > > > >>> > > 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 <
> > > > > >>> > > > > > >> >
> > > > > >>> > > > > > >> > [hidden email]> a écrit :
> > > > > >>> > > > > > >> > > On Sat 4 Jul 2020 at 16:54, Romain Manni-Bucau
> > > > > >>> > > > > > >> > > <
> > > > > >>> > > > >
> > > > > >>> > > > > [hidden email]
> > > > > >>> > > > >
> > > > > >>> > > > > > >> > > wrote:
> > > > > >>> > > > > > >> > > > Le sam. 4 juil. 2020 à 16:38, Stephen
> >
> > Connolly <
> >
> > > > > >>> > > > > > >> > > > [hidden email]> a écrit :
> > > > > >>> > > > > > >> > > > > On Sat 4 Jul 2020 at 10:21, Romain
> >
> > Manni-Bucau
> >
> > > > > >>> > > > > > >> > > > > <
> > > > > >>> > > > > > >>
> > > > > >>> > > > > > >> [hidden email]>
> > > > > >>> > > > > > >>
> > > > > >>> > > > > > >> > > > > 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
> >
> > > > > >>> > > > > > >> > > > > > <
> > > > > >>> > > > > > >>
> > > > > >>> > > > > > >> [hidden email]>
> > > > > >>> > > > > > >>
> > > > > >>> > > > > > >> > > 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 <
> >
> > > > > >>> > > > > > >> [hidden email]>
> > > > > >>> > > > > > >>
> > > > > >>> > > > > > >> > > > > 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:
> > > > > >>> > > > > [hidden email]
> > > > > >>> > > > >
> > > > > >>> > > > > > >> > > > > > > > For additional commands, e-mail:
> > > > > >>> > > > > [hidden email]
> > > > > >>> > > > >
> > > > > >>> > > > > > >> > > > > --
> > > > > >>> > > > > > >> > > > > Sent from my phone
> > > > > >>> > > > > > >> > >
> > > > > >>> > > > > > >> > > --
> > > > > >>> > > > > > >> > > Sent from my phone
> > > >
> > > > --------------------------------------------------------------------
> > > >
> > > > > >>> > > -
> > > > > >>> > >
> > > > > >>> > > > > > >> To unsubscribe, e-mail:
> > > > [hidden email]
> > > >
> > > > > >>> > > > > > >> For additional commands, e-mail:
> > > > [hidden email]
> >
> > --------------------------------------------------------------------
> >
> > > > > >>> -
> > > > > >>>
> > > > > >>> > > > > To unsubscribe, e-mail: [hidden email]
> >
> > > > > >>> > > > > For additional commands, e-mail:
> > [hidden email]
> >
> > > > --------------------------------------------------------------------
> > > >
> > > > > >>> > > -
> > > > > >>> > > To unsubscribe, e-mail: [hidden email]
> > > > > >>> > > For additional commands, e-mail: [hidden email]
> >
> > --------------------------------------------------------------------
> >
> > > > > >>> -
> > > > > >>> To unsubscribe, e-mail: [hidden email]
> > > > > >>> For additional commands, e-mail: [hidden email]
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]