API Tools Plugin requires baseline to contain dependencies

[Kummallinen]

tycho-apitools mojo requires the dependencies of the bundle being analysed to also be in the baseline. This can significantly inflate the size of the baseline repo on projects with many dependencies.

This is not required by the PDE based methods

[INFO] --- tycho-apitools:4.0.6:verify (verify) @ REDACTED ---
[INFO] Resolve API baseline for REDACTED:eclipse-plugin:1.3.3-SNAPSHOT with linux/gtk/x86_64
[INFO] {osgi.os=linux, osgi.ws=gtk, org.eclipse.update.install.features=true, osgi.arch=x86_64, org.eclipse.update.install.sources=true}
[ERROR] Cannot resolve project dependencies:
[ERROR]   Software being installed: REDACTED 1.3.2.v20231004-1003
[ERROR]   Missing requirement: REDACTED 1.3.2.v20231004-1003 requires 'osgi.bundle; org.eclipse.ui 0.0.0' but it could not be found

[laeubi]

How do you develop in PDE without the dependencies of the bundle?

[Kummallinen]

@laeubi the dependencies exist in the current target platform and the bundle builds. The issue is that tycho API tools appears to need the baseline repo to contain the dependencies of the baseline version.

In most cases I've seen the baseline is a p2 repo which will rarely contain all the dependencies of the bundle. e.g. you won't ship "org.eclipse.ui" in your P2 repo unless you're shipping a full RCP produce

For example this is CDT's baseline target platform, the repo only include CDT + some CDT specific dependencies. This works in PDE: https://github.com/eclipse-cdt/cdt/blob/main/releng/org.eclipse.cdt.target/cdt-baseline.target

[laeubi]

It should work to add other repositories (those containing the dependencies) ass additional baseline repository, e.g. in the CDT case you probably want to add https://download.eclipse.org/eclipse/updates/4.32-I-builds/ as baseline repo.

I think we can probably add a "light" mode, but as API tools often behave quite strange in case it finds not all dependencies currently it is required to have a full resolved "target" as a baseline.

[Kummallinen]

If all the dependencies are needed to work fully then allowing a target platform, similar to #3523 but referenced via a maven artefact, would make usage much simpler. The baseline target platform could then just include the original target platform used to build the baseline version.

[laeubi]

Yes that's what one would expect as "baseline repo", e.g. one could use a previous updatesite (that contains references to other sites) so one can fetch a complete overview.

[Kummallinen]

Using on referenced repositories is problematic for a number of use cases

1. Where you're building behind a firewall & use internal only proxy/mirror repositories
2. When the final location of those dependencies cannot be known at build time. e.g. building as part of Eclipse Simrel, where the exact final location might not be fully known until release

This can be worked around, by either matching every repository from the previous target platform in the plugins configuration, or by generating a dedicated "baseline" p2 repo which bundles all dependencies. But this is adding extra work the PDE method of running API analysis did not need.

Target Platform support would resolve this, so I am happy to add a comment to #3523 and close this.

[laeubi]

I can just offer some alternatives, of course the easiest (and safest) would be to build a baseline repo that includes al dependencies, as that's the only way to "archive" your baseline.