Community
Participate
Working Groups
Several builds started failing with compile and test errors since Tycho is not resolving the highest available version of o.e.mylyn.tasks.ui but an older 3.6.x release which is missing recently added API. [INFO] o.h.m.e.h.MavenExecutionResultHandler - Build failed with exception(s) [INFO] o.h.m.e.h.MavenExecutionResultHandler - [1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.eclipse.tycho:tycho-compiler-plugin:0.14.0-SNAPSHOT:compile (default-compile) on project org.eclipse.mylyn.context.tasks.ui: Compilation failure [DEBUG] Closing connection to remote [ERROR] Failed to execute goal org.eclipse.tycho:tycho-compiler-plugin:0.14.0-SNAPSHOT:compile (default-compile) on project org.eclipse.mylyn.context.tasks.ui: Compilation failure: Compilation failure: [ERROR] /home/hudson/.hudson/jobs/mylyn-context-trigger/workspace/org.eclipse.mylyn.context.tasks.ui/src/org/eclipse/mylyn/internal/context/tasks/ui/editors/ContextEditorFormPage.java (at line 37):[-1,-1] [ERROR] import org.eclipse.mylyn.internal.tasks.ui.context.AttachContextHandler;
I have updated the version constraints in o.e.m.context.tasks.ui and o.e.m.wikitext.tests to require o.e.m.tasks.ui 3.7.0 or later. I'll keep this open as a reminder to investigate further what is causing this unexpected behavior in the resolver.
Created attachment 211231 [details] sample project
It seems that Tycho uses the lowest version of available bundles to satisfy a dependency when using an implicit target. I had always assumed that Tycho would use the highest available version. Is that assumption wrong? If I use this or leave out the bundle-version in the attached sample project's manifest "mvn clean package" fails: Require-Bundle: org.eclipse.mylyn.commons.core;bundle-version="[3.0.0,4.0.0)" It works if I use this which forces the latest version of the org.eclipse.mylyn.commons.core bundle to be resolved: Require-Bundle: org.eclipse.mylyn.commons.core;bundle-version="3.7.0" Is that the expected behavior?
(In reply to comment #3) > It seems that Tycho uses the lowest version of available bundles to satisfy a > dependency when using an implicit target. I had always assumed that Tycho would > use the highest available version. Is that assumption wrong? > > If I use this or leave out the bundle-version in the attached sample project's > manifest "mvn clean package" fails: > > Require-Bundle: org.eclipse.mylyn.commons.core;bundle-version="[3.0.0,4.0.0)" > > It works if I use this which forces the latest version of the > org.eclipse.mylyn.commons.core bundle to be resolved: > > Require-Bundle: org.eclipse.mylyn.commons.core;bundle-version="3.7.0" > > Is that the expected behavior? You leave it up to the p2 resolver to choose a solution within the given constraints. AFAIK the resolver algorithm does not have a strict preference on latest version if multiple versions satisfy the constraints.
(In reply to comment #4) > (In reply to comment #3) > You leave it up to the p2 resolver to choose a solution within the given > constraints. AFAIK the resolver algorithm does not have a strict preference on > latest version if multiple versions satisfy the constraints. scratch that.
I am getting exactly the same (but different from the one in comment #0) compile error building the attached sample project with Tycho 0.13.0, 0.14.0 and 0.15.0-SNAPSHOT, so this does not look like a recent regression ---------- 1. ERROR in /private/tmp/org.eclipse.mylyn.example.tycho/src/UseMylyn37Api.java (at line 6) System.err.println(CoreUtil.getFrameworkVersion()); ^^^^^^^^^^^^^^^^^^^ The method getFrameworkVersion() is undefined for the type CoreUtil ---------- 1 problem (1 error) I also agree with Jan's comment #3 -- afaik, p2 optimization function prefers newer versions but does not guarantee the latest available version of all dependencies will be used even if the result satisfies all constraints. I don't know enough about mylyn code to suggest a specific solution, but I think there are generally two possibilities here If your project actually requires certain minimal version of Eclipse dependencies, say 3.7.0, the best solution is to specify that version in the bundle manifest. This will make the project compile against proper dependencies but, more importantly, will prevent nasty runtime errors if somebody tries to install the bundle on unsupported version of Eclipse. If your project has optional dependency on Eclipse 3.7.0 but is still expected to work with earlier Eclipse versions, then you can use dependency resolver <dependency-resolution> configuration to force newer build-time version, i.e. something like this: <plugin> <groupId>org.eclipse.tycho</groupId> <artifactId>target-platform-configuration</artifactId> <version>${tycho-version}</version> <configuration> <dependency-resolution> <extraRequirements> <requirement> <type>eclipse-plugin</type> <id>org.eclipse.core.runtime</id> <versionRange>3.7</versionRange> </requirement> </extraRequirements> </dependency-resolution> </configuration> </plugin>
(In reply to comment #6) > If your project actually requires certain minimal version of Eclipse > dependencies, say 3.7.0, the best solution is to specify that version in the > bundle manifest. This will make the project compile against proper dependencies > but, more importantly, will prevent nasty runtime errors if somebody tries to > install the bundle on unsupported version of Eclipse. That is true, but it's very onerous to manage dependencies on a bundle level without tooling support. With a few hundred bundles this means managing thousands of version constraints manually. Every time I wanted to consume an upstream change I would need to update the version constraints to require the latest upstream snapshot build. At least for the interdependencies between Mylyn bundles this would mean quite frequent updates to the version constraints. So far we have mostly managed constraints on a feature basis which is still considerable effort but we have a magnitude fewer features than bundles. I'll take another look at our build and check if we can scope the repositories better when using implicit targets so Tycho doesn't "see" older versions of dependencies. From my point of view it would seems useful to have a more predictable behavior (e.g. the resolver prefers the most recent version) but feel free to close this bug if it works as intended. > If your project has optional dependency on Eclipse 3.7.0 but is still expected > to work with earlier Eclipse versions, then you can use dependency resolver > <dependency-resolution> configuration to force newer build-time version, i.e. > something like this: [...] Thanks for pointing this out. I wasn't aware of that configuration option. I am not sure if/how it would ease dependency management but it's good to know that I could add additional build-time dependencies that way.
(In reply to comment #6) > I also agree with Jan's comment #3 -- afaik, p2 optimization function prefers > newer versions but does not guarantee the latest available version of all > dependencies will be used even if the result satisfies all constraints. p2 optimizes for both higher versions and fewer bundles. The later versions of your dependencies seem to pull in more bundles, and therefore the older version is preferred. Probably, p2's optimization function is biased towards fewer bundles, but this would need to be discussed with the sat4j expert Daniel LeBerre. (In reply to comment #7) > That is true, but it's very onerous to manage dependencies on a bundle level > without tooling support. With a few hundred bundles this means managing > thousands of version constraints manually. Every time I wanted to consume an > upstream change I would need to update the version constraints to require the > latest upstream snapshot build. At least for the interdependencies between Mylyn > bundles this would mean quite frequent updates to the version constraints. I think this is a valid point: the tooling needs to be improved to make this feasible. I opened a new enhancement for this: bug 392410. I also think that we need specific support for intra-project dependencies, e.g. an automatic update of the lower bound of the version constraint (idea 3 in bug 392410). > From my point of view it would seems useful to have a more predictable behavior > (e.g. the resolver prefers the most recent version) but feel free to close this > bug if it works as intended. We can leave this open as enhancement. Maybe a warning (with the explanation above and instructions to fix the problem) would also be sufficient for a start?
(In reply to comment #8) > > From my point of view it would seems useful to have a more predictable behavior > > (e.g. the resolver prefers the most recent version) but feel free to close this > > bug if it works as intended. > We can leave this open as enhancement. Maybe a warning (with the explanation > above and instructions to fix the problem) would also be sufficient for a > start? A warning would be definitely a good starting point, at least this would help users unaware of the default behaviour to trace down the source of problem. If not possible to fix it by always insuring the highest version, some instructions on how to fix it manually in the project would be also helpful.
After stumbling across this problem again, I debugged p2 resolution process and found out that higher versions will not be preferred anymore as soon as its corresponding solution size (in terms of all required IUs) is two or more IUs larger than that of the older version. Interestingly, with only one IU difference the solution with a higher version is always chosen as a result. For demonstration, see attached minimal example with only few modules. There is already a bugzilla open for this issue in p2 (bug 352560), that references another bugzilla for Tycho (bug 352081). It hope it would be feasible to make this p2 optimization behaviour optional and controllable from the client, so that Tycho would disable it for more predictable resolution behavior in the build. In my scenario I run into this problem mainly because the target platform for a project may contain latest milestone builds and current snapshot builds of some dependency simultaneously. If the version from the current snapshot build brings in new dependencies, it may happen that the version from the older milestone build is resolved instead. Controlling this with a minimal version constraint is not possible as the base version remains the same.
Created attachment 226590 [details] Minimal example with wrong version resolution
Is this bug going to be resolved any time soon? Or can someone tell me what is the workaround for this issue?
(In reply to Miki Jankov from comment #12) > Is this bug going to be resolved any time soon? Or can someone tell me what > is the workaround for this issue? If this depends on changing p2's behavior, I doubt it would be fixed soon (but, I am not really the one to say ... just my impression). And I am not sure of your specific setup or problem, but sometimes the issue can be "worked around" by using more specific URL pointing to specific repositories that only have one version available. (I actually think of this as a best practice, not a workaround :) but I am not sure that is relevant to the issue you are seeing.
this depends on p2 bug 352560 (see "depends on" section above)
As the referenced bug is closed and we have upated P2 in the meantime, is this still an issue?
Closed/wontfix as echo of bug 352560
