[MNG-8052] New Lifecycle API#1411
Conversation
e352d2e to
bae14ce
Compare
bc224e1 to
b1895a6
Compare
22f2b4b to
36110b1
Compare
049146f to
956ee16
Compare
9013a20 to
8bf3a5f
Compare
michael-o
left a comment
There was a problem hiding this comment.
Enum values should be upper case by convention
| String POST = "post:"; | ||
| String RUN = "run:"; | ||
|
|
||
| String READY = "ready"; |
There was a problem hiding this comment.
It's not really used anymore in this PR, so I'll remove those new concepts and I'll defer their addition to #1429.
For the record, it's used for the new lifecycle definition supporting dynamic phases and a fully concurrent build, see https://github.com/apache/maven/pull/1429/files#diff-dbccda410d9433bca88c9821a2ebd7ecb3b759738a2599a85748766c34658547R224-R252
In this PR, the phases are more fine-grained with inter-phases dependencies and more fine-grained inter-project dependencies. The lifecycle is not a simple list anymore, but looks more like a tree.
So ready represents the state of a project which is ready to be used as a dependency. This usually means that resources have been processed and classes compiled. The main point is that the compile phase should not have to be executed after the resources phase, as they both execute on different input and output and can be executed in parallel. So compile phase depends on sources phase, and ready depends on compile and resources, then package depends on ready.
The benefits (in addition to supporting dynamic phases with pre/post steps) is that we can have a package phase which does not depend on running tests, while verify would package and run unit/integration tests. This also cleanly solves problems coming from running mvn compile where some post processing can be mapped to that ready phase. So the definition of the tree-lifecycle above is not well defined yet, especially, the problem is how to bring those new features and keep a good level of compatibility.
I'd rather have a clean set of inter-phase and inter-project dependencies (for example, install and deploy do depend on package, but should not depend on running unit-tests and integration-tests).
Anyway, this can be deferred and discussed in the context of #1429, so I'll trim the Lifecycle interface to what is currently in Maven 3 (keeping in mind it can be extended in the future).
|
|
||
| @Override | ||
| public Iterator<Lifecycle> iterator() { | ||
| return values.values().iterator(); |
| Set<String> s2 = | ||
| computed.stream().filter(s -> !given.contains(s)).collect(Collectors.toSet()); | ||
| throw new IllegalArgumentException( | ||
| "List of phases differ in size: expected " + computed.size() + " but received " + given.size() |
| given.stream().filter(s -> !computed.contains(s)).collect(Collectors.toSet()); | ||
| Set<String> s2 = | ||
| computed.stream().filter(s -> !given.contains(s)).collect(Collectors.toSet()); | ||
| throw new IllegalArgumentException( |
There was a problem hiding this comment.
Why is it IAE instead of ISE?
|
|
||
| import java.util.List; | ||
| import java.util.Map; | ||
| import java.util.*; |
|
Mmh, it does not make sense to remove the new stuff from this PR, as the JIRA is about the new lifecycle. |
|
Resolve #9821 |
JIRA issue: https://issues.apache.org/jira/browse/MNG-8052