This kind of overlaps with MNG-6118, which is also about the path to the
end-result.
I haven't thought about excluding some pieces of the lifecycle by default,
but we should focus more on the result.
Maven should react much better on the execute location within a
multimodule project and what you really want to happen here.
As an example I use starting jetty on the war of a multimodule project,
which is now requires 2 steps: mvn install from root and jetty:run n th
specific module.
I think MNG-6118 would be a first step before getting this up and running.
Robert
[1]
https://issues.apache.org/jira/browse/https://issues.apache.org/jira/browse/MNG-6118
On Sat, 18 Mar 2017 16:46:28 +0100, Stephen Connolly
<stephen.alan.conno...@gmail.com> wrote:
So I am thinking the lifecycle should support the concept of *optional*
phases.
If no subsequent phase depends on the output of an optional phase, and
the
optional phase was not explicitly called out on the invocation request,
then Maven could drop the phase.
By way of example, all the current test phases: generate-test-resources,
test-compile, test, etc could be optional. The verify phase would depend
on
the result of the test phase.
This means that: `mvn package` could bypass even doing anything with the
tests (unless somebody bound jar:test-jar to the package phase - which
would mean that test-compile was required but not test)
If you wanted the tests run, you either go `mvn test package` (I think we
can dedup redundant phases from the request) or `mvn verify`
What this gets us is the ability to build targeted portions of the
reactor
without requiring that stuff be installed.
Another idea I have is to allow @groupId:artifactId or @module/path (with
wild cards for each) as suffixes to goals and phases...
So
mvn test@foo:bar-*
Would load the whole reactor and apply the test phase to all modules in
groupId foo with artifactIds starting with bar- but ensuring that any
within reactor requirements have been minimally built...
so if foo:bar-api depends on foo:manchu-api:jar then the build plan would
include bringing manchu-api as far as the package phase (when the jar
file
is produced)
If further to that, foo:bar-impl depends on foo:manchu-impl:(dir|jar)
then
the reactor would also include bringing manchu-impl as far as
process-classes (when the classes dir is "produced" because the
requirement
is for either classes or jar)
Of course all the above magically needs a simple sintax for users and
easy
to understand docs... both of which we may not be able to achieve... but
the above goal is something I think we would love to have in 5.0.0...
(and
a pink fluffy unicorn too)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
