This repository was archived by the owner on Apr 21, 2023. It is now read-only.
Lb task 1686 simplify domainmodel #1687
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,42 +1,29 @@ | ||
| <?xml version="1.0" encoding="UTF-8" standalone="no"?> | ||
| <?pde?> | ||
| <target name="domainmodel" sequenceNumber="1"> | ||
| <locations> | ||
| <location includeAllPlatforms="false" includeConfigurePhase="false" includeMode="planner" includeSource="true" type="InstallableUnit"> | ||
| <unit id="org.eclipse.jdt.feature.group" version="0.0.0"/> | ||
| <unit id="org.eclipse.platform.feature.group" version="0.0.0"/> | ||
| <unit id="org.eclipse.pde.feature.group" version="0.0.0"/> | ||
| <unit id="org.eclipse.emf.sdk.feature.group" version="0.0.0"/> | ||
| <unit id="org.apache.commons.jxpath" version="0.0.0"/> | ||
| <repository location="https://download.eclipse.org/releases/2023-03"/> | ||
| </location> | ||
| <location includeAllPlatforms="false" includeConfigurePhase="false" includeMode="planner" includeSource="true" type="InstallableUnit"> | ||
| <unit id="org.eclipse.emf.mwe2.launcher.feature.group" version="0.0.0"/> | ||
| <repository location="https://download.eclipse.org/modeling/emft/mwe/updates/releases/2.14.0/"/> | ||
| </location> | ||
| <location includeAllPlatforms="false" includeConfigurePhase="false" includeMode="planner" includeSource="true" type="InstallableUnit"> | ||
| <unit id="org.eclipse.xtext.sdk.feature.group" version="0.0.0"/> | ||
| <repository location="https://download.eclipse.org/modeling/tmf/xtext/updates/nightly"/> | ||
| </location> | ||
| <location includeAllPlatforms="false" includeConfigurePhase="false" includeMode="planner" includeSource="true" type="InstallableUnit"> | ||
| <!-- | ||
| Just mention the p2 repo so that additional requirements with ranges specified in | ||
| features and bundles are taken from Orbit (e.g., objectweb.asm) | ||
|
Contributor
There was a problem hiding this comment. Do we want to stick to using the orbit update site?
Contributor
Author
There was a problem hiding this comment. I guess it depends here: if we update to the next Eclipse version and the Orbit contents of the next Eclipse version are fine, then we should be safe. |
||
| --> | ||
| <repository location="https://download.eclipse.org/tools/orbit/downloads/2023-03"/> | ||
| </location> | ||
| </locations> | ||
| </target> | ||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
an not sure (have no idea) how properly maintained our manifests are
and what would be fixed if we have
version x in manifest (no range)
and orbit has x and x+1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if so should we also change the wizard?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cdietrich what do you mean by "change the wizard"? Do you mean the one that generates a new Xtext project? That was my next proposal ;)
If you have version x without no upper limit then it means that when the bundle will be installed it will use any latest version, so having a fixed version in the TP would probably be even worse, because you built it with a known version but it will be installed with a probably more up to date version.
Indeed, for objectweb.asm we have very strict version ranges in the MANIFEST, IIRC.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://github.com/eclipse/xtext-core/blob/857b6e2efbc350a7cda1b0ff22a72c300d1d9dd5/org.eclipse.xtext.xtext.wizard/src/org/eclipse/xtext/xtext/wizard/TargetPlatformProject.xtend
unfortunately i really have no idea on target platforms and thus cannot judge if this is a good idea
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you use "0.0.0" in the TP then the latest version will be used that respects the version ranges in features and bundles.
In any case, that's only for compiling. As I said above, if a feature or bundle is known NOT to work with a specific newer version, then a version range must be set explicitly in the feature or bundle: having a fixed version in the TP will only make sure you compile the code with that fixed version, but then users will still be able to install your feature or bundle with a newer (not working version) if you haven't specified the range correctly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i really would like a second or 3rd opinion here @kthoms @miklossy @ArneDeutsch
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No problem, let's wait :)
For sure, "slicer" should be avoided, but for the other parts let's see
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like there won't be a second opinion coming soonish.
I can see why this makes sense for an example project but for "production" mode I'd rather pin the dependencies. Which raises the question if we want the examples to be different from what I personally would consider reliable practise for production environments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As you prefer. For sure, pinning dependency versions help make builds reproducible.
In any case, "slicer" makes no sense ;)