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.
>
> > 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-performance
> > > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > >
> > > >
> > >
> >
> --
> Sent from my phone
>
