|
Re: Programmatically opening compare editor [message #1048210 is a reply to message #1047753] |
Wed, 24 April 2013 07:07 |
|
Hi Victor,
Quote:You guys took seriously breaking API
Yup, that was the main reason for 2.0 : to break everything apart .
More seriously, though we did break everything, the goal was to get rid of the limitations of the previous architecture . We hope that this will be your general feeling too as a client of the API .
Do not hesitate to ask if you think some of compare's internals should be exposed : the new API is meant to be much more extensible, but may still be missing bits and pieces.
Quote:There seems to exist a new ICompareEditingDomain, but for some reason I can't seem to find it.
ICompareEditingDomain is part of org.eclipse.emf.compare.edit.
Quote:BTW ComparisonEditorInput is internal, is there any legit way to get it?
I am pretty sure this was meant to be public API. Mikaël, could you take a look?
Laurent Goubet
Obeo
|
|
|
Re: Programmatically opening compare editor [message #1048277 is a reply to message #1048210] |
Wed, 24 April 2013 08:47 |
Victor Roldan Betancort Messages: 524 Registered: July 2009 |
Senior Member |
|
|
Laurent,
first of all, thanks for your prompt feedback
Quote:
Yup, that was the main reason for 2.0 : to break everything apart .
More seriously, though we did break everything, the goal was to get rid of the limitations of the previous architecture . We hope that this will be your general feeling too as a client of the API .
Do not hesitate to ask if you think some of compare's internals should be exposed : the new API is meant to be much more extensible, but may still be missing bits and pieces.
At first glance, things make much more sense now, cleaner and full of nice APIs to be extended / implemented. Previously, customizations of the comparison engines required some nasty hacks.
Now I'm trying to figure out how to migrate all that logic, hopefully I would be able to get rid of a big part of it.
Quote:
ICompareEditingDomain is part of org.eclipse.emf.compare.edit.
ha! so thats the reason I couldn't find it, missing ".edit" in the namespace. I thought best practices pushed us to use bundle namespace in the java packages too. My first though was that .edit bundle corresponded to old's 1.X emf's .edit framework generated bundle. I see this is something different now in 2.X.
Quote:
I am pretty sure this was meant to be public API. Mikaël, could you take a look?
Very much appreciated!
Cheers,
Víctor [Open Canarias]
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03101 seconds