-
Notifications
You must be signed in to change notification settings - Fork 75
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
Update to Tycho 4.0.9 #2360
Conversation
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
@laeubi do you know about any change in Tycho that might have produced this regression? |
Just found that with the new Tycho version, the classpath for the
vs
|
Its hard to tell without a testcase and given all test for Tycho complete without a problem I would suggest to at best
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. |
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.
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". |
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...
This use-case is official supported and the corresponding tests seem to pass (but sadly not covering the special situation of SWT). |
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'll try to investigate it tomorrow (of course help is always welcome). |
Good catch, thank you! 🥇 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:
And this is without it:
The difference between these two are exactly the other fragments of the host of the fragment currently being built. |
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. |
Yes, the change resulted in these additional fragments being resolved (from the m2 repo). The causing change is the change in 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. |
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 |
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 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 |
No description provided.