Uses constraint violation while upgrading from tycho 2.2 -> 2.3 #169
Comments
|
This currently prevents one using different versions of the same bundle in the same reactor build. |
|
This currently makes it impossible to use |
laeubi
added
the
🚨 regression
|
This is definitely a consequence of usage of the "good" resolver since 2.3: https://wiki.eclipse.org/Tycho/Release_Notes/2.3#Official_Equinox_Resolver_used_for_dependency_resolution_.28stricter_and_can_produce_errors_for_split_packages.29 |
|
Nope this is defiantly not a good solution and a major degradation from 2.2>2.3. |
Signed-off-by: Christoph Läubrich <[email protected]>
|
So indeed, p2 adds multiple versions as expected, this is the content of the DependencyArtifacts Those results are correct, or at least not incorrect, and are then passed to EquinoxResolver. |
If we are talking about this particular bundle it is wrong to have two different versions (1.9.1 + 1.14.0) of the same dependency on classpath. Why do you think its fine to have both? |
|
Actually, I take that back: p2 result are not satisfactory, and -without surprise- Equinox is correct here (a good approach is to assume is always correct). eclipse-plugin:org.apache.batik.svggen:1.14.0.v20210324-0332 would actually require (via import-package) eclipse-plugin:org.apache.batik.ext.awt:1.14.0 , but p2 gives 1.9.1 without complaining. So I do not see it as a general problem of Tycho being suddenly unable to resolve, but more as a particular issue with batik & Orbit. |
The problem is that 1.14.0 should never be resolved but 1.9.1 is the only choice applicable here for that bundle!
org.apache.batik.ext.awt is not available for 1.14.0 anyways its named org.apache.batik.awt.util there. |
Don't know if the resolver or p2 or both trigger that change, actually it has worked before (or ignored the potentially inconsistency) and from a classpath perspective doesn't matter here. So tycho is being 'over correct' here because it sees an inconsistency on its internal p2 resolved artifacts, but these might never be occur as the runtime configuration might be different! |
OK, and p2 doesn't include svggen 1.9.1 but prefer 1.14 despite incompatibility with the org.apache.batik.ext.awt 1.9.1. So this seems like the root cause, isn't it?
I think it used to be 2 errors, one in p2 sending incorrect input and another in old resolver returning false-positive, that used to balance each other and make this pass. |
|
Hard to guess... As I have used that in a product since a while and in the end simply get both batik versions included but equinox do not complained when actually running the product there might be a solution that is not obvious here. If I take a look at the code at |
But does the product have multiple versions of svggen included (unlike the example here) ? |
|
Running If I rember correctly we have tweaked two features that include explicit versions of bundles so not |
OK, so it seems like you were already facing the issue of p2 not properly resolving batik bundles, and you implemented a workaround for it by adding constraints (narrower version ranges) to p2 resolver to ensure you get the right one. |
|
The problem was/is that tycho only resolves "to latest" when using |
Not Tycho, but p2.
Yes, it definitely is possible to have multiple (complete) versions of batik. The issue here is not that there is too much stuff in p2 resolution, but instead that something is missing to build a good dependency set, in particular org.apache.batik.svggen 1.9.1. <build>
<plugins>
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>target-platform-configuration</artifactId>
<version>2.4.0-SNAPSHOT</version>
<configuration>
<dependency-resolution>
<extraRequirements>
<requirement>
<type>p2-installable-unit</type>
<id>org.apache.batik.svggen</id>
<versionRange>[1.7.0,1.10.0)</versionRange>
</requirement>
</extraRequirements>
</dependency-resolution>
</configuration>
</plugin>
</plugins>
</build>Please report the issue upstream to p2. |
|
I'll try to enhance the example as much as possible (with feature+product) but from a users perspective this is clearly tycho not behave as expected. I'm not sure if I would be able to describe what the actual bug in P2 is here ... and I still think that this is "too much" as from a resolving perspective the versions > 1.9.1 are useless as the bundle itself can't ever use them, so I would expect that P2 ever only install the version that satisfy this bundle or do I get something wrong here? |
|
BTW the problem is not that one could tweak the manifest or features or config but that a working build fails due to (unused) additional items in the target (like with the justj) in this case a newer batik version. |
Signed-off-by: Christoph Läubrich <[email protected]>
Yes, that's the idea. In that case, p2 should choose 1.9.1 only and not include anything 1.14.0. |
|
I'll close this for now as it is not relevant for me anymore and no one else seems to complain. |
I try to upgrade a build from tycho 2.2 -> 2.3 (the same happens for the current SNAPSHOT) but the build fails now with:
While this is something that might be resolved by tweaking the imports and use constraints, tycho seem to resolve / install conflicting bundles here, as in the runtime / product there is no issue with this as there is always only one provider for that package. The bundle itself is from an update-site so not part of the build and works with 2.3...
@mickaelistria any idea what can be the culprit here between 2.2 -> 2.3 ?
The text was updated successfully, but these errors were encountered: