| Problems satisfying version constraints when materializing [message #1753058] |
Wed, 01 February 2017 13:31  |
|
Hi
I'm experiencing problems when materializing the workspace, the context is the Eclipse project EMF Parsley. Its DSL is implemented in Xtext and in our dsl bundles we have a version range for Xtext dependencies, [2.10.0,2.11.0). Now that Xtext 2.11.0 has been released, I updated the Oomph setup pointing to the new update site of Xtext 2.11.0 and I updated the contraints in our bundles to [2.11.0,2.12.0) (of course in the workspace I have errors since they're not satisfied). When performing the setup tasks, I'd expect that the targlet will consider these new constraints from our sources. However, this is not case, and, as it happened in the past, the problem seems to be that our EMF Parsley bundles are taken as sources from the git repository and as binary bundles from the current Oxygen simrel update site. Since the previous release in the simrel update site had the old constraints, the old constraints are considering for the targlet, while I would have expected that the sources had the precedence... am I doing anything wrong?
thanks in advance
Lorenzo
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
|
| Re: Problems satisfying version constraints when materializing [message #1753118 is a reply to message #1753058] |
Thu, 02 February 2017 03:08  |
 Ed Merks
Messages: 33258
Registered: July 2009 |
Senior Member |
|
|
Yes, I can imagine this is a problem in how we substitute workspace IUs with binary IUs when binary IUs are available. So one approach is to not include an update site that has your binary IUs. I know it's convenient to point at the release train aggregate, but what's there is always a bit behind what's will be contributed to the next version of that repository. So for master branch development, it's generally better to point at the update site provided by each project that contains the builds that will be contributed to the next version of the train. The Repository Explorer is very helpful for finding such update sites: https://wiki.eclipse.org/Eclipse_Oomph_Authoring#How_to_find_a_P2_repository_at_Eclipse_using_the_Repository_Explorer
We do consider any addition requirements in the workspace IU but don't consider whether the binary IU's requirements have different version ranges from the workspace IU, though perhaps we should (and perhaps that would just break something else). We could consider adding another property to targlet (similar to the Include All Requirements or Include All Platforms) to say you don't want this substitution behavior. Some projects really want this binary substitution behavior and some projects pretty much need this behavior. E.g., Papyrus and Xtext wanted this behavior because they want to be able to close projects and still have the binary equivalents available in the target platform. For many of the platform projects it's even more essential, because they often want the full Eclipse SDK in their target platform, with only parts of what's in the SDK in their workspace; this gets very tricky to resolve, because feature dependencies typically lock in a very specific version of each the include bundles, one that would exclude the workspace version of that bundle if the version number has been incremented in the master branch. So in that case we need to resolve in a way that allows p2 to resolve fully. In the end, p2 is much less forgiving than is PDE, which allows workspace bundles with a different version to replace the bundle required by some feature. It's all very tricky to make all these technologies happy...
In any case, pointing at more specific update sites, i.e., ones that include all your master dependencies but don't include your own binaries would avoid the problem. It's probably best that we provide an additional property to be able to disable binary substitution during resolution because I'm quite sure that considering only workspace IU requirements in general will not allow platform projects to resolve against a binary SDK unless we dramatically change the preprocessing steps to massage all the binary requirements to favor workspace versions. Please open a Bugzilla and we'll revisit this issue when I'm back from my travel.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
| Re: Problems satisfying version constraints when materializing [message #1753168 is a reply to message #1753160] |
Thu, 02 February 2017 11:26 |
Ed Merks
Messages: 33258
Registered: July 2009 |
Senior Member |
|
|
Yes, a list of update sites is hard to maintain...
You can use variables, but you also have to use org.eclipse.oomph.setup.AnnotationConstants.ANNOTATION_FEATURE_SUBSTITUTION annotations for features where the syntax of the representation doesn't allow a variable to be expressed. They're processed by org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.handleFeatureSubstitutions(Collection<? extends EObject>) where the annotation details can specify the key as the name of the feature being substituted and the value is the string representation of the substitution. So it will be evaluated and then can converted to a VersionRange instance, in this case.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.03267 seconds
] 
Search
Help
Register
Login
Home
