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,

Oomph doesn’t use the *.target files to provision the PDE Target; it builds its modular target independently of any of that.

We had briefly discussed, early on, the notion of teaching Oomph to generate the targets from the TPDs so that we could unify our workspace and build target definitions.  But, this doesn’t work, because the Modular Target mechanism in Oomph is bigger than Papyrus-RT:  any other projects that a developer imports from other setups also will contribute to the modular target, and PDE can only have one active target, so you can’t mix Oomph’s modular target with *.target files.

The only way I could see would be to develop an Oomph extension that synthesizes a dynamic Targlet from a *.TPD during the setup execution.  This would be cool.

cW

On 14 July, 2016 at 12:47:16, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote:

I only tried re-creating the .target(s) but that didn't work. Re-setting the targets the the 'papyrusrelease' TP seems to work for the *.compare.* plugins, but it breaks the *.migration.* plugins. Resetting to the 'papyrusnightly' TP seems to work.

Still, I wonder if we could make Oomph create the .target(s) and set the default TP.



On Thu, Jul 14, 2016 at 12:38 PM Philip Langer <planger@xxxxxxxxxxxxxxxxx> wrote:
Hi Ernesto,

actually, this change added the compare dependencies to the modular targets of the setup files: https://git.eclipse.org/r/#/c/75408/

And this change added them to the tdp files and also adds the regenerated targets: https://git.eclipse.org/r/#/c/72757/

The resolution of the dependencies worked for me so that there are now compile errors on the compare projects. Did you re-set the target manually to test if it isn't just a caching issue?

Thanks and best wishes,

Philip


On Thu, Jul 14, 2016 at 6:34 PM, Ernesto Posse <eposse@xxxxxxxxxxxxx> wrote:
Is it possible that the TPDs where updated but not the actual .target files when the new dependencies where added?

If so, what should be done in general whenever new dependencies are added?

1)  update the .tpd(s), generate the .target(s) and commit both new .tpd(s) and .target(s)
2)  update the .tpd(s), commit only the .tpd(s) and let Oomph generate .target(s) from .tpd(s)
3)  update the .tpd(s), commit only the .tpd(s) and let the developers manually generate the .target(s) 


On Thu, Jul 14, 2016 at 12:29 PM Ernesto Posse <eposse@xxxxxxxxxxxxx> wrote:
Is the change https://git.eclipse.org/r/#/c/77132/ supposed to get all of the compare feature's dependencies? I see it is merged, but after executing the setup I get errors on all the *.compare.* projects.


On Tue, Jul 12, 2016 at 2:13 PM Christian Damus <give.a.damus@xxxxxxxxx> wrote:
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
_______________________________________________
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




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

Back to the top