Re: Custom lifecycles

[Robert Scholte <rf...@apache.org>]

I have another usecase:

For a CD pipeline we do the following:
1. build the application
2. deploy it to a container
3. run integration tests

Step 3 has a pom.xml with packaging type pom and has a couple of plugins  
specified (e.g. jmeter run + analyze + report)
In this case there are a lot of projects which make use of this pipeline,  
so we want to have a parent-pom, so the it projects only have to specify  
project specific properties.
in the parent you need to specify the plugins with pluginManagement, since  
you don't want to execute them when building the parent.
However, this means that every it-project must add the plugin to their pom  
just to be picked up as part of the lifecycle.

In this case you're actually looking for something which is the opposite  
of <inherit>, which means that the child project inherits it or not. The  
opposite would always be inherited by the child-module, but its value  
tells if this parent-project uses the configuration or not.

Or it would be nice if the pom could define the lifecycle *without* the  
use of an extension, that would be overkill. The only thing that needs to  
be done is to have some configuration which binds goals to phases, nothing  
more.

I don't think that this fits in the 4.0.0 model and you might wonder if it  
belongs there. One solution I can think of is an attachment to the  
parent-project with a 'lifecycles'-classifier. It would be an xml  
containing the some kind of configuration which looks like the one we're  
already using in the components.xml

Robert


On Mon, 08 Feb 2016 23:33:54 +0100, Stephen Connolly  
<st...@gmail.com> wrote:

> So I was thinking somewhat about the issues with custom lifecycles.
>
> One of the nice things I like about Maven is that the use of the standard
> lifecycles helps orientate new developers and prevents the sprawl of ANT
> targets.
>
> When I look at all the other build systems, what I keep missing in them  
> is
> the standard lifecycle. Every time you land on a project you end up
> spending altogether far too much time trying to figure out the special
> incantations required to build the project... Is it `ant clean build`, is
> it `ant distclean dist`, etc. And this is not just an ANT issue, it  
> affects
> all the build systems from make onwards.
>
> Now the thing is that Maven actually supports custom lifecycles, so I can
> create a custom lifecycle with a custom list of phases using whatever  
> names
> I decide... The reason people don't do this is because it's seen as hard  
> to
> do...
>
> There is that quote: "Nothing is either good or bad, but thinking makes  
> it
> so"
>
> By being perceived as hard to do, custom lifecycles have resulted in a
> solid set of well defined phases...
>
> On the other hand, people end up abusing the standard lifecycle in order  
> to
> do lifecycle like things... Has anyone seen people using special profiles
> coupled with plugins bound to early lifecycle phases to do non-build
> related things? I know I have been guilt of this... After all  
> `initialize`
> and `validate` are generally no-op phases and if you use `<defaultGoal>`  
> in
> the profile you can achieve quite a lot... Except now the old problem is
> back... How do I start up a local test environment: `mvn  
> -Pcreate-test-env
> -pl :test-env`... Well that's non-obvious to discover... And it's not  
> very
> portable either... In fact give me 3 months away and I'll probably have
> forgotten how to do it myself...
>
> So much nicer would be to actually start using custom lifecycles...
>
> First off, let's say we define a deployment lifecycle with goals to  
> assist
> shipping the artifacts to deployment environments. So you want to type  
> `mvn
> ship -Pproduction` to ship the artifacts to production. In a multi module
> project this will only work if all modules in the project have the
> extension with this custom lifecycle in scope... So good luck to you if  
> you
> have to pull in some projects to your reactor where you only have read
> access to SCM and they don't use your extension... You used to end up
> needing a custom distribution of Maven with the extension pre-loaded...
>
> This is somewhat easier with the .mvn directory... As we can ensure the
> extension defining the custom lifecycle is loaded for all projects in the
> repository...
>
> But here is my problem:
>     What happens when there are two extensions defining different
> lifecycles with the same phase names?
>
> So I've added my extension which defines the `ship` phase and there's  
> also
> another project in the reactor with an extension which has defined a
> different lifecycle which also has the phase `ship`... Who wins?
>
> Well the current answer to who wins is: "first in the reactor wins"
>
> So if I have the .mvn directory loading up the custom extension and the
> other project is second in the reactor then my `ship` will win... But if
> the other project is first in the reactor then that project's `ship` may
> win... And then the build will fail as on the second reactor module that
> lifecycle does not exist.
>
> So it seems obvious to me that we need to provide a way to namespace
> lifecycle phases... So that
>
> `mvn default::deploy` and `mvn deploy` are logically the same as long as
> only the "default" build lifecycle defines a "deploy" phase. The same  
> would
> work for `mvn clean::clean` vs `mvn clean` and `mvn site::site-deploy` vs
> `mvn site-deploy` for the "clean" and "site" lifecycles respectively
>
> The second nice thing about namespacing lifecycles is that we can
> automatically trim the project list based on those projects that define  
> the
> lifecycles...
>
> So then
>
> `mvn ship::ship`
>
> will only operate on those projects that actually have an extension that
> defines the ship lifecycle...
>
> If we take this further we may also need to ack that we have no control
> over the extensions that define lifecycles with specific IDs... So you  
> may
> need to further qualify the lifecycle... `mvn
> groupId:artifactId:version::lifecycleId::phase` being the fully specified
> phase
>
> What do people think? Is this something to consider? Will I file a JIRA
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org