Re: custom default lifecycle per project

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Re: custom default lifecycle per project

Romain Manni-Bucau
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 <[hidden email]> 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]
> [2]
> 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 <
> > | LinkedIn <> | Book
> > <
> > >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]