[MNG-7157] [MNG-6843] Provide a better design for obtaining artifacts…#475
[MNG-7157] [MNG-6843] Provide a better design for obtaining artifacts…#475gnodet wants to merge 3 commits intoapache:masterfrom
Conversation
…ies in MavenProject This make the code shorter and easier to understand and also removes the risk of hitting the 2000 lines barrier for a single file
…enProject inside a mojo # Conflicts: # maven-core/src/main/java/org/apache/maven/project/MavenProject.java
|
Is this really a follow-up? Instead, to me it seems like an alternative, more comprehensive solution than #413? |
| return testCompileSourceRoots; | ||
| } | ||
|
|
||
| @Deprecated |
There was a problem hiding this comment.
It would be nice to document what to use instead (and why) via JavaDoc @deprecated ....
There was a problem hiding this comment.
I'm willing to provide more doc once there's a consensus.
Honestly, I'm not even sure we need such an API, unless there's a clear path for the deprecation and for moving to a more immutable MavenProject. What are the deprecation rules ? Will 4.0 remove things deprecated in 3.x ? If they stay forever, there's really no point in deprecating and trying to find slightly better APIs... I'm just asking here, but 3.0 is very old I think there are quite a few things that are deprecated since early 3.x versions, which looks like 10 years or so.
Yes, the wording is wrong. I originally went to only extend and provide an alternative api, but then refactored your original proposal a bit, so it's now more an extended alternative.... |
| { | ||
| value = mojoExecution; | ||
| } | ||
| else if ( "artifactFilter".equals( expression ) ) |
There was a problem hiding this comment.
We should investigate if we can solve this with MPLUGIN-302 instead of exposing this a new expression.
|
Resolve #8297 |
4 participants
… from a MavenProject inside a mojo
Follow-up on #413 ...