| Re: [papyrus-rt-dev] UML-RT Compare in Oomph Setup? |
Hi, Philip,What you forgot to test was my local workspace in which I work on the setup model and so have its URI redirected into my local checkout of the website git. 😉 In other words, it was entirely my fault for not having pulled the website repo lately. Sorry about that.I’ve proposed a change https://git.eclipse.org/r/#/c/77132/ that splits out a separate compare sub-project for Oomph setup purposes without changing the git layout nor feature structure. What do you think? I’ll be content either way.
BTW, what do you mean by the “new tool configuration that was introduced a few months ago”? Is there something else that I need to catch up on?Again, sorry for my mistake.ChristianOn 12 July, 2016 at 03:49:05, Philip Langer (planger@xxxxxxxxxxxxxxxxx) wrote:
Hi Christian,_______________________________________________On Mon, Jul 11, 2016 at 10:16 PM, Christian Damus <give.a.damus@xxxxxxxxx> wrote:Hi, Team,I noticed today that there are some new compare-related bundles in the Papyrus-RT git repo, in the plugins/umlrt/tooling tree. These are imported into the workspace by the existing Tooling sub-project of the Papyrus-RT Oomph setup model, but the setup does not provide any targlet content to support these bundles (obviously we now require EMF Compare, at least). So, lots of red Xes.This is surprising, because I added the necessary dependencies to the modular target definition in the Oomph Setup files with this commit: https://git.eclipse.org/r/#/c/75408/I only tested it with creating a new workspace though and not with updating an existing one. Is there anything specific to consider to also support upgrading existing workspaces?It would be nice to have a compare-specific sub-project in the setup. Could somebody please add that? And make sure that the Tooling sub-project excludes these bundles from the workspace import? (which could be assisted by the next item ...)I can take care of that. Currently I assumed they should be part of the tooling.Do we want these to be in the tooling tree or would it make more sense to give them their own tree in git, especially considering that
- the EMF Compare feature is an optional installation
I'm not sure if the EMF Compare feature should eventually be a "non-optional" part of the product or if it is intended to be optional.Charles, what does your product planning say about that?Currently, I added it as a non-optional part.
- we have (so far) mostly disjoint committer groups working on the compare bundles, the tooling bundles, and the codegen bundles (not to say that we shouldn’t all contribute to any and all of these areas, which we already do from time to time, as a team naturally does)
I'm ok with whatever is best for all and I'm happy to add it as an own sub-project to the Oomph setup.I'm also ok with moving it to an own sub-directory in the git tree.Also, a large number of source files in the compare bundles had EOL line errors in git; I had to fix those in commit bbcd582 to avoid being blocked in the creation of new commits.Sorry about that! I thought I caught all of them after migrating the contributions to the new tool configuration that has been introduced a few months ago.Thanks and best wishes,PhilipThanks,Christian
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
--
Dr. Philip Langer
Senior Software Architect / General Manager
EclipseSource Services GmbH
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev