Rejuvenate existing Modisco Jenkins job

[eclipse-modisco-bot]

| --- | --- | | Bugzilla Link | 553120 | | Status | RESOLVED WONTFIX | | Importance | P3 normal | | Reported | Nov 16, 2019 04:55 EDT | | Modified | Nov 17, 2019 05:03 EDT | | See also | 552988 | | Reporter | Ed Willink |

Description

Bug 553002 - the Jenkins server is back albeit migrated to JIRO.

The last build on 18-May-2018 was green (199 tests, 20 skipped).

Similarly the last Gerrit build on 18-May-2018 was green.

They show that the build actually involves a script, three mavens, one script. Not surprising that interactive guessing fails.

If it worked 18 months ago, maybe it's easier to get it working again then migrate rather than guess and recode.

The auto-build on 15-Nov-2019 failed because XVNC doesn't run.

Restricting the buld to migration and it goes a lot further, but crashed with a cannot resolve org.eclipse.ui.ide because of an insoluble dependency cycle. I recall that the platform team are having pain with 'spurious' cycles; probably the same pain.

[ERROR] Cannot resolve project dependencies:\ [ERROR] Software being installed: org.eclipse.gmt.modisco.infra.browser 1.2.0.qualifier\ [ERROR] Missing requirement: org.eclipse.gmt.modisco.infra.browser 1.2.0.qualifier requires 'bundle org.eclipse.ui.ide 0.0.0' but it could not be found\ [ERROR] \ [ERROR] Internal error: java.lang.RuntimeException: No solution found because the problem is unsatisfiable.: [Unable to satisfy dependency from javax.xml 1.3.4.v201005080400 to bundle org.eclipse.osgi 0.0.0.; Unable to satisfy dependency from javax.xml.stream 1.0.1.v201004272200 to bundle org.eclipse.osgi 0.0.0.; Unable to satisfy dependency from org.apache.batik.dom 1.7.1.v201505191845 to bundle org.eclipse.osgi 0.0.0.; Unable to satisfy dependency from org.apache.xerces 2.8.0.v200803070308 to bundle org.eclipse.osgi 0.0.0.; Unable to satisfy dependency from org.apache.xml.resolver 1.1.0.v200806030311 to bundle org.eclipse.osgi 0.0.0.; Unable to satisfy dependency from org.apache.xml.resolver 1.2.0.v201005080400 to bundle org.eclipse.osgi 0.0.0.; Unable to satisfy dependency from org.eclipse.emf.codegen 2.19.0.v20190821-1536 to bundle org.eclipse.core.runtime [3.6.0,4.0.0).; Unable to satisfy dependency

But preceding the failure there are numerous warnings in regard to unresolved versions such as

[WARNING] No explicit target runtime environment configuration. Build is platform dependent.

Bundle org.eclipse.gmt.modisco.infra.browser.uicore.examples.cnf - Missing Constraint: Require-Bundle: org.eclipse.ui.ide; bundle-version="3.6.0"

[WARNING] p2 repository with URL http://download.eclipse.org/modeling/emf/emf/builds/milestone/S201910290220 is associated with multiple IDs; was 'EMF 2.206', now is 'EMF 2.205__3'

It would appear the the EMF Facet Releng naturally runs with prolific warnings where vintage versions such as 3.6.0 rather than 3.16.0 were tolerated or just ignored. Hard to know which warnings might be aggravating a platform issue.

Looking more closely there doesn't appear to be a ccle at all; just the final not very distinct line:

Unable to satisfy dependency from org.eclipse.modisco.util.emf.core 1.2.0.qualifier to bundle org.eclipse.emf.transaction 1.4.0.; No solution found because the problem is unsatisfiable.

which is possibly evolved to exactly 1.4.0 rather than greater than or equal to 1.4.0 and so misses the 1.9.0 in the latest release. Very confusing diagnosis.

[eclipse-modisco-bot]

By Ed Willink on Nov 16, 2019 05:15

Doh! OCL/QVTd/QVTo jobs fail by identifying a repository load failure. The Modisco build seems to plough on regardless. But comparing the good bad build, at least four repos are stale and so missing.

[eclipse-modisco-bot]

By Ed Willink on Nov 16, 2019 05:51

The target platform is specified in the not very obviously releng plugin:

/org.eclipse.modisco.archi.tech.targetplatform/org.eclipse.modisco.archi.tech.targetplatform.target

and uses

http://download.eclipse.org/releases/helios/201006230900/\ http://download.eclipse.org/technology/epp/packages/helios/

Surprisingly the helios platform is still there but the epp has vanished no doubt causing the problems.

[eclipse-modisco-bot]

By Ed Willink on Nov 16, 2019 05:59

(In reply to Ed Willink from comment #2)

The target platform is specified in the not very obviously releng plugin:

To be fair, Modisco seems to have been an early adopter of Tycho, the history shows a refactoring of the platform file in 2012.

Clearly the capabilities of Tycho in 2017 when I started on the OCL build are much improved. Modisco therefore has many unfortunate relics.

[eclipse-modisco-bot]

By Ed Willink on Nov 17, 2019 04:39

Providing explicit report to solve the missing emf.transactiion doesn't work ...

(In reply to Ed Willink from comment #0)

If it worked 18 months ago, maybe it's easier to get it working again then migrate rather than guess and recode.

Using the "migration" JIRO should solve the build repeats.

Unfortunately the use of vanished 10 years old repos is challenging.

The vanishing workspaces reported in Bug 553128 make debugging really hard.

The huge number f 'ok' warnings makes debugging hard.

---

Bottom line. Getting an irregular unfamiliar vintage build working doesn't seem easy at all.

In contrast, selectively migrating old pom.xml content to a working new-style build may be easier after all.