[
https://issues.apache.org/jira/browse/MDEP-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16544513#comment-16544513
]
ASF GitHub Bot commented on MDEP-621:
-------------------------------------
alexec opened a new pull request #1: MDEP-621 - New goal to "fix-warnings"
URL: https://github.com/apache/maven-dependency-plugin/pull/1
The rational behind this PR is in the [MDEP-621
JIRA](https://issues.apache.org/jira/browse/MDEP-621) ticket.
In summary, it adds a new goal that attemps to fix the warnings show by the
`dependency:analyze` goal. This is so that large, but well-formed projects, can
be automatically fixed.
---
Following this checklist to help us incorporate your
contribution quickly and easily:
- [x] Make sure there is a [JIRA
issue](https://issues.apache.org/jira/browse/MDEP) filed
for the change (usually before you start working on it). Trivial
changes like typos do not
require a JIRA issue. Your pull request should address just this
issue, without
pulling in other changes.
- [x] Each commit in the pull request should have a meaningful subject line
and body.
- [x] Format the pull request title like `[MDEP-XXX] - Fixes bug in
ApproximateQuantiles`,
where you replace `MDEP-XXX` with the appropriate JIRA issue. Best
practice
is to use the JIRA issue title in the pull request title and in the
first line of the
commit message.
- [ ] Write a pull request description that is detailed enough to
understand what the pull request does, how, and why.
- [ ] Run `mvn clean verify` to make sure basic checks pass. A more
thorough check will
be performed on your pull request automatically.
- [ ] You have run the integration tests successfully (`mvn -Prun-its clean
verify`).
If your pull request is about ~20 lines of code you don't need to sign an
[Individual Contributor License
Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure
please ask on the developers list.
To make clear that you license your contribution under
the [Apache License Version 2.0, January
2004](http://www.apache.org/licenses/LICENSE-2.0)
you have to acknowledge this by using the following check-box.
- [x] I hereby declare this contribution to be licenced under the [Apache
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
- [x] In any other case, please file an [Apache Individual Contributor
License Agreement](https://www.apache.org/licenses/icla.pdf).
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
> New goal to "fix-warnings"
> --------------------------
>
> Key: MDEP-621
> URL: https://issues.apache.org/jira/browse/MDEP-621
> Project: Maven Dependency Plugin
> Issue Type: New Feature
> Components: analyze
> Affects Versions: 3.1.1
> Reporter: Alex Collins
> Priority: Major
>
> The analyze goal works well in some scenarios, but time and time again I come
> across a large project (100s modules and 1000s dependenencies) where I want
> fix the warnings that the "analyze" goal produces.
> Fixing these dependency issues will make builds faster, and with large
> projects, Maybe 2-5x faster. As they reduce IO and CPU usage, allow the
> reactor more flexibily in build order, so parallel builds can make better
> usage of the CPU cores.
> This is hard to automate, and I've tried a few scripts people have written,
> but they're generally not up to the job, typically they are basic:
> * Only work on one pom, not multi-module projects.
> * Do multi-module, but don't follow reactor order.
> * Try to remove the wrong dependencies.
> * Don't check the removal worked OK, e.g.
> ** Removing annotation processors.
> ** Removing "magic" jars, those that appear unused, but actually are some
> how (e.g. some Spring class-path scanning magic).
> My thought is to introduce a new goal that peforms the following steps for
> each pom in reactor order:
> # Verify the module isn't broken to start with (clean install).
> # Check-point (save a backup of the pom.xml).
> # Perform dependency analysis.
> # Add in all used undeclared dependencies.
> # Verify - check that didn't break anything (clean install) and give up if
> it did.
> # Check-point.
> # Remove all unused declared dependencies (i.e. see if any of them are
> needed at all, this assumes that there is a good probabily that is the case
> and is quicker than testing each in order).
> # Check-point
> # Verify.
> # For each unused declared dependency.
> # Check-point.
> # Remove.
> # Validate.
> I'm making a key assumption here that if a module's tests pass, then it's
> just fine. That's a big assumption, but I see no feasible way to make this
> work otherwise.
> Many projects have "terminal" modules, i.e. modules that have no downstream
> dependencies. It would be risky to remove "magic" dependencies, so it maybe
> the case we want to bookend this process by
> # Determine "terminal" modules.
> # For each terminal module, create a list of their dependencies.
> # Do the fix as discussed above.
> # For each terminal module, create a list of their dependencies.
> # Re-instate any that were removed.
> Whadaythink?
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
