| Re: [mdt-papyrus.dev] Keeping Up with Kepler |
|
Hello Christian and Kenn, Ø
I would recommend that Papyrus be built against current (e.g., integration) builds of its dependencies well in advance of each milestone to catch potential problems like this, especially until API freeze (M6). It is difficult to follow all dependencies’ Integration builds. Moreover, this would make the Papyrus builds unusable on the current Eclipse milestone.
As we really have a lot of dependencies, it seems like a lot of extra work. I’m not sure it’s worth it. Ø
The local.rmap seems to be pulling content from Juno release, but indeed the build.rmap is taking the latest milestones. Indeed, the local.rmap is absolutely not up-to-date. We don’t use it anymore (Last updated on 2012/03/20, somewhere around Juno M5). Hudson relies
on the build.rmap, which is updated before each milestone (between +1 and +3). Ø
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 This plug-in is not part of the build and hasn’t been maintained for a few months, I guess, as well as all marte.*xtext.ui plug-ins. I’ll see if
I can re-generate them easily to fix this issue. Until then, you can simply ignore (and close) these plug-ins. Regards, __________________________ Camille Letavernier +33 (0)1 69 08 00 59 -
camille.letavernier@xxxxxx CEA LIST - Laboratoire d'Ingénierie dirigée par les modèles pour les Systèmes Embarqués (LISE) Papyrus :
http://www.eclipse.org/papyrus De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx]
De la part de Christian W. Damus 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 On 2013-01-29, at 10:54 AM, LETAVERNIER Camille <Camille.LETAVERNIER@xxxxxx> wrote:
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 Letavernier +33 (0)1 69 08 00 59 - camille.letavernier@xxxxxx CEA LIST - Laboratoire d'Ingénierie dirigée par les modèles pour les Systèmes Embarqués (LISE) Papyrus : http://www.eclipse.org/papyrus De : mdt-papyrus.dev-bounces@xxxxxxxxxxx
[mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Christian W. Damus 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:
Thanks, Christian _______________________________________________ |