| State of Papyrus compare in 2022 [message #1853268] |
Fri, 24 June 2022 12:12  |
Eclipse User |
|
|
|
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 #1853314 is a reply to message #1853309] |
Mon, 27 June 2022 12:32  |
| Eclipse User |
|
|
|
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 #1853326 is a reply to message #1853322] |
Mon, 27 June 2022 17:29 |
| Eclipse User |
|
|
|
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 #1853362 is a reply to message #1853351] |
Wed, 29 June 2022 04:57 |
| Eclipse User |
|
|
|
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
|
|
|
Powered by
FUDForum. Page generated in 0.04277 seconds
Home