feat: [OSM-2668] introduced dfs for maven dverbose - #5891
Conversation
03714ca to
76f3f7e
Compare
76f3f7e to
5abe28b
Compare
| expect(sbom.dependencies[6].dependsOn.length).toEqual(1); | ||
| expect(sbom.dependencies[6].dependsOn[0]).toEqual( | ||
| 'commons-logging:commons-logging@1.0.4', |
There was a problem hiding this comment.
Just curious about this change, can you explain? Length of dependencies because you go depth first I presume? But why does the version change?
There was a problem hiding this comment.
package version in the key for the visited/ancestry. this means that we'll include all the versions that dverbose outputs. An example, with scope too is included is here in this output: https://github.com/snyk/snyk-mvn-plugin/pull/188/files#diff-2ce7e54ca0da5e7003be9ff7c3606b9a54fbcddf4b01c062b202b57786475b94.
That version is not actually resolved by maven, but maven Dverbose does mention it as omitted.
We are waiting on a product decision here for our Dverbose functionality, I personally think that only the version that maven resolves should be included.
But, in the meantime, to unblock, we are adding exactly what Dverbose outputs.
2 participants
Pull Request Submission Checklist
What does this PR do?
Bumps snyk-mvn-plugin to include: snyk/snyk-mvn-plugin#189.
Includes:
As mentioned on the PR, dependening on the decision to only keep the scope/versions that maven resolves dependencies to, instead of the Dverbose output, a change will come on top of this one.
Where should the reviewer start?
snyk/snyk-mvn-plugin#189
How should this be manually tested?
Test with the example here.
What's the product update that needs to be communicated to CLI users?
[test, monitor, sbom] Maven Dverbose improvement for long running scans resulting from dense dependency graphs creation.
What are the relevant tickets?
https://snyksec.atlassian.net/browse/OSM-2668