Issue #77 - Externalize the target platform into definition file #78
Conversation
abstratt
commented
Jul 25, 2019
abstratt
commented
- Externalized target platform using a target definition file for easier dev set-up - see https://wiki.eclipse.org/PDE/Target_Definitions
- Externalized target platform using a target definition file for easier dev set-up - see https://wiki.eclipse.org/PDE/Target_Definitions
| org.eclipse.papyrus.moka.fuml, | ||
| org.eclipse.papyrus.moka.fuml.interfaces;bundle-version="2.0.0", | ||
| org.eclipse.papyrus.moka.fuml.standardlibrary;bundle-version="2.0.0", | ||
| org.eclipse.papyrus.moka.fuml.standardlibrary;bundle-version="2.0.100", |
There was a problem hiding this comment.
This was necessary as there was an API feature added after 2.0.0 that we rely on (Div_ class).
seidewitz
left a comment
seidewitz
left a comment
There was a problem hiding this comment.
This would need to be merged into the maintenance branch, not the development branch. It could be considered for inclusion in the 1.1.0g release.
|
Thanks @seidewitz, that was something I was unsure about. Done. |
seidewitz
left a comment
seidewitz
left a comment
There was a problem hiding this comment.
It is really time to move this project of Eclipse Oxygen (4.7). If we are going to be creating a target platform, we should move to Eclipse 2019-06 (4.12) and set up the platform for that. (But we need to stay on Java 8 for now.)
|
@seidewitz I tried to infer the versions of upstream projects based on the minimum bundle versions you had specified. Is this giving you different results than the approach you used so far (resulting in unexpected - too old or to new - versions of dependencies)? Updating this to a more recent set of dependencies makes sense. Maybe we could that later as a separate task, assuming the dependencies proposed here are not incorrect? |
|
Actually, you did pretty much get the versions right, and I am, in fact, still using Oxygen for RI development. You can probably also add http://eclipse-javacc.sourceforge.net (SF JavaCC Eclipse plugin feature 1.5.33) to the platform. I originally stayed on Oxygen/4.7 (and, in fact, until recently, was still testing on 4.6, too) for compatibility with a user that is no longer relevant. I have been thinking for a while that it is finally time to move on to the current Eclipse version, but haven't had a chance to do so. However, doing that as a separate task probably makes sense -- it is lower priority than making progress on Issue #75. |
|
@seidewitz The target platform needs to contain the bare minimum bundles that the project's own bundles are compiled against. it does not affect the functionality available to the IDE during development time. For instance, we can still use an old version of Eclipse as the target platform (because the Alf RI does not require a newer version) and use the latest Eclipse as our development environment. Re: the JavaCC plug-in for Eclipse - since JavaCC itself or the JavaCC Eclipse plug-in are not used for compiling the code, at this time it seems it is not needed in the target platform. Do you see a reason for us to include it? Re: versions - the target platform should reflect our minimum requirements, so making it rely on recent versions of Eclipse, Eclipse UML2 or Papyrus mean dropping compatibility for earlier versions, even if as recent as last year's. No problem with that, if that is really what you are looking for. At least for the Eclipse Platform, I would try to have the oldest possible version the Alf RI can work on as a prerequisite. |
|
Not sure if including the Javacc plugin in the platform might be necessary if we better automate the build process in the future. But that's not important for now. |
