Re: [discuss] extend extensions.xml to lifecycles/packaging and types?

[Romain Manni-Bucau]

Le jeu. 4 janv. 2024 à 13:17, Christoph Läubrich  a
écrit :

>  > Why? extension is global for the project so no copy needed.
>
> If you want to use it in different project I'm not aware how you can
> share extension.xml between them ... but a pom deployed somewhere can be
> reused (in pom.xml) also extension/extensions.xml cant contain any
> configuration)
>

s/project/modules/ ;)


>
>  > You can get a phase if it exists, not sure if you make it empty
>  > - was my point
>
> I see, well maybe it would better be named "empty-jar" and defines al
> phases of the usual jar except that it does not bind any plugins by
> default, or maybe thinking more about it maybe one should not use any
> name but a simple list e.g.
>
> 
> jar
>clean,custom,package,install (would default to
> lifecycle of packaging if not given)
>
>
> would define an (empty) lifecycle that has the phase
> clean,custom,package,install only and now you know the order one can
> bind plugins there...
>

This is more or less the idea except you define the chain in extensions.xml
to let be reused by submodules.
Inline you will need an aggregator pom and I'm not sure how well it will
sit in a packaging=pom pom defining it for children.


>
>
>
>
> Am 04.01.24 um 11:32 schrieb Romain Manni-Bucau:
> > Le jeu. 4 janv. 2024 à 10:37, Christoph Läubrich  a
> > écrit :
> >
> >>   > Kind of but it requires a lot of abstraction and inheritance abuse
> IMHO.
> >>
> >> Not completely sure, but of course all would need to inherit the same
> >> parent, maybe one can allow to "import" pom with plugin configuration as
> >> an alternative, but for extension.xml it is the same you need to copy it
> >> over to all child projects of course.
> >>
> >
> > Why? extension is global for the project so no copy needed.
> >
> >
> >>
> >>   > almost, you still need to associate phase(s) to each plugin
> >>
> >> Plugins can have a default phase that is chosen if not specified, still
> >> a lifecycle mapping would require that as well, so lifeycle mapping (as
> >> xml component xml) is just a little bit different syntax then?
> >>
> >
> > You can get a phase if it exists, not sure if you make it empty - was my
> > point
> >
> >
> >>
> >> Am 04.01.24 um 10:32 schrieb Romain Manni-Bucau:
> >>> Hi Christoph,
> >>>
> >>> commented inline
> >>>
> >>> Le jeu. 4 janv. 2024 à 10:19, Christoph Läubrich 
> a
> >>> écrit :
> >>>
>  Isn't it already possible to "extend" the lifecycle by simply putting
>  plugin + execution into root pom?
> 
> >>>
> >>> Kind of but it requires a lot of abstraction and inheritance abuse
> IMHO.
> >>> For a single module you are very right but for a 10+ project where 5+
> >>> modules will use the same kind of build it will require a pom in the
> >> middle
> >>> leading to werid structures like root/services/x/pom.xml
> >> root/lib/x/pom.xml
> >>> so composition would be better there - but you're right, not a blocker
> to
> >>> build the final deliverables.
> >>>
> >>>
> 
>  Main problem for me is that currently packaging == type == lifecycle,
>  otherwise one could simply have an "empty" lifecycle + whatever
>  packaging and simply bind anything you want tin pom.xml e.g.
> 
> 
>  
>    jar
>   empty (would default to packaging if not
>  given, where empty is just a lifecycle with no mappings)
>   
>    
> 
>   org.apache.maven.plugins
>   maven-jar-plugin
>   
>    
> ... define all your custom bindings here ...
> 
> 
> >>> almost, you still need to associate phase(s) to each plugin to be able
> to
> >>> run "mvn compile" "mvn test" or alike until we have an alias notion in
> >>> pom/extensions.xml (= say "mvn foo" means run these plugins but it is
> the
> >>> lifecycle somehow).
> >>>
> >>>
> >>>
> 
> 
>  Am 04.01.24 um 09:37 schrieb Romain Manni-Bucau:
> > Hi all,
> >
> > Reviewing and trying to follow Martin's thread about JPMS I thought
> >> about
> > the old issue that our build pipelines (plugins chain) is very hard
> to
> > customize.
> > Guillaume added the priority case but the clean solution proposed
> > originally was to define custom lifecycles (to add frontend, docker
>  builds
> > for ex) - more or less a custom AbstractLifecycleMappingProvider.
> >
> > I wonder if we shouldn't extend .mvn/extensions.xml (or root pom
> >  block) to support to define custom lifecycle mappings
> >> there
> > and potentially explicit new "types" too which would be great for
>  Martin's
> > work since it would allow to avoid undefined types and implicit jar
>  mapping
> > in a "strict" mode (to detect typos for ex since it must become
> open).
> >
> > So proposal is to extend extension to get more configuration - and
> >> coded
> > extensions can indeed plug themselves there.
> > The main challenge seems 

Re: [discuss] extend extensions.xml to lifecycles/packaging and types?

[Christoph Läubrich]

> Why? extension is global for the project so no copy needed.

If you want to use it in different project I'm not aware how you can 
share extension.xml between them ... but a pom deployed somewhere can be 
reused (in pom.xml) also extension/extensions.xml cant contain any 
configuration)


> You can get a phase if it exists, not sure if you make it empty
> - was my point

I see, well maybe it would better be named "empty-jar" and defines al 
phases of the usual jar except that it does not bind any plugins by 
default, or maybe thinking more about it maybe one should not use any 
name but a simple list e.g.



   jar
  clean,custom,package,install (would default to 
lifecycle of packaging if not given)

  

would define an (empty) lifecycle that has the phase 
clean,custom,package,install only and now you know the order one can 
bind plugins there...





Am 04.01.24 um 11:32 schrieb Romain Manni-Bucau:

Le jeu. 4 janv. 2024 à 10:37, Christoph Läubrich  a
écrit :


  > Kind of but it requires a lot of abstraction and inheritance abuse IMHO.

Not completely sure, but of course all would need to inherit the same
parent, maybe one can allow to "import" pom with plugin configuration as
an alternative, but for extension.xml it is the same you need to copy it
over to all child projects of course.



Why? extension is global for the project so no copy needed.




  > almost, you still need to associate phase(s) to each plugin

Plugins can have a default phase that is chosen if not specified, still
a lifecycle mapping would require that as well, so lifeycle mapping (as
xml component xml) is just a little bit different syntax then?



You can get a phase if it exists, not sure if you make it empty - was my
point




Am 04.01.24 um 10:32 schrieb Romain Manni-Bucau:

Hi Christoph,

commented inline

Le jeu. 4 janv. 2024 à 10:19, Christoph Läubrich  a
écrit :


Isn't it already possible to "extend" the lifecycle by simply putting
plugin + execution into root pom?



Kind of but it requires a lot of abstraction and inheritance abuse IMHO.
For a single module you are very right but for a 10+ project where 5+
modules will use the same kind of build it will require a pom in the

middle

leading to werid structures like root/services/x/pom.xml

root/lib/x/pom.xml

so composition would be better there - but you're right, not a blocker to
build the final deliverables.




Main problem for me is that currently packaging == type == lifecycle,
otherwise one could simply have an "empty" lifecycle + whatever
packaging and simply bind anything you want tin pom.xml e.g.



  jar
 empty (would default to packaging if not
given, where empty is just a lifecycle with no mappings)
 
  
   
 org.apache.maven.plugins
 maven-jar-plugin
 
  
   ... define all your custom bindings here ...



almost, you still need to associate phase(s) to each plugin to be able to
run "mvn compile" "mvn test" or alike until we have an alias notion in
pom/extensions.xml (= say "mvn foo" means run these plugins but it is the
lifecycle somehow).






Am 04.01.24 um 09:37 schrieb Romain Manni-Bucau:

Hi all,

Reviewing and trying to follow Martin's thread about JPMS I thought

about

the old issue that our build pipelines (plugins chain) is very hard to
customize.
Guillaume added the priority case but the clean solution proposed
originally was to define custom lifecycles (to add frontend, docker

builds

for ex) - more or less a custom AbstractLifecycleMappingProvider.

I wonder if we shouldn't extend .mvn/extensions.xml (or root pom
 block) to support to define custom lifecycle mappings

there

and potentially explicit new "types" too which would be great for

Martin's

work since it would allow to avoid undefined types and implicit jar

mapping

in a "strict" mode (to detect typos for ex since it must become open).

So proposal is to extend extension to get more configuration - and

coded

extensions can indeed plug themselves there.
The main challenge seems to be to re-evaluate the mappings but looks

doable.

High level it is more or less "let the pom/.mvn inject maven components
without coding/by declaration".

Hope it makes sense, let me know if it is worth investigating more or

if

the idea is too particular to my old needs.

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






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

Re: [discuss] extend extensions.xml to lifecycles/packaging and types?

[Romain Manni-Bucau]

Le jeu. 4 janv. 2024 à 10:37, Christoph Läubrich  a
écrit :

>  > Kind of but it requires a lot of abstraction and inheritance abuse IMHO.
>
> Not completely sure, but of course all would need to inherit the same
> parent, maybe one can allow to "import" pom with plugin configuration as
> an alternative, but for extension.xml it is the same you need to copy it
> over to all child projects of course.
>

Why? extension is global for the project so no copy needed.


>
>  > almost, you still need to associate phase(s) to each plugin
>
> Plugins can have a default phase that is chosen if not specified, still
> a lifecycle mapping would require that as well, so lifeycle mapping (as
> xml component xml) is just a little bit different syntax then?
>

You can get a phase if it exists, not sure if you make it empty - was my
point


>
> Am 04.01.24 um 10:32 schrieb Romain Manni-Bucau:
> > Hi Christoph,
> >
> > commented inline
> >
> > Le jeu. 4 janv. 2024 à 10:19, Christoph Läubrich  a
> > écrit :
> >
> >> Isn't it already possible to "extend" the lifecycle by simply putting
> >> plugin + execution into root pom?
> >>
> >
> > Kind of but it requires a lot of abstraction and inheritance abuse IMHO.
> > For a single module you are very right but for a 10+ project where 5+
> > modules will use the same kind of build it will require a pom in the
> middle
> > leading to werid structures like root/services/x/pom.xml
> root/lib/x/pom.xml
> > so composition would be better there - but you're right, not a blocker to
> > build the final deliverables.
> >
> >
> >>
> >> Main problem for me is that currently packaging == type == lifecycle,
> >> otherwise one could simply have an "empty" lifecycle + whatever
> >> packaging and simply bind anything you want tin pom.xml e.g.
> >>
> >>
> >> 
> >>  jar
> >> empty (would default to packaging if not
> >> given, where empty is just a lifecycle with no mappings)
> >> 
> >>  
> >>   
> >> org.apache.maven.plugins
> >> maven-jar-plugin
> >> 
> >>  
> >>   ... define all your custom bindings here ...
> >>
> >>
> > almost, you still need to associate phase(s) to each plugin to be able to
> > run "mvn compile" "mvn test" or alike until we have an alias notion in
> > pom/extensions.xml (= say "mvn foo" means run these plugins but it is the
> > lifecycle somehow).
> >
> >
> >
> >>
> >>
> >> Am 04.01.24 um 09:37 schrieb Romain Manni-Bucau:
> >>> Hi all,
> >>>
> >>> Reviewing and trying to follow Martin's thread about JPMS I thought
> about
> >>> the old issue that our build pipelines (plugins chain) is very hard to
> >>> customize.
> >>> Guillaume added the priority case but the clean solution proposed
> >>> originally was to define custom lifecycles (to add frontend, docker
> >> builds
> >>> for ex) - more or less a custom AbstractLifecycleMappingProvider.
> >>>
> >>> I wonder if we shouldn't extend .mvn/extensions.xml (or root pom
> >>>  block) to support to define custom lifecycle mappings
> there
> >>> and potentially explicit new "types" too which would be great for
> >> Martin's
> >>> work since it would allow to avoid undefined types and implicit jar
> >> mapping
> >>> in a "strict" mode (to detect typos for ex since it must become open).
> >>>
> >>> So proposal is to extend extension to get more configuration - and
> coded
> >>> extensions can indeed plug themselves there.
> >>> The main challenge seems to be to re-evaluate the mappings but looks
> >> doable.
> >>> High level it is more or less "let the pom/.mvn inject maven components
> >>> without coding/by declaration".
> >>>
> >>> Hope it makes sense, let me know if it is worth investigating more or
> if
> >>> the idea is too particular to my old needs.
> >>>
> >>> Best,
> >>> 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
> >>
> >>
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [discuss] extend extensions.xml to lifecycles/packaging and types?

[Christoph Läubrich]

> Kind of but it requires a lot of abstraction and inheritance abuse IMHO.

Not completely sure, but of course all would need to inherit the same 
parent, maybe one can allow to "import" pom with plugin configuration as 
an alternative, but for extension.xml it is the same you need to copy it 
over to all child projects of course.


> almost, you still need to associate phase(s) to each plugin

Plugins can have a default phase that is chosen if not specified, still 
a lifecycle mapping would require that as well, so lifeycle mapping (as 
xml component xml) is just a little bit different syntax then?


Am 04.01.24 um 10:32 schrieb Romain Manni-Bucau:

Hi Christoph,

commented inline

Le jeu. 4 janv. 2024 à 10:19, Christoph Läubrich  a
écrit :


Isn't it already possible to "extend" the lifecycle by simply putting
plugin + execution into root pom?



Kind of but it requires a lot of abstraction and inheritance abuse IMHO.
For a single module you are very right but for a 10+ project where 5+
modules will use the same kind of build it will require a pom in the middle
leading to werid structures like root/services/x/pom.xml root/lib/x/pom.xml
so composition would be better there - but you're right, not a blocker to
build the final deliverables.




Main problem for me is that currently packaging == type == lifecycle,
otherwise one could simply have an "empty" lifecycle + whatever
packaging and simply bind anything you want tin pom.xml e.g.



 jar
empty (would default to packaging if not
given, where empty is just a lifecycle with no mappings)

 
  
org.apache.maven.plugins
maven-jar-plugin

 
  ... define all your custom bindings here ...



almost, you still need to associate phase(s) to each plugin to be able to
run "mvn compile" "mvn test" or alike until we have an alias notion in
pom/extensions.xml (= say "mvn foo" means run these plugins but it is the
lifecycle somehow).






Am 04.01.24 um 09:37 schrieb Romain Manni-Bucau:

Hi all,

Reviewing and trying to follow Martin's thread about JPMS I thought about
the old issue that our build pipelines (plugins chain) is very hard to
customize.
Guillaume added the priority case but the clean solution proposed
originally was to define custom lifecycles (to add frontend, docker

builds

for ex) - more or less a custom AbstractLifecycleMappingProvider.

I wonder if we shouldn't extend .mvn/extensions.xml (or root pom
 block) to support to define custom lifecycle mappings there
and potentially explicit new "types" too which would be great for

Martin's

work since it would allow to avoid undefined types and implicit jar

mapping

in a "strict" mode (to detect typos for ex since it must become open).

So proposal is to extend extension to get more configuration - and coded
extensions can indeed plug themselves there.
The main challenge seems to be to re-evaluate the mappings but looks

doable.

High level it is more or less "let the pom/.mvn inject maven components
without coding/by declaration".

Hope it makes sense, let me know if it is worth investigating more or if
the idea is too particular to my old needs.

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






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

Re: [discuss] extend extensions.xml to lifecycles/packaging and types?

[Romain Manni-Bucau]

Hi Christoph,

commented inline

Le jeu. 4 janv. 2024 à 10:19, Christoph Läubrich  a
écrit :

> Isn't it already possible to "extend" the lifecycle by simply putting
> plugin + execution into root pom?
>

Kind of but it requires a lot of abstraction and inheritance abuse IMHO.
For a single module you are very right but for a 10+ project where 5+
modules will use the same kind of build it will require a pom in the middle
leading to werid structures like root/services/x/pom.xml root/lib/x/pom.xml
so composition would be better there - but you're right, not a blocker to
build the final deliverables.


>
> Main problem for me is that currently packaging == type == lifecycle,
> otherwise one could simply have an "empty" lifecycle + whatever
> packaging and simply bind anything you want tin pom.xml e.g.
>
>
> 
> jar
>empty (would default to packaging if not
> given, where empty is just a lifecycle with no mappings)
>
> 
>  
>org.apache.maven.plugins
>maven-jar-plugin
>
> 
>  ... define all your custom bindings here ...
>
>
almost, you still need to associate phase(s) to each plugin to be able to
run "mvn compile" "mvn test" or alike until we have an alias notion in
pom/extensions.xml (= say "mvn foo" means run these plugins but it is the
lifecycle somehow).



>
>
> Am 04.01.24 um 09:37 schrieb Romain Manni-Bucau:
> > Hi all,
> >
> > Reviewing and trying to follow Martin's thread about JPMS I thought about
> > the old issue that our build pipelines (plugins chain) is very hard to
> > customize.
> > Guillaume added the priority case but the clean solution proposed
> > originally was to define custom lifecycles (to add frontend, docker
> builds
> > for ex) - more or less a custom AbstractLifecycleMappingProvider.
> >
> > I wonder if we shouldn't extend .mvn/extensions.xml (or root pom
> >  block) to support to define custom lifecycle mappings there
> > and potentially explicit new "types" too which would be great for
> Martin's
> > work since it would allow to avoid undefined types and implicit jar
> mapping
> > in a "strict" mode (to detect typos for ex since it must become open).
> >
> > So proposal is to extend extension to get more configuration - and coded
> > extensions can indeed plug themselves there.
> > The main challenge seems to be to re-evaluate the mappings but looks
> doable.
> > High level it is more or less "let the pom/.mvn inject maven components
> > without coding/by declaration".
> >
> > Hope it makes sense, let me know if it is worth investigating more or if
> > the idea is too particular to my old needs.
> >
> > Best,
> > 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: [discuss] extend extensions.xml to lifecycles/packaging and types?

[Christoph Läubrich]

Isn't it already possible to "extend" the lifecycle by simply putting 
plugin + execution into root pom?


Main problem for me is that currently packaging == type == lifecycle, 
otherwise one could simply have an "empty" lifecycle + whatever 
packaging and simply bind anything you want tin pom.xml e.g.




   jar
  empty (would default to packaging if not 
given, where empty is just a lifecycle with no mappings)

  
   

  org.apache.maven.plugins
  maven-jar-plugin
  

... define all your custom bindings here ...



Am 04.01.24 um 09:37 schrieb Romain Manni-Bucau:

Hi all,

Reviewing and trying to follow Martin's thread about JPMS I thought about
the old issue that our build pipelines (plugins chain) is very hard to
customize.
Guillaume added the priority case but the clean solution proposed
originally was to define custom lifecycles (to add frontend, docker builds
for ex) - more or less a custom AbstractLifecycleMappingProvider.

I wonder if we shouldn't extend .mvn/extensions.xml (or root pom
 block) to support to define custom lifecycle mappings there
and potentially explicit new "types" too which would be great for Martin's
work since it would allow to avoid undefined types and implicit jar mapping
in a "strict" mode (to detect typos for ex since it must become open).

So proposal is to extend extension to get more configuration - and coded
extensions can indeed plug themselves there.
The main challenge seems to be to re-evaluate the mappings but looks doable.
High level it is more or less "let the pom/.mvn inject maven components
without coding/by declaration".

Hope it makes sense, let me know if it is worth investigating more or if
the idea is too particular to my old needs.

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