[ 
https://issues.apache.org/jira/browse/MDEP-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Collins updated MDEP-621:
------------------------------
    Component/s: analyze

> 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 reator 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)

Reply via email to