Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

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

m
(new proposal: new section)
Line 54: Line 54:
  
 
--[[User:Charles.zeligsoft.com|Charles.zeligsoft.com]] ([[User talk:Charles.zeligsoft.com|talk]]) 09:35, 5 June 2015 (EDT)
 
--[[User:Charles.zeligsoft.com|Charles.zeligsoft.com]] ([[User talk: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)

Revision as of 08:36, 10 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)

Back to the top