> 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 <m...@laeubi-soft.de> 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.
<project>
<packaging>jar</packaging>
<lifecycle>empty</lifecycle> (would default to packaging if not
given, where empty is just a lifecycle with no mappings)
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<executions>
<execution>
... 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
<extensions> 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 <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <
https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<
https://www.packtpub.com/application-development/java-ee-8-high-performance
---------------------------------------------------------------------
To unsubscribe, e-mail: 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
