Re: custom default lifecycle per project

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

Re: custom default lifecycle per project

Hervé BOUTEMY
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 <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
> >





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

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

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

That sounds like a dedicated plugin use case

>
>
>
> >
> > > 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-performance
> > > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: [hidden email]
> > > > > For additional commands, e-mail: [hidden email]
> > > > >
> > > > >
> > > >
> > >
> > --
> > Sent from my phone
> >
>
--
Sent from my phone
Reply | Threaded
Open this post in threaded view
|

Re: custom default lifecycle per project

Romain Manni-Bucau
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-server-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-performanc
> > > 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]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: custom default lifecycle per project

rfscholte
Packaging should refer to the type of resulting main artifact.
I see quite often that the jar-lifecycle is used, whereas the result is not a jar. They try to fix this by changing the phase the none for several goals.
Also, I know it is possible to generate a war with the soapui-maven-plugin based on a soapui config file, so this one should have packaging: war, binding: pom

Robert 
On 11-7-2020 12:59:23, Romain Manni-Bucau <[hidden email]> wrote:
Le sam. 11 juil. 2020 à 12:39, Robert Scholte a
écrit :

> such solution confirms that packaging is used for 2 different things,
> which should be split in the next pom definition:
> packaging: the resulting artifact
> binding: the bindings to use for the default/build lifecycle.
>

This just replace the term packaging by binding. At the end you define a
chain of plugins for a module which leads to artifacts, whatever terms you
use this does not change much (and is the only goal of a build right? ;)).
Today packaging defines a binding and the actual packaging is just one
plugin of the binding loaded from packaging string so IMHO it is the same.



> Robert
> On 11-7-2020 12:09:49, Hervé BOUTEMY wrote:
> 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: war+front+living-doc+docker
>
> 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 readAs(final Path path, final Class 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 ? "" : "") +
> > new String(Files.readAllBytes(path),
> > StandardCharsets.UTF_8)
> > .replaceFirst("]+\\?>",
> > "").trim() + (wrapper != null ? "" : ""))); } 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 readAs(final Path path, final Class type, final
> > String wrapper) {
> > try {
> > return type.cast(
> > converter.convert(TypeLiteral.get(type),
> > (wrapper != null ? "" : "") +
> > new
> > String(Files.readAllBytes(path), StandardCharsets.UTF_8)
> >
> > .replaceFirst("]+\\?>", "").trim() +
> > (wrapper != null ? "
> > + ">" : "")));
> > } 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 | Blog
> > | Old Blog
> > | Github
> > | LinkedIn | Book
> >
> > >
> >
> >
> > Le dim. 5 juil. 2020 à 11:09, Romain Manni-Bucau 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 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
> > >> > >
> > >> > > 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
In reply to this post by Hervé BOUTEMY
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

>
> > the more I think about it, the more I feel that what we need is
> > pluginManagement and eventually plugins import, like we did in the past
> > for
> > dependencyManagement [3]
> >
> > This would permit:
> > - to import plugins versions form an external source,
> > - share plugins configurations and executions either in the reactor,
> > either from outside
> >
> > I still don't know if this import should be triggered as a
> > dependencyManagement scope, like "import" scope was added
>
> Well, yes and no because it still relies on the inheritance compared to the
> composition which keeps the big drawback to easily break (just add a new
> module needing something a little bit different, or just try to exclude one
> of the plugins automatically imported - it is in dependency model but not
> in plugin one).
inheritance? no, aggregation: the plugin or pluginManagement import can be done by aggregation in any POM, not through parent

> It would also require to be able to import a chain of plugins and not just
> a plugin from a management block or all plugin from the same block (as done
> with the packaging in the sample), otherwise you are back to redefining all
> plugins in your new module or to be forced to define a new parent to
> isolate the children from this shared declarations.
plugin import would import every plugin from the imported POM: no per-plugin import

> I'm also not sure how you would merge plugins (let say I import
> frontend-plugins and java-plugins, how do I define their order in main and
> test phases)? Back to the lifecycle merge issue, no?
I still don't see any issue here, but just choice of phases that match required order

>
> So it can be about defining a new <lifecycleManagement> section containing
> this mix of packaging+binding definition (the overlap is certain so we
> shouldnt force to define both IMHO) but it also means waiting for another
> major and does not change much the design which is about being able to
> define a new binding+packaging. The part which can be smoother though is
> the fact to patch an existing packaging even if I'm not yet seeing it
> working.
> The more I'm thinking about it, more I think the patch option is about
> defining edges of the build graph (frontend:npm-build "runs after"
> "process-classes" for example)
patching will require to define the language or configuration to set the order: not sure it is reasonable

> whereas the packaging+binding option is
> about defining the global graph (of one new module type) explicitly.
you're defining a new lifecycle with its plugin bindings: let's call it like it is, please
your extension is about being able to do it directly in reactor, instead of creating an extension in a separate build

>
> > Or if we could do something at dependencyManagement and/or dependency
> > level.
> > Given "extensions" is a boolean represented as a String (for inheritance
> > reasons), why not use this String to have support
> > <extensions>import</extensions> that imports content?
> >
> > Regards,
> >
> > Hervé
> >
> >
> > [1] https://maven.apache.org/ref/3.6.3/maven-core/default-bindings.html
> >
> > [2] https://maven.apache.org/ref/3.6.3/maven-core/default-bindings.html
> >
> > [3] https://maven.apache.org/ref/3.6.3/maven-core/default-bindings.html
> >
> > Le dimanche 12 juillet 2020, 19:27:28 CEST Romain Manni-Bucau a écrit :
> > > Just to illustrate the proposal - likely to rework on config side to
> >
> > avoid
> >
> > > to kind of expose maven IoC (as we were playing with application
> > > contexts
> > > 10 years ago ;)) here is a small repo:
> > > https://github.com/rmannibucau/custom-lifecycle-extension.
> > >
> > > A sample project ([1]) defines a custom packaging ([2]) which takes its
> > > definition in mappings.xml ([3]). This sample just renames some phase
> > > and
> > > replace one plugin by another for demo purposes but it is what I had in
> > > mind to give the user enough flexibility for its build.
> > > A complete alternative which works too - = achieves the same goal - is
> > > to
> > > enable the user to define the build chain somewhere (like <plugins> but
> > > order is the straight definition order for example) and autowire
> >
> > everything
> >
> > > as expected through an extension to avoid all the headaches associated
> >
> > with
> >
> > > the inheritance and other indirections making the pom execution hard to
> > > follow. The issue with this one is to lose the aliasing feature.
> > >
> > > [1]
> >
> > https://github.com/rmannibucau/custom-lifecycle-extension/tree/master/samp
> > le>
> > > [2]
> >
> > https://github.com/rmannibucau/custom-lifecycle-extension/blob/master/samp
> > le>
> > > /pom.xml#L10 [3]
> >
> > https://github.com/rmannibucau/custom-lifecycle-extension/blob/master/samp
> > le>
> > > /.extensions/custom/mappings.xml
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> >
> > https://github.com/rmannibucau>
> >
> > > | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > >
> > > <
> >
> > https://www.packtpub.com/application-development/java-ee-8-high-performanc
> > e
> >
> > > Le dim. 12 juil. 2020 à 18:10, Romain Manni-Bucau
> > > <[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]

Reply | Threaded
Open this post in threaded view
|

Re: custom default lifecycle per project

Romain Manni-Bucau
Le ven. 17 juil. 2020 à 00:03, Hervé BOUTEMY <[hidden email]> a
écrit :

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

There is a my-test in the custom binding defined in the sample.
In current flavor it replaces default one so no issue.


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

Ok, then it defeats one of the original goal (to not modify the reactor and
add a module on the critical path of the project).


>
> > So IMHO this is not an option for one of the original goals to not modify
> > the user reactor.
> there is a goal to not modify the user reactor? why?
>

Cause:
1. it slows down the overall build significatively compared to an extension
2. it makes the project more noisy in all env (console can be ok but IDE
too - don't think 1 module project but ~30 modules ones, if you add 5
modules for that, it is a lot of noise for nothing)
3. keep in mind we enrich maven setup so we inject something already
"built" virtually, we don't need to be in the build itself
4. from a design perspective, it is not part of the build so shouldn't be
there
5. it shouldn't be installed + deployed and it shouldn't require to fake
the distribution management to something like target


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

Yes and no.
Yes cause technically you are right - but see you start stacking solutions
instead of having one and since it is user facing it sounds wrong and
overcomplex.
No because as an user you don't care there are bindings, lifecycles and
packaging, you only care about your build graph, anything outside this
primary concept is internal and shouldn't be exposed (in the extension).


>
> >
> > > > 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]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: custom default lifecycle per project

Hervé BOUTEMY
Le vendredi 17 juillet 2020, 08:22:10 CEST Romain Manni-Bucau a écrit :
> Le ven. 17 juil. 2020 à 00:03, Hervé BOUTEMY <[hidden email]> a

> > I don't get what "mvn my-test" means: there is no "my-test" phase
> > and I don't understand how your custom lifecycle shares some phases with
> > default lifecycle, but has some specific ones: I fear there will be
> > conflicts
>
> There is a my-test in the custom binding defined in the sample.
> In current flavor it replaces default one so no issue.
I don't understand yet, I'll dig into that


> > and it's not a "fake" module: it's a module to define the "series of
> > plugins
> > executions that are expected to be able to be composed
> > yes, it's not a pure internal module, not producing by itself any code
> > compilation
>
> Ok, then it defeats one of the original goal (to not modify the reactor and
> add a module on the critical path of the project).
>
> > > So IMHO this is not an option for one of the original goals to not
> > > modify
> > > the user reactor.
> >
> > there is a goal to not modify the user reactor? why?
>
> Cause:
> 1. it slows down the overall build significatively compared to an extension
> 2. it makes the project more noisy in all env (console can be ok but IDE
> too - don't think 1 module project but ~30 modules ones, if you add 5
> modules for that, it is a lot of noise for nothing)
> 3. keep in mind we enrich maven setup so we inject something already
> "built" virtually, we don't need to be in the build itself
> 4. from a design perspective, it is not part of the build so shouldn't be
> there
> 5. it shouldn't be installed + deployed and it shouldn't require to fake
> the distribution management to something like target
thanks for taking time to write such detailed analysis: I better understand
what you want to avoid

I'll add one key aspect to me: putting in a pom is a way to reuse. I hope
aggregation solution will not only permit ad-hoc configuration.

FYI, when working on build vs consumer POM, one conclusion was that most POMs
in a repository are consumer POM = POMs of libraries that will be used as
dependencies, but a few ones are build POM:
- parent POM
- BOM POM, to permit dependencyManagement import
that's not a surprise that reusable plugin/pluginManagement configuration would
require to publish a build POM to the repository
But I see your point that in an ad-hoc non-reusable configuration, this extra
build POM currently costs a build module, which should be avoided

> >
> > the fact that we need more phases is another issue: I was not trying to
> > solve
> > that one, that is IMHO completely orthogonal to the build composition
> > objective
> > of course, mixing build composition and additional phases brings a lot of
> > power
>
> Yes and no.
> Yes cause technically you are right - but see you start stacking solutions
> instead of having one and since it is user facing it sounds wrong and
> overcomplex.
> No because as an user you don't care there are bindings, lifecycles and
> packaging, you only care about your build graph, anything outside this
> primary concept is internal and shouldn't be exposed (in the extension).
IMHO, there are 2 levels of users: pure user, who only build and don't want to
understand, and more power user who adds new build structure
the second type of users has to see some inernals: but I get your point, he
should not see too much
He's not a plugin developer...

FYI, I'll be out for a few days, so may not answer: this is not because of
lack of interest, but lack of connectivity :)

And I'll now need some time to dig, test, propose test implementations...

Nice discussion, I hope others can follow and we'll end up with something to
merge

Regards,

Hervé



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