Side topic - still thinking out loud - which is also covered by custom
lifecycles: aliases. A common need is to alias a complex command ("mvn
docker" executing "mvn dependency:build-classpath git-commit:generate
docker:bundle docker-java:cds" to give an idea), with default or merged
lifecycles it is hard to make relevant. Indeed, an option is a custom
plugin or extension reading aliases somewhere and hacking lifecycleStater
to stash/pop the real goal to execute it, works but is a workaround whereas
custom lifecycle gives a proper solution to that.
What I'm unsure today is if the custom lifecycle must be fully explicit or
can insert phases and goals in an existing lifecycle ("patch mode"), not
sure what is the simplest for users.
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. 12 juil. 2020 à 11:58, Romain Manni-Bucau <rmannibu...@gmail.com> a
écrit :
>
>
> Le dim. 12 juil. 2020 à 11:26, Hervé BOUTEMY <herve.bout...@free.fr> a
> écrit :
>
>> Le dimanche 12 juillet 2020, 10:37:36 CEST Romain Manni-Bucau a écrit :
>> > Le sam. 11 juil. 2020 à 23:01, Hervé BOUTEMY <herve.bout...@free.fr> a
>> >
>> > écrit :
>> > > Le samedi 11 juillet 2020, 12:55:37 CEST Romain Manni-Bucau a écrit :
>> > > > Le sam. 11 juil. 2020 à 12:09, Hervé BOUTEMY <herve.bout...@free.fr>
>> a
>> > > >
>> > > > écrit :
>> > > > > are really your plugin bindings so specific to your build that
>> they
>> > >
>> > > could
>> > >
>> > > > > not be reused and need full ad-hoc definition?
>> > > >
>> > > > Think so
>> > > >
>> > > > > 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
>> > > >
>> > > > Ok but "front" means already 5-6 different bindings at least
>> > >
>> > > nice, that proves that this "sub-packaging" is useful: what would be
>> the
>> > > bindings, please, to make this case very concrete?
>> > >
>> > > > and
>> > > > "living-doc" is per project by design (depends your stack, leads to
>> > > > different set of plugins).
>> > >
>> > > let's dig a little bit: can you provide a few examples of stacks and
>> > > corresponding bindings, please?
>> > > perhaps "living-doc" is too generic, and should be more specific per
>> stack
>> >
>> > Jar+front=jar lifecycle + frontend:npm-install + frontend:npm-build
>> in such a case, where it's only 1 single plugin, we don't even need the
>> "sub-
>> packaging" feature: adding the plugin will use its default bindings (just
>> tell
>> if that one is not clear: I'm not sure if this is clearly documented)
>>
>
> For all these plugins there is no default binding or it does nuot match
> mentionned lifecycle so it must still be customized.
> Can be done in a pom but in multimodule it is still nice to be able to
> share it between 3-4 modules - this is why the proposed extension helps a
> lot and enables to migrate tooling (yarn to npm for ex) trivially.
> To rephrase it: it is to make maven align on modern dev where inheritance
> is dropped in favor of composition because it is more flexible and easy to
> maintain.
>
>
>
>> >
>> >
>> > Then you can add openapi.json generation with
>> geronimo-openapi-maven-plugin
>> same as before: adding a plugin should do the job of default goal bindings
>>
>
> When used in 1 module yes, otherwise it enforce to either create a fake
> parent (broken design imho) or duplicate the plugin instead of being able
> to reuse a standard *project specific* way of doing (which is super
> important for consistency).
>
>
>> >
>> > You have the same with a war instead of a jar.
>> thisis why "sub-packaging" is useful: it can be used whatever the main
>> packaging is. And default goal bindings when is a plugin is added is also
>> independant of the packaging
>>
>> >
>> > Ablut living doc it can be several exec + openapi patch (either with a
>> json
>> > plugin or something else like ant or even another exec or gplus:execute
>> for
>> > what I saw). Add github-page or cms deployment, jira chabgelog
>> generation
>> > (saw it with public and private plugins) and doc content itself can be
>> home
>> > made (exec), jbake based, antora based (frontend but not the same config
>> > than build one) or even jekyll based for what I saw.
>> parent POM, or reactor pom is already there for that: I don't understand
>> what
>> a new configuration file will add
>>
>> >
>> >
>> > Indeed npm can be yarn too and you can add npm-test and potentially
>> npm-e2e
>> > to the combinations
>> >
>> > > > I envision a reusable solution can be a thing but it is way more
>> complex
>> > > > than having these dynamic bindings which are straight forward on
>> user
>> > >
>> > > side
>> > >
>> > > > so I prefer to let the user adapt maven to his need rather than the
>> > > > opposite.
>> > > >
>> > > > Also note that your proposal makes us moving one step forward but we
>> > > > stay
>> > > > blocked: how do you merge phases and plugin order? This can also
>> depends
>> > >
>> > > on
>> > >
>> > > > projetcs and "+" only allows one order whereas order can be
>> different
>> > > > between main and test plugins so you would need a complete dsl, not
>> that
>> > > > easy compared to being explicit imo.
>> > >
>> > > sure, this part is only one step
>> > > I need examples of such "merge phase" and order requirements to
>> better see
>> > > what mechanisms would be useful
>> >
>> > Start by what i mentionned just before, jar+frontend which can be
>> > simpkified by
>> >
>> > Compile-class+npm-run+test-java+npm-test
>> >
>> > Compile-class runs before test-java
>> > Npm-run runs before npm-test
>> > All combinations respecting that are used (if one phase generates code
>> for
>> > the other using typescript-generator plugin or the opposite).
>> classical phases are sufficient: I don't get what is missing
>>
>
> No, this is sufficient when you add one or two plugins without profiles,
> otherwise you can do it but it is a mess - and to be honest, even if I know
> how it works and I made it working, I always reworked my build to bypass
> maven and add my own substeps in such cases cause in terms of maintainance
> it is too costly and rigid.
>
> Stephen proposal was helping even if priorities are not explicit enough
> IMO -a chain is saner for me - but was a nice workaround to have it today
> without breaking pom versioning.
>
> If I want to solve it cleanly today i would do a packaging extension with
> some autoconfig extension based on properties.
> This thread is just about avoiding to create an useless project with a
> different lifecycle just for that purpose and enable it to be done inline
> in the project.
>
> But thinking out loud, it can be done with a plugin extension too and be
> defined in the plugin conf too instead of another folder.
>
>
>
>
>> >
>> > > > > 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/a
>> > >
>> > > > >
>> pache/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-performanc
>> > >
>> > > > > e
>> > > > >
>> > > > > > 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
>> > >
>> > > ---------------------------------------------------------------------
>> > > 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
>>
>>
