Difference between revisions of "Talk:Papyrus-RT/Developer/Developer Guide/Git Repository"

Revision as of 10:53, 16 June 2015

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)