Hi Romain,
Do you expect another phases (life cycle) for specific technologies or
packaging.
What phases would you expect in case of frontend technologies, e.g.
JavaScript-like Angular, ReactJS, Vue?
What phases in case of scrip-like technologies and native technologies?
Should these phases be hardcoded alternatives? Or a customizable life cycle?
Cheers
T
On Sat, Jul 4, 2020 at 6:09 PM Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> 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?
>
> That sounds like a dedicated plugin use case
>
> >
> >
> >
> > >
> > > > 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
> > >
> >
> --
> Sent from my phone
>
