Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Papyrus » State of Papyrus compare in 2022
State of Papyrus compare in 2022 [message #1853268] Fri, 24 June 2022 16:12 Go to next message
John Harris is currently offline John HarrisFriend
Messages: 3
Registered: June 2022
Junior Member
Hi, I'm looking to merge papyrus model changes (in uml and notation files) with a git feature branch workflow.

My understanding is that EMFCompare doesn't work correctly with papyrus models, and Papyrus Compare bridges that gap. However the latter hasn't been officially supported on eclipse since 2019-06. I know there is a pending patch but no timescale for completing that.

It seems that the focus on collaborative model working shifted towards CDO in 2020.

Is anyone trying to use compare to git merge papyrus models in 2022? Does it seem like this will be supported again, or has the approach changed?
Re: State of Papyrus compare in 2022 [message #1853297 is a reply to message #1853268] Mon, 27 June 2022 07:00 Go to previous messageGo to next message
Carsten Pitz is currently offline Carsten PitzFriend
Messages: 435
Registered: May 2015
Location: Germany
Senior Member
I know what Papyrus Compare does. But what is Papyrus Compare good for?
The same question for LieberLieber LemonTree or other similar add-ons.

I am using Papyrus since version 0.7 and used Topcased since version 2 point something before. I use both with models shared among several modelers being altered concurrently. More than 15 years by now. Never had a need for a graphical model compare.

What is Papyrus Compare good for?
Is it a work-around for inadequate model structure or for lacking governance.

/Carsten
Re: State of Papyrus compare in 2022 [message #1853302 is a reply to message #1853297] Mon, 27 June 2022 09:51 Go to previous messageGo to next message
John Harris is currently offline John HarrisFriend
Messages: 3
Registered: June 2022
Junior Member
Hi Carsten, thanks for your views on this.

The scenario I'm describing is a single model (di, uml, notation files) being version controlled in git, with concurrent feature branches containing modifications to be merged. Text merging non trivial model changes in the UML file is challenging, text merging changes in the notation file not practical. It is my experience that EMFCompare, and the Papyrus Compare extension to that, provide an IDE based solution to that problem.

I'm interested to hear what workflow can be used to avoid the need for compare/merge entirely.
Re: State of Papyrus compare in 2022 [message #1853307 is a reply to message #1853302] Mon, 27 June 2022 12:49 Go to previous messageGo to next message
Carsten Pitz is currently offline Carsten PitzFriend
Messages: 435
Registered: May 2015
Location: Germany
Senior Member
Hi John,

you can split the model at each package/model into sub-models via context menu -> Model refactor -> Create Submodel within the Model Explorer. The model I am currently working on consists of some 300 sub-models. I expect a figure between 2000 and 3000 if it is finished.
Second factor is to introduce a model breakdown that facilitates modelers after having created sub-models to work without interfering each other. Another factor of it is planning the tasks to build the model.

So it is about structure, planning and governance.

/Carsten
Re: State of Papyrus compare in 2022 [message #1853309 is a reply to message #1853268] Mon, 27 June 2022 13:29 Go to previous messageGo to next message
Carsten Pitz is currently offline Carsten PitzFriend
Messages: 435
Registered: May 2015
Location: Germany
Senior Member
Hi John,

on CDO in my experience

+ real concurrent modelling -- no task planning required to not interfere
+ no merge conflicts -- transactions based

- really bad baseline support -- technically merely a database snapshot
- no support for releasing model parts -- one big pile or how to prove a part of the model has not been altered after release?
- no commit messages -- how to bind changes to review reports/tickets/tasks?
- performance issues

All in all I personally prefer GIT on models split into a sufficient number of sub-models or even separate linked models.

/Carsten

[Updated on: Mon, 27 June 2022 13:51]

Report message to a moderator

Re: State of Papyrus compare in 2022 [message #1853314 is a reply to message #1853309] Mon, 27 June 2022 16:32 Go to previous messageGo to next message
Oliver Gardiner is currently offline Oliver GardinerFriend
Messages: 45
Registered: May 2014
Location: Oxford, UK
Member
FWIW, I'm in exactly the same position as John - we have a number of data architects working on a reasonably large class model. Initially, we subdivided the model into domains but we really want to be in a position where different architects can work in the same domains without tripping over each other. We looked at CDO but a) as Carsten observes, that doesn't really provide the features needed for true collaborative development, and b) requires an install of a CDO server in a network accessible location - and that's not always easy on a corporate network. Git does support collaborative workflows really well and secure cloud repositories are widely available, and the platform is also very familiar to developers.

But... a collaborative Git-based workflow does require a tool that can compare and merge branches, with regard to both the model and the diagrams. Papyrus Compare clearly is intended to support this. I would in no way want to criticise the community for developing Papyrus Compare and it is a tool that shows real promise. However, in practice, we found it just too hard to use, partly because it is very unclear how to identify and resolve "real" conflicts (I think quite a lot of the work requires filtering the copious output from EMF Compare into something that makes sense to a developer), and partly because we found it very difficult to create a repeatable merge process that didn't end up with the model being in an unusable state. It may well be that our difficulties were down to our mistakes but I'm not convinced they were and, in any case, that would point to some significant usability issues that would probably seriously limit its application.

Currently, we get our Data Architects to work in separate branches and then copy/transcribe their works in progress into the master branch when it makes sense - not ideal but has proved to be the most workable approach for us, but we may go back to splitting the model as well. Personally, I think Papyrus is an amazing tool that is invaluable to us, but making the Compare feature work simply and reliably would be a game changer for us.

Regards,

Oliver
Re: State of Papyrus compare in 2022 [message #1853319 is a reply to message #1853314] Mon, 27 June 2022 17:49 Go to previous messageGo to next message
Carsten Pitz is currently offline Carsten PitzFriend
Messages: 435
Registered: May 2015
Location: Germany
Senior Member
Hi Oliver,

if you have to work on a single, flat, atomic class model you either go CDO or sequentialize access.
BTW, with 'flat' in this context I classify class models without hierarchies, implying without locality. These kind of class models are hard to create, review and maintain anyway. That is why a strongly advise to avoid such class models.

SAP R/3 maintenance suffers hard from a historically grown flat data model. SAP learned its lessons and avoided it with S4/HANA

With SASPF mainly SAP as contractor restructured a historically grown flat data model used by some 1800 applications used by the German Armed Forces containing some 30K tables restructured. Cost point was above EUR 2 billion.

/Carsten
Re: State of Papyrus compare in 2022 [message #1853322 is a reply to message #1853319] Mon, 27 June 2022 19:07 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7505
Registered: July 2009
Senior Member
Hi

Modeling tools are hard to develop, and consequently many/all fail to adequately hide the underlying details. requiring users to tunnel down. Compare / Merge is particularly challenging.

I mostly just use Ecore so don't face nearly as many challenges as UML, but nonetheless I often need to work at the XMI level to correct GIT merge errors.

Carsten's advice seems absolutely excellent, and it's backed up by substantial non-trivial real world usage. I recommend you do as he recommends, unless you have the time and skills to develop a better tool yourself. (You wouldn't organize a large Java application as nested classes all in a single huge monolithic million line one dimensional textual Main.java, so why try to do that with two dimensional graphical models?)

Regards

Ed Willink
Re: State of Papyrus compare in 2022 [message #1853326 is a reply to message #1853322] Mon, 27 June 2022 21:29 Go to previous messageGo to next message
Oliver Gardiner is currently offline Oliver GardinerFriend
Messages: 45
Registered: May 2014
Location: Oxford, UK
Member
Many thanks - that is all eminently sensible and, yes, our modelling is very structured so lends itself to being managed as sub-models. Indeed, when we set it up that way initially we had hoped to combine that approach with Papyrus Compare but quickly came unstuck. We then moved to a single file containing the whole Package hierarchy in the hope that this would work better with Compare but are now considering going back to the sub-model approach. Rest assured that I am no fan of monolithic models, though!

I have tried a few tools in my time and I certainly agree that they are tricky things, so I have always been impressed at how the Eclipse projects have demonstrated the viability and benefits of a ground-up MOF based approach. I also appreciate that Compare/Merge is probably one of the hardest things to make work given the nature of the underlying XMI. Personally, I have not come across another tool that gets even remotely as close as Papyrus Compare in this regard - Atlova's UModel was, I think, the best commercial Compare/Merges I found but it was still pretty poor. I guess that thing that feels a slight shame is that, despite the intrinsic difficulties, Papyrus Compare seems so close to being great.

All that said, we still find Papyrus to be a great tool and certainly the approaches discussed here are entirely workable.

Regards,

Oliver
Re: State of Papyrus compare in 2022 [message #1853351 is a reply to message #1853322] Tue, 28 June 2022 19:21 Go to previous messageGo to next message
Carsten Pitz is currently offline Carsten PitzFriend
Messages: 435
Registered: May 2015
Location: Germany
Senior Member
Hi Ed,
just out of curiosity. I try hard to get the (fractal) dimension of a model into the [1.05,1.09] range.
As definition of fractal dimension I use the one defined by Benoit Mandelbrot.
/Carsten
Re: State of Papyrus compare in 2022 [message #1853362 is a reply to message #1853351] Wed, 29 June 2022 08:57 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7505
Registered: July 2009
Senior Member
Hi Carsten

I'm not at all sure that fractal dimension is helpful here. If anything a small number would seem to indicate an over-emphasis on a single structuring approach. Potentially one dimension for inheritance depth and another for inheritance width. There may also be composition depth and width and referencing. And I haven't started considering run-time states or activities or deployment.

Regards

Ed
Previous Topic:Default css file?
Next Topic:[C++ Code Build] Can the generated code be built with VCXX compiler?
Goto Forum:
  


Current Time: Sat Aug 13 16:37:46 GMT 2022

Powered by FUDForum. Page generated in 0.02006 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top