Op Mon, 08 Feb 2016 23:33:54 +0100 schreef Stephen Connolly
<stephen.alan.conno...@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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
