[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [sw360-dev] Oldie but goldie: Component Identification
|
Hi,
I am not one hundred percent sure what the actual proposal is. However, I think it is generally a good idea to store the purl for a component. Shouldn't this already work with our external id concept. We just define another external id "purl" which stores the purl.
In antenna we had similar discussions about coordinates and introduced a hierarchy of possible namings for components, from very generic ones, eg just the filename, to specific ones like maven coordinates. This allows to cover all types of identified components and you don't need to miss any.
Kind regards,
Johannes
Mit freundlichen Grüßen / Best regards
Johannes Kristan
INST-CSS/BSV-OS
Tel. +49 30 726112-432
-----Ursprüngliche Nachricht-----
Von: sw360-dev-bounces@xxxxxxxxxxx <sw360-dev-bounces@xxxxxxxxxxx> Im Auftrag von Michael C. Jaeger
Gesendet: Freitag, 11. Januar 2019 11:54
An: sw360 developer discussions <sw360-dev@xxxxxxxxxxx>
Betreff: [sw360-dev] Oldie but goldie: Component Identification
Hi,
I am sitting here with Alex from Codescoop and we are discussing how to match component entries between two systems. eventually we do not see another approach than
* use the artefact management domain as part of the identification for a component
* allow for some low percentage missing mappings to get it actually working
* because any own ids are not suitable
The next thing is how to actually apply a common naming for things like maven, nuget, pypi, composer, deb etc etc. because also you could have a decision on "mvn" or "maven", or composer vs cmp, and more discussions alike and how to have a compiled list on the first hand.
Of course we remember the purl proposal by Philippe and we are very much fond of taking the purl proposal for a definitive list of "artefact management domain" names which referred there as type:
https://github.com/package-url/purl-spec
-> see "Known purl types"
-> see "Other candidate types to define"
Any other thoughts on this?
in SW360 on component level we would need to add the field "type" and rename the existing field "category" (where we put value like "lib", "tool", "application", "database", etc.) to be consistent, but I think it is worth it, because the potential for solving a mapping problem and enabling a lot of use cases is huge.
Kind regards, Michael
_______________________________________________
sw360-dev mailing list
sw360-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sw360-dev
