Talk:Papyrus-RT/Developer/Developer Guide/Git Repository

Following up the discussion on the location of "runtime(s)", do we really want to have it in the plugins folder? I think that would be misleading, as the rts is not a plugin. --Eposse.gmail.com (talk) 13:47, 19 May 2015 (EDT)

• OK, I misunderstood one of your email. In this case, they could be aside the plugins/ structure, and become a root folder as plugins/ or features/

• Maybe, maybe not. Charles says they should be at the same level, like you describe. Maybe that's desirable, I don't know if that really matters, but it seems misleading to put it inside plugins, specially if we want to make it easier for developers to find.

Also, in your last e-mail you mentioned that perhaps the code generators and runtime should not be distributed as plugins, but as Eclipse bundles. I'm not sure I follow. I don't think I understand the difference. Is it simpler to distribute them as bundles? Why would it be preferable? (I'm not opposed, I'm just trying to understand).

Anyway, if we make these bundles, maybe we need a separate top-level 'bundles' folder:

documentation/ plugins/ .core/ .tooling/ .examples/ bundles/ .codegen/ .runtimes/ features/ releng/ tests/

I don't know if that makes sense. Is that the idea?

--Eposse.gmail.com (talk) 14:06, 19 May 2015 (EDT)

---

Because Papyrus-rt is meant to be able to host different "real time" approached, there is the need to package elements based on these "languages". For example, we would need:

 <some base folder>
   +- core
   +- tooling
   +- common
   +- umlrt
       +- codegen
           +- src
           +- tests
       +- rts
           +- src
           +- tests
       + examples
   +- xtumlrt
       +- codegen
           +- src
           +- tests
       +- rts
           +- src
           +- tests
       + examples

Perhaps the best way to approach this would be to have different repositories, so that modeling language-specific development teams only clone what they need?

--Charles.zeligsoft.com (talk) 09:35, 5 June 2015 (EDT)

new proposal

I would in this case propose following structure:

Git

• documentation/
  • wikitext/ - location of the source for the generated documentation plugins, embedded in the tool or generated as pdf or as html pages
• plugins/
  • core/ (contains profile, UML specific implementation & semantic element types for edition). This set of plugins should be usable by headless applications (no UI)
  • tooling/ (contains graphical customizations, as Property views, Model explorer customization, diagrams).
  • xtumlrt/
    • codegen/ (contains the tests for the code generator for xtuml)
    • runtime/ (contains the tests for the runtime based on xtuml)
  • other language
    • codegen/
    • runtime/
  • examples/ (contains the sample models used to demo Papyrus-RT, accessible as examples in Papyrus-RT==> File > New... > Examples > etc.)
• features/ (contains all features, which are used for deployment)
• releng/ (contains mainly the release engineering artifacts, as maven pom)
• tests/
  • junit/
    • core/ (contains the tests for the core part: tests on UML specific API, profile implementation, validation rules validation)
    • tooling/ (contains the tests for the tooling part)
    • xtumlrt/
      • codegen/ (contains the tests for the code generator for xtuml)
      • runtime/ (contains the tests for the runtime based on xtuml)
    • other language
      • codegen/
      • runtime/
  • rcptt/ (contains functional tests written using rcptt)

Variation: languages

I'm OK with the structure but I have a comment regarding the languages: our code generator and runtime are (for now at least) for UML-RT, and xtumlrt just happens to be the intermediate representation, which could also be used by a future XtUML code-generator/runtime. Calling the folder for our code-generator/runtime 'xtumlrt' might be a bit confusing.

So I propose a refinement:

• plugins/
  • core/ (contains profile, UML specific implementation & semantic element types for edition). This set of plugins should be usable by headless applications (no UI)
  • xtumlrt/
    • codegen/ (contains the code generator for xtumlrt)
  • umlrt/
    • codegen/ (contains the code generator for umlrt; uses the plugins under xtumlrt)
    • runtime/ (contains the runtime based on umlrt)
  • xtuml/
    • codegen/ (contains the code generator for xtuml; uses the plugins under xtumlrt)
    • runtime/ (contains the runtime based on xtuml)

Note that xtumlrt does not contain a runtime, as the runtime is for more concrete languages (UML-RT, XtUML).

Alternatively the 'xtumlrt' folder could be called 'common'.

And there is another question: should we put the meta-models in their own folder? e.g.

• plugins/
  • core/ (contains profile, UML specific implementation & semantic element types for edition). This set of plugins should be usable by headless applications (no UI)
  • xtumlrt/
    • metamodel/
    • codegen/ (contains the code generator for xtumlrt)

...etc.

This separation makes sense to me. Besides, Akos would actually like the xtumlrt.common meta-model to be hosted in its own git repo. --Eposse.gmail.com (talk) 10:23, 10 June 2015 (EDT)

RS: I would propose then an update based on those variants:

• plugins/
  • umlrt/
    • profile/ (contains the umlrt profile)
    • core/ (contains UML specific implementation & semantic element types for edition of UML-RT models). This set of plugins should be usable by headless applications (no UI)
    • tooling/ (contains the tooling to edit uml-rt models , basically the custom of Papyrus for UML-RT)
    • codegen/ (contains the code generator for umlrt; uses the plugins under xtumlrt)
    • runtime/ (contains the runtime based on umlrt)
  • xtuml/
    • codegen/ (contains the code generator for xtuml; uses the plugins under xtumlrt)
    • runtime/ (contains the runtime based on xtuml)
  • xtumlrt/ (or common/)
    • metamodel/
    • codegen/ (contains the code generator for xtumlrt)

This separation makes sense to me. Besides, Akos would actually like the xtumlrt.common meta-model to be hosted in its own git repo. I am not very keen on that yet, if this is a common asset we have to reuse for the various languages supports. It is already hard to setup the build and git layout. Later on, we could imagine to have a repo for each language, but we need to ensure that everyone is in sync during simultaneous releases.

Can you setup a structural overview of what should be the resulting code generators/runtimes structure? I feel a bit confused about all those contributions (xtuml/umlrt/xtumlrt)

--remi.schnekenburger@cea.fr (talk) 16:53, 16 June 2015 (EDT)

The general idea is that 'xtumlrt' is (at least currently) the intermediate representation for the code generator. The code generation goes like this:

UML2 model ---> xtumlrt model ---> C++ model ---> C++ text

However, even though xtumlrt is an intermediate representation, it is intended to be usable by other tools/code generators, not only for UML-RT. We introduced it as a collaboration between Zeligsoft, Ericsson Budapest and IncQuery, precisely with that goal of having some tool-independent meta-model which was not as complex as UML. We also introduced it in part because we had a custom-build intermediate representation but a couple of months ago, I think Ansgar or Sebastien or you had mentioned that it would be preferable to either use UML directly or an EMF-based representation. Simon felt the UML representation was too heavy, so we went for the EMF-based representation.

So the 'xtumlrt' meta-model consists of several sub-projects:

1. xtumlrt.common: the elements which are in common between UML-RT and xtUML (includes things like NamedElements, RedefinableElements, TypedElements, Classes (called Entities) Capsules, Ports, Protocols, State Machines)

2. xtumlrt.umlrt: contains UML-RT-specific elements (e.g. RTPort, RTTrigger)

3. xtumlrt.xtuml: contains xtUML-specific elements (e.g. XTComponent)

We have others which are more specific to code-generation of C++.

So your latest update to the structure looks fine to me, the only caveat is the location of the metamodels 1, 2 and 3 above. They could go under their respective codegen folder, or under a metamodel folder, like this:

• plugins/
  • umlrt/
    • profile/ (contains the umlrt profile)
    • core/ (contains UML specific implementation & semantic element types for edition of UML-RT models). This set of plugins should be usable by headless applications (no UI)
    • tooling/ (contains the tooling to edit uml-rt models , basically the custom of Papyrus for UML-RT)
    • metamodel/ (contains xtumlrt.umlrt; refers to xtumlrt.common)
    • codegen/ (contains the code generator for umlrt; uses the plugins under xtumlrt)
    • runtime/ (contains the runtime based on umlrt)
  • xtuml/
    • metamodel/ (contains xtumlrt.xtuml; refers to xtumlrt.common)
    • codegen/ (contains the code generator for xtuml; uses the plugins under xtumlrt)
    • runtime/ (contains the runtime based on xtuml)
  • xtumlrt/ (or common/)
    • metamodel/ (contains xtumlrt.common)
    • codegen/ (contains the code generator for xtumlrt)

How does this sound?

I don't include a runtime/ under xtumlrt/ because, at least for now, there is no such runtime. The runtimes are for concrete languages, and xtumlrt represents an abstracted common. There might be in the future, but not yet.

My comment about Akos wanting the xtumlrt stuff in a separate git repo is because he wants to be able to do tools that do not depend on the whole of PapyrusRT. Under that proposal, the folders xtumlrt/ and xtuml/ would be in a different git repo, and we can include them here as git submodules (which is what we did when we hosted the code in the Zeligsoft server).

I hope it's clearer now.

--Eposse.gmail.com (talk) 12:50, 16 June 2015 (EDT)

That seems clear, thanks for explanation! I have the feeling that xtumlrt should really be named common in this case.

For the submodules, I know that we avoided them in Papyrus in the past, because of their support in EGit were not goof. But EGit support is probably better now. I have nothing against testing it. I hope everything will be smooth for the releases, being in different repos requires some more work (need to tag all the repos at the same time for example)

--remi.schnekenburger@cea.fr (talk) 19:00, 16 June 2015 (EDT)