The content contributed to SimRel/EPP is very stale

[merks]

The project's contributed content is very old:

https://eclipse.dev/simrel/?file=report/report.md#-embedded-cdt--3

This site is 5 release cycles old:

https://download.eclipse.org/embed-cdt/releases/6.6.1/p2/

The package has not be tested for 5 release cycles:

https://github.com/eclipse-packaging/packages/blob/8be74dfb08fecf3a4dc50f3d719d3ee3e9f7fda0/releng/org.eclipse.epp.config/tools/upload-to-staging.sh#L60

The stale content contributes to a significant number of CVEs in the packaged IDE and hence also in the release train repository:

https://sbom.eclipse.org/projects/e1ac111b-8567-403c-8df7-950588c102e9/collectionprojects

This really needs attention, or we need to consider discontinuing SimRel participation as well as the IDE packages.

[ilg-ul]

This really needs attention...

Can you be more specific? I don't know what the Risk score means.

[merks]

I have not triaged all the CVEs nor do I plan to do that because if you look at the long list:

https://sbom.eclipse.org/projects/6efa4ff8-2bc1-4342-8e70-a722ed3b3e4b/findings

You'll see a major problem here is old versions of jackson and jsoup that will simply go away with the latest Orbit:

https://sbom.eclipse.org/projects/b96efdc4-388b-4e18-a3e6-84fae7e314e5/findings

It seems jdom is more problematic though again, I have not triaged the problems. I think generally folks need to switch to jdom2.

https://repo.maven.apache.org/maven2/org/jdom/jdom2/2.0.6.1/

The problem with xalan is even more annoying because I was hoping for a new version with source but I think that this hope must die:

eclipse-orbit/orbit-simrel#14

---

Anyway, I'd be happy if the project simply did a new build with new Orbit dependencies and very happy if someone occasionally (once per cycle) tested the EPP package...

[ilg-ul]

Hi Jonah @jonahgraham,

I downloaded the following from Orbit (https://download.eclipse.org/tools/orbit/downloads/drops/R20230531010532/):

-rw-r--r--@ 1 ilg  staff    91975 Jan  6 18:47 com.fasterxml.jackson.core.jackson-annotations_2.13.2.v20220426-1653.jar
-rw-r--r--@ 1 ilg  staff   396127 Jan  6 18:47 com.fasterxml.jackson.core.jackson-core_2.13.2.v20220426-1653.jar
-rw-r--r--@ 1 ilg  staff  1602238 Jan  6 18:47 com.fasterxml.jackson.core.jackson-databind_2.13.2.v20220426-1653.jar
-rw-r--r--@ 1 ilg  staff    27178 Jan  6 18:47 com.google.api.client-json_1.2.3.v20221112-0806.jar
-rw-r--r--@ 1 ilg  staff   457538 Jan  6 18:49 org.jsoup_1.14.3.v20211012-1727.jar

Should I copy them into plugins/org.eclipse.embedcdt.core/lib, with their current long names?

In plugins/org.eclipse.embedcdt.core/META-INF/MANIFEST.MF I can read:

Bundle-ClassPath: lib/antlr-runtime-3.5.2.jar,
 lib/jackson-annotations-2.9.9.jar,
 lib/jackson-core-2.9.9.jar,
 lib/jackson-databind-2.9.9.3.jar,
 lib/ST4-4.0.8.jar,
 lib/json-simple-1.1.1.jar,
 lib/org.jsoup_1.7.2.v201411291515.jar,

Should I update the paths to the new files?

[jonahgraham]

Actually I think the content of https://github.com/eclipse-embed-cdt/eclipse-plugins/tree/master/plugins/org.eclipse.embedcdt.core/lib is itself a (the) problem. Those dependencies should be coming from the orbit bundles, not copied in.

I will make a PR for this, but I may need some pointers on how to test these changes.

[merks]

Oh dear goodness. 😱 😢

I try to provide up-to-date details in announcements for Orbit locations:

https://github.com/orgs/eclipse-simrel/discussions/1188

[ilg-ul]

I may need some pointers on how to test these changes

There are more than 10 years since I wrote that code, so all I can do is to inspect the code. :-(

The jackson libraries are used in the *.core.liqp classes, used to process Liquid templates. So I guess that instantiating projects that use Liquid templates might be a good starting point.

The json library is used in the debug plugins to parse some configuration files. I'm not sure which ones...

[jonahgraham]

@ilg-ul WDYT about the project changing all dependencies to latest Eclipse? Managing builds against very old (2020 version) of Eclipse + CDT but running against latest version is complicated.

We can do that as Embed CDT version 7.0 or 6.7.0 - my preference is 7.0 to make it clear to consumers that the dependency version changed.

I know in the past you had objected to this, but as we are now 5+ years past the version in the target file I hope we can revisit this.

eclipse-plugins/target-platform/org.eclipse.embedcdt.target-platform.target

Line 6 in 4ed6716

<repository location="https://download.eclipse.org/releases/2020-09/202009161000"/>

[merks]

If there is anything I can do to help, let me know and I will try my best...

[ilg-ul]

WDYT about the project changing all dependencies to latest Eclipse?

Well, I'm sure that there are still many users running old Eclipses (directly or via various Studios), and they'll not be happy.

Plus that after so many years of no longer using Eclipse in my day to day work I'm quite disconnected from the project, and I don't know how difficult would be to do this update.

But we'll do as you think more appropriate for the project.

[jonahgraham]

Somethings have bitrotten in the docs AFAICT. The default qemu-arm does not support "STM32F4-Discovery". Is there a quick workaround for this so I can run the tutorial? To verify these changes I would like to test in the standalone way rather than how Renesas or other ISVs have extended.

qemu-system-arm: unsupported machine type: "STM32F4-Discovery"
Use -machine help to list supported machines

I tried a bunch of old versions, and my really old one qemu/2.8.0-6-20190517-1329 I had lying around supports the board, but not the processor:

qemu-system-gnuarmeclipse: Unable to find CPU definition STM32F407VG

[ilg-ul]

The final xPack QEMU that supports that board is 8.2.6-1:

• https://xpack-dev-tools.github.io/qemu-arm-xpack/blog/2024/09/12/qemu-arm-v8-2-6-1-released/

[ruspl-afed]

Managing builds against very old (2020 version) of Eclipse + CDT but running against latest version is complicated.

I tried to build both master and develop locally with JDK 11 (tycho 1.7.0), but failed with strange maven class path resolution errors.
Since you have announced your plans regarding PR @jonahgraham , I'd rather wait for that.