Re: custom default lifecycle per project

[Romain Manni-Bucau]

Le ven. 17 juil. 2020 à 09:31, Hervé BOUTEMY  a
écrit :

> Le vendredi 17 juillet 2020, 08:22:10 CEST Romain Manni-Bucau a écrit :
> > Le ven. 17 juil. 2020 à 00:03, Hervé BOUTEMY  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.
>

Hmm, technically al these solutions are strictly equivalent:

1. using an extension to read files "somewhere"
2. using a plugin and injecting all the needing conf (extremely we can say
give part of maven IoC control) in ) in 
3. using a pom as a template ("import")

But agree that having a built-in solution is saner so I suppose we should
find how to do it in Maven N+1 and backport it as possible with
modelversion=4.


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

Thinking out loud - another time sorry,  a custom packaging - as a marker -
can enable to handle it in maybe more cleanly (overriding or patching some
component):
build

This would let maven know it is a build module then the lifecycle can be -
hope we can bypass reuse of existing plugin to make it faster and avoid a
tons of mojo instantiation:
1. if only descriptors -> inject them and bypass most of module handling
2. if java code -> build and add it as an exploded extension (directly in
maven-core)? (nice to have, likely just a thought and not needed for this
thread topic but I see cases it can enable in the future)

The advantage is that this wouldn't be a real reactor module but strictly
equivalent to an extension.
Limitation will be that it will not be able to use all the pom strength
(same limitation than afterMavenProjectRead hook more or less) but I think
it is more than enough for this kind of need already.

Also sounds like a way to do it today and tomorrow without much breaking
change.

Think it enables to really define custom phases and therefore to handle
plugin list merge properly (as being global).
Finally it avoids to have to predefine a tons of phases "in case of"
because you can add the phases you need when required and not upfront so
build can stay lean.


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

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  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: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: custom default lifecycle per project

[Romain Manni-Bucau]

Le ven. 17 juil. 2020 à 00:03, Hervé BOUTEMY  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  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 
> 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" (?).
> > 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.
> > >

Re: custom default lifecycle per project

[Hervé BOUTEMY]

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

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

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

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

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

> 
> > > So it can be about defining a new  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
> > 

Re: custom default lifecycle per project

[Romain Manni-Bucau]

Le jeu. 16 juil. 2020 à 00:09, Hervé BOUTEMY  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  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.
Maybe it needs a new "config API" (?).
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?
So IMHO this is not an option for one of the original goals to not modify
the user reactor.


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


>
> >
> > So it can be about defining a new  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
> > > import that imports content?
> > >
> > > Regards,
> > >
> > > 

Re: custom default lifecycle per project

[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  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  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
> > import 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  but
> > > order is the straight definition order for example) and autowire
> > 
> > everything
> > 
> > > as expected through an extension to 

Re: custom default lifecycle per project

[Romain Manni-Bucau]

Le mar. 14 juil. 2020 à 20:01, Hervé BOUTEMY  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.


>
> 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).
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.
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?

So it can be about defining a new  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) whereas the packaging+binding option is
about defining the global graph (of one new module type) explicitly.


>
> 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
> import 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  but
> > order is the straight definition order for example) and autowire
> everything
> > as expected through an extension to avoid all the headaches associated
> with
> > the inheritance and other indirections making the pom execution hard to
> > follow. The issue with this one is to lose the aliasing feature.
> >
> > [1]
> >
> https://github.com/rmannibucau/custom-lifecycle-extension/tree/master/sample
> > [2]
> >
> https://github.com/rmannibucau/custom-lifecycle-extension/blob/master/sample
> > /pom.xml#L10 [3]
> >
> https://github.com/rmannibucau/custom-lifecycle-extension/blob/master/sample
> > /.extensions/custom/mappings.xml
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> https://github.com/rmannibucau>
> > | LinkedIn  | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le dim. 12 juil. 2020 à 18:10, Romain Manni-Bucau 
> a
> >
> > écrit :
> > > Side topic - still thinking out loud - which is also covered by custom
> > > lifecycles: aliases. A common need is to alias a complex command ("mvn
> > 

Re: custom default lifecycle per project

[Hervé BOUTEMY]

in this example, you strictly define a new "my-mapping" packaging, like done in 
Maven core for every default packagings [1] with documentation in [2]: don't 
call it bindings, but simply "packaging-bindings.xml" and it's more clear

the more I think about it, the more I feel that what we need is 
pluginManagement and eventually plugins import, like we did in the past for 
dependencyManagement [3]

This would permit:
- to import plugins versions form an external source,
- share plugins configurations and executions either in the reactor, either 
from outside

I still don't know if this import should be triggered as a dependencyManagement 
scope, like "import" scope was added

Or if we could do something at dependencyManagement and/or dependency level.
Given "extensions" is a boolean represented as a String (for inheritance 
reasons), why not use this String to have support 
import 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  but
> order is the straight definition order for example) and autowire everything
> as expected through an extension to avoid all the headaches associated with
> the inheritance and other indirections making the pom execution hard to
> follow. The issue with this one is to lose the aliasing feature.
> 
> [1]
> https://github.com/rmannibucau/custom-lifecycle-extension/tree/master/sample
> [2]
> https://github.com/rmannibucau/custom-lifecycle-extension/blob/master/sample
> /pom.xml#L10 [3]
> https://github.com/rmannibucau/custom-lifecycle-extension/blob/master/sample
> /.extensions/custom/mappings.xml
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github 
> | LinkedIn  | Book
>  >
> 
> 
> Le dim. 12 juil. 2020 à 18:10, Romain Manni-Bucau  a
> 
> écrit :
> > Side topic - still thinking out loud - which is also covered by custom
> > lifecycles: aliases. A common need is to alias a complex command ("mvn
> > docker" executing "mvn dependency:build-classpath git-commit:generate
> > docker:bundle docker-java:cds" to give an idea), with default or merged
> > lifecycles it is hard to make relevant. Indeed, an option is a custom
> > plugin or extension reading aliases somewhere and hacking lifecycleStater
> > to stash/pop the real goal to execute it, works but is a workaround
> > whereas
> > custom lifecycle gives a proper solution to that.
> > 
> > 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  |  Blog
> >  | Old Blog
> >  | Github
> >  | LinkedIn
> >  | Book
> >  > ce>
> > 
> > 
> > Le dim. 12 juil. 2020 à 11:58, Romain Manni-Bucau 
> > 
> > a écrit :
> >> Le dim. 12 juil. 2020 à 11:26, Hervé BOUTEMY  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  a
> >>> > 
> >>> > écrit :
> >>> > > Le samedi 11 juillet 2020, 12:55:37 CEST Romain Manni-Bucau a écrit :
> >>> > > > Le sam. 11 juil. 2020 à 12:09, Hervé BOUTEMY <
> >>> 
> >>> herve.bout...@free.fr> a
> >>> 
> >>> > > > écrit :
> >>> > > > > are really your plugin bindings so specific to your build that
> >>> 
> >>> they
> >>> 
> >>> > > could
> >>> > > 
> >>> > > > > not be reused and need full ad-hoc definition?
> >>> > > > 
> >>> > > > Think so
> >>> > > > 
> >>> > > > > I imagined to provide composite packaging:
> >>> > > > > war+front+living-doc+docker
> >>> > > > > 
> >>> > > > > in fact, 

Re: custom default lifecycle per project

[Romain Manni-Bucau]

Le dim. 12 juil. 2020 à 23:04, Hervé BOUTEMY  a
écrit :

> Le dimanche 12 juillet 2020, 18:10:59 CEST Romain Manni-Bucau a écrit :
> > Side topic - still thinking out loud - which is also covered by custom
> > lifecycles: aliases. A common need is to alias a complex command ("mvn
> > docker" executing "mvn dependency:build-classpath git-commit:generate
> > docker:bundle docker-java:cds" to give an idea), with default or merged
> > lifecycles it is hard to make relevant. Indeed, an option is a custom
> > plugin or extension reading aliases somewhere and hacking lifecycleStater
> > to stash/pop the real goal to execute it, works but is a workaround
> whereas
> > custom lifecycle gives a proper solution to that.
> from experience with site lifecycle in parallel to default lifecycle,
> interactions between lifecycles are hard to maintain: that's why we have
> "no-
> fork" reports in addition to "fork"
>
> in your docker case, how would be your docker lifecycle be related or not
> to
> default lifecycle?
>

Guess both cases are realistic.
Generally speaking, it is part of the default build - it is the same as
building a jar for the project, you just have a -Dfoo.skip to bypass it if
needed.
But I also saw some docker registry a bit "buggy" so the docker build+push
can need to be done separately to not fail releases, so here it would be a
"meta-plugin" aggregating N plugins in one command - but still must be done
in the project and not packaged as another plugin (.jar).


>
> >
> > 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  |  Blog
> >  | Old Blog
> >  | Github <
> https://github.com/rmannibucau>
> > | LinkedIn  | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le dim. 12 juil. 2020 à 11:58, Romain Manni-Bucau 
> a
> >
> > écrit :
> > > Le dim. 12 juil. 2020 à 11:26, Hervé BOUTEMY  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 
> 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
> > >> > > > 
> > >>
> > >> 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:
> > >> > > > > 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
> > >> > > >
> > >> > > > 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 

Re: custom default lifecycle per project

[Romain Manni-Bucau]

Le dim. 12 juil. 2020 à 23:01, Hervé BOUTEMY  a
écrit :

> Le dimanche 12 juillet 2020, 11:58:08 CEST Romain Manni-Bucau a écrit :
> > Le dim. 12 juil. 2020 à 11:26, Hervé BOUTEMY  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 
> a
> > > >
> > > > écrit :
> > > > > Le samedi 11 juillet 2020, 12:55:37 CEST Romain Manni-Bucau a
> écrit :
> > > > > > Le sam. 11 juil. 2020 à 12:09, Hervé BOUTEMY <
> herve.bout...@free.fr>
> > >
> > > a
> > >
> > > > > > écrit :
> > > > > > > are really your plugin bindings so specific to your build that
> > > > > > > they
> > > > >
> > > > > could
> > > > >
> > > > > > > not be reused and need full ad-hoc definition?
> > > > > >
> > > > > > Think so
> > > > > >
> > > > > > > I imagined to provide composite packaging:
> > > > > > > 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
> > > > > >
> > > > > > 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.
> perhaps the plugins should be enhanced
>
> > 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.
> if default bindings can't work, sub-packaging is more flexible, providing
> composition in a structured way, no?
>

It is one way but I think it is not a real option (N work vs 1 for an
extension or maven).


>
> >
> > > > 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).
> sorry, I don't understand: I really miss concrete examples
>

If I have, as in the linked project before, N (>1) modules using the same
structure, then I must define the specific plugin N times instead of just
importing the new lifecycle/packaging.
When it is about 1 plugin it is 1-1 but often it is 5-6 plugins at least so
it makes the poms harder to maintain for no real reason and the custom
lifecycle or a parent is way less expensive.
However, the parent option is not justified by anything except a maven
limitation today and this is one thing I'd like to enhance.


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

Re: custom default lifecycle per project

[Hervé BOUTEMY]

Le dimanche 12 juillet 2020, 18:10:59 CEST Romain Manni-Bucau a écrit :
> Side topic - still thinking out loud - which is also covered by custom
> lifecycles: aliases. A common need is to alias a complex command ("mvn
> docker" executing "mvn dependency:build-classpath git-commit:generate
> docker:bundle docker-java:cds" to give an idea), with default or merged
> lifecycles it is hard to make relevant. Indeed, an option is a custom
> plugin or extension reading aliases somewhere and hacking lifecycleStater
> to stash/pop the real goal to execute it, works but is a workaround whereas
> custom lifecycle gives a proper solution to that.
from experience with site lifecycle in parallel to default lifecycle, 
interactions between lifecycles are hard to maintain: that's why we have "no-
fork" reports in addition to "fork"

in your docker case, how would be your docker lifecycle be related or not to 
default lifecycle?

> 
> What I'm unsure today is if the custom lifecycle must be fully explicit or
> can insert phases and goals in an existing lifecycle ("patch mode"), not
> sure what is the simplest for users.
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github 
> | LinkedIn  | Book
>  >
> 
> 
> Le dim. 12 juil. 2020 à 11:58, Romain Manni-Bucau  a
> 
> écrit :
> > Le dim. 12 juil. 2020 à 11:26, Hervé BOUTEMY  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  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
> >> > > > 
> >> 
> >> 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:
> >> > > > > 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
> >> > > > 
> >> > > > 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 

Re: custom default lifecycle per project

[Hervé BOUTEMY]

Le dimanche 12 juillet 2020, 11:58:08 CEST Romain Manni-Bucau a écrit :
> Le dim. 12 juil. 2020 à 11:26, Hervé BOUTEMY  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  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 
> > 
> > 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:
> > > > > > 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
> > > > > 
> > > > > 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.
perhaps the plugins should be enhanced

> 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.
if default bindings can't work, sub-packaging is more flexible, providing 
composition in a structured way, no?

> 
> > > 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).
sorry, I don't understand: I really miss concrete examples

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

Re: custom default lifecycle per project

[Romain Manni-Bucau]

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  but
order is the straight definition order for example) and autowire everything
as expected through an extension to avoid all the headaches associated with
the inheritance and other indirections making the pom execution hard to
follow. The issue with this one is to lose the aliasing feature.

[1]
https://github.com/rmannibucau/custom-lifecycle-extension/tree/master/sample
[2]
https://github.com/rmannibucau/custom-lifecycle-extension/blob/master/sample/pom.xml#L10
[3]
https://github.com/rmannibucau/custom-lifecycle-extension/blob/master/sample/.extensions/custom/mappings.xml

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le dim. 12 juil. 2020 à 18:10, Romain Manni-Bucau  a
écrit :

> Side topic - still thinking out loud - which is also covered by custom
> lifecycles: aliases. A common need is to alias a complex command ("mvn
> docker" executing "mvn dependency:build-classpath git-commit:generate
> docker:bundle docker-java:cds" to give an idea), with default or merged
> lifecycles it is hard to make relevant. Indeed, an option is a custom
> plugin or extension reading aliases somewhere and hacking lifecycleStater
> to stash/pop the real goal to execute it, works but is a workaround whereas
> custom lifecycle gives a proper solution to that.
>
> 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  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | Book
> 
>
>
> Le dim. 12 juil. 2020 à 11:58, Romain Manni-Bucau 
> a écrit :
>
>>
>>
>> Le dim. 12 juil. 2020 à 11:26, Hervé BOUTEMY  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  a
>>> >
>>> > écrit :
>>> > > Le samedi 11 juillet 2020, 12:55:37 CEST Romain Manni-Bucau a écrit :
>>> > > > Le sam. 11 juil. 2020 à 12:09, Hervé BOUTEMY <
>>> herve.bout...@free.fr> a
>>> > > >
>>> > > > écrit :
>>> > > > > are really your plugin bindings so specific to your build that
>>> they
>>> > >
>>> > > could
>>> > >
>>> > > > > not be reused and need full ad-hoc definition?
>>> > > >
>>> > > > Think so
>>> > > >
>>> > > > > I imagined to provide composite packaging:
>>> > > > > 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
>>> > > >
>>> > > > 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 

Re: custom default lifecycle per project

[Romain Manni-Bucau]

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  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le dim. 12 juil. 2020 à 11:58, Romain Manni-Bucau  a
écrit :

>
>
> Le dim. 12 juil. 2020 à 11:26, Hervé BOUTEMY  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  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 
>> 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:
>> > > > > 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
>> > > >
>> > > > 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 

Re: custom default lifecycle per project

[Romain Manni-Bucau]

Le dim. 12 juil. 2020 à 11:26, Hervé BOUTEMY  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  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 
> 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:
> > > > > 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
> > > >
> > > > 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 

Re: custom default lifecycle per project

[Hervé BOUTEMY]

Le dimanche 12 juillet 2020, 10:37:36 CEST Romain Manni-Bucau a écrit :
> Le sam. 11 juil. 2020 à 23:01, Hervé BOUTEMY  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  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:
> > > > 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
> > > 
> > > 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)

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

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

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

Re: custom default lifecycle per project

[Romain Manni-Bucau]

Le sam. 11 juil. 2020 à 23:01, Hervé BOUTEMY  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  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:
> > > 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
> >
> > 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


Then you can add openapi.json generation with geronimo-openapi-maven-plugin

You have the same with a war instead of a jar.

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.


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


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

Re: custom default lifecycle per project

[Hervé BOUTEMY]

Le samedi 11 juillet 2020, 12:55:37 CEST Romain Manni-Bucau a écrit :
> Le sam. 11 juil. 2020 à 12:09, Hervé BOUTEMY  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:
> > 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
> 
> Ok but "front" means already 5-6 different bindings at least
nice, that proves that this "sub-packaging" is useful: what would be the 
bindings, please,  to make this case very concrete?

> and
> "living-doc" is per project by design (depends your stack, leads to
> different set of plugins).
let's dig a little bit: can you provide a few examples of stacks and 
corresponding bindings, please?
perhaps "living-doc" is too generic, and should be more specific per stack

> 
> I envision a reusable solution can be a thing but it is way more complex
> than having these dynamic bindings which are straight forward on user side
> so I prefer to let the user adapt maven to his need rather than the
> opposite.
> 
> Also note that your proposal makes us moving one step forward but we stay
> blocked: how do you merge phases and plugin order? This can also depends on
> projetcs and "+" only allows one order whereas order can be different
> between main and test plugins so you would need a complete dsl, not that
> easy compared to being explicit imo.
sure, this part is only one step
I need examples of such "merge phase" and order requirements to better see 
what mechanisms would be useful

> 
> > this could be injected by the LifecycleBindingsInjector [1]
> > 
> > WDYT?
> > 
> > Regards,
> > 
> > Hervé
> > 
> > [1]
> > https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/a
> > pache/maven/model/plugin/DefaultLifecycleBindingsInjector.java#L63> 
> > Le vendredi 10 juillet 2020, 19:33:35 CEST Romain Manni-Bucau a écrit :
> > > Looked a bit on how to impl this kind of extension and it would help if
> > > maven wouldn't assume everything is hardcoded in components.xml (or eq)
> > 
> > or
> > 
> > > if sisu would enable to reuse its plexus scanner which has a very low
> > > visibility today. It is also weird to not have access to the guice
> > 
> > injector
> > 
> > > in components and have to go through the plexuscontainer to lookup
> > > beans.
> > > 
> > > As code often says more than words, here a small hello world showing
> > > that
> > > reusing this part of maven "core" is not that trivial:
> > > 
> > > @Component(role = AbstractMavenLifecycleParticipant.class)
> > > public class CustomLifecycleExtension extends
> > > AbstractMavenLifecycleParticipant {
> > > 
> > > @Inject
> > > private PlexusContainer container;
> > > 
> > > @Override
> > > public void afterProjectsRead(final MavenSession session) throws
> > > 
> > > MavenExecutionException {
> > > 
> > > final Path root =
> > > 
> > > session.getRequest().getMultiModuleProjectDirectory().toPath();
> > > 
> > > final Path configFolder = root.resolve(".extensions/custom");
> > > 
> > > final Path mappings = configFolder.resolve("mappings.xml");
> > > if (Files.exists(mappings)) {
> > > 
> > > final ComponentSetDescriptor componentSet =
> > > 
> > > readAs(mappings, ComponentSetDescriptor.class, null);
> > > 
> > > System.out.println(componentSet);
> > > 
> > > }
> > > 
> > > super.afterProjectsRead(session);
> > > 
> > > }
> > > 
> > > private  T 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 ? "<" + wrapper + ">" : "") +
> > > 
> > > new String(Files.readAllBytes(path),
> > > 
> > > StandardCharsets.UTF_8)
> > > 
> > > .replaceFirst("<\\?[^>]+\\?>",
> > > 
> > > "").trim() + (wrapper != null ? "" : ""))); } catch
> > > (final Exception e) {
> > > 
> > > 

Re: custom default lifecycle per project

[Hervé BOUTEMY]

Le samedi 11 juillet 2020, 12:39:01 CEST Robert Scholte a écrit :
> such solution confirms that packaging is used for 2 different things, which
> should be split in the next pom definition: 
no, it can't be split
because this value is the link from the objective (I want to build a jar or a 
war) to the way to attain the objective (what are the build tasks to do it?)

> packaging: the resulting artifact
there are many resulting artifacts from one POM build
I know there is one eventual "main" one; is there anywhere that something is 
coded to really get the main artifact? any pointer?

> binding: the bindings to use for the default/build lifecycle.

if we update the semantics of this POM packaging field, yes, every code that 
uses the value will have to be updated to take account of the update: no magic

Of course, we can also wait for POM v5 to add new build fields

> 
> 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/ap
> ache/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) {

Re: custom default lifecycle per project

[Romain Manni-Bucau]

Le sam. 11 juil. 2020 à 14:43, Robert Scholte  a
écrit :

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

I dont think it makes sense today, it is common to have 4-5 different
"packaging" per module - strictly speaking we always had pom and jar for
jat packaging. Nowdays we have jar, zip, openapi.json, docker, remote image
(oci) *per* module (often the project itself) and it is a good thing
compared to be forced to split in 5 fake module just to respect 1
package/module IMHO so let's drop packaging notion which is no more
matching the way we work/dev today and focus on lifecycle/binding only IMHO.



> Robert
> On 11-7-2020 12:59:23, Romain Manni-Bucau  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
> > 

Re: custom default lifecycle per project

[Robert Scholte]

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

Re: custom default lifecycle per project

[Romain Manni-Bucau]

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

Re: custom default lifecycle per project

[Romain Manni-Bucau]

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

Ok but "front" means already 5-6 different bindings at least and
"living-doc" is per project by design (depends your stack, leads to
different set of plugins).

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.


> 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 ? "<" + wrapper + ">" : "") +
> > 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 =
> > 

Re: custom default lifecycle per project

[Robert Scholte]

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.

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 

Re: custom default lifecycle per project

[Hervé BOUTEMY]

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

I imagined to provide composite packaging: 
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 ? "<" + wrapper + ">" : "") +
> 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 ? "<" + wrapper + ">" : "") +
> 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 

Re: custom default lifecycle per project

[Romain Manni-Bucau]

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 ? "<" + wrapper + ">" : "") +
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 ? "<" + wrapper + ">" : "") +
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 

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  a
écrit :

> Le samedi 4 juillet 2020, 23:15:19 CEST Romain Manni-Bucau a écrit :
> > Le sam. 4 juil. 2020 à 18:09, Stephen Connolly <
> >
> > stephen.alan.conno...@gmail.com> a écrit :
> > > On Sat 4 Jul 2020 at 16:54, Romain Manni-Bucau 
> > >
> > > wrote:
> > > > Le sam. 4 juil. 2020 à 16:38, Stephen Connolly <
> > > >
> > > > stephen.alan.conno...@gmail.com> a écrit :
> > > > > On Sat 4 Jul 2020 at 10:21, Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > > > >
> > > > > wrote:
> > > > > > Well, there are two points I'd like to emphasis:
> > > > > >
> > > > > > 1. I dont think we should wait for 2 majors to get that as a
> > > > > > feature,
> > > > >
> > > > > would
> > > > >
> > > > > > be too late IMHO
> > > > >
> > > > > Well does my dynamic phases PR do what you need?
> > > >
> > > > Partly if you think to priority one, it moves the issue a bit further
> > > > due
> > > > to priority usage which is not great in practice compare to names +
> > > > requires to use 100, 200 etc to be able to inject plugin between two
> > >
> > > others
> > >
> > > > in children with the project becoming more complex. Think we must
> have
> > > > an
> > > > explicit control here even with complex hierarchies.
> > >
> > > If you need that much control then you’re doing something wrong.
> > >
> > > How often do you need more than 3-4 plugin executions in strict ordered
> > > succession?
> >
> > All my projects not being libraries since ~7 years. Frontend is often 3
> > exec, living doc is often 4-5 exec, docker is often 3-4 exec too (needs
> > some computation steps for cds or build time precomputation things) plus
> > custom resources, git integration meta, custom artifact attachement,
> etc...
> I like this approach: can we share a demo project to have a concrete case?
>
> > These are very common use cases today in the same build. It is key to
> keep
> > a single build orchestrator (mvn) for team sharing and CI
> > industrialization. Issue being each project set it up differently and
> > making it generic is often overcomplex (living doc can be jbake plugin
> or a
> > plain mvn exec:java or a groovy script etc... depending doc output and
> > reusability of the code+libs). With software lifecycle passing from years
> > to months we are in a more dynamic and changing ecosystem our beloved
> build
> > tool should align on IMHO.
> I suppose we all agree from very high level point of view: IMHO, we now
> need
> to dig a little more in detail on typical cases, with sample demo builds.
> Then
> we'll work on solutions.
>
> >
> > > That sounds like a dedicated plugin use case
> >
> > This is why i want a generic extension as solution, each project have its
> > specificities and standardizing it is hard and likely adds too much
> > complexity compared to let the user enriching default phases (can be a
> > merge of 2 packagings instead of a new one fully defined).
> yes, looks like adding "sub-packaging"s for additional build aspects
> (frontend, living doc, container, ...), taking care of eventual
> interactions
> between each one
>
> >
> > If I stick to plain maven and want a clean build without workarounds I
> must
> > write plugins+extensions for each of the apps - plugins and ext must be
> > reusable or not be IMHO, sounds not great whereas maven backbone is very
> > good, this is why I want to push it to the next step to keep a high
> quality
> > unique (in terms of #tools) build for projects.
> >
> > I dont have big blockers to do it without patching maven itself so will
> not
> > spend much energy if idea is not liked but I hope maven tackles it some
> day
> > in a built in fashion (which means better IDE and ecosystem integration
> > even if personally I dont abuse of that).
> from experience, sharing a solution before sharing issues that the
> solution is
> expected to solve makes it hard to get consensus.
> You shared the high level issue: that's great.
> Now we must share sample builds.
> And work on solutions.
> I'm all in
>
> Regards,
>
> Hervé
>
> >
> > > > > > 2. Pom model is based on inheritance whereas years showed
> > > > > > composition
> > > >
> > > > and
> > > >
> > > > > > reuse is saner so IMHO it does not belong to pom but .mvn
> > > > >
> > > > > Your proposal would only work if all projects shared the same
> > > > > packaging
> > > >
> > > > as

Re: custom default lifecycle per project

[Hervé BOUTEMY]

Le samedi 4 juillet 2020, 23:15:19 CEST Romain Manni-Bucau a écrit :
> Le sam. 4 juil. 2020 à 18:09, Stephen Connolly <
> 
> stephen.alan.conno...@gmail.com> a écrit :
> > On Sat 4 Jul 2020 at 16:54, Romain Manni-Bucau 
> > 
> > wrote:
> > > Le sam. 4 juil. 2020 à 16:38, Stephen Connolly <
> > > 
> > > stephen.alan.conno...@gmail.com> a écrit :
> > > > On Sat 4 Jul 2020 at 10:21, Romain Manni-Bucau 
> > > > 
> > > > 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 à 

Re: custom default lifecycle per project

[Romain Manni-Bucau]

Le sam. 4 juil. 2020 à 18:09, Stephen Connolly <
stephen.alan.conno...@gmail.com> a écrit :

> On Sat 4 Jul 2020 at 16:54, Romain Manni-Bucau 
> wrote:
>
> > Le sam. 4 juil. 2020 à 16:38, Stephen Connolly <
> > stephen.alan.conno...@gmail.com> a écrit :
> >
> > > On Sat 4 Jul 2020 at 10:21, Romain Manni-Bucau 
> > > 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...
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.


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

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


> >
> >
> >
> > >
> > > > 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 
> 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 
> > > wrote:
> > > > > I agree I mixed both in my explanationcause 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 

Re: custom default lifecycle per project

[Tibor Digana]

Hi Romain,

Do you expect another phases (life cycle) for specific technologies or
packaging.
What phases would you expect in case of frontend technologies, e.g.
JavaScript-like Angular, ReactJS, Vue?
What phases in case of scrip-like technologies and native technologies?
Should these phases be hardcoded alternatives? Or a customizable life cycle?

Cheers
T


On Sat, Jul 4, 2020 at 6:09 PM Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> On Sat 4 Jul 2020 at 16:54, Romain Manni-Bucau 
> wrote:
>
> > Le sam. 4 juil. 2020 à 16:38, Stephen Connolly <
> > stephen.alan.conno...@gmail.com> a écrit :
> >
> > > On Sat 4 Jul 2020 at 10:21, Romain Manni-Bucau 
> > > 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 
> 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 
> > > wrote:
> > > > > I agree I mixed both in my explanationcause 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 

Re: custom default lifecycle per project

[Stephen Connolly]

On Sat 4 Jul 2020 at 16:54, Romain Manni-Bucau 
wrote:

> Le sam. 4 juil. 2020 à 16:38, Stephen Connolly <
> stephen.alan.conno...@gmail.com> a écrit :
>
> > On Sat 4 Jul 2020 at 10:21, Romain Manni-Bucau 
> > 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  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 
> > wrote:
> > > > I agree I mixed both in my explanationcause 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 

Re: custom default lifecycle per project

[Romain Manni-Bucau]

Le sam. 4 juil. 2020 à 16:38, Stephen Connolly <
stephen.alan.conno...@gmail.com> a écrit :

> On Sat 4 Jul 2020 at 10:21, Romain Manni-Bucau 
> 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.


>
> > 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  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 
> wrote:
> > > I agree I mixed both in my explanationcause 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]
> > 

Re: custom default lifecycle per project

[Stephen Connolly]

On Sat 4 Jul 2020 at 10:21, Romain Manni-Bucau 
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?


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

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


>
> Le sam. 4 juil. 2020 à 10:19, Robert Scholte  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  wrote:
> > I agree I mixed both in my explanationcause 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 

Re: custom default lifecycle per project

[Romain Manni-Bucau]

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

Le sam. 4 juil. 2020 à 10:19, Robert Scholte  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  wrote:
> I agree I mixed both in my explanationcause 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
> > >
> 

Re: custom default lifecycle per project

[Robert Scholte]

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  wrote:
I agree I mixed both in my explanationcause 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: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: custom default lifecycle per project

[Romain Manni-Bucau]

I agree I mixed both in my explanationcause 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: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

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  |  Blog
>  | Old Blog
>  | Github 
> | LinkedIn  | Book
>  >





-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

custom default lifecycle per project

[Romain Manni-Bucau]

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