Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [orbit-dev] Handling of ip log entries in Orbit

If I recall correctly the purpose of the IP Log is historical, when CQs where mandatory. I do believe we should look for a way to get rid of them.

Most bundles are sourced from Maven these days. Thus, we do have the Maven coordinates in the Orbit recipe. 

@Wayne can you propose something that makes technically sense to you? Can you parse the pom.xml of Orbit bundles? Should we put the originating coordinates into the produced jar?


Gunnar Wagenknecht

On Jun 27, 2022, at 12:21, Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx> wrote:

I have no opinion regarding whether or not Orbit information tracks the source of approval.

From an IP due diligence point of view, what I need from Orbit is the mapping from the bundle to the source content.

That is, what I actually need is knowledge that org.junit.platform.suite.api_1.8.1.v20211018-1956.jar comes from maven/mavencentral/org.junit.platform/junit-platform-suite-api/1.8.1 (that is, org.junit.platform:junit-platform-suite-api:1.8.1 on Maven Central). Right now, I'm tapping the Orbit metadata to try and get a mapping back to a CQ, and from the CQ to the GAV and from the GAV to the ClearlyDefined Id and from the ClearlyDefined Id to license information. I've written a pretty insane heuristic that with minimal hinting actually sorts out a lot of these mappings, but many of them end up just being really good guesses. Having a well-defined mapping would be handy.

My strong preference is that we not duplicate information. There is probably some value in having the historical perspective preserved as there is some tendency for the license information to evolve as we get better information. But... we can capture that historical perspective in IPLab.


On Mon, Jun 27, 2022 at 11:45 AM Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:
Hi Orbit-devs/Wayne,

I have come across a strange case that I want to know how to handle going forward. At the moment every bundle in Orbit has a CQ# or clearly defined entry in /src/eclipse/ip_log.xml

However we have some bundles which are incorrect in orbit - e.g. maven/mavencentral/org.junit.platform/junit-platform-suite-api/1.8.2 is listed via its clearly defined entry, where the score is only 15. But the license tool accepts it because covers the bundle.

Can we ditch maintaining CQ, ClearlyDefined metadata in Orbit? Or is there something used here still? If it is the latter, it sounds like we need to extend support for the ip_log.xml file to have gitlab tracking #s too so the correct information is there.



Jonah Graham
Kichwa Coders
orbit-dev mailing list
To unsubscribe from this list, visit

Wayne Beaton
Director of Open Source Projects | Eclipse Foundation

My working day may not be your working day! Please don’t feel obliged to read or reply to this e-mail outside of your normal working hours.
orbit-dev mailing list
To unsubscribe from this list, visit

Back to the top