[BUILD-285] Further define the effort for clean dependency analysis reports Created: 06/Nov/17  Updated: 06/Jun/18  Resolved: 08/Dec/17

Status: Closed
Project: Build
Component/s: None
Affects Version/s: None
Fix Version/s: POMs 35

Type: Task Priority: Neutral
Reporter: Maxime Michel Assignee: Maxime Michel
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
relation
is related to BUILD-291 Remove ununused com.google.code.findb... Accepted
is related to BUILD-292 Implement Jenkins pipelines for some ... Closed
is related to CONTEDIT-163 dam-app and MTK aren't Maven but desc... Closed
Template:
Acceptance criteria:
Empty
Task DoR:
Empty
Date of First Response:
Epic Link: 5.7 library update
Sprint: Basel 123, Basel 124, Basel 125, Basel 126
Story Points: 13

 Description   

Following the initial POC done in DEV-676, here are some points that need to be adressed before we implement such a health check:

  1. javax.servlet-api is used in a lot of modules, often declared as unused, but tests fail in some cases if it is not present (~RepositoryTestCase). Investigate if that could be fixed, allowing us to remove the dependency everywhere. those will be ignored thanks to the wildcard rule, they're not really false positive, though - but an investigation into the topic would be a task on its own
  2. javax.jcr and javax.inject are used almost everywhere but not necessarily explicitely declared. Do we want to have them as part of every POM? Near the bottom? yes, they'll be added. Order TBD exactly in a later step
  3. Investigate if it is possible with a reasonable effort to have yellow rather than red builds for failing analysis reports. in the implementation phase
  4. In the backup module, does h2 need to be scoped appropriately (rather than excluded) to no longer be an error? not a scope issue, no
  5. Reactor vs. parent POM: which responsibilities does each have? no longer relevant AFAICS
  6. Investigate why, in site/site-app, mvn says mockito-core and magnolia-site are superfluous dependencies, which they are not at all. Same with mockito-core in templating-samples. false positives that will be ignored once PR is in place
  7. In UI, org.vaadin.addon:easyuploads:jar:8.0.0:compile is a false positive in submodules that don't even use it. Investigate. false positive that will be ignored once PR is in place
  8. In groovy/magnolia-module-groovy, com.google.gwt:gwt-elemental:jar:2.8.1:provided is both a problem if you add or remove it. false positive that will be ignored once PR is in place
  9. com.google.code.findbugs:annotations used in resources and main wasn't added to the BOM but individually to those two projects - apchelintcev thought we might use other impls. of nullability annotations. Also the project seems dead. see BUILD-291
  10. usages of the icons project are not caught by Maven. What to do? false positive that will be ignored once PR is in place
  11. how to skip the webapps? this could be done in a Jenkins pipeline file if that's what we end up doing. Let's see in the impl phase
  12. investigate comment by Michael below. equivalent to what we're doing


 Comments   
Comment by Michael Mühlebach [ 06/Nov/17 ]

To validate the case of using code without explicit dependency, we could add an enforcer rule to ban transitive dependencies (http://maven.apache.org/enforcer/enforcer-rules/banTransitiveDependencies.html)

Comment by Maxime Michel [ 21/Nov/17 ]

Current findings are gathered at: https://wiki.magnolia-cms.com/display/DEVINT/Automatic+Maven+dependency+analysis+checks

Comment by Maxime Michel [ 12/Dec/17 ]

The end result of this ticket is the addition in PPOM 35 of a Maven profile called 'loose-dependency-analysis'. Developers will not see any difference in their potential working with the dependency analysis report, but Jenkins, using this profile, will exclude false positives from the warnings it sees, and fail only if there's a warning left.

Comment by Mikaël Geljić [ 12/Dec/17 ]

Generated at Sun Feb 11 23:40:30 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.