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
I hadn't thought of parsing the pom.xml files...

Based on a cursory look, it appears that everything that I'd need is there. The artifactId and version basically provide the bundle information and the dependencies describe the sources. I think that I can make that work.

Wayne

On Mon, Jun 27, 2022 at 2:04 PM Gunnar Wagenknecht <gunnar@xxxxxxxxxxxxxxx> wrote:
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

-- 
Gunnar Wagenknecht
gunnar@xxxxxxxxxxxxxxx, http://guw.io/



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.

Wayne

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 https://gitlab.eclipse.org/eclipsefdn/emo-team/iplab/-/issues/1490 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.

Thoughts?

Thanks
Jonah


~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com
_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/orbit-dev


--
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
orbit-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/orbit-dev

_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/orbit-dev


--

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.

Back to the top