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