Closed romeara closed 4 years ago
Merging #21 into master will increase coverage by
0.19%
. The diff coverage is100%
.
@@ Coverage Diff @@
## master #21 +/- ##
============================================
+ Coverage 84.65% 84.84% +0.19%
- Complexity 240 245 +5
============================================
Files 24 24
Lines 717 726 +9
Branches 47 47
============================================
+ Hits 607 616 +9
Misses 91 91
Partials 19 19
Impacted Files | Coverage Δ | Complexity Δ | |
---|---|---|---|
...abs/flare/plugins/model/DependencyConstraints.java | 94.59% <100%> (+1.73%) |
15 <7> (+5) |
:arrow_up: |
Merging #21 into master will not change security risk.
Note: Need to determine how this differs when transitive dependencies are in the properties file, and if it still applied to them (and if it doesn't, whether that is a problem)
I think I am going to try a different approach here, and instead of automatically only applying used constraints, allow specifying in the dependencies file a restricted set of configurations to apply a constraint to (instead of the default "all"). I will likely close this and put up a different implementation change as a result
Using a different approach to solve this issue, closing this PR
Change the way dependency constraints are applied so that only constraints used for dependencies within a given configuration are applied to that configuration. To allow this, constraint application was moved to a "pre-resolve" step for configurations (which means constraints are alow not applied for a configuration unless it is actually used)
This change in behavior results in the same constraints being applied, but prevents extraneous constraints on configurations, which could "leak" into built artifacts in cases such as generated Maven POM files (in POMs, this manifested as unused "dependencyManagement" entries)