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: <packaging>war+front+living-doc+docker</packaging> 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> T readAs(final Path path, final Class<T> 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 ? "</" + wrapper + ">" : ""))); } 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> T readAs(final Path path, final Class<T> 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 ? "</" + wrapper > + ">" : ""))); > } 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 DefaultLifecycleMapping mapping = > *loadOrParse(*mappings*)*; > > container.addComponent(mapping, LifecycleMapping.class, > "my-mapping"); > } > } > } > > Then we can put the new mapping as packaging and voilà :). > > If you have tips for the parsing it is welcomed otherwise I'll continue to > play with my custom parser. > > 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 > > > > > Le dim. 5 juil. 2020 à 11:09, Romain Manni-Bucau <rmannibu...@gmail.com> a > > écrit : > > 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-s > > erver-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 <herve.bout...@free.fr> 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 <rmannibu...@gmail.com > >> > > > >> > > 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 > >> > > > > >> > > > > 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 < > >> > >> rfscho...@apache.org> > >> > >> > > 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 < > >> > >> rmannibu...@gmail.com> > >> > >> > > > > wrote: > >> > > > > > > I agree I mixed both in my explanation....cause 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-performan > >> c > >> > >> > > e > >> > >> --------------------------------------------------------------------- > >> > >> > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> > > > > > > > For additional commands, e-mail: dev-h...@maven.apache.org > >> > > > > > >> > > > > -- > >> > > > > Sent from my phone > >> > > > >> > > -- > >> > > Sent from my phone > >> > >> --------------------------------------------------------------------- > >> 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
