| Hi, Camille,
Thanks for your reply. It seems, then, that I must have something misconfigured in my target environment, where Xtext is concerned. And I must have misunderstood the Buckminster build configuration. The local.rmap seems to be pulling content from Juno release, but indeed the build.rmap is taking the latest milestones. I thought that because the Xtext compilation errors were on my target that has Xtext 2.4 M4, it must be that the Juno version is required and the local.rmap that is used by the build.
I see in the build.rmap that the build is using Xtext 2.4 M4, so I wonder why I have compilation errors? The Papyrus code is using API that isn't in this version of Xtext. (example below)
Thanks for the information about the compare plug-ins. If they are not being built, does this mean that they are discontinued and I can just remove them from my workspace? Otherwise, is it acceptable that they would not be installable in a Papyrus workbench that has the CDO integration feature installed?
Thanks,
Christian
P.S. Sample of compilation errors on Xtext API:
In the org.eclipse.papyrus.marte.vsl.ui plug-in:
org.eclipse.xtext.ui.refactoring.IDependentElementsCalculator.Null cannot be resolved to a type AbstractVSLUiModule.java /org.eclipse.papyrus.marte.vsl.ui/src-gen/org/eclipse/papyrus/marte/vsl/ui line 43 Java Problem
Hello Christian, Ø As far as I can tell in the Buckminster build configuration, Papyrus is still building against the Juno versions of UML2, EMF, Xtext, and other components. Is this correct? I don’t think so. Our dependencies are updated automatically before each milestone build. So, currently, Papyrus Kepler should build against Eclipse M4 plug-ins (For both the platform and other dependencies). The update sites are read from the simrel build configuration. We’re using the following ones: - UML2: /modeling/mdt/uml2/updates/4.1milestones/ - CDO: None - EMF: /modeling/emf/emf/updates/2.9milestones/ (Will be moved to /modeling/emf/emf/updates/2.9-I-builds/ in a few days, during M5+3 build) - XText: /modeling/tmf/xtext/updates/milestones/head/S201212180716/ So basically, all Kepler M4 builds. The UML2 update site hasn’t changed in the simrel build, so I guess the API change has not been pushed yet. As far as I can tell, the Papyrus build is correct. Ø Currently, Papyrus still uses EMF Compare 1.3. I asked on the bug [3] when/whether it is planned to update to EMF Compare 2.x, but have no response, yet. This is important because CDO already uses EMF Compare 2.1 in Kepler, so currently it is not install-compatible with Papyrus (I can only work because I have all of the sources checked out in my workspace) AFAIK, nothing planed yet. The compare feature of Papyrus is currently disabled in the build, and has never been part of the simultaneous release train (It is an extra component). You should not have installation problems, as long as you’re not trying to install all Papyrus extra components (Which apparently still contain an EMF compare 1.3 dependency… I don’t even know why it does not break the build). Anyway, if you’re trying to install Papyrus M4 (From http://download.eclipse.org/releases/kepler), it should work. Nightly builds should work too, if you only use the main components (http://download.eclipse.org/modeling/mdt/papyrus/updates/nightly/kepler/main) Ø The Xtext 2.3.1 version currently used by Papyrus also is not install-compatible with the Kepler version; as I don't have it checked out from source, I am living with numerous compilation errors in my workspace because I can't have Xtext Kepler and Juno versions both in my target. Are we planning to update to Xtext Kepler, and if so, when? Papyrus Kepler nightly builds still rely on Xtext M4 (And it seems to be working as expected; at least could I install Papyrus and XText correctly). I guess we’ll meet the issue when moving to M5? I can see runtime errors with the M4 version, but everything compiles/installs correctly. Regards,
Camille __________________________ Camille Letavernier CEA LIST - Laboratoire d'Ingénierie dirigée par les modèles pour les Systèmes Embarqués (LISE) Hi, Team, I raised a bug today [1] to report an incompatible API change in the generated UMLEditor class in the MDT UML2 project's imminent Kepler M5 milestone, which breaks compilation of a subclass in Papyrus. This raises the question of keeping Papyrus up-to-date with its dependencies throughout the Kepler development cycle. As far as I can tell in the Buckminster build configuration, Papyrus is still building against the Juno versions of UML2, EMF, Xtext, and other components. Is this correct? For my CDO feature work [2], and on that branch which I hope to create in the next few days, the Kepler versions of CDO (including Dawn) and UML2 will be required, because the feasibility of CDO support depends on enhancements in those components. So, questions: - When are we planning to update Papyrus's build to use the Kepler versions of its dependencies? Would it be feasible to do this for M5?
- Currently, Papyrus still uses EMF Compare 1.3. I asked on the bug [3] when/whether it is planned to update to EMF Compare 2.x, but have no response, yet. This is important because CDO already uses EMF Compare 2.1 in Kepler, so currently it is not install-compatible with Papyrus (I can only work because I have all of the sources checked out in my workspace)
- The Xtext 2.3.1 version currently used by Papyrus also is not install-compatible with the Kepler version; as I don't have it checked out from source, I am living with numerous compilation errors in my workspace because I can't have Xtext Kepler and Juno versions both in my target. Are we planning to update to Xtext Kepler, and if so, when?
_______________________________________________ mdt-papyrus.dev mailing list mdt-papyrus.dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
|
