Approval for using DaisyDiff in Eclipse EMF Compare

[Philip Langer]

Hi everyone,

we would like to integrate DaisyDiff in the open-source Eclipse Modeling project EMF Compare to handle rich text comments in EMF-based models. Therefore we need someone of the DaisyDiff team, such as a committer, to communicate with Eclipse regarding the intellectual property of the project.

Guy Van den Broeck seems to be unavailable currently. So it would be great if someone of you guys could help us out?

We appreciate any help!

Thanks a lot in advance,

Philip

[Kostis Kapelonis]

Hello

I am one of the committers of the project and author of the few wiki pages.
I also did all the last releases (1.1 and 1.2)
The code is already licenced under Apache 2.0. Do you need something else?

Also if you noticed daisydiff is already using Eclipse compare code,
so I think it would be a good fit for EMF Compare.

The project is practically stalled and with the imminent close down of
Google code, I think in fact that you would do well to give
this code a new house.

Tell me if you need anything else. I am not one of the core committers
(just one of the last ones) so other people can join and talk about
what they think.

Kostis

> --
> You received this message because you are subscribed to the Google Groups
> "DaisyDiff" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to daisydiff+...@googlegroups.com.
> To post to this group, send email to dais...@googlegroups.com.
> Visit this group at http://groups.google.com/group/daisydiff.
> For more options, visit https://groups.google.com/d/optout.

[Philip Langer]

Hi Kostis,

thanks a lot for your fast response! I forwarded this to the team at the Eclipse foundation responsible for the IP-related tasks.

This would be more about the integration with EMF Compare (in terms of shipping DaisyDiff with EMF Compare). Thus, EMF Compare wouldn't be a good "new home for development", also because DaisyDiff well deserves to be a project on its own with its own community. Nevertheless, with the integration of DaisyDiff and maintenance of EMF Compare, I'm sure that we'll have a bunch of fixes and possibly extensions that we'd certainly like to contribute back, if accept them. Therefore, I'd suggest to move DaisyDiff to GitHub (this is fairly easy as Google Code offers a new export feature for that) and we open pull requests for the fixes and extensions that we might have and take it from there.

What do you think?

Thanks again and best wishes,

Philip

[Kostis Kapelonis]

Yes I was already thinking about moving to Github.

However even then, somebody will have to approve/test the pull
requests and I am not sure who will that be. Even now issues stay open
and patches stay behind because of lack of time/interest.

Let me put it another way.

If you are going to invest your time in DaisyDiff, feel free to take
over completely its development (unless somebody has an objection). I
already integrated
my own extensions, so there is nothing more I need at the moment
(although a port to Maven would be nice)

Any other opinions from DaisyDiff committers? Speak up! :-)

Kostis

[Carsten Pfeiffer]

On Sunday 10 May 2015 12:39:11 dais...@googlegroups.com wrote:

> Yes I was already thinking about moving to Github.

Me too, so +1 from me.

> If you are going to invest your time in DaisyDiff, feel free to take
> over completely its development (unless somebody has an objection). I
> already integrated
> my own extensions, so there is nothing more I need at the moment
> (although a port to Maven would be nice)
>
> Any other opinions from DaisyDiff committers? Speak up! :-)

Same feelings here. We also run a custom version of Daisydiff and actually for
a reason that origins in eclipse: Daisydiff ships a patched copy of
org.eclipse.compare. We cannot easily use the unpatached pristine version
because the testsuite brings up a lot of errors then.

So

1) first org.eclipse.compare would need to be opened up a bit so that Daisydiff
can reuse it as desired.
2) then Daisydiff can scrap its old copy of it
3) and finally you can make Daisydiff an OSGi bundle with a proper dependency to
org.eclipse.compare

I didn't do that myself yet, because I had another (way more trivial) patch
for org.eclipse.compare lying around for literally ages on bugs.eclipse.org.

Now that patch is actually committed, so an attempt may be worthwhile,
especially if there's support from the EMF community.

FWIW, here's my notes for when I last had a look at porting Daisydiff to
pristine org.eclipse.compare:

org.eclipse.compare changes (Daisydiff ships a version for Eclipse 3.4).

Eclipse 3.4 -> 3.7
- rangedifferencer now in org.eclipse.compare.core
- LCS now has isCappingDisabled() (configurable)

- OldDifferencer: has gone
- AbstractRangeDifferenceFactory introduced
- RangeComparatorLCS
- findDifferences() has additional parameter AbstractRangeDifferenceFactory
- getDifferences() has additional parameter AbstractRangeDifferenceFactory
- RangeDifference: some fields renamed
- Rangedifferencer:
- has AbstractRangeDifferenceFactory
- many methods are overloaded with additional AbstractRangeDifferenceFactory
parameter and use it
- isUseOldDifferencer has gone

Eclipse 3.4 -> Daisydiff
- LCSSettings introduced to make hardcoded options configurable
- explicitly uses OldDifferencer in TextOnlyComparator (via
LCSSettings.setUseGreedyMethod and RangeDifferencer.findDifferences()
- POW_LIMIT not necessary anymore? Always uses default eclipse value
- TOO_LONG configured by TextOnlyComparator to (150*150) instead of
100000000.0
- setUseGreedyMethod not really possible since OldDifferencer not available
anymore
=> maybe we can always use the plain eclipse LCS settings, verify with
testcases




BIG PROBLEM:
- no way to reference ComparePlugin.getDefault() for isCappingDisabled()
without OSGi running
=> must fix LCS.isCappingDisabled() somehow

PROBLEMS:
- RangeDifference has package-private constructors! And no public
AbstractRangeDifferenceFactory available! => Reflection
- LCS needs org.NLS (org.eclipse.osgi bundle)
- ComparePlugin (LCS.isCappingDisabled) needs org.eclipse.core.runtime.Plugin
- IProgressMonitor needed, but now in org.eclipse.equinox.common

Cheers
Carsten