[
https://issues.apache.org/jira/browse/MDEP-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17159990#comment-17159990
]
Elliotte Rusty Harold commented on MDEP-621:
--------------------------------------------
My concern about automated fixes is that dependency mediation is order
dependent. Where you add a new dependency element matters.
> 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
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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
(v8.3.4#803005)
