Cyclonedx sbom for tycho dependencies

[Swapnil-CSI]

Hi Cyclonedx Team,

Is there any way to scan the Tycho dependencies using cyclonedx-maven-plugin?.

I found that syft tool can generate cyclonedx format but it has limitations. It does not generate license information.

Thanks,
Swapnil Bharshankar

[stevespringett]

Any Maven project, including Tycho, is supported. I'd recommend integrating CycloneDX Maven plugin into the pom itself that way it becomes part of the Maven lifecycle.

[Swapnil-CSI]

I tried the cyclonedx maven plugin( pom.xml) on repo : https://github.com/eclipse/tycho/tree/master/demo/itp04-rcp to generate sbom.
In the generated sbom, dependencies are showing as a group of p2.eclipse-plugin and not showing original maven group/artifact id, So with this, it will not find any CVE's present in dependencies also the Licences section is missing in the report.

Used following block in pom.xml

    <plugin>
        <groupId>org.cyclonedx</groupId>
        <artifactId>cyclonedx-maven-plugin</artifactId>
        <version>2.5.3</version>
        <executions>
            <execution>
                <phase>package</phase>
                <goals>
                    <goal>makeAggregateBom</goal>
                </goals>
            </execution>
        </executions>
        <configuration>
            <projectType>library</projectType>
            <schemaVersion>1.3</schemaVersion>
            <includeBomSerialNumber>true</includeBomSerialNumber>
            <includeCompileScope>true</includeCompileScope>
            <includeProvidedScope>true</includeProvidedScope>
            <includeRuntimeScope>true</includeRuntimeScope>
            <includeSystemScope>true</includeSystemScope>
            <includeTestScope>false</includeTestScope>
            <includeLicenseText>true</includeLicenseText>
            <outputFormat>all</outputFormat>
            <outputName>bom</outputName>
        </configuration>
    </plugin>

Please refer to the attached sbom report.
bom.zip

[stevespringett]

Sounds like the tycho project either needs to:

1. Create a CycloneDX implementation that supports their build process and lifecycle - which seems to be very different from vanilla Maven.

or

2. Adopt CycloneDX and automatically produce it in the build process so that every plugin automatically has a complete and accurate BOM.

I would strongly encourage the second approach. Other Eclipse projects are already adopting CycloneDX including Eclipse Temurin.

[amergey]

Do you mean this should be done on tycho side ? so currently for projects with builds based on tycho we either need to fill a bug against tycho asking them to adopt CycloneDX, or create a CycloneDX implementation by ourself if they are not willing to do so, right ?

[laeubi]

In the generated sbom, dependencies are showing as a group of p2.eclipse-plugin and not showing original maven group/artifact id

The project you mentioned does not reference a single "maven" dependency but only P2 dependencies (beside that its using an old target+tycho version) so the question is how should this ever work?

If you use the latest Tycho version, there is an option to map P2 dependencies to "regular" maven ones as much as possible and you can reference maven dependencies directly in your target, but without that there is not much Tycho can do for you.

[laeubi]

@stevespringett can you please explain if the plugin can be somehow extended by a third party?
A quick look at the project code does not reveal any obvious option, I don't think the problem is that the build is different but that some dependencies (not originating from maven) are need to be specifically represented, so either there should be direct support in the plugin or some way to modify the outcome, e.g. a plain maven dependency is currently represented as:

"pkg:maven/org.eclipse.sisu/org.eclipse.sisu.plexus@0.3.5?type=jar"

while for a P2 dependency one probably want something like:

"pkg:p2/bundle/org.eclipse.m2e.archetype.common@3.2.103"

[stevespringett]

some dependencies (not originating from maven) are need to be specifically represented

@laeubi I guess there would be two ways to do this. The first being to merge the results from the Maven plugin with a BOM containing the p2 components. The CycloneDX CLI performs merging. The second option would be to add direct, but optional support for p2 in the Maven plugin. I don’t know what this would involve as I have no experience with p2.

@hboutemy at the Apache Foundation is leading the development efforts of this plugin. @hboutemy would you by chance know how this could potentially work?

[hboutemy]

I know sufficiently about Tycho to know that I don't know, sorry
And I fear adding even more complexity

[laeubi]

The first being to merge the results from the Maven plugin with a BOM containing the p2 components. The CycloneDX CLI performs merging

Maybe it would be possible to have a parameter in the CycloneDX Plugin to specify some "merge boms", Tycho could then just generate it at the standard location (e.g. target/tycho.sbom) and it gets merged with the default generated one.
This would maybe the most felxible solotuion and allows enhancement by other tools as well (even non java/maven).

The second option would be to add direct, but optional support for p2 in the Maven plugin. I don’t know what this would involve as I have no experience with p2.

It is actually a quite easy rule:

1. It is a system dependency
2. the group.id starts with p2. and ends with the type (e.g. eclipse.plugin)

Then it mapped in the following way;

P2_ID = artifactId
P2_VERSION = version

then one might get a result of pkg:p2/bundle/<P2_ID>@<P2_VERSION>

[laeubi]

By the way is there a libary I could use to write a SBOM in CycloneDX format?

[hboutemy]

@laeubi please share a simple Tycho project that we can transform into cyclonedx-maven-plugin IT
then explain the differences between the current "base-Maven" SBOMs and the Tycho-aware ones that you want

we can try and see how hard this will be

[hboutemy]

is there a libary I could use to write a SBOM in CycloneDX format?

https://github.com/CycloneDX/cyclonedx-core-java is used by cyclonedx-maven-plugin

[laeubi]

I'll try to prepare a demo for this purpose, for a quick look there is the example from the comment above:
#137 (comment)

it has a zip file attached and there you can search for p2.eclipse-plugin and see for example:

"purl" : "pkg:maven/p2.eclipse-plugin/org.eclipse.core.runtime@3.11.1.v20150903-1804?type=jar",

this is actually a P2 dependency with ID = org.eclipse.core.runtime and version 3.11.1.v20150903-1804 and one would most probably not find that on maven central with the given PURL (there is no p2.eclipse-plugin groupId) even though some versions are deployed under different groupIds because it originates from here:
https://download.eclipse.org/releases/2022-06/

[sithmein]

What is the status of this? I read the conversation several times but I didn't fully get what can/should be done in order to get "real" Maven PURLs out of Eclipse plug-ins. Is there some information that can be put into the the Eclipse plug-in Jars that can be consumes by the cyclonedx Maven plug-in? Or are there code changes required in the Maven plug-in or in Tycho? I'm happy to invest some time since we are very interested in this feature but I will need some more concrete hints where and how to start.

[laeubi]

@sithmein it all depends on the context and use case, to summarize a Eclipse plug-in can be a maven deployed in which case it can be mapped as a maven PURL, if that's not the case it can't and one obviously needs a different scheme, but its not clear how useful this is.

It seems this is not really something the usual committer/contributors encounter and thus handled with very low priority, so if this is crucial to your business and you likes to speed up the development you can contact me for an individual contract for working dedicated on this specific issue.

[hboutemy]

I completely overlooked the example, now diving into it:

I now understand the problem in provided bom.json is for example

    {
      "group" : "p2.eclipse-plugin",
      "name" : "javax.annotation",
      "version" : "1.2.0.v201401042248",

is a Tycho / OSGi bundle (with its specific hashes) associated to I suppose an original "classical" non-OSGi jar (and its original hashes)

and you want to track the transformation of the original jar file (that is known to the usual non-OSGi community) into the OSGi bundle

I still need to understand the magic behind these OSGi bundle. I ran the example, and as of today, I got this download

[INFO] Fetching javax.annotation_1.3.5.v20200909-1856.jar from https://eclipse.c3sl.ufpr.br/releases/2022-06/202206151000/plugins/ (46,27kB)

(I suppose the version difference is just an update in the example code)

What Maven coordinates is this OSGi bundle supposed to match?
I guess a clear groupId, but not artifactId, looking at https://repo.maven.apache.org/maven2/javax/annotation/ : is it supposed to be javax.annotation-api? Is there an algorithm to extract that info?

FYI, rebuilding today, the group in generated bom.json is nowadays p2.eclipse.plugin instead of p2.eclipse-plugin that you had in the past: I don't know where the magic group was defined, but it has changed
Notice: I find this "Eclipse Plugin" term quite confusing here: IIUC, this has nothing to do with Eclipse plugins, but OSGI-fied jars (that sometimes are used in Eclipse plugins context, but not always)

please help clarifying the problem, then we'll see what solutions may be found (probably at multiple levels)

[laeubi]

As said there is not a 1:1 mapping to maven artifacts, it might be that a maven artifact was used and just wrapped as a bundle, it might be build from source with some modification, it might even not be on maven central at all, it could even be directly consumed from maven, but the unit-id does not mean anything in this regard.

[sithmein]

What we see in our applications is the following:

1. OSGi bundles that only exist as OSGi bundles, such as most of org.eclipse.*. Having them under the p2.eclipse.plugin group id is totally fine.

2. OSGi bundles that have been converted from Maven artifacts using the p2 Maven plug-in or more generally bnd. The problem is that the bundle name does reflect the Maven name 1:1 in many cases. Oftentimes the group ID is stripped during the conversion. For example, org.slf4j:slf4j-api:1.7.15 simply becomes slf4j.api_1.7.25.jar. However, in all these cases the bundle jar contains the original pom.xml, e.g. META-INF/maven/org.slf4j/slf4j-api/pom.xml. Therefore I could image that some new code looks into the bundle jar, tries to find a pom.xml file, and uses this information to get to the Maven coordinates.

3. OSGi bundles that were converted from Maven artifacts by some other means (e.g. manually). javax.annotation_1.3.5.v20200909-1856.jar is an example. It also contains the original pom.xml, but at a slightly different path META-INF/maven/org.eclipse.orbit.bundles/javax.annotation/pom.xml (notice the org.eclipse.orbit.bundles).

4. OSGi bundles that are hand-crafted. Name and content is more or less arbitrary.

Case 1 is already covered in my opinion. Having a solution for case 2 would cover > 80% (in our case). Case 3 is very similar to case 2 and I guess they could be solved together. Case 4 isn't something that has to (or can be) be supported.

[hboutemy]

ok, I think I'm starting to understand the problem space

I propose the following plan:

1. add p2 to purl spec: https://github.com/package-url/purl-spec
2. have cyclonedx-maven-plugin generate p2 coordinates when it finds Maven pseudo-coordinates generated by Tycho (IIUC: I'd love to have a pointer to the code that generates the groupId, because I'd love to have the value changed)
3. eventually try to implement some heuristics to generate some pedigree when it looks like a p2 artifact is a re-packaging from a Maven one https://cyclonedx.org/docs/1.4/json/#components_items_pedigree

when I see the javax.annotation_1.3.5.v20200909-1856.jar bundle that contains META-INF/maven/org.eclipse.orbit.bundles/javax.annotation/pom.xml, perhaps Tycho should generate in org.eclipse.orbit.bundles groupId instead of p2.eclipse.plugin / p2.eclipse-plugin: having a pointer to the Tycho doc on this pseudo groupId wuold be useful to share for non-experts if we want more people to understand p2/Tycho vs Maven

[laeubi]

add p2 to purl spec: https://github.com/package-url/purl-spec

It should be something like pkg:p2/bundle/<P2_ID>@<P2_VERSION> but I have no clue how to modify the spec, so if someone wants to do so I can help review / give further information.

have cyclonedx-maven-plugin generate p2 coordinates when it finds Maven pseudo-coordinates generated by Tycho (IIUC: I'd love to have a pointer to the code that generates the groupId, because I'd love to have the value changed)

The value is an implementation detail of Tycho and can't be changed it is purely used inside the current reactor build to specify system scoped dependencies in the maven model, the only thing we somehow gurantee as stable is that is starts with p2. as defined here:

https://github.com/eclipse-tycho/tycho/blob/ff1f7538c8ecd9718a1bd269dd791289ff1c7ffb/tycho-api/src/main/java/org/eclipse/tycho/TychoConstants.java#L27

eventually try to implement some heuristics to generate some pedigree when it looks like a p2 artifact is a re-packaging from a Maven one https://cyclonedx.org/docs/1.4/json/#components_items_pedigree

The is no guarantee at all that a P2 artifact has ever been "repacked" from a maven artifact, the tycho-packaging:update-consumer-pom performs some back-resolving for items that where consumed directly from maven but this is more to support consumers of the pom not as a mean of what is shipped with a product.

perhaps Tycho should generate in org.eclipse.orbit.bundles groupId instead of p2.eclipse.plugin / p2.eclipse-plugin

This has nothing to do with Tycho and not every bundle build by Tycho is an orbit one, actually orbit uses bnd to build its bundles. Please don't repeat the error of the Eclipse license tool to assume every bundle originates from orbit, that is simply wrong.

having a pointer to the Tycho doc on this pseudo groupId would be useful to share for non-experts if we want more people to understand p2/Tycho vs Maven

See above, there is no such documentation because it is internal behavior of Tycho to overcome the restrictions of the maven model, also note that P2 != Tycho, Tycho just supports using P2 repositories as it supports to use Maven Repositories as well.

[hboutemy]

on updating https://github.com/package-url/purl-spec, it all starts with a PR
I suppose that the bundle word in pkg:p2/bundle/<P2_ID>@<P2_VERSION> is not necessary: I suppose pkg:p2/<P2_ID>@<P2_VERSION> is what is expected

On cyclonedx-maven-plugin generating such p2 purl, IIUC, it' about detecting Maven p2.* groupId to know that a p2 purl should be done, and that's it: looks reasonable

We'll see later if heuristics can be done to try to generate a pedigree from a p2 purl to a Maven artifact: honestly, that part is the type of tricks that I'd prefer to keep out of cyclonedx-maven-plugin

[laeubi]

I suppose that the bundle word in pkg:p2/bundle/<P2_ID>@<P2_VERSION> is not necessary:

P2 can store different type, e.g. bundles, features, products, ... so the type should be represented somehow to not run into issues later on.

On cyclonedx-maven-plugin generating such p2 purl, IIUC, it' about detecting Maven p2.* groupId to know that a p2 purl should be done, and that's it: looks reasonable

If that helps anything it could be done that way yes, another indication is that it is a system scoped dependency.

[hboutemy]

if there are different "types" for p2 that need to be represented in purl , pkg:p2/<P2_TYPE>/<P2_ID>@<P2_VERSION> what are these types, and how can cyclonedx-maven-plugin determine which type a p2 dependency is?
this will have to be clearly defined

[laeubi]

I think the most relevant ones are

• p2.eclipse.plugin = bundle
• p2.eclipse.feature = feature

There are also update sites, products and target but those are usually nothing one can depend on.

[hboutemy]

are all these really related to an artifact? When I read, it feels to me that it is related to the repository where the artifact comes from

[laeubi]

Sorry I don't fully understand. A bundle is not a feature even if both are stored as a jar file (a feature usually groups bundles and other features), the repository (like a maven repository) can store different things but do not really care of course much here but I'm not that familiar with SBOM to decide if / hwo it makes a difference so would say it should be handled like in maven where an artifact can be type xml, jar, zip, ....

[hboutemy]

nobody of us is expert in both p2 Tycho and SBOM, that's why we need to share examples to try to define what best fits the different aspects

the current question is to define if p2 has a notion of namespace or not: see scheme:type/namespace/name@version?qualifiers#subpath fields description in purl description and examples at https://github.com/package-url/purl-spec#purl (we'll see later optionql qualifiers and subpath)

It seems that the "bundle", "feature", "update site", "product", "target" examples that you shares are in fact a precision of a sub-part of a p2 repository location
but an artifact like javax.annotation_1.3.5.v20200909-1856.jar can be stored in the bundle or feature parts of a p2 repository: it's only one content (with one hash), it would not make sense to have a different content (hash) when it is stored in bundle or feature part, isn't it?

is pkg:p2/javax.annotation@1.3.5.v20200909-1856 describing sufficiently the artifact?
or is it absolutely necessary to write pkg:p2/plugin/javax.annotation@1.3.5.v20200909-1856 to show that it is fundamentally different from pkg:p2/feature/javax.annotation@1.3.5.v20200909-1856 or pkg:p2/product/javax.annotation@1.3.5.v20200909-1856?
Perhaps accepting both is what p2 needs, like npm and Docker purls are supported with or without namespace

Notice: perhaps that instead of having this discussion in this cyclonedx-maven-plugin issue, we should move to the same discussion in a purl issue...

[hboutemy]

another source of examples for purl is https://github.com/package-url/purl-spec/blob/master/PURL-TYPES.rst

can be useful to imagine how p2 would be added to the page; eclipse, osgi and p2 are already listed at the end as candidates (I don't how eclipse, osgi and p2 relate or not...)

[laeubi]

P2 artifacts originate from P2 repositories, such a repository for example can look like this:

https://download.eclipse.org/technology/m2e/releases/latest/

if you download the content.jar you will see a set of units each unit can have artifacts, a unit usually provides a capability of org.eclipse.equinox.p2.eclipse.type for example for a bundle

<provided namespace='org.eclipse.equinox.p2.eclipse.type' name='bundle' version='1.0.0'/>

or for a feature

<provided namespace='org.eclipse.equinox.p2.eclipse.type' name='feature' version='1.0.0'/>

So feature and bundle are different types and never point to the same artifact, as the artifact of a bundle type is a jar file that contains some compiled classes while a feature is a jar file that contains a feature.xml file and usually requires other bundle/feature units in the metadata (so this is maybe similar to a maven project of packaging jar versus packing pom).

[hboutemy]

when I see https://download.eclipse.org/technology/m2e/releases/latest/features/ and https://download.eclipse.org/technology/m2e/releases/latest/plugins/ it looks very similar
but I now understand that it would not really make sense to have a copy of the same file in the 2 directories, since in fact the expected content is from a different nature

ok, why not: this will have to be described in https://github.com/package-url/purl-spec/blob/master/PURL-TYPES.rst with the same approach as other types

I won't lead p2 addition to purl, as I'm not an expert of p2: once p2 will be added to purl types, I hope that the way Tycho defines Maven coordinates will permit us to implement in cyclonedx-maven-plugin a way to point to a p2 purl instead of a fake maven purl as it is currently the case

[ptziegler]

Given that this feature would be quite interesting for us, I took the liberty to create both package-url/purl-spec#271 and package-url/purl-spec#272.

Even though I'm not an expert, I like to think that I'm familiar enough with both Tycho and p2 that I'm willing to further pursue this topic.

As an example, the bundle javax.annotation_1.3.5.v20200909-1856.jar given above would correspond to the following PURL:

pkg:p2/bundle/javax.annotation@1.3.5.v20200909-1856?repository_url=https://download.eclipse.org/tools/orbit/downloads/drops/R20201130205003/repository

Assuming that this proposition gets accepted, how exactly would the Maven coordinates need to look like, in order for CycloneDX to detect them as p2 artifacts? The problems I can see so far are that:

• Those artifacts need to use the p2 type instead of the maven type.
• The group-id is effectively fixed to p2.eclipse-plugin/p2.eclipse-feature

[hboutemy]

you proposition for p2 support in purl looks reasonable to me

Assuming that this proposition gets accepted, how exactly would the Maven coordinates need to look like

in fact, I think that in cyclonedx-maven-plugin, Maven coordinates would be just in-memory transient state from Tycho: when generating the CycloneDX content, the Tycho provided groupId would permit to detect that this is not really Maven coordinates but p2, then p2 purl format

we can probably try to create a draft PR (sorry, I'm quite buy for now, I won't have time before December, but I love this)

[laeubi]

By the way, if cyclonedx-maven-plugin would offer an extension point for providers @Component Tycho could even implement something that could help cyclone-dx to determine the correct content, because we do not gurantee the group id it might change over time (but very unlikley).

@ptziegler while repository_url= seems useful you should take into account that not every p2 item is deployed to a P2 repository accessible by an URL.

[sithmein]

How can we make sure that with the new PURL prefix, p2 bundles that are merely converted Maven artifacts are correctly recognized as such and vulnerability databases are able to match vulnerabilities correctly?

[laeubi]

How can we make sure that with the new PURL prefix, p2 bundles that are merely converted Maven artifacts are correctly recognized as such and vulnerability databases are able to match vulnerabilities correctly?

There is no such thing as "p2 bundles"... P2 is a repository format like Maven, so there are no "maven bundles" either there are only artifacts that have some coordinates.

The whole purpose is to have a way to "target" artifacts (!) stored only in a P2 repository, Tycho already tries to map artifacts stored in a P2 repository to maven as good as possible. If that's not possible, because an artifact was taken from maven, then modified ("merely converted") and republished as P2 then in fact it is not the same artifact and you can't be sure it has or has not a CVE assigned to the original thing.

That's a reason why we at Tycho/Platform more and more move towards reusing contents directly from maven because then one can match those by the SHA-1/SHA-256 hashsums as a last resort.

[ptziegler]

when generating the CycloneDX content, the Tycho provided groupId would permit to detect that this is not really Maven coordinates but p2, then p2 purl format

Tycho could even implement something that could help cyclone-dx to determine the correct content, because we do not gurantee the group id it might change over time (but very unlikley).

Alternatively CycloneDX could check whether the artifact contains e.g. the feature.xml or OSGi metadata in the Manifest file (in an agnostic way, unrelated to Tycho). Though just by writing it down, I'm already not a huge fan of the additional overhead.
In general I agree that this is something that's better implemented in Tycho directly. Especially because this would avoid all expectations on how Tycho generates those group ids.

while repository_url= seems useful you should take into account that not every p2 item is deployed to a P2 repository accessible by an URL.

I've currently described it as a required property. Do you think it'd be better to keep it optional or to drop it entirely?
I know that one can report CVEs for a given purl, but I'm not sure if it then also takes the repository url into consideration...

How can we make sure that with the new PURL prefix, p2 bundles that are merely converted Maven artifacts are correctly recognized as such and vulnerability databases are able to match vulnerabilities correctly?

I'd agree with laeubi that if an artifact also exists on Maven Central, Tycho should try to (and already can) map it to its Maven GAV, which I think that's also something that could be handled within a potential extension. Otherwise you have no guarantee what's inside and have to treat it as a black box.

Now the interesting question whether there is a way to define aliases between purls. If an artifact was first uploaded to a p2 repository, but later to Maven Central, we end up with a p2 and a maven purl, both describing the same artifact.

At least from my side, the main goal is to have a formal way to report CVEs for "pure" p2 artifacts. The only way right now is via the artifical coordinates generated by Tycho, which I don't think is appropriate for such a case.

I can hopefully get some time towards the end of the month, to have a closer look at how this could work for CycloneDX/Tycho and perhaps even work on a small PoC.

[laeubi]

Alternatively CycloneDX could check whether the artifact contains e.g. the feature.xml or OSGi metadata in the Manifest file (in an agnostic way, unrelated to Tycho)

This won't work as just because a jar is a bundle or contains a feature does not mean it is an p2 hosted artifact...

I've currently described it as a required property. Do you think it'd be better to keep it optional or to drop it entirely?

Yes at least optional, with P2 its quite common that an artifact "travels along", so question is how one finds it, I don't know how Maven does it but I assume one has to supply some kind of repositories to search for (with default to central), so for P2 one likely want to specify the repositories as well if one wants to resolve the artifact itself.

Now the interesting question whether there is a way to define aliases between purls. If an artifact was first uploaded to a p2 repository, but later to Maven Central, we end up with a p2 and a maven purl, both describing the same artifact.

That's the biggest point for me regarding the bom "hype", this all works if you have well defined sources and the tools all know it and people report things transparent but in the end, if a purl is NOT found it does not imply that there is no problem at all and if one is found not that there are not others.

[ptziegler]

By the way, if cyclonedx-maven-plugin would offer an extension point for providers Tycho could even implement something that could help cyclone-dx to determine the correct content, because we do not gurantee the group id it might change over time (but very unlikley).

As far as I understand, the tool already provides those extension points in form of the ModelConverter:

Model converter from Maven concepts (Artifact + MavenProject) to CycloneDX ones (resp. pURL and Component + Metadata).

and

ProjectDependenciesConverter:

Converts a Maven Project with its Maven dependencies resolution graph transformed into a SBOM dependencies list with their dependsOn.

So I assume Tycho (or any tool for that matter) would only need to provide their own implementation, which is then used instead of the default implementation.

[ptziegler]

Alright... I've just set up a small project containing a mock implementation of the ModelConverter:

package test;

@Component(role = ModelConverter.class, hint = "test")
public class CustomModelConverter implements ModelConverter {
    ...
}

In the META-INF/plexus folder, I've created a components.xml file with content:

<component-set>
    <components>
        <component>
            <role>org.cyclonedx.maven.ModelConverter</role>
            <hint>test</hint>
            <implementation>test.CustomModelConverter</implementation>
        </component>
    </components>
</component-set>

This project is then added as a dependency to the cyclonedx-maven-plugin

<plugin>
	<groupId>org.cyclonedx</groupId>
	<artifactId>cyclonedx-maven-plugin</artifactId>
	<dependencies>
		<dependency>
			<groupId>ptziegler</groupId>
			<artifactId>cyclonedx-extension</artifactId>
			<version>0.0.1-SNAPSHOT</version>
		</dependency>
	</dependencies>
</plugin>

And so far, my own implementation takes precedence over the default implementation.
Meaning at first glance, the CycloneDX Maven plugin already provides all the extensions required for external tools to inject their own model converters.

The first step should now probably be to clean up the definition of a p2 PURL and then, if there is interest, I could try to create a draft for Tycho with a proper implementation of the ModelConverter.

[schmoddi]

@ptziegler There certainly is interest. Looking forward to your implementation.

[ptziegler]

A proof-of-concept has recently been merged to Tycho, which generates a p2 PURL for OSGi artifacts.

Example:
bom.xml.txt

While implementing it, I noticed some weird edge-cases, where I'm not really sure how to handle them, or whether they are problematic to begin with:

The concept of a group doesn't really exist for an OSGi bundle. Instead, the artificial group id generated by Tycho is used. As mentioned above, this is an internal name and may be changed in a future Tycho version.

<component type="library" bom-ref="pkg:p2/org.eclipse.swt.cocoa.macosx.x86_64@3.124.200.v20231113-1355?classifier=osgi.bundle&amp;location=http%3A%2F%2Fdownload.eclipse.org%2Freleases%2F2023-12">
	<group>p2.eclipse.plugin</group>
	<name>org.eclipse.swt.cocoa.macosx.x86_64</name>
	<version>3.124.200.v20231113-1355</version>
	...
</component>

I don't know whether this is a critical component and what the implications are, if this value changes. Is there a document where I can look up the meaning of those entries?

[laeubi]

@ptziegler I would recommend not using the artificial group id, as it is more a technical thing as maven requires one.

I would simply align here with the osgi.identity Namespace specification and choose osgi.bundle as the group (or maybe osgi.fragment if applicable), for (p2) features we can choose an own name for example "eclipse-feature".

[JayAtFujifilm]

@stevespringett - We would also very much welcome a solution to the problem of not being able to associate p2.eclipse-plugin artifacts with the source artifacts in Maven Central (or whatever other original repository). This would be very useful to us.

[laeubi]

@JayAtFujifilm if they are from central and you haven't disable it Tycho will map them for you, but if your using something thats not on central it obviously can't be associated...

[JayAtFujifilm]

@laeubi Thanks for your quick reply. We are primarily interested in artifacts that originally came from Maven Central. We will look into this.