Le jeu. 4 janv. 2024 à 10:37, Christoph Läubrich <m...@laeubi-soft.de> 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 <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 > >
