Add optional configuration parameter "includeLicenses".

[akurth]

The default is true. Setting it to false will entirely omit component license information. This may be useful for environments where spdx.org cannot be reached or where license information is not relevant at all.

[stevespringett]

This appears to be an issue with the SPDX tools library used by CycloneDX Core and not specific to the Maven plugin.

This PR seems to be a workaround rather than a solution. I'm more interested in having an offline solution that includes the license information than simply omitting it. I'll have to investigate the use of spdx-tools in cyclonedx-core-java and see if the license lookup functionality can be performed without spdx-tools, and if not, then I might need to create a ticket for the spdx-tools project to have their tool work in offline mode as a fallback.

[davidkarlsen]

@stevespringett Can't we do both? Some will simply not be interested in the licensing altogether and this flag is valuable for those.

[rylyade1]

@stevespringett Do you have any updates on this issue from SPDX tools library? As suggested by @davidkarlsen wouldn't it be helpful to have this flag as well for those not quite interested in the licensing?

[stevespringett]

BOMs are a statement of fact. Crippling the plugin through configuration which produces inaccurate license information for the purpose of getting around locked-down build environments is not something I support. Other ecosystems actually require outside access, so it's fortunate that Maven contains most of the information to create accurate BOMs in a disconnected environment.

Instead of modifying the plugin, try executing it with the following system property. SPDXParser.OnlyUseLocalLicenses=true.

mvn -DSPDXParser.OnlyUseLocalLicenses=true org.cyclonedx:cyclonedx-maven-plugin:1.6.1:makeAggregateBom

[davidkarlsen]

Adding the system property seems to work wonders. Thanks!

[leonard84]

It would be nice to have the plugin pass a maven property to the SPDXParser.OnlyUseLocalLicenses system property for the tool. Having to set system property makes it harder to manage in an enterprise environment where you have countless builds that now have to add this system property instead of just setting a maven property in a centrally managed pom.

[mfriedenhagen]

@stevespringett, what about proxying configuration for SPDXParser in the plugin? Would that be something feasible? We have a company-pom and in the CI environment we now had to adjust MAVEN_OPTS. It is a pity that the URL for licenses.json is not injectible but hard-coded.

[mfriedenhagen]

@stevespringett, what about my suggestion to proxy the SPDXParser configuration?

[stevespringett]

Thanks for the ping @mfriedenhagen. I'm actually working to remove reliance on SPDX Tools from the next major release of CycloneDX Core Java. v3.0.0 will likely be released in June shortly after the launch of the CycloneDX v1.2 spec. Once an updated Core Java module is published without SPDX Tools, the proxy issue disappears.