Note that I have also created a wiki page for a “ DSL Developer Guide” (currently empty - just waiting for contributions!).
Could we get some “lessons learned” out of this? I believe that this would be good input for Papyrus-RT-based DSL developers.
Hi everyone, The merge yesterday was a partial implementation of the final fix I wanted to push since several days about the system classes / protocol management. Unfortunately, based on our current builders, it was impossible to merge the initial version where I was removing stuff from the repository (mainly the core.cpp plugins). The previous builds were red for the codegen, as it was recompiling the model library plugin itself. So I did this partial merge while the 2 gerrit builds were green, but with this duplicates for cpp plugin, one in core and another in the new cpp component. The first merge was done yesterday, and I was working on the second part of the patch [1] to remove the cpp plugin from the core component when I had to left the office. However, I could have updated the oomph contribution for the first iteration of the patch, that may have simplified the integration process. Especially since I am using this setup also. I did never touch to the oomph models, but as Christian said, I should be comfortable enough with emf models to be able to modify the content of these files. Should I update the developer wiki to remind these steps (kind of check-list before updating the architecture?). Thanks Christian for your contribution on the setup. For the build process, I still find it quite tough to make some evolutions on the architecture, especially on the core /common components. For example, tooling and cogen builds depends on the same common plugin (rts model library), so this common component should be build (if changed) before triggering the build for codegen and tooling, and codegen & tooling should depend on this new version of the rts binaires when building themselves. If not changed, they could run on the current version. But doing this kind of build architecture may require a complex build infrastructure, I do not see all the impacts on the current jobs and the conditional triggers that may come with it. This may be one of the items at the agenda of today’s meeting (that I unfortunately cannot join, I have another meeting I need to assist). Regards, Rémi ------------------------------------------------------- Rémi SCHNEKENBURGER +33 (0)1 69 08 48 48 CEA Saclay Nano-INNOV Institut CARNOT CEA LIST Sure, not everyone on the team is familiar yet with Oomph, but we are all developers of a complex Eclipse-based modeling tool. We understand models and we understand setting up an Eclipse environment, so any of us is as well equipped as I am to figure out Oomph. Besides, now we’ve built up enough examples in the setup that it should be easy for everyone to maintain! And, of course, I’m always happy to answer questions to help Oomph newcomers. That doesn’t interrupt my work (or yours or anyone’s) as much as running the setup and finding that the workspace has gone haywire. 😀 I would much prefer that everybody become familiar with maintaining the setup by actually doing it themselves when they restructure the repository, instead of delegating the work. That’s better for everyone. And after all, we expect every contribution to build (Gerrit enforces this), so we already have to ensure that the build system is maintained together with the sources, so why not the setup? cW On 30 May, 2016 at 16:05:34, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote: Hi Christian. +1 on people updating the setup model whenever new bundles are added. I think a few of us are using it, and I expect future developers will use it too. It's getting far too complicated to install a developer environment by hand, so the setup model is becoming a necessity. Of course, the issue is that not everyone is familiar with Oomph setup models. In which case, I would propose that, if any committer adds (or deletes) a new bundle and is not familiar with the setup models, then inform me and I'll make the updates. @Remi: do you intend to remove o.e.prt.umlrt.core.cpp? Indeed, this gerrit was not ready to be merged. There are two problems: - the org.eclipse.papyrusrt.umlrt.core.cpp bundle is superseded by the new org.eclipse.papyrusrt.umlrt.cpp bundle, but the former was not deleted from git. The old bundle project has the compilation error; you can just close it to get a clean workspace
- the org.eclipse.papyrusrt.umlrt.core.cpp.tests bundle is still present and is in the “core” component in git, not in the new “cpp” component. It should be renamed as org.eclipse.papyrusrt.umlrt.cpp.tests
Also, I would appreciate it if, when committers add new components to the repository, they could also update the Oomph setup model to add sub-projects for those new components so that (a) when developers run the setup they get all of the right projects in their workspaces presented in a coherent way and (b) I don’t have to follow up everybody’s work to do it. Unless, of course, I’m the only one using the setup model, in which case I’ll just ignore any new components. For now, I have created an update for the setup model: but I won’t merge it until the problems above are fixed, because otherwise people will run the setup, get problems, and blame the setup. On 30 May, 2016 at 15:28:35, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote: Thanks I see the updates to the setup now. As for the missing method, the were added by commit f9a153c99874bde712a93baf3d0c3e00622eccf2, gerrit 73928 which was merged. The RSA Import bundle was merged by Camille today and I updated the setup model to provide a new sub-project with the required dependencies. See the mailing list discussion from earlier today (eastern time). I have no compilation errors in the CppDefaultLanguage class. In my workspace, the IDefaultLanguage interface has no getSystemClasses method. And my git workspace (fetched today) has neither of those first two projects. AFAIK, Rémi’s Gerrit patch hasn’t been merged, yet. I'm getting some errors after recent merges. I noticed three new projects: o.e.prt.umlrt.common.rts.library o.e.prt.umlrt.migration.rsa After importing them most errors go away, except two: 1) The MANIFEST of o.e.prt.umlrt.migration.rsa shows an unresolved dependency on org.eclipse.papyrus.migration.rsa;bundle-version="1.2.0",. I'm guessing this is missing from the target platform? 2) In o.e.prt.umlrt.core.cpp class CppDefaultLanguage gets this: The type CppDefaultLanguage must implement the inherited abstract method IDefaultLanguage.getSystemClasses(ResourceSet) Is this known? @Remi: I'm guessing this is your work? --
_______________________________________________ papyrus-rt-dev mailing list papyrus-rt-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
|
