Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [papyrus-rt-dev] UML-RT Compare in Oomph Setup?
Hi, Philip,

From the development perspective, I’m happy with however these bundles may be packaged and delivered in features, whether optionally installed or not.

It’s only in the development workspace that I have a concern, hence the focus on the Oomph setup model.  I just need to be able to plausibly exclude them from a workspace that imports the other tooling bundles.  And my patch achieves that.  😉  Thanks in advance for the review!  There is absolutely no rush, because it’s working fine for me with the URI redirection to my local git (of course), and will continue to do so even through rebases.

cW

On 12 July, 2016 at 12:52:08, Philip Langer (planger@xxxxxxxxxxxxxxxxx) wrote:

Hi Charles,

thanks for clarifying that!

So I understand that the feature in general is not optional from a project plan point of view, but still could be made available as an optional feature from a installation point of view.

@development team of Papyrus-RT:
What are you thoughts on that, should the diff/merge support be installed by default or just be available to be installed if needed?
I'm open to both, of course. In case, you'd prefer the latter, I just think we need to document the installation process on a Wiki page or in another documentation.

Thanks for your input!

Best wishes,

Philip


On Tue, Jul 12, 2016 at 5:11 PM, charles+zeligsoft.com <charles@xxxxxxxxxxxxx> wrote:
My answer to the question about the product plan can be found inline below


On 2016.07.12, at 03:48 , 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?

The product plan does not deal with components, it deals with features. You can find the definitions of the minimal viable products (MVP) for v0.8 and v0.9 (which will probably be 1.0) on the Releases page of Papyrus-RT wiki.

Basically, the MVP simply state that there must be the ability to compare and merge UML-RT models (split into structure in v0.8 and behavior in v0.9). This would not be an optional feature. How this is accomplished in terms of components and installation is up to the development team (and the architecture committee).
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,

Philip

 

Thanks,

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
_______________________________________________
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

Back to the top