Classification of test scope components in the BOM file

[karthika-g]

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?

[hboutemy]

you're right, each component can have properties https://cyclonedx.org/docs/1.4/json/#components_items_properties
then we can add properties: good idea

should we add a Maven scope property? as maven.scope? something else?

[karthika-g]

Yes that would be great!! maven.scope will be good.Then we can specify it as "direct" for direct dependencies and maybe "test" for test/development dependencies?

[hboutemy]

"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 maven.scope https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#dependency-scope

@knrc @stevespringett WDYT (on Maven scopes only for now, we'll see other properties later)?

[karthika-g]

Oh you meant the maven dependency scope ! Slight misunderstanding from my side.
Yes then i think we can go ahead with the approach you suggested then.

The other properties we can check later. For now this will be helpful.

[karthika-g]

@hboutemy Any updates on this issue ? can this maven.scope like you mentioned be added as a property?

[knrc]

@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?

[karthika-g]

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 compile scope and which is of test scope.

It is helpful to have this information during the time of component clearance so that the dependency of test scope can be excluded since normally they are considered to be development dependency.

Does this make sense?

[stevespringett]

@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 cdx:maven namespace is added and things like scope are defined, we'll be able to enhance the Maven plugin to support those properties.

[knrc]

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 compile scope and which is of test scope.

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

A
+- B:compile
|   \- C:compile
|       \- D:compile
\- D:test

which would resolve D to the test artifact and hide the compile artifact. How would this impact your use case?

[karthika-g]

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.

[wleese]

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.

[karthika-g]

Hi,

Any updates on this issue?