New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[MNG-8052] New Lifecycle API #1411
base: master
Are you sure you want to change the base?
Conversation
e352d2e
to
bae14ce
Compare
bc224e1
to
b1895a6
Compare
22f2b4b
to
36110b1
Compare
049146f
to
956ee16
Compare
9013a20
to
8bf3a5f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Enum values should be upper case by convention
String POST = "post:"; | ||
String RUN = "run:"; | ||
|
||
String READY = "ready"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is this stage?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this remove-safe?
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() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
, but
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is it IAE instead of ISE?
@@ -18,8 +18,8 @@ | |||
*/ | |||
package org.apache.maven.lifecycle; | |||
|
|||
import java.util.List; | |||
import java.util.Map; | |||
import java.util.*; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't we avoid this?
Mmh, it does not make sense to remove the new stuff from this PR, as the JIRA is about the new lifecycle. |
JIRA issue: https://issues.apache.org/jira/browse/MNG-8052