maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Collins (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (MDEP-621) New goal to "fix-warnings"
Date Sat, 14 Jul 2018 13:34:00 GMT

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

Alex Collins updated MDEP-621:
------------------------------
    Description: 
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?

 

 

  was:
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?

 

 


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

Mime
View raw message