[releng] Maintain currency

[eclipse-modisco-bot]

| --- | --- | | Bugzilla Link | 582650 | | Status | RESOLVED FIXED | | Importance | P3 normal | | Reported | Nov 19, 2023 06:28 EDT | | Modified | Dec 07, 2023 12:37 EDT | | See also | 582651, 582716 | | Reporter | Ed Willink |

Description

org.eclipse.modisco.usecase.modelfilter.tests.SimpleBlackBoxDiscovery.testUmlModelFromJavaProjectWithReferenceModel has been failing since March with a mismatching file content.

Superficially looks like a perhaps-unjistifoed ordered/not-ordered assumption.

Now with Platform/Orbit changes we fail on Java 17, missing antlr, ...

Time for a bit of TLC.

[eclipse-modisco-bot]

By Ed Willink on Nov 19, 2023 11:22

Using Java 17 for platform execution is straightforward.

Then we can eliminate use of pack200.

Fortuitously the test broken in March seems ok now.

Then we can get Antlr, Lucene, Prefuse from the old Orbit.

New Orbit provides an alternative 3.2.0. Since it is still 3.2.0 and the tests all work this is probably safe.

New Orbit provides lucene 9.8.0 rather than 3.5.0 and the tests all work. But it is a huge version change; too dangerous while on life support.

OOMPH setup updated for Java 17 and new Orbit and no nature pop-ups; 'latest' might now be future proof.

Pushed to master.

(In principle nothing has changed since 1.5.2, so we do not need a release, but with so much changing infrastructure-wise, perhaps we had better release the refresh. email sent to cross-project-dev.)

[eclipse-modisco-bot]

By Ed Willink on Nov 19, 2023 12:01

(In reply to Ed Willink from comment #1)

Fortuitously the test broken in March seems ok now.

Ouch! 1.5.2 had 201 tests with 0 fails, 26 skipped.

1.5.3 N-build has 49 tests with 0 fails, 13 skipped. 1.5.3 S-build has 201 tests with 1 fails, 26 skipped.

Looks like our old friend

Caused by: java.lang.ClassNotFoundException: org.apache.maven.surefire.junit4.JUnit4Provider

[eclipse-modisco-bot]

By Ed Willink on Nov 20, 2023 01:11

(In reply to Ed Willink from comment #2)

Looks like our old friend

Caused by: java.lang.ClassNotFoundException: org.apache.maven.surefire.junit4.JUnit4Provider

QVTo Bug 582609. But we already have javax.annotation

---

Is problem reproducible? Yes. Reproduces on branch-tests and earlier builds seem 'consistent'.

What is different between N/S? Obviously just nightly/stable.target.

The stable build is better since it runs more tests albeit one fails.

The nightly.target attempts to fetch many of its contributions from explicit 'nightly' repos, but seems out of date. stable.target seems more credible.

So redevelop nightly.target from stable.target.

[eclipse-modisco-bot]

By Ed Willink on Nov 20, 2023 05:00

(In reply to Ed Willink from comment #3)

Is problem reproducible? Yes. Reproduces on branch-tests and earlier builds seem 'consistent'.

Even reproduces locally on an OOMPH installation on my 'new' laptop. (Stalled on my 'old' laptop.)

Superficially the failing test appears to work sincethe local launch lacks the overall UNSTABLE verdict, but viewing the failed test report shows similar comparison failure.

Even reproduces as a JUnit plugin test so that the comparison is viewable. Differences all seem to involve extra java.lang.constant externals. Perhaps the test failure is just extra Java 17 stuff to discover.

What is different between N/S? Obviously just nightly/stable.target.

The stable build is better since it runs more tests albeit one fails.

The nightly.target attempts to fetch many of its contributions from explicit 'nightly' repos, but seems out of date. stable.target seems more credible.

So redevelop nightly.target from stable.target.

(In reply to Ed Willink from comment #0)

org.eclipse.modisco.usecase.modelfilter.tests.SimpleBlackBoxDiscovery. testUmlModelFromJavaProjectWithReferenceModel has been failing since March with a mismatching file content.

Bug 582651

[eclipse-modisco-bot]

By Ed Willink on Nov 20, 2023 12:10

(In reply to Ed Willink from comment #3)

So redevelop nightly.target from stable.target.

stable.target has a gratuitous old-Orbit repo reference that can be safely removed.

nightly.target fetches org.eclipse.sdk.feature.group from https://download.eclipse.org/eclipse/updates/I-builds whereas stable.target fetches from https://download.eclipse.org/releases/latest.

Refining the fetch we find that https://download.eclipse.org/releases/2023-12/202310271000 is ok but https://download.eclipse.org/releases/2023-12/202311171000 has the JUnit4Provider problem.

So for the 2023-12 release we can use 2023-09 explicitly or implicitly via releases/latest. The latter defers solving the JUnit4Provider till 2024-03 M1.

[eclipse-modisco-bot]

By Ed Willink on Nov 22, 2023 09:31

(In reply to Ed Willink from comment #5)

So for the 2023-12 release we can use 2023-09 explicitly or implicitly via releases/latest.

Pushed to master for RC1.

The latter defers solving the JUnit4Provider till 2024-03 M1.

These problems are sometimes a consequence of mismatching versions. The removal of an explicit export in one place needs an import in another.

If (when) it recurs after 2023-12 fixing a new bug can first move to latest Tycho and Maven then debug. IIRC this was reproducible on a local Tycho build.