Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update to Tycho 4.0.9 #2360

Merged
merged 1 commit into from
Sep 19, 2024
Merged

Conversation

laeubi
Copy link
Contributor

@laeubi laeubi commented Sep 19, 2024

No description provided.

@akurtakov akurtakov merged commit 47c6b46 into eclipse-platform:master Sep 19, 2024
4 checks passed
@HeikoKlare
Copy link
Contributor

The update to Tycho 4.0.9 broke the SWT builds. For some reason, tests within a fragment are not compiled against classes in that fragment anymore but seem to be compiled against the classes from the fragment for the current platform. This results in compilation failures for the win32 tests (within the win32 fragment) on MacOS and Linux, e.g., in our Jenkins builds such as https://ci.eclipse.org/releng/job/eclipse.platform.swt/job/PR-1478/2/pipeline-console/?selected-node=214

[ERROR] Failed to execute goal org.eclipse.tycho:tycho-compiler-plugin:4.0.9:testCompile (default-testCompile) on project org.eclipse.swt.win32.win32.x86_64: Compilation failure: Compilation failure: 
11:34:44  [ERROR] /home/jenkins/agent/workspace/eclipse.platform.swt_PR-1478/eclipse.platform.swt/bundles/org.eclipse.swt/Eclipse SWT Tests/win32/org/eclipse/swt/graphics/GCWin32Tests.java:[35] 
11:34:44  [ERROR] 	scaledGcNativeZoom.complete(event.gc.getGCData().nativeZoom);
11:34:44  [ERROR] 	                                                 ^^^^^^^^^^
...

@laeubi do you know about any change in Tycho that might have produced this regression?

@HeikoKlare
Copy link
Contributor

Just found that with the new Tycho version, the classpath for the testCompile execution does not only contain the current fragment (like before), but also contains jars of all the other fragments from the Maven repository:

[INFO] --- tycho-compiler:4.0.9:testCompile (default-testCompile) @ org.eclipse.swt.win32.win32.aarch64 ---
...
[DEBUG] Classpath: [/Users/heikoklare/dev/eclipse/platform-aggregator/git/eclipse.platform.swt/bundles/org.eclipse.swt/.
 /Users/heikoklare/.m2/repository/p2/osgi/bundle/org.eclipse.swt.cocoa.macosx.x86_64/3.128.0.v20240917-1259/org.eclipse.swt.cocoa.macosx.x86_64-3.128.0.v20240917-1259.jar
 /Users/heikoklare/.m2/repository/p2/osgi/bundle/org.eclipse.swt.gtk.linux.ppc64le/3.128.0.v20240917-1259/org.eclipse.swt.gtk.linux.ppc64le-3.128.0.v20240917-1259.jar
 /Users/heikoklare/.m2/repository/p2/osgi/bundle/org.eclipse.swt.gtk.linux.aarch64/3.128.0.v20240917-1259/org.eclipse.swt.gtk.linux.aarch64-3.128.0.v20240917-1259.jar
 /Users/heikoklare/.m2/repository/p2/osgi/bundle/org.eclipse.swt.cocoa.macosx.aarch64/3.128.0.v20240917-1259/org.eclipse.swt.cocoa.macosx.aarch64-3.128.0.v20240917-1259.jar
 /Users/heikoklare/.m2/repository/p2/osgi/bundle/org.eclipse.swt.gtk.linux.x86_64/3.128.0.v20240917-1259/org.eclipse.swt.gtk.linux.x86_64-3.128.0.v20240917-1259.jar
 /Users/heikoklare/dev/eclipse/platform-aggregator/git/eclipse.platform.swt/binaries/org.eclipse.swt.win32.win32.aarch64/target/classes
...

vs

[INFO] --- tycho-compiler:4.0.8:testCompile (default-testCompile) @ org.eclipse.swt.win32.win32.aarch64 ---
...
[DEBUG] Classpath: [/Users/heikoklare/dev/eclipse/platform-aggregator/git/eclipse.platform.swt/bundles/org.eclipse.swt/.
 /Users/heikoklare/dev/eclipse/platform-aggregator/git/eclipse.platform.swt/binaries/org.eclipse.swt.win32.win32.aarch64/target/classes
...

@laeubi
Copy link
Contributor Author

laeubi commented Sep 20, 2024

Its hard to tell without a testcase and given all test for Tycho complete without a problem I would suggest to at best
provide an integration-test to demonstrate the issue.

do you know about any change in Tycho that might have produced this regression?

In general if there is no test there is no regression, just relying on undefined behavior, especially as the problem seem to not arise in the usual integration builds.

@HeikoKlare
Copy link
Contributor

I was just asking whether there is an idea of which change might be the cause, because it would be easier if one could simply take a look at specific changes and their effects to find the cause than considering the issue as rather a black box with quite some effort to find potential reasons and writing a test case. If not, that's of course fine.

In general if there is no test there is no regression, just relying on undefined behavior, especially as the problem seem to not arise in the usual integration builds.

If that is really the attitude, then I am not sure why you have ever agreed on adding tests to fragments (eclipse-platform/eclipse.platform.swt#1203), i.e. to add code that is "relying on undefined behavior".

@laeubi
Copy link
Contributor Author

laeubi commented Sep 20, 2024

I was just asking whether there is an idea of which change might be the cause

As said all test run successful (including full platform integration build) so I have no real clue, I'm also not aware of any changes in that area, as its all mostly dependency updates and some additional feature, so nothing "dramatic", maybe eclipse-tycho/tycho#3928 could be something to check but thats just a guess because it slightly changes dependency resolution in very special cases. Maybe also its just an ordering issue of the classpath but I can't spot a specific changes in that area...

If that is really the attitude, then I am not sure why you have ever agreed on adding tests to fragments

This use-case is official supported and the corresponding tests seem to pass (but sadly not covering the special situation of SWT).

@HannesWell
Copy link
Member

With regards to eclipse-platform/eclipse.platform.swt#1478, I also see similar warnings that fail the build in PDE now, but they are actually false positives since the mentioned filters actually have to stay forever and in the IDE API-tools also complain if I remove them.
I also see API-errors about removed types in the platform and platform UI repo build and sporadically see them in Equinox. So something is wrong any where. It is maybe in Tycho or the API-tools themself or it is due to an infrastructure problem.

I'll try to investigate it tomorrow (of course help is always welcome).

@HeikoKlare
Copy link
Contributor

HeikoKlare commented Sep 21, 2024

maybe eclipse-tycho/tycho#3928 could be something to check but thats just a guess because it slightly changes dependency resolution in very special cases

Good catch, thank you! 🥇
I have just built the tycho-4.0.x branch with and without that change reverted. Reverting it makes the build succeed again.

I guess the indeterministic consequences (integration builds working while standalone SWT builds fail) might be because of dependency ordering. But in general, the change leads to further fragments being placed on the classpath.

This is the complete classpath (during compile / testCompile) with the mentioned change:

[DEBUG] Classpath: [/Users/heikoklare/dev/eclipse/platform-aggregator/git/eclipse.platform.swt/bundles/org.eclipse.swt/.
 /Users/heikoklare/.m2/repository/p2/osgi/bundle/org.eclipse.swt.cocoa.macosx.x86_64/3.128.0.v20240917-1259/org.eclipse.swt.cocoa.macosx.x86_64-3.128.0.v20240917-1259.jar
 /Users/heikoklare/.m2/repository/p2/osgi/bundle/org.eclipse.swt.gtk.linux.ppc64le/3.128.0.v20240917-1259/org.eclipse.swt.gtk.linux.ppc64le-3.128.0.v20240917-1259.jar
 /Users/heikoklare/.m2/repository/p2/osgi/bundle/org.eclipse.swt.gtk.linux.aarch64/3.128.0.v20240917-1259/org.eclipse.swt.gtk.linux.aarch64-3.128.0.v20240917-1259.jar
 /Users/heikoklare/.m2/repository/p2/osgi/bundle/org.eclipse.swt.cocoa.macosx.aarch64/3.128.0.v20240917-1259/org.eclipse.swt.cocoa.macosx.aarch64-3.128.0.v20240917-1259.jar
 /Users/heikoklare/.m2/repository/p2/osgi/bundle/org.eclipse.swt.gtk.linux.x86_64/3.128.0.v20240917-1259/org.eclipse.swt.gtk.linux.x86_64-3.128.0.v20240917-1259.jar
 /Users/heikoklare/dev/eclipse/platform-aggregator/git/eclipse.platform.swt/binaries/org.eclipse.swt.win32.win32.aarch64/target/classes
 /Users/heikoklare/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.11.0/junit-jupiter-api-5.11.0.jar[+**/*:?**/*]
 /Users/heikoklare/.m2/repository/org/junit/jupiter/junit-jupiter-engine/5.11.0/junit-jupiter-engine-5.11.0.jar[+**/*:?**/*]
 /Users/heikoklare/.m2/repository/org/junit/jupiter/junit-jupiter-migrationsupport/5.11.0/junit-jupiter-migrationsupport-5.11.0.jar[+**/*:?**/*]
 /Users/heikoklare/.m2/repository/org/junit/jupiter/junit-jupiter-params/5.11.0/junit-jupiter-params-5.11.0.jar[+**/*:?**/*]
 /Users/heikoklare/.m2/repository/org/junit/platform/junit-platform-commons/1.11.0/junit-platform-commons-1.11.0.jar[+**/*:?**/*]
 /Users/heikoklare/.m2/repository/org/junit/platform/junit-platform-engine/1.11.0/junit-platform-engine-1.11.0.jar[+**/*:?**/*]
 /Users/heikoklare/.m2/repository/org/junit/platform/junit-platform-launcher/1.11.0/junit-platform-launcher-1.11.0.jar[+**/*:?**/*]
 /Users/heikoklare/.m2/repository/org/junit/platform/junit-platform-runner/1.11.0/junit-platform-runner-1.11.0.jar[+**/*:?**/*]
 /Users/heikoklare/.m2/repository/org/junit/platform/junit-platform-suite-api/1.11.0/junit-platform-suite-api-1.11.0.jar[+**/*:?**/*]
 /Users/heikoklare/.m2/repository/org/junit/vintage/junit-vintage-engine/5.11.0/junit-vintage-engine-5.11.0.jar[+**/*:?**/*]
 /Users/heikoklare/.m2/repository/org/opentest4j/opentest4j/1.3.0/opentest4j-1.3.0.jar[+**/*:?**/*]
 /Users/heikoklare/.m2/repository/org/apiguardian/apiguardian-api/1.1.2/apiguardian-api-1.1.2.jar[+**/*:?**/*]
 /Users/heikoklare/.m2/repository/p2/osgi/bundle/org.junit/4.13.2.v20230809-1000/org.junit-4.13.2.v20230809-1000.jar[+**/*:?**/*]
 /Users/heikoklare/.m2/repository/org/apache/servicemix/bundles/org.apache.servicemix.bundles.hamcrest/1.3_1/org.apache.servicemix.bundles.hamcrest-1.3_1.jar[+**/*:?**/*]
 /Users/heikoklare/.m2/repository/org/osgi/org.osgi.service.event/1.4.1/org.osgi.service.event-1.4.1.jar[+org/osgi/service/event/annotations/*:?**/*]
 /Users/heikoklare/.m2/repository/org/osgi/org.osgi.annotation.bundle/1.1.1/org.osgi.annotation.bundle-1.1.1.jar[+org/osgi/annotation/bundle/*:?**/*]
 /Users/heikoklare/.m2/repository/org/osgi/org.osgi.service.metatype.annotations/1.4.1/org.osgi.service.metatype.annotations-1.4.1.jar[+org/osgi/service/metatype/annotations/*:?**/*]
 /Users/heikoklare/.m2/repository/org/osgi/org.osgi.service.cm/1.6.1/org.osgi.service.cm-1.6.1.jar[+org/osgi/service/cm/annotations/*:?**/*]
 /Users/heikoklare/.m2/repository/org/osgi/org.osgi.annotation.versioning/1.1.2/org.osgi.annotation.versioning-1.1.2.jar[+org/osgi/annotation/versioning/*:?**/*]
 /Users/heikoklare/.m2/repository/org/eclipse/pde/org.eclipse.pde.api.tools.annotations/1.4.0/org.eclipse.pde.api.tools.annotations-1.4.0.jar[+org/eclipse/pde/api/tools/annotations/*:?**/*]
 /Users/heikoklare/.m2/repository/p2/osgi/bundle/org.eclipse.osgi.services/3.12.100.v20240327-0645/org.eclipse.osgi.services-3.12.100.v20240327-0645.jar[+org/osgi/service/component/annotations/*:?**/*]]

And this is without it:

[DEBUG] Classpath: [/Users/heikoklare/dev/eclipse/platform-aggregator/git/eclipse.platform.swt/bundles/org.eclipse.swt/.
 /Users/heikoklare/dev/eclipse/platform-aggregator/git/eclipse.platform.swt/binaries/org.eclipse.swt.win32.win32.aarch64/target/classes
 /Users/heikoklare/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.11.0/junit-jupiter-api-5.11.0.jar[+**/*:?**/*]
 /Users/heikoklare/.m2/repository/org/junit/jupiter/junit-jupiter-engine/5.11.0/junit-jupiter-engine-5.11.0.jar[+**/*:?**/*]
 /Users/heikoklare/.m2/repository/org/junit/jupiter/junit-jupiter-migrationsupport/5.11.0/junit-jupiter-migrationsupport-5.11.0.jar[+**/*:?**/*]
 /Users/heikoklare/.m2/repository/org/junit/jupiter/junit-jupiter-params/5.11.0/junit-jupiter-params-5.11.0.jar[+**/*:?**/*]
 /Users/heikoklare/.m2/repository/org/junit/platform/junit-platform-commons/1.11.0/junit-platform-commons-1.11.0.jar[+**/*:?**/*]
 /Users/heikoklare/.m2/repository/org/junit/platform/junit-platform-engine/1.11.0/junit-platform-engine-1.11.0.jar[+**/*:?**/*]
 /Users/heikoklare/.m2/repository/org/junit/platform/junit-platform-launcher/1.11.0/junit-platform-launcher-1.11.0.jar[+**/*:?**/*]
 /Users/heikoklare/.m2/repository/org/junit/platform/junit-platform-runner/1.11.0/junit-platform-runner-1.11.0.jar[+**/*:?**/*]
 /Users/heikoklare/.m2/repository/org/junit/platform/junit-platform-suite-api/1.11.0/junit-platform-suite-api-1.11.0.jar[+**/*:?**/*]
 /Users/heikoklare/.m2/repository/org/junit/vintage/junit-vintage-engine/5.11.0/junit-vintage-engine-5.11.0.jar[+**/*:?**/*]
 /Users/heikoklare/.m2/repository/org/opentest4j/opentest4j/1.3.0/opentest4j-1.3.0.jar[+**/*:?**/*]
 /Users/heikoklare/.m2/repository/org/apiguardian/apiguardian-api/1.1.2/apiguardian-api-1.1.2.jar[+**/*:?**/*]
 /Users/heikoklare/.m2/repository/p2/osgi/bundle/org.junit/4.13.2.v20230809-1000/org.junit-4.13.2.v20230809-1000.jar[+**/*:?**/*]
 /Users/heikoklare/.m2/repository/org/apache/servicemix/bundles/org.apache.servicemix.bundles.hamcrest/1.3_1/org.apache.servicemix.bundles.hamcrest-1.3_1.jar[+**/*:?**/*]
 /Users/heikoklare/.m2/repository/org/osgi/org.osgi.service.event/1.4.1/org.osgi.service.event-1.4.1.jar[+org/osgi/service/event/annotations/*:?**/*]
 /Users/heikoklare/.m2/repository/org/osgi/org.osgi.annotation.bundle/1.1.1/org.osgi.annotation.bundle-1.1.1.jar[+org/osgi/annotation/bundle/*:?**/*]
 /Users/heikoklare/.m2/repository/org/osgi/org.osgi.service.metatype.annotations/1.4.1/org.osgi.service.metatype.annotations-1.4.1.jar[+org/osgi/service/metatype/annotations/*:?**/*]
 /Users/heikoklare/.m2/repository/org/osgi/org.osgi.service.cm/1.6.1/org.osgi.service.cm-1.6.1.jar[+org/osgi/service/cm/annotations/*:?**/*]
 /Users/heikoklare/.m2/repository/org/osgi/org.osgi.annotation.versioning/1.1.2/org.osgi.annotation.versioning-1.1.2.jar[+org/osgi/annotation/versioning/*:?**/*]
 /Users/heikoklare/.m2/repository/org/eclipse/pde/org.eclipse.pde.api.tools.annotations/1.4.0/org.eclipse.pde.api.tools.annotations-1.4.0.jar[+org/eclipse/pde/api/tools/annotations/*:?**/*]
 /Users/heikoklare/.m2/repository/p2/osgi/bundle/org.eclipse.osgi.services/3.12.100.v20240327-0645/org.eclipse.osgi.services-3.12.100.v20240327-0645.jar[+org/osgi/service/component/annotations/*:?**/*]]

The difference between these two are exactly the other fragments of the host of the fragment currently being built.

@laeubi
Copy link
Contributor Author

laeubi commented Sep 22, 2024

Looking at the output I see that multiple fragments are resolved but actually their platform filter should not match, this has not changed but seem to contribute to the problem here.

@HeikoKlare
Copy link
Contributor

Yes, the change resulted in these additional fragments being resolved (from the m2 repo). The causing change is the change in TargetPlatformFactoryImpl#getPreliminaryReactorProjectUIs() from

project.getDependencyMetadata(DependencyMetadataType.INITIAL);

to

project.getDependencyMetadata(DependencyMetadataType.SEED);

I cannot say anything about the reasons for this change leading to additional fragments on the classpath. I tried to provide a Tycho test case for some time now, but so far I was not able to write a proper regression test.

@laeubi
Copy link
Contributor Author

laeubi commented Sep 23, 2024

I tried to provide a Tycho test case for some time now, but so far I was not able to write a proper regression test.

My guess currently is that they are pulled in by the I-Build repository what contains the fragments of the previous build (as enabled by the -Pbuild-individual-bundles) that would also explain why it is not a problem in the integration builds itself.

@HeikoKlare
Copy link
Contributor

My guess currently is that they are pulled in by the I-Build repository what contains the fragments of the previous build (as enabled by the -Pbuild-individual-bundles) that would also explain why it is not a problem in the integration builds itself.

I can confirm this with my latest experiments: stripping down the SWT builds results in the fragments disappearing from the classpath once I remove the I-Build repo (provided via the build-individual-bundles profile).

I was not able to generate a perfect reproduction, but now I at least one that shows the problem: when you reference a P2 repo in your build that contains a fragment for the host of a fragment currently being built, that other fragment will be put on the classpath such that you (illegally) compile against it. The test case is provided via: eclipse-tycho/tycho#4293

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants