-
-
Notifications
You must be signed in to change notification settings - Fork 84
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Classification of test scope components in the BOM file #384
Comments
you're right, each should we add a Maven scope property? as |
Yes that would be great!! |
"direct" is not a valid Maven scope: no, "direct" would be another property, if we think it's useful. Personally, I don't get why this direct property would be useful, given we have dependency graph to more accurately detect everything https://cyclonedx.org/docs/1.4/json/#dependencies I think this direct aspect deserves a discussion in another issue. I'm not convinced by direct vs transitive, but I now think that marking aggregates (in makeAggregateBom) would be useful. But it's another discussion. let's focus for now on Maven scopes as @knrc @stevespringett WDYT (on Maven scopes only for now, we'll see other properties later)? |
Oh you meant the maven dependency scope ! Slight misunderstanding from my side. The other properties we can check later. For now this will be helpful. |
@hboutemy Any updates on this issue ? can this |
@karthika-g @hboutemy This is not as straight forward as it appears, since it could be that the resolved artifact was pulled in via test dependencies and overrides a compile dependency. What are we trying to solve with this? |
The idea is to have a scope mentioned in the final output bom file of this cyclonedx-maven-plugin tool as a property maybe. So that when dependencies are checked in the bom file ,we have a clear classification as of which dependency is It is helpful to have this information during the time of component clearance so that the dependency of Does this make sense? |
@karthika-g if that's the case, the first step would be to define what those properties are similar to how CycloneDX does it for npm and other ecosystems. Refer to the CycloneDX Property Taxonomy repository for more information Once the |
Apologies,. I understand the above but I'm not sure what this information would then be used for. My concern is that within the maven resolution process the scope of the actual resolved artifacts is not something that can really be trusted. Once the resolution process has occurred it may appear that a particular artifact is being included because it is a test dependency, however this would ignore the overridden instances which would exist via the compile time dependency part of the graph. One example of this would be a hierarchy similar to
which would resolve D to the test artifact and hide the compile artifact. How would this impact your use case? |
The use case for the scope is basically to take the bom generated from cycloneDx maven plugin as input into another tool and then identify the components from it and classify them based on their scope as compile,test etc.. In the scenario that you have mentioned we will be considering the final scope of D as test it self, even though as a transitive dependency it's scope is compile. |
I'd like to add our use case. We want to track all dependencies, transitive and in all scopes, to understand how our framework (which includes a maven profile to run cyclonedx maven plugin) is being used in the larger context of the java/kotlin ecosystem. Currently we run the plugin once per maven scope on behalf of the user, outputting to a different file per scope. So an app uses our framework, runs mvn verify or such, cyclonedx maven plugin outputs sboms which our framework reads and will output to an external storage system when the application runs. The result: we know that app A runs our framework and has included these, and these dependencies. We use this knowledge to understand what our developers use and need (1000+ apps). From that point of view, it is good to differentiate what our developers need for testing, vs runtime. We experience that the "Resolving dependencies" cyclonedx maven plugin step in our CI/CD environment is 2x - 10x slower compared to locally, which is why we're very interested in reducing the amount of times we run the plugin. |
Hi, Any updates on this issue? |
Hi,
I have been using this tool since sometime and it is really helpful for identifying maven packages. But there is one feature that would be really helpful.
Normally test scope components are considered as Development dependency and if i add them in the bom using the configuration
<includeTestScope>true</includeTestScope>
there is no way to distinguish from the direct dependency. Can any property be added for this purpose which will act as an indicator.? Could this feature be implemented?
The text was updated successfully, but these errors were encountered: