You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Stephen Connolly <st...@gmail.com> on 2016/02/08 23:33:54 UTC
Custom lifecycles
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
--
Sent from my phone
Re: Custom lifecycles
Posted by Robert Scholte <rf...@apache.org>.
Op Mon, 08 Feb 2016 23:33:54 +0100 schreef Stephen Connolly
<st...@gmail.com>:
> 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
Re: Custom lifecycles
Posted by Stephen Connolly <st...@gmail.com>.
On Tuesday 9 February 2016, Robert Scholte <rf...@apache.org> wrote:
> So this sounds like Maven will slowly shift from build management tool to
> lifecycle management tool, which maybe isn't too bad.
Well I think that is the "missing feature" that drives people elsewhere...
>
> Reading this I really wonder if it is worth investigating in this. I hope
> this is so rare that if you hit this issue, you have control over at least
> one of the lifecycles so that you can adjust it.
> Namespaces are a solution, but I wonder if one would user them if they
> exist. In batchmode you probably must.
> Instead I would try to detect the conflict and give the user the choice
> which of the lifecycles he wants to execute. This list should never become
> as long as the available archetypes right now!
>
> And if there are lifecycles which makes sense, why not adopt them inside
> Maven?
I agree, if we see a good generally useful lifecycle, we should pick it up
and define the phase names
>
> So my first action would be to throw an exception in case there's an
> unresolvable phase name conflict.
Perhaps if it's a maven bundled phase we just force using that one... But
otherwise, yes we could blow up if there is a conflict... Though I like
namespaces to auto-select the project module subset to run on
>
> my 2 cents,
> Robert
>
>
> Op Mon, 08 Feb 2016 23:33:54 +0100 schreef Stephen Connolly <
> stephen.alan.connolly@gmail.com>:
>
> 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
>
>
--
Sent from my phone
Re: Custom lifecycles
Posted by Robert Scholte <rf...@apache.org>.
So this sounds like Maven will slowly shift from build management tool to
lifecycle management tool, which maybe isn't too bad.
Reading this I really wonder if it is worth investigating in this. I hope
this is so rare that if you hit this issue, you have control over at least
one of the lifecycles so that you can adjust it.
Namespaces are a solution, but I wonder if one would user them if they
exist. In batchmode you probably must.
Instead I would try to detect the conflict and give the user the choice
which of the lifecycles he wants to execute. This list should never become
as long as the available archetypes right now!
And if there are lifecycles which makes sense, why not adopt them inside
Maven?
So my first action would be to throw an exception in case there's an
unresolvable phase name conflict.
my 2 cents,
Robert
Op Mon, 08 Feb 2016 23:33:54 +0100 schreef Stephen Connolly
<st...@gmail.com>:
> 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
Re: Custom lifecycles
Posted by Mirko Friedenhagen <mf...@gmail.com>.
Hello Stephen,
sounds like a good idea. This would help a lot, we have projects using
custom gradle scripts to achieve things like this. Using name spacing seems
to be a good idea here.
Regards
Mirko
--
Sent from my mobile
Am 08.02.2016 23:33 schrieb "Stephen Connolly" <
stephen.alan.connolly@gmail.com>:
> 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
>
>
> --
> Sent from my phone
>
Re: Custom lifecycles
Posted by 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