search

CycloneDX / cyclonedx-maven-plugin

Creates CycloneDX Software Bill of Materials (SBOM) from Maven projects
https://cyclonedx.org/
Apache License 2.0
287 stars 85 forks source link

Apache Karaf OSGi feature file support #10

Open wlfshmn opened 5 years ago

wlfshmn commented 5 years ago

Apache Karaf delegates its dependency information to feature files to support enhanced functionality, such as supporting multiple versions of the same artifact. It would be useful if these dependencies could be captured into the BOM as well.

stevespringett commented 5 years ago

Related to #7

stevespringett commented 5 years ago

Karaf itself appears to use standard Maven conventions for dependency resolution when being built. Do they use feature files in addition to Maven dependencies?

Have they contributed a Maven plugin or other core java module which provides an implementation of their dependency information scheme?

wlfshmn commented 5 years ago

The project karaf builds with Maven yes, but it is an OSGI runtime which will load bundles (jar files with OSGi metadata) dynamically. Feature files is a Karaf-specific (not OSGi-standard) way of expressing dependencies. These files are either specified explicitly, such as https://github.com/apache/karaf/blob/master/assemblies/features/framework/src/main/feature/feature.xml or can be generated by a maven plugin https://svn.apache.org/repos/asf/karaf/site/production/manual/latest/karaf-maven-plugin.html

I do not believe karaf has made any attempt to integrate with maven itself beyond providing their own plugin. I doubt the maven project would be open for such a thing as OSGi enables things that are alien to the way java usually does things.

Artifacts are typically refered to by maven coordinates fortunatley. There is no guarantee that the artifacts mentioned in the feature file are sourced from the projects POMs, in fact they are often not due to the POM inability to express things like including multiple versions of the same artifact (each bundle in OSGi has it's own isolated classloader and thus this isn't a conflict as it would be in a more tranditional Java application)

As you can see from the feature file example, it is common for it to template a feature file and use maven resource processing to fill in details from the POM, typically versions. This means features files likely aren't fully resolvable until after build (atleast process-resources, in maven terms)

Features don't resolve maven artifacts transitive graph, runtime dependencies have to be explicitly listed in a feature, or a feature it depends on. (CycloneDX shouldn't need to care about this though, if the feature isn't availible to us, it is outside the scope of our project and thus what the BOM should cover).

I intend to have a try at this myself as I have work projects with several hundred artifacts in feature files which it would be very nice to be able to build BOMs for. Those artifacts among those which are built by us will naturally have a more typicall maven project at he source for which cycloneDx already works well, but for the aggregations it does not.