[azoitl]

Add GitHub CI action to check 3rd party with Eclipse Dash. "Automate IP team review requests" functionality requires API token to be asked via EF HelpDesk ticket by PL

This helps to identify any dependencies that are currently not license vetted. We started doing this at 4diac IDE and as we are an Eclipse Milo user we noticed this could be also interesting for you.

[greptile-apps]

Confidence Score: 4/5

[High impact] Adds a CI workflow that calls an external license-checking action.

Fix the branch filters before merging so license checks run on normal development changes.

Findings

1.  Active branches miss license checks ▶
2.  Checks change without review ▶

Summary

Adds an Eclipse Dash workflow to check third-party licenses.

• GitHub runs an Eclipse Dash license check for Milo.

_{Reviews (1) · Last reviewed commit: "Employ Eclipse Dash to control 3rd party..." · Reviewed by Greptile}

[kevinherron]

thanks @azoitl - just to be clear, this requires a new HelpDesk ticket on my part before it will work / merging?

[azoitl]

thanks @azoitl - just to be clear, this requires a new HelpDesk ticket on my part before it will work / merging?

if you want automatic reporting of new dependencies to IpLab yes. If you just want feedback and do the IpLab requests your self, no.

[azoitl]

@kevinherron could you please retrigger running the workflows. The last run was somehow strangely aborted.

[kevinherron]

@azoitl looks like it's working:

  [INFO] --- license-tool:1.1.0:license-check (default-cli) @ milo ---
  [INFO] Querying Eclipse Foundation for license data for 40 items.
  [INFO] Found 38 items.
  [INFO] Querying ClearlyDefined for license data for 2 items.
  [INFO] Found 2 items.
  [INFO] Vetted license information was found for all content. No further investigation is required.
  [INFO] Summary file was written to: /home/runner/work/milo/milo/target/dash/summary

thanks!

[azoitl]

This is interesting because we at 4diac IDE have problems with two dependencies we get through Eclipse Milo: eclipse-4diac/4diac-ide#2253 (comment)

Can this be because you improved on develop or are we doing something wrong?

[kevinherron]

@azoitl some AI sleuthing:

This appears to be an identifier-mapping issue after Tycho wraps the libraries as OSGi bundles.

Milo still uses the same versions:

Library	Maven coordinates
strict-machine	com.digitalpetri.fsm:strict-machine:1.0.0
netty-channel-fsm	com.digitalpetri.netty:netty-channel-fsm:1.0.2

4diac's CI log shows Tycho wrapping both JARs. Dash then checks these generated identities:

p2/orbit/p2.eclipse.plugin/com.digitalpetri.fsm.strict-machine/1.0.0
p2/orbit/p2.eclipse.plugin/com.digitalpetri.netty.netty-channel-fsm/1.0.2

Dash's plugin code assigns p2/orbit to artifacts whose group starts with p2.. It does not recover their original Maven coordinates there.

Milo checks the Maven identities instead. Its successful CI run checks 40 items, finds 38 through Eclipse's service, and verifies the remaining two through ClearlyDefined.

That points to a missing mapping for 4diac's generated p2 identities. A dependency update on Milo's development branch does not explain the difference, since Milo still uses those same versions. The next step would be to raise the mapping issue with Dash/Tycho or request review of the generated p2 identities.

[azoitl]

@kevinherron thx for the support. I will then investigate further on our side.

It looks like that it is coming again from Eclipse Milo shadowing and repackaging dependencies. Have you every considered to provide also maven packages without shadowed packages. TBH these shadowing made us from the beginning troubles. For example we have now some packages that we also use doubled. Also we can not easily update these packages without using a newer Eclipse Milo version.

[kevinherron]

I only shadow and relocate Guava, and I'm not sure what issues it's causing you - maybe something OSGi specific that I don't understand? To normal Maven/Gradle consumers it is completely transparent.

I feel pretty strongly that library authors (as opposed to applications) should not be exposing extremely common/popular transitive dependencies such as Guava to their downstream consumers. If I could rid myself of Guava entirely I would.

[azoitl]

TBH I'm not sure. I'm neither an OSGI, nor a Maven and Eclipse Tycho expert. I'll further investigate. Having Eclipse Dash in place here helps already a lot to narrow down the problem.