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
<[email protected]> 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: [email protected]
For additional commands, e-mail: [email protected]
