Harden bundle constraints between Xtext bundles #2892
Conversation
Since we don't do any semantic versioning in Xtext, it's safest to assume that all bundles require always the lastest version of their peers. Signed-off-by: Sebastian Zarnekow <sebastian.zarnekow@gmail.com>
This should allow clients to use import-package instead of require-bundle for their Xtext dependencies
Signed-off-by: Sebastian Zarnekow <sebastian.zarnekow@gmail.com>
Signed-off-by: Sebastian Zarnekow <sebastian.zarnekow@gmail.com>
Signed-off-by: Sebastian Zarnekow <sebastian.zarnekow@gmail.com>
There was a problem hiding this comment.
Sorry for being late ;)
I think the updates to the xtext.logging version are wrong: that is a fragment that has to match the version of the log4j bundle. At least, that's what @cdietrich told me during the porting to the monorepo.
Moreover, I don't remember the rationale for this explicit versioning. You told me something about future Xtext OSGI enhancements; it's related to that, isn't it?
| @@ -79,7 +79,7 @@ | |||
| <requirement> | |||
| <type>eclipse-plugin</type> | |||
| <id>org.eclipse.xtext.logging</id> | |||
| <versionRange>1.2.24</versionRange> | |||
| <versionRange>${xtextVersion}</versionRange> | |||
There was a problem hiding this comment.
see my comment above about the xtext.logging version
No worries. The rationale is that Xtext bundles strictly depend on each other and therefore the OSGI metadata should reflect that. So far we didn't provide this information as part of the Manifest which could have led to wirings in an OSGI container that are not working. Exporting packages with proper versions will help users who try to be good OSGI citizens and use import-package rather than require-bundle. |
|
This is also new to me |
You mean the versioning of fragments? |
|
yes we always had the host bundle version there. and i dont know why |
I think back then we didn't know better. |
Also: