29 May
2012
29 May
'12
4:07 p.m.
Hi devs,
As I said in another mail I'm working on a diff/merge module to use in
XWiki, the first target being Extension Manager and document history
(since both are going to use the same code, see Marius mails).
You can see the detail on https://github.com/xwiki/xwiki-commons/pull/2.
TODO/QUESTIONS:
* improve the generic 3 ways merge to be at least as good as the
List<String> 3 ways merge and get rid of JDiff
* not sure where/if I should put String related helpers (things that
do a diff on two String instead of having to cut List<String> or
List<Character> and call the diff API etc.)
I'm ready to merge it into master so I'm waiting your vote.
Caleb is it OK to put new stuff in master already or should I wait the
complete release to be done ?
Here is my +1.
Thanks,
--
Thomas Mortagne
29 May
29 May
6:05 p.m.
Hi Thomas,
On May 29, 2012, at 4:07 PM, Thomas Mortagne wrote:
Hi devs,
As I said in another mail I'm working on a diff/merge module to use in
XWiki, the first target being Extension Manager and document history
(since both are going to use the same code, see Marius mails).
You can see the detail on https://github.com/xwiki/xwiki-commons/pull/2.
TODO/QUESTIONS:
* improve the generic 3 ways merge to be at least as good as the
List<String> 3 ways merge and get rid of JDiff
* not sure where/if I should put String related helpers (things that
do a diff on two String instead of having to cut List<String> or
List<Character> and call the diff API etc.)
I'm ready to merge it into master so I'm waiting your vote.
Caleb is it OK to put new stuff in master already or should I wait the
complete release to be done ?
Here is my +1.
+1
Thanks
-Vincent
30 May
30 May
7:57 a.m.
I'm rewriting my code to use your new diff API instead of jrcs. I'll
let you know about the result ASAP.
Thanks,
Marius
On Tue, May 29, 2012 at 5:07 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
Hi devs,
As I said in another mail I'm working on a diff/merge module to use in
XWiki, the first target being Extension Manager and document history
(since both are going to use the same code, see Marius mails).
You can see the detail on https://github.com/xwiki/xwiki-commons/pull/2.
TODO/QUESTIONS:
* improve the generic 3 ways merge to be at least as good as the
List<String> 3 ways merge and get rid of JDiff
* not sure where/if I should put String related helpers (things that
do a diff on two String instead of having to cut List<String> or
List<Character> and call the diff API etc.)
I'm ready to merge it into master so I'm waiting your vote.
Caleb is it OK to put new stuff in master already or should I wait the
complete release to be done ?
Here is my +1.
Thanks,
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2:18 p.m.
Hi Thomas,
On Tue, May 29, 2012 at 5:07 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
Hi devs,
As I said in another mail I'm working on a diff/merge module to use in
XWiki, the first target being Extension Manager and document history
(since both are going to use the same code, see Marius mails).
You can see the detail on https://github.com/xwiki/xwiki-commons/pull/2.
TODO/QUESTIONS:
* improve the generic 3 ways merge to be at least as good as the
List<String> 3 ways merge and get rid of JDiff
* not sure where/if I should put String related helpers (things that
do a diff on two String instead of having to cut List<String> or
List<Character> and call the diff API etc.)
This looks a bit awkward to use, specially from (but not limited to)
Velocity. When I think of a diff service API, I imagine passing Strings,
not lists of composing strings or list of characters.
Also, I don`t quite understand the List<String> approach. I can imagine the
List<Character> version by breaking a string into characters, but what
would you do for List<String>? You would split a String using "\s" as a
separator?
Can you please mention a use case where a list oriented API is better than
a string based one?
Thanks,
Eduard
I'm ready to merge it into master so I'm waiting your vote.
Caleb is it OK to put new stuff in master already or should I wait the
complete release to be done ?
Here is my +1.
Thanks,
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2:28 p.m.
On May 30, 2012, at 2:18 PM, Eduard Moraru wrote:
Hi Thomas,
On Tue, May 29, 2012 at 5:07 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
Thomas is proposing a Java API here AFAIK. For Velocity we never expose java API directly;
we use Script Services for that.
Thanks
-Vincent
PS: FTR I'm a big -1 to model our Java APIs to be easily usable from Velocity since
that means having suboptimal APIs for the wrong reason ;)
Hi devs,
As I said in another mail I'm working on a diff/merge module to use in
XWiki, the first target being Extension Manager and document history
(since both are going to use the same code, see Marius mails).
You can see the detail on https://github.com/xwiki/xwiki-commons/pull/2.
TODO/QUESTIONS:
* improve the generic 3 ways merge to be at least as good as the
List<String> 3 ways merge and get rid of JDiff
* not sure where/if I should put String related helpers (things that
do a diff on two String instead of having to cut List<String> or
List<Character> and call the diff API etc.)
This looks a bit awkward to use, specially from (but not limited to)
Velocity. When I think of a diff service API, I imagine passing Strings,
not lists of composing strings or list of characters. Also, I don`t quite understand the List<String>
approach. I can imagine the
List<Character> version by breaking a string into characters, but what
would you do for List<String>? You would split a String using "\s" as a
separator?
Can you please mention a use case where a list oriented API is better than
a string based one?
Thanks,
Eduard
>
> I'm ready to merge it into master so I'm waiting your vote.
>
> Caleb is it OK to put new stuff in master already or should I wait the
> complete release to be done ?
>
> Here is my +1.
>
> Thanks,
> --
> Thomas Mortagne
2:32 p.m.
On May 30, 2012, at 2:28 PM, Vincent Massol wrote:
On May 30, 2012, at 2:18 PM, Eduard Moraru wrote:
Sorry, just realized you wrote "but not limited to" ;)
I'll let Thomas reply since I don't know this diff api yet….
Sorry for the noise
-Vincent
Hi Thomas,
On Tue, May 29, 2012 at 5:07 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
Thomas is proposing a Java API here AFAIK. For Velocity we never expose java API
directly; we use Script Services for that. Hi devs,
As I said in another mail I'm working on a diff/merge module to use in
XWiki, the first target being Extension Manager and document history
(since both are going to use the same code, see Marius mails).
You can see the detail on https://github.com/xwiki/xwiki-commons/pull/2.
TODO/QUESTIONS:
* improve the generic 3 ways merge to be at least as good as the
List<String> 3 ways merge and get rid of JDiff
* not sure where/if I should put String related helpers (things that
do a diff on two String instead of having to cut List<String> or
List<Character> and call the diff API etc.)
This looks a bit awkward to use, specially from (but not limited to)
Velocity. When I think of a diff service API, I imagine passing Strings,
not lists of composing strings or list of characters.
Thanks
-Vincent
PS: FTR I'm a big -1 to model our Java APIs to be easily usable from Velocity since
that means having suboptimal APIs for the wrong reason ;)
> Also, I don`t quite understand the List<String> approach. I can imagine the
> List<Character> version by breaking a string into characters, but what
> would you do for List<String>? You would split a String using "\s" as
a
> separator?
>
> Can you please mention a use case where a list oriented API is better than
> a string based one?
>
> Thanks,
> Eduard
>
>>
>> I'm ready to merge it into master so I'm waiting your vote.
>>
>> Caleb is it OK to put new stuff in master already or should I wait the
>> complete release to be done ?
>>
>> Here is my +1.
>>
>> Thanks,
>> --
>> Thomas Mortagne
2:55 p.m.
I mentioned Velocity because I saw a DiffScriptService component with
@Named("diff") that has the same method signature as the Java API:
public <E> DiffResult<E> diff(List<E> previous, List<E> next,
DiffConfiguration<E> configuration)
See the discussion [1] on the pull request for more details on the Velocity
question.
Back to my original question (same question as Thomas basically), that's
exactly what I am trying to understand, Vincent... if the
List<String/Character> is the optimal use case and not just String.
Without a scenario in favour of List<E>, I would go for exposing a String
based API (well, just an extra method in this case) as well.
Thanks,
Eduard
----------
[1] https://github.com/xwiki/xwiki-commons/pull/2/files#L27R58
On Wed, May 30, 2012 at 3:32 PM, Vincent Massol <vincent(a)massol.net> wrote:
On May 30, 2012, at 2:28 PM, Vincent Massol wrote:
Thomas is proposing a Java API here AFAIK. For Velocity we never expose java API
directly; we use Script Services for that.
Sorry, just realized you wrote "but not limited to" ;)
I'll let Thomas reply since I don't know this diff api yet….
Sorry for the noise
-Vincent
On May 30, 2012, at 2:18 PM, Eduard Moraru wrote:
> Hi Thomas,
>
> On Tue, May 29, 2012 at 5:07 PM, Thomas Mortagne
> <thomas.mortagne(a)xwiki.com>wrote;wrote:
>
>> Hi devs,
>>
>> As I said in another mail I'm working on a diff/merge module to use in
>> XWiki, the first target being Extension Manager and document history
>> (since both are going to use the same code, see Marius mails).
>>
>> You can see the detail on
https://github.com/xwiki/xwiki-commons/pull/2.
TODO/QUESTIONS:
* improve the generic 3 ways merge to be at least as good as the
List<String> 3 ways merge and get rid of JDiff
* not sure where/if I should put String related helpers (things that
do a diff on two String instead of having to cut List<String> or
List<Character> and call the diff API etc.)
This looks a bit awkward to use, specially from (but not limited to)
Velocity. When I think of a diff service API, I imagine passing Strings,
not lists of composing strings or list of characters.
Thanks
-Vincent
PS: FTR I'm a big -1 to model our Java APIs to be easily usable from
Velocity
since that means having suboptimal APIs for the wrong reason ;)
> Also, I don`t quite understand the List<String> approach. I can imagine
the
> List<Character> version by breaking a
string into characters, but what
> would you do for List<String>? You would split a String using "\s" as
a
> separator?
>
> Can you please mention a use case where a list oriented API is better
than
> a string based one?
>
> Thanks,
> Eduard
>
>>
>> I'm ready to merge it into master so I'm waiting your vote.
>>
>> Caleb is it OK to put new stuff in master already or should I wait the
>> complete release to be done ?
>>
>> Here is my +1.
>>
>> Thanks,
>> --
>> Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3:16 p.m.
On Wed, May 30, 2012 at 2:55 PM, Eduard Moraru <enygma2002(a)gmail.com> wrote:
I mentioned Velocity because I saw a DiffScriptService
component with
@Named("diff") that has the same method signature as the Java API:
public <E> DiffResult<E> diff(List<E> previous, List<E> next,
DiffConfiguration<E> configuration)
See the discussion [1] on the pull request for more details on the Velocity
question.
Back to my original question (same question as Thomas basically), that's
exactly what I am trying to understand, Vincent... if the
List<String/Character> is the optimal use case and not just String.
Without a scenario in favour of List<E>, I would go for exposing a String
based API (well, just an extra method in this case) as well.
You can imagine all sort of use cases with any value so I don't see
the point in arbitrary limiting the API to just Strings where the
logic is the same whatever the type. If you really need a direct use
case for existing stuff then just think about producing a diff between
two static list properties values, it would be very bad to have to
create a String from it first especially since you could have \n in
one of the elements.
My main concern is to expose a clear API and no String it everything
but clear, it's simple yes but it's not the same things. When you
provide String you don't have no idea what you are diffing exactly
(could be characters, \n, words, etc.) so having only one method with
two strings is just very bad design.
Also if you read my mail I did talked about String based APIs but as
helpers and I'm would be surely -1 for any attempt to restrict the
whole API to it. So the only question here is: is that really needed
to expose String based helpers or not.
Thanks,
Eduard
----------
[1] https://github.com/xwiki/xwiki-commons/pull/2/files#L27R58
On Wed, May 30, 2012 at 3:32 PM, Vincent Massol <vincent(a)massol.net> wrote:
--
Thomas Mortagne
On May 30, 2012, at 2:28 PM, Vincent Massol wrote:
java API
directly; we use Script Services for that.
Sorry, just realized you wrote "but not limited to" ;)
I'll let Thomas reply since I don't know this diff api yet….
Sorry for the noise
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
On May 30, 2012, at 2:18 PM, Eduard Moraru wrote:
> Hi Thomas,
>
> On Tue, May 29, 2012 at 5:07 PM, Thomas Mortagne
> <thomas.mortagne(a)xwiki.com>wrote;wrote:
>
>> Hi devs,
>>
>> As I said in another mail I'm working on a diff/merge module to use in
>> XWiki, the first target being Extension Manager and document history
>> (since both are going to use the same code, see Marius mails).
>>
>> You can see the detail on
https://github.com/xwiki/xwiki-commons/pull/2.
>
> TODO/QUESTIONS:
> * improve the generic 3 ways merge to be at least as good as the
> List<String> 3 ways merge and get rid of JDiff
> * not sure where/if I should put String related helpers (things that
> do a diff on two String instead of having to cut List<String> or
> List<Character> and call the diff API etc.)
>
This looks a bit awkward to use, specially from (but not limited to)
Velocity. When I think of a diff service API, I imagine passing Strings,
not lists of composing strings or list of characters.
Thomas is proposing a Java API here AFAIK. For Velocity we never expose
Thanks
-Vincent
PS: FTR I'm a big -1 to model our Java APIs to be easily usable from
Velocity
since that means having suboptimal APIs for the wrong reason ;)
> Also, I don`t quite understand the List<String> approach. I can imagine
the
> List<Character> version by breaking a
string into characters, but what
> would you do for List<String>? You would split a String using "\s" as
a
> separator?
>
> Can you please mention a use case where a list oriented API is better
than
> a string based one?
>
> Thanks,
> Eduard
>
>>
>> I'm ready to merge it into master so I'm waiting your vote.
>>
>> Caleb is it OK to put new stuff in master already or should I wait the
>> complete release to be done ?
>>
>> Here is my +1.
>>
>> Thanks,
>> --
>> Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4:01 p.m.
On Wed, May 30, 2012 at 4:16 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
On Wed, May 30, 2012 at 2:55 PM, Eduard Moraru
<enygma2002(a)gmail.com>
wrote:
Yes, I understand now how it works. If other are interested, please see my
new comment [1] on the pull request.
Short version: The API compares lists of objects by using Object#equals()
and does not go into the structure of the compared elements, just reports
differences of the list itself. You have to structure/break your input to
the level of granularity that you need for the diff to be relevant to your
use case.
I mentioned Velocity because I saw a
DiffScriptService component with
@Named("diff") that has the same method signature as the Java API:
public <E> DiffResult<E> diff(List<E> previous, List<E> next,
DiffConfiguration<E> configuration)
See the discussion [1] on the pull request for more details on the
Velocity
question.
Back to my original question (same question as Thomas basically), that's
exactly what I am trying to understand, Vincent... if the
List<String/Character> is the optimal use case and not just String.
Without a scenario in favour of List<E>, I would go for exposing a String
based API (well, just an extra method in this case) as well.
You can imagine all sort of use cases with any value so I don't see
the point in arbitrary limiting the API to just Strings where the
logic is the same whatever the type. If you really need a direct use
case for existing stuff then just think about producing a diff between
two static list properties values, it would be very bad to have to
create a String from it first especially since you could have \n in
one of the elements.
My main concern is to expose a clear API and no String it everything
but clear, it's simple yes but it's not the same things. When you
provide String you don't have no idea what you are diffing exactly
(could be characters, \n, words, etc.) so having only one method with
two strings is just very bad design.
Also if you read my mail I did talked about String based APIs but as
helpers and I'm would be surely -1 for any attempt to restrict the
whole API to it. So the only question here is: is that really needed
to expose String based helpers or not.
No, I was never suggesting to drop the generic API, I was just saying that
the helpers might be a good idea since I imagine that String diff would
cover most of the usage of this API. Anyway, this is not important for now
since it is something that can be added later if API clients start
complaining :)
Thanks,
Eduard
----------
[1] https://github.com/xwiki/xwiki-commons/pull/2/files#r900063
Thanks,
Eduard
----------
[1] https://github.com/xwiki/xwiki-commons/pull/2/files#L27R58
On Wed, May 30, 2012 at 3:32 PM, Vincent Massol <vincent(a)massol.net>
wrote:
>
> On May 30, 2012, at 2:28 PM, Vincent Massol wrote:
>
> >
> > On May 30, 2012, at 2:18 PM, Eduard Moraru wrote:
> >
> >> Hi Thomas,
> >>
> >> On Tue, May 29, 2012 at 5:07 PM, Thomas Mortagne
> >> <thomas.mortagne(a)xwiki.com>wrote;wrote:
> >>
> >>> Hi devs,
> >>>
> >>> As I said in another mail I'm working on a diff/merge module to use
in
> >>> XWiki, the first target being
Extension Manager and document history
> >>> (since both are going to use the same code, see Marius mails).
> >>>
> >>> You can see the detail on
> https://github.com/xwiki/xwiki-commons/pull/2.
> >>>
> >>> TODO/QUESTIONS:
> >>> * improve the generic 3 ways merge to be at least as good as the
> >>> List<String> 3 ways merge and get rid of JDiff
> >>> * not sure where/if I should put String related helpers (things that
> >>> do a diff on two String instead of having to cut List<String> or
> >>> List<Character> and call the diff API etc.)
> >>>
> >>
> >> This looks a bit awkward to use, specially from (but not limited to)
> >> Velocity. When I think of a diff service API, I imagine passing
Strings,
> >> not lists of composing strings or
list of characters.
> >
> > Thomas is proposing a Java API here AFAIK. For Velocity we never
expose
> java API directly; we use Script Services
for that.
>
> Sorry, just realized you wrote "but not limited to" ;)
>
> I'll let Thomas reply since I don't know this diff api yet….
>
> Sorry for the noise
> -Vincent
>
> >
> > Thanks
> > -Vincent
> >
> > PS: FTR I'm a big -1 to model our Java APIs to be easily usable from
> Velocity since that means having suboptimal APIs for the wrong reason ;)
> >
> >> Also, I don`t quite understand the List<String> approach. I can
imagine
> the
> >> List<Character> version by breaking a string into characters, but
what
> >> would you do for List<String>?
You would split a String using "\s"
as a
> >> separator?
> >>
> >> Can you please mention a use case where a list oriented API is better
> than
> >> a string based one?
> >>
> >> Thanks,
> >> Eduard
> >>
> >>>
> >>> I'm ready to merge it into master so I'm waiting your vote.
> >>>
> >>> Caleb is it OK to put new stuff in master already or should I wait
the
>> complete release to be done ?
>>
>> Here is my +1.
>>
>> Thanks,
>> --
>> Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4:03 p.m.
Oh and... +1 :)
Thanks,
Eduard
On Wed, May 30, 2012 at 5:01 PM, Eduard Moraru <enygma2002(a)gmail.com> wrote:
On Wed, May 30, 2012 at 4:16 PM, Thomas Mortagne <
thomas.mortagne(a)xwiki.com> wrote:
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
On Wed, May 30, 2012 at 2:55 PM, Eduard Moraru
<enygma2002(a)gmail.com>
wrote:
Yes, I understand now how it works. If other are interested, please see my
new comment [1] on the pull request.
Short version: The API compares lists of objects by using Object#equals()
and does not go into the structure of the compared elements, just reports
differences of the list itself. You have to structure/break your input to
the level of granularity that you need for the diff to be relevant to your
use case.
I mentioned Velocity because I saw a
DiffScriptService component with
@Named("diff") that has the same method signature as the Java API:
public <E> DiffResult<E> diff(List<E> previous, List<E> next,
DiffConfiguration<E> configuration)
See the discussion [1] on the pull request for more details on the
Velocity
question.
Back to my original question (same question as Thomas basically), that's
exactly what I am trying to understand, Vincent... if the
List<String/Character> is the optimal use case and not just String.
Without a scenario in favour of List<E>, I would go for exposing a
String
based API (well, just an extra method in this
case) as well.
You can imagine all sort of use cases with any value so I don't see
the point in arbitrary limiting the API to just Strings where the
logic is the same whatever the type. If you really need a direct use
case for existing stuff then just think about producing a diff between
two static list properties values, it would be very bad to have to
create a String from it first especially since you could have \n in
one of the elements.
My main concern is to expose a clear API and no String it everything
but clear, it's simple yes but it's not the same things. When you
provide String you don't have no idea what you are diffing exactly
(could be characters, \n, words, etc.) so having only one method with
two strings is just very bad design.
Also if you read my mail I did talked about String based APIs but as
helpers and I'm would be surely -1 for any attempt to restrict the
whole API to it. So the only question here is: is that really needed
to expose String based helpers or not.
No, I was never suggesting to drop the generic API, I was just saying that
the helpers might be a good idea since I imagine that String diff would
cover most of the usage of this API. Anyway, this is not important for now
since it is something that can be added later if API clients start
complaining :)
Thanks,
Eduard
----------
[1] https://github.com/xwiki/xwiki-commons/pull/2/files#r900063
Thanks,
Eduard
----------
[1] https://github.com/xwiki/xwiki-commons/pull/2/files#L27R58
On Wed, May 30, 2012 at 3:32 PM, Vincent Massol <vincent(a)massol.net>
wrote:
>
> On May 30, 2012, at 2:28 PM, Vincent Massol wrote:
>
> >
> > On May 30, 2012, at 2:18 PM, Eduard Moraru wrote:
> >
> >> Hi Thomas,
> >>
> >> On Tue, May 29, 2012 at 5:07 PM, Thomas Mortagne
> >> <thomas.mortagne(a)xwiki.com>wrote;wrote:
> >>
> >>> Hi devs,
> >>>
> >>> As I said in another mail I'm working on a diff/merge module to
use in
> >>> XWiki, the first target being
Extension Manager and document
history
> >>> (since both are going to use the
same code, see Marius mails).
> >>>
> >>> You can see the detail on
> https://github.com/xwiki/xwiki-commons/pull/2.
> >>>
> >>> TODO/QUESTIONS:
> >>> * improve the generic 3 ways merge to be at least as good as the
> >>> List<String> 3 ways merge and get rid of JDiff
> >>> * not sure where/if I should put String related helpers (things
that
> >>> do a diff on two String instead
of having to cut List<String> or
> >>> List<Character> and call the diff API etc.)
> >>>
> >>
> >> This looks a bit awkward to use, specially from (but not limited to)
> >> Velocity. When I think of a diff service API, I imagine passing
Strings,
> >> not lists of composing strings or
list of characters.
> >
> > Thomas is proposing a Java API here AFAIK. For Velocity we never
expose
> java API directly; we use Script Services
for that.
>
> Sorry, just realized you wrote "but not limited to" ;)
>
> I'll let Thomas reply since I don't know this diff api yet….
>
> Sorry for the noise
> -Vincent
>
> >
> > Thanks
> > -Vincent
> >
> > PS: FTR I'm a big -1 to model our Java APIs to be easily usable from
> Velocity since that means having suboptimal APIs for the wrong reason
;)
> >
> >> Also, I don`t quite understand the List<String> approach. I can
imagine
> the
> >> List<Character> version by breaking a string into characters, but
what
> >> would you do for List<String>?
You would split a String using "\s"
as a
> >> separator?
> >>
> >> Can you please mention a use case where a list oriented API is
better
> than
> >> a string based one?
> >>
> >> Thanks,
> >> Eduard
> >>
> >>>
> >>> I'm ready to merge it into master so I'm waiting your vote.
> >>>
> >>> Caleb is it OK to put new stuff in master already or should I wait
the
>>> complete release to be done ?
>>>
>>> Here is my +1.
>>>
>>> Thanks,
>>> --
>>> Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4:29 p.m.
On Wed, May 30, 2012 at 4:01 PM, Eduard Moraru <enygma2002(a)gmail.com> wrote:
On Wed, May 30, 2012 at 4:16 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
That's more or less what I was planning, I'm waiting for my first
client report now, any news Marius ? ;)
On Wed, May 30, 2012 at 2:55 PM, Eduard Moraru
<enygma2002(a)gmail.com>
wrote:
Yes, I understand now how it works. If other are interested, please see my
new comment [1] on the pull request.
Short version: The API compares lists of objects by using Object#equals()
and does not go into the structure of the compared elements, just reports
differences of the list itself. You have to structure/break your input to
the level of granularity that you need for the diff to be relevant to your
use case.
I mentioned Velocity because I saw a
DiffScriptService component with
@Named("diff") that has the same method signature as the Java API:
public <E> DiffResult<E> diff(List<E> previous, List<E> next,
DiffConfiguration<E> configuration)
See the discussion [1] on the pull request for more details on the
Velocity
question.
Back to my original question (same question as Thomas basically), that's
exactly what I am trying to understand, Vincent... if the
List<String/Character> is the optimal use case and not just String.
Without a scenario in favour of List<E>, I would go for exposing a String
based API (well, just an extra method in this case) as well.
You can imagine all sort of use cases with any value so I don't see
the point in arbitrary limiting the API to just Strings where the
logic is the same whatever the type. If you really need a direct use
case for existing stuff then just think about producing a diff between
two static list properties values, it would be very bad to have to
create a String from it first especially since you could have \n in
one of the elements.
My main concern is to expose a clear API and no String it everything
but clear, it's simple yes but it's not the same things. When you
provide String you don't have no idea what you are diffing exactly
(could be characters, \n, words, etc.) so having only one method with
two strings is just very bad design.
Also if you read my mail I did talked about String based APIs but as
helpers and I'm would be surely -1 for any attempt to restrict the
whole API to it. So the only question here is: is that really needed
to expose String based helpers or not.
No, I was never suggesting to drop the generic API, I was just saying that
the helpers might be a good idea since I imagine that String diff would
cover most of the usage of this API. Anyway, this is not important for now
since it is something that can be added later if API clients start
complaining :)
Thanks,
Eduard
----------
[1] https://github.com/xwiki/xwiki-commons/pull/2/files#r900063
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
Thanks,
Eduard
----------
[1] https://github.com/xwiki/xwiki-commons/pull/2/files#L27R58
On Wed, May 30, 2012 at 3:32 PM, Vincent Massol <vincent(a)massol.net>
wrote:
>
> On May 30, 2012, at 2:28 PM, Vincent Massol wrote:
>
> >
> > On May 30, 2012, at 2:18 PM, Eduard Moraru wrote:
> >
> >> Hi Thomas,
> >>
> >> On Tue, May 29, 2012 at 5:07 PM, Thomas Mortagne
> >> <thomas.mortagne(a)xwiki.com>wrote;wrote:
> >>
> >>> Hi devs,
> >>>
> >>> As I said in another mail I'm working on a diff/merge module to use
in
> >>> XWiki, the first target being
Extension Manager and document history
> >>> (since both are going to use the same code, see Marius mails).
> >>>
> >>> You can see the detail on
> https://github.com/xwiki/xwiki-commons/pull/2.
> >>>
> >>> TODO/QUESTIONS:
> >>> * improve the generic 3 ways merge to be at least as good as the
> >>> List<String> 3 ways merge and get rid of JDiff
> >>> * not sure where/if I should put String related helpers (things that
> >>> do a diff on two String instead of having to cut List<String> or
> >>> List<Character> and call the diff API etc.)
> >>>
> >>
> >> This looks a bit awkward to use, specially from (but not limited to)
> >> Velocity. When I think of a diff service API, I imagine passing
Strings,
> >> not lists of composing strings or
list of characters.
> >
> > Thomas is proposing a Java API here AFAIK. For Velocity we never
expose
> java API directly; we use Script Services
for that.
>
> Sorry, just realized you wrote "but not limited to" ;)
>
> I'll let Thomas reply since I don't know this diff api yet….
>
> Sorry for the noise
> -Vincent
>
> >
> > Thanks
> > -Vincent
> >
> > PS: FTR I'm a big -1 to model our Java APIs to be easily usable from
> Velocity since that means having suboptimal APIs for the wrong reason ;)
> >
> >> Also, I don`t quite understand the List<String> approach. I can
imagine
> the
> >> List<Character> version by breaking a string into characters, but
what
> >> would you do for List<String>?
You would split a String using "\s"
as a
> >> separator?
> >>
> >> Can you please mention a use case where a list oriented API is better
> than
> >> a string based one?
> >>
> >> Thanks,
> >> Eduard
> >>
> >>>
> >>> I'm ready to merge it into master so I'm waiting your vote.
> >>>
> >>> Caleb is it OK to put new stuff in master already or should I wait
the
>>> complete release to be done ?
>>>
>>> Here is my +1.
>>>
>>> Thanks,
>>> --
>>> Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4:50 p.m.
On Wed, May 30, 2012 at 5:29 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
On Wed, May 30, 2012 at 4:01 PM, Eduard Moraru
<enygma2002(a)gmail.com> wrote:
On Wed, May 30, 2012 at 4:16 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
On Wed, May 30, 2012 at 2:55 PM, Eduard Moraru
<enygma2002(a)gmail.com>
wrote:
Yes, I understand now how it works. If other are interested, please see my
new comment [1] on the pull request.
Short version: The API compares lists of objects by using Object#equals()
and does not go into the structure of the compared elements, just reports
differences of the list itself. You have to structure/break your input to
the level of granularity that you need for the diff to be relevant to your
use case.
I mentioned Velocity because I saw a
DiffScriptService component with
@Named("diff") that has the same method signature as the Java API:
public <E> DiffResult<E> diff(List<E> previous, List<E> next,
DiffConfiguration<E> configuration)
See the discussion [1] on the pull request for more details on the
Velocity
question.
Back to my original question (same question as Thomas basically), that's
exactly what I am trying to understand, Vincent... if the
List<String/Character> is the optimal use case and not just String.
Without a scenario in favour of List<E>, I would go for exposing a String
based API (well, just an extra method in this case) as well.
You can imagine all sort of use cases with any value so I don't see
the point in arbitrary limiting the API to just Strings where the
logic is the same whatever the type. If you really need a direct use
case for existing stuff then just think about producing a diff between
two static list properties values, it would be very bad to have to
create a String from it first especially since you could have \n in
one of the elements.
My main concern is to expose a clear API and no String it everything
but clear, it's simple yes but it's not the same things. When you
provide String you don't have no idea what you are diffing exactly
(could be characters, \n, words, etc.) so having only one method with
two strings is just very bad design.
Also if you read my mail I did talked about String based APIs but as
helpers and I'm would be surely -1 for any attempt to restrict the
whole API to it. So the only question here is: is that really needed
to expose String based helpers or not.
No, I was never suggesting to drop the generic API, I was just saying that
the helpers might be a good idea since I imagine that String diff would
cover most of the usage of this API. Anyway, this is not important for now
since it is something that can be added later if API clients start
complaining :) That's more or less what I was planning, I'm
waiting for my first
client report now, any news Marius ? ;)
Yes. Works great! I rewrote my display-oriented diff builders to use
the new API. I have 3 remarks about the code:
(1). The third parameter you pass to DiffManager when creating a diff,
DiffConfiguration, is a bit awkward. At first I though it was a class.
Then I looked for an implementation. Then I looked at the test and saw
that you pass null. I'm not convinced the configuration is very
useful. At least we could add a new signature without the
DiffConfiguration parameter. I'm thinking that we could remove it and
use instead a ConfigurationSource for global configuration.
(2) I don't understand what getCurrentMergeResult has to do with
MergeConfiguration. I haven't done any merge yet, I just saw this
method while looking for a diff configuration implementation and it
strike me.
(3) I think that getUnifiedDiff could be moved outside of DiffResult.
I haven't use it since I have my own display-oriented builders (to
help me display a diff), but I think it's too specific to be placed
inside the DiffResult interface.
Thanks,
Marius
Thanks,
Eduard
----------
[1] https://github.com/xwiki/xwiki-commons/pull/2/files#r900063
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Thanks,
Eduard
----------
[1] https://github.com/xwiki/xwiki-commons/pull/2/files#L27R58
On Wed, May 30, 2012 at 3:32 PM, Vincent Massol <vincent(a)massol.net>
wrote:
>
> On May 30, 2012, at 2:28 PM, Vincent Massol wrote:
>
> >
> > On May 30, 2012, at 2:18 PM, Eduard Moraru wrote:
> >
> >> Hi Thomas,
> >>
> >> On Tue, May 29, 2012 at 5:07 PM, Thomas Mortagne
> >> <thomas.mortagne(a)xwiki.com>wrote;wrote:
> >>
> >>> Hi devs,
> >>>
> >>> As I said in another mail I'm working on a diff/merge module to use
in
> >>> XWiki, the first target being
Extension Manager and document history
> >>> (since both are going to use the same code, see Marius mails).
> >>>
> >>> You can see the detail on
> https://github.com/xwiki/xwiki-commons/pull/2.
> >>>
> >>> TODO/QUESTIONS:
> >>> * improve the generic 3 ways merge to be at least as good as the
> >>> List<String> 3 ways merge and get rid of JDiff
> >>> * not sure where/if I should put String related helpers (things that
> >>> do a diff on two String instead of having to cut List<String> or
> >>> List<Character> and call the diff API etc.)
> >>>
> >>
> >> This looks a bit awkward to use, specially from (but not limited to)
> >> Velocity. When I think of a diff service API, I imagine passing
Strings,
> >> not lists of composing strings or
list of characters.
> >
> > Thomas is proposing a Java API here AFAIK. For Velocity we never
expose
> java API directly; we use Script Services
for that.
>
> Sorry, just realized you wrote "but not limited to" ;)
>
> I'll let Thomas reply since I don't know this diff api yet….
>
> Sorry for the noise
> -Vincent
>
> >
> > Thanks
> > -Vincent
> >
> > PS: FTR I'm a big -1 to model our Java APIs to be easily usable from
> Velocity since that means having suboptimal APIs for the wrong reason ;)
> >
> >> Also, I don`t quite understand the List<String> approach. I can
imagine
> the
> >> List<Character> version by breaking a string into characters, but
what
> >> would you do for List<String>?
You would split a String using "\s"
as a
> >> separator?
> >>
> >> Can you please mention a use case where a list oriented API is better
> than
> >> a string based one?
> >>
> >> Thanks,
> >> Eduard
> >>
> >>>
> >>> I'm ready to merge it into master so I'm waiting your vote.
> >>>
> >>> Caleb is it OK to put new stuff in master already or should I wait
the
> >>> complete release to be done ?
> >>>
> >>> Here is my +1.
> >>>
> >>> Thanks,
> >>> --
> >>> Thomas Mortagne
>
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5:09 p.m.
On Wed, May 30, 2012 at 4:50 PM, Marius Dumitru Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
On Wed, May 30, 2012 at 5:29 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
The DiffConfiguration and MergeConfiguration are more future stuff in
which I forgot to put generic map for at least custom setup even if
the current implementation does not really have much setup
possibilities. I have some ideas of things to put in
MergeConfiguration already (priority to current or next version in
case of conflict, etc.) but did not had time to implement them already
and DiffConfiguration is mostly here for consistency but I can remove
it. null is simply supported as "I don't have any configuration".
On Wed, May 30, 2012 at 4:01 PM, Eduard Moraru
<enygma2002(a)gmail.com> wrote:
On Wed, May 30, 2012 at 4:16 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
On Wed, May 30, 2012 at 2:55 PM, Eduard Moraru
<enygma2002(a)gmail.com>
wrote:
> I mentioned Velocity because I saw a DiffScriptService component with
> @Named("diff") that has the same method signature as the Java API:
>
> public <E> DiffResult<E> diff(List<E> previous, List<E>
next,
> DiffConfiguration<E> configuration)
>
> See the discussion [1] on the pull request for more details on the
Velocity
> question.
>
> Back to my original question (same question as Thomas basically), that's
> exactly what I am trying to understand, Vincent... if the
> List<String/Character> is the optimal use case and not just String.
>
> Without a scenario in favour of List<E>, I would go for exposing a String
> based API (well, just an extra method in this case) as well.
You can imagine all sort of use cases with any value so I don't see
the point in arbitrary limiting the API to just Strings where the
logic is the same whatever the type.
Yes, I understand now how it works. If other are interested, please see my
new comment [1] on the pull request.
Short version: The API compares lists of objects by using Object#equals()
and does not go into the structure of the compared elements, just reports
differences of the list itself. You have to structure/break your input to
the level of granularity that you need for the diff to be relevant to your
use case.
If you really need a direct use
case for existing stuff then just think about producing a diff between
two static list properties values, it would be very bad to have to
create a String from it first especially since you could have \n in
one of the elements.
My main concern is to expose a clear API and no String it everything
but clear, it's simple yes but it's not the same things. When you
provide String you don't have no idea what you are diffing exactly
(could be characters, \n, words, etc.) so having only one method with
two strings is just very bad design.
Also if you read my mail I did talked about String based APIs but as
helpers and I'm would be surely -1 for any attempt to restrict the
whole API to it. So the only question here is: is that really needed
to expose String based helpers or not.
No, I was never suggesting to drop the generic API, I was just saying that
the helpers might be a good idea since I imagine that String diff would
cover most of the usage of this API. Anyway, this is not important for now
since it is something that can be added later if API clients start
complaining :) That's more or less what I was planning,
I'm waiting for my first
client report now, any news Marius ? ;)
Yes. Works great! I rewrote my display-oriented diff builders to use
the new API. I have 3 remarks about the code:
(1). The third parameter you pass to DiffManager when creating a diff,
DiffConfiguration, is a bit awkward. At first I though it was a class.
Then I looked for an implementation. Then I looked at the test and saw
that you pass null. I'm not convinced the configuration is very
useful. At least we could add a new signature without the
DiffConfiguration parameter. I'm thinking that we could remove it and
use instead a ConfigurationSource for global configuration.
(2) I don't understand what getCurrentMergeResult has to do with
MergeConfiguration. I haven't done any merge yet, I just saw this
method while looking for a diff configuration implementation and it
strike me.
This was actually mostly to indicate to the implementation a kind of
top logqueue to update along with the current mergeresult. I forgot to
removed it since I planned to let the API client copy the log from the
returned merge result if needed intead.
(3) I think that getUnifiedDiff could be moved outside of DiffResult.
I haven't use it since I have my own display-oriented builders (to
help me display a diff), but I think it's too specific to be placed
inside the DiffResult interface.
It's not really specific IMO, it's just one way to represent a diff
between two versions. The idea is to provide a bunch of diff
representations in the DiffResult that the implementation is creating
the way it fit the best for it. We can imagine some library which
actually create a unified diff (JDiff do it that way for example) from
which you would create a lighter patch oriented diff.
Thanks,
Marius
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
Thanks,
Eduard
----------
[1] https://github.com/xwiki/xwiki-commons/pull/2/files#r900063
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs >
> Thanks,
> Eduard
>
> ----------
> [1] https://github.com/xwiki/xwiki-commons/pull/2/files#L27R58
>
> On Wed, May 30, 2012 at 3:32 PM, Vincent Massol <vincent(a)massol.net>
wrote:
>
>>
>> On May 30, 2012, at 2:28 PM, Vincent Massol wrote:
>>
>> >
>> > On May 30, 2012, at 2:18 PM, Eduard Moraru wrote:
>> >
>> >> Hi Thomas,
>> >>
>> >> On Tue, May 29, 2012 at 5:07 PM, Thomas Mortagne
>> >> <thomas.mortagne(a)xwiki.com>wrote;wrote:
>> >>
>> >>> Hi devs,
>> >>>
>> >>> As I said in another mail I'm working on a diff/merge module to
use
in
>> >>> XWiki, the first target being Extension Manager and document
history
>> >>> (since both are going to use the same code, see Marius mails).
>> >>>
>> >>> You can see the detail on
>> https://github.com/xwiki/xwiki-commons/pull/2.
>> >>>
>> >>> TODO/QUESTIONS:
>> >>> * improve the generic 3 ways merge to be at least as good as the
>> >>> List<String> 3 ways merge and get rid of JDiff
>> >>> * not sure where/if I should put String related helpers (things
that
>> >>> do a diff on two String instead of having to cut List<String>
or
>> >>> List<Character> and call the diff API etc.)
>> >>>
>> >>
>> >> This looks a bit awkward to use, specially from (but not limited to)
>> >> Velocity. When I think of a diff service API, I imagine passing
Strings,
>> >> not lists of composing strings or list of characters.
>> >
>> > Thomas is proposing a Java API here AFAIK. For Velocity we never
expose
>> java API directly; we use Script Services for that.
>>
>> Sorry, just realized you wrote "but not limited to" ;)
>>
>> I'll let Thomas reply since I don't know this diff api yet….
>>
>> Sorry for the noise
>> -Vincent
>>
>> >
>> > Thanks
>> > -Vincent
>> >
>> > PS: FTR I'm a big -1 to model our Java APIs to be easily usable from
>> Velocity since that means having suboptimal APIs for the wrong reason ;)
>> >
>> >> Also, I don`t quite understand the List<String> approach. I can
imagine
>> the
>> >> List<Character> version by breaking a string into characters,
but
what
>> >> would you do for List<String>? You would split a String using
"\s"
as a
>> >> separator?
>> >>
>> >> Can you please mention a use case where a list oriented API is better
>> than
>> >> a string based one?
>> >>
>> >> Thanks,
>> >> Eduard
>> >>
>> >>>
>> >>> I'm ready to merge it into master so I'm waiting your
vote.
>> >>>
>> >>> Caleb is it OK to put new stuff in master already or should I wait
the
>> >>> complete release to be done ?
>> >>>
>> >>> Here is my +1.
>> >>>
>> >>> Thanks,
>> >>> --
>> >>> Thomas Mortagne
>>
>> _______________________________________________
>> devs mailing list
>> devs(a)xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5:11 p.m.
On Wed, May 30, 2012 at 5:09 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
--
Thomas Mortagne
On Wed, May 30, 2012 at 4:50 PM, Marius Dumitru
Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
Actually thoses are not supposed to be interfaces. That's a mistake, I
skipped this part of your question.
On Wed, May 30, 2012 at 5:29 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
The DiffConfiguration and MergeConfiguration are more future stuff in
which I forgot to put generic map for at least custom setup even if
the current implementation does not really have much setup
possibilities. I have some ideas of things to put in
MergeConfiguration already (priority to current or next version in
case of conflict, etc.) but did not had time to implement them already
and DiffConfiguration is mostly here for consistency but I can remove
it. null is simply supported as "I don't have any configuration". On Wed, May 30, 2012 at 4:01 PM, Eduard Moraru
<enygma2002(a)gmail.com> wrote:
On Wed, May 30, 2012 at 4:16 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
> On Wed, May 30, 2012 at 2:55 PM, Eduard Moraru <enygma2002(a)gmail.com>
> wrote:
> > I mentioned Velocity because I saw a DiffScriptService component with
> > @Named("diff") that has the same method signature as the Java API:
> >
> > public <E> DiffResult<E> diff(List<E> previous, List<E>
next,
> > DiffConfiguration<E> configuration)
> >
> > See the discussion [1] on the pull request for more details on the
> Velocity
> > question.
> >
> > Back to my original question (same question as Thomas basically), that's
> > exactly what I am trying to understand, Vincent... if the
> > List<String/Character> is the optimal use case and not just String.
> >
> > Without a scenario in favour of List<E>, I would go for exposing a String
> > based API (well, just an extra method in this case) as well.
>
> You can imagine all sort of use cases with any value so I don't see
> the point in arbitrary limiting the API to just Strings where the
> logic is the same whatever the type.
Yes, I understand now how it works. If other are interested, please see my
new comment [1] on the pull request.
Short version: The API compares lists of objects by using Object#equals()
and does not go into the structure of the compared elements, just reports
differences of the list itself. You have to structure/break your input to
the level of granularity that you need for the diff to be relevant to your
use case.
> If you really need a direct use
> case for existing stuff then just think about producing a diff between
> two static list properties values, it would be very bad to have to
> create a String from it first especially since you could have \n in
> one of the elements.
>
> My main concern is to expose a clear API and no String it everything
> but clear, it's simple yes but it's not the same things. When you
> provide String you don't have no idea what you are diffing exactly
> (could be characters, \n, words, etc.) so having only one method with
> two strings is just very bad design.
>
> Also if you read my mail I did talked about String based APIs but as
> helpers and I'm would be surely -1 for any attempt to restrict the
> whole API to it. So the only question here is: is that really needed
> to expose String based helpers or not.
>
No, I was never suggesting to drop the generic API, I was just saying that
the helpers might be a good idea since I imagine that String diff would
cover most of the usage of this API. Anyway, this is not important for now
since it is something that can be added later if API clients start
complaining :)
That's more or less what I was planning,
I'm waiting for my first
client report now, any news Marius ? ;)
Yes. Works great! I rewrote my display-oriented diff builders to use
the new API. I have 3 remarks about the code:
(1). The third parameter you pass to DiffManager when creating a diff,
DiffConfiguration, is a bit awkward. At first I though it was a class.
Then I looked for an implementation. Then I looked at the test and saw
that you pass null. I'm not convinced the configuration is very
useful. At least we could add a new signature without the
DiffConfiguration parameter. I'm thinking that we could remove it and
use instead a ConfigurationSource for global configuration.
(2) I don't understand what getCurrentMergeResult has to do with
MergeConfiguration. I haven't done any merge yet, I just saw this
method while looking for a diff configuration implementation and it
strike me.
This was actually mostly to indicate to the implementation a kind of
top logqueue to update along with the current mergeresult. I forgot to
removed it since I planned to let the API client copy the log from the
returned merge result if needed intead.
(3) I think that getUnifiedDiff could be moved outside of DiffResult.
I haven't use it since I have my own display-oriented builders (to
help me display a diff), but I think it's too specific to be placed
inside the DiffResult interface.
It's not really specific IMO, it's just one way to represent a diff
between two versions. The idea is to provide a bunch of diff
representations in the DiffResult that the implementation is creating
the way it fit the best for it. We can imagine some library which
actually create a unified diff (JDiff do it that way for example) from
which you would create a lighter patch oriented diff.
Thanks,
Marius
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
Thanks,
Eduard
----------
[1] https://github.com/xwiki/xwiki-commons/pull/2/files#r900063
> >
> > Thanks,
> > Eduard
> >
> > ----------
> > [1] https://github.com/xwiki/xwiki-commons/pull/2/files#L27R58
> >
> > On Wed, May 30, 2012 at 3:32 PM, Vincent Massol <vincent(a)massol.net>
> wrote:
> >
> >>
> >> On May 30, 2012, at 2:28 PM, Vincent Massol wrote:
> >>
> >> >
> >> > On May 30, 2012, at 2:18 PM, Eduard Moraru wrote:
> >> >
> >> >> Hi Thomas,
> >> >>
> >> >> On Tue, May 29, 2012 at 5:07 PM, Thomas Mortagne
> >> >> <thomas.mortagne(a)xwiki.com>wrote;wrote:
> >> >>
> >> >>> Hi devs,
> >> >>>
> >> >>> As I said in another mail I'm working on a diff/merge
module to use
> in
> >> >>> XWiki, the first target being Extension Manager and document
history
> >> >>> (since both are going to use the same code, see Marius mails).
> >> >>>
> >> >>> You can see the detail on
> >> https://github.com/xwiki/xwiki-commons/pull/2.
> >> >>>
> >> >>> TODO/QUESTIONS:
> >> >>> * improve the generic 3 ways merge to be at least as good as
the
> >> >>> List<String> 3 ways merge and get rid of JDiff
> >> >>> * not sure where/if I should put String related helpers (things
that
> >> >>> do a diff on two String instead of having to cut
List<String> or
> >> >>> List<Character> and call the diff API etc.)
> >> >>>
> >> >>
> >> >> This looks a bit awkward to use, specially from (but not limited
to)
> >> >> Velocity. When I think of a diff service API, I imagine passing
> Strings,
> >> >> not lists of composing strings or list of characters.
> >> >
> >> > Thomas is proposing a Java API here AFAIK. For Velocity we never
> expose
> >> java API directly; we use Script Services for that.
> >>
> >> Sorry, just realized you wrote "but not limited to" ;)
> >>
> >> I'll let Thomas reply since I don't know this diff api yet….
> >>
> >> Sorry for the noise
> >> -Vincent
> >>
> >> >
> >> > Thanks
> >> > -Vincent
> >> >
> >> > PS: FTR I'm a big -1 to model our Java APIs to be easily usable
from
> >> Velocity since that means having suboptimal APIs for the wrong reason ;)
> >> >
> >> >> Also, I don`t quite understand the List<String> approach. I
can
> imagine
> >> the
> >> >> List<Character> version by breaking a string into characters,
but
> what
> >> >> would you do for List<String>? You would split a String using
"\s"
> as a
> >> >> separator?
> >> >>
> >> >> Can you please mention a use case where a list oriented API is
better
> >> than
> >> >> a string based one?
> >> >>
> >> >> Thanks,
> >> >> Eduard
> >> >>
> >> >>>
> >> >>> I'm ready to merge it into master so I'm waiting your
vote.
> >> >>>
> >> >>> Caleb is it OK to put new stuff in master already or should I
wait
> the
> >> >>> complete release to be done ?
> >> >>>
> >> >>> Here is my +1.
> >> >>>
> >> >>> Thanks,
> >> >>> --
> >> >>> Thomas Mortagne
> >>
> >> _______________________________________________
> >> devs mailing list
> >> devs(a)xwiki.org
> >> http://lists.xwiki.org/mailman/listinfo/devs
> >>
> > _______________________________________________
> > devs mailing list
> > devs(a)xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
>
>
>
> --
> Thomas Mortagne
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3:32 p.m.
On Tue, May 29, 2012 at 4:07 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
Hi devs,
As I said in another mail I'm working on a diff/merge module to use in
XWiki, the first target being Extension Manager and document history
(since both are going to use the same code, see Marius mails).
You can see the detail on https://github.com/xwiki/xwiki-commons/pull/2.
TODO/QUESTIONS:
* improve the generic 3 ways merge to be at least as good as the
List<String> 3 ways merge and get rid of JDiff
Done.
* not sure where/if I should put String related
helpers (things that
do a diff on two String instead of having to cut List<String> or
List<Character> and call the diff API etc.)
I'm ready to merge it into master so I'm waiting your vote.
Caleb is it OK to put new stuff in master already or should I wait the
complete release to be done ?
Here is my +1.
Thanks,
--
Thomas Mortagne
--
Thomas Mortagne
3:40 p.m.
On 05/29/2012 10:07 AM, Thomas Mortagne wrote:
Hi devs,
As I said in another mail I'm working on a diff/merge module to use in
XWiki, the first target being Extension Manager and document history
(since both are going to use the same code, see Marius mails).
You can see the detail on https://github.com/xwiki/xwiki-commons/pull/2.
TODO/QUESTIONS:
* improve the generic 3 ways merge to be at least as good as the
List<String> 3 ways merge and get rid of JDiff
* not sure where/if I should put String related helpers (things that
do a diff on two String instead of having to cut List<String> or
List<Character> and call the diff API etc.)
I'm ready to merge it into master so I'm waiting your vote.
Caleb is it OK to put new stuff in master already or should I wait the
complete release to be done ?
I'd rather the build be as stable as possible for M2, if you need it then you
don't need my permission :)
Caleb
Here is my +1.
Thanks,
3:48 p.m.
On Wed, May 30, 2012 at 3:40 PM, Caleb James DeLisle
<calebdelisle(a)lavabit.com> wrote:
On 05/29/2012 10:07 AM, Thomas Mortagne wrote:
It's not require to have it in M2, it's just a timing question. I
don't mind merging it after your green light.
Hi devs,
As I said in another mail I'm working on a diff/merge module to use in
XWiki, the first target being Extension Manager and document history
(since both are going to use the same code, see Marius mails).
You can see the detail on https://github.com/xwiki/xwiki-commons/pull/2.
TODO/QUESTIONS:
* improve the generic 3 ways merge to be at least as good as the
List<String> 3 ways merge and get rid of JDiff
* not sure where/if I should put String related helpers (things that
do a diff on two String instead of having to cut List<String> or
List<Character> and call the diff API etc.)
I'm ready to merge it into master so I'm waiting your vote.
Caleb is it OK to put new stuff in master already or should I wait the
complete release to be done ?
I'd rather the build be as stable as possible for M2, if you need it then you
don't need my permission :)
Caleb
--
Thomas Mortagne
Here is my +1.
Thanks,
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5:29 p.m.
On 05/30/2012 09:48 AM, Thomas Mortagne wrote:
On Wed, May 30, 2012 at 3:40 PM, Caleb James DeLisle
<calebdelisle(a)lavabit.com> wrote:
Thanks, just looked over the code and +1 to it for me.
I am curious as to why you chose to make the TYPE enum all caps rather than Type.
It seems more natural to use Type.CHANGE rather than TYPE.CHANGE to me.
Anyway +1 for me either way.
Caleb
On 05/29/2012 10:07 AM, Thomas Mortagne wrote:
It's not require to have it in M2, it's just a timing question. I
don't mind merging it after your green light. Hi devs,
As I said in another mail I'm working on a diff/merge module to use in
XWiki, the first target being Extension Manager and document history
(since both are going to use the same code, see Marius mails).
You can see the detail on https://github.com/xwiki/xwiki-commons/pull/2.
TODO/QUESTIONS:
* improve the generic 3 ways merge to be at least as good as the
List<String> 3 ways merge and get rid of JDiff
* not sure where/if I should put String related helpers (things that
do a diff on two String instead of having to cut List<String> or
List<Character> and call the diff API etc.)
I'm ready to merge it into master so I'm waiting your vote.
Caleb is it OK to put new stuff in master already or should I wait the
complete release to be done ?
I'd rather the build be as stable as possible for M2, if you need it then you
don't need my permission :)
Caleb
Here is my +1.
Thanks,
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5:32 p.m.
On Wed, May 30, 2012 at 5:29 PM, Caleb James DeLisle
<calebdelisle(a)lavabit.com> wrote:
On 05/30/2012 09:48 AM, Thomas Mortagne wrote:
You are right, that's what I would do generally. This is actually a
quick copy past from diff-utils API. I will fix it.
On Wed, May 30, 2012 at 3:40 PM, Caleb James
DeLisle
<calebdelisle(a)lavabit.com> wrote:
Thanks, just looked over the code and +1 to it for me.
I am curious as to why you chose to make the TYPE enum all caps rather than Type.
It seems more natural to use Type.CHANGE rather than TYPE.CHANGE to me.
On 05/29/2012 10:07 AM, Thomas Mortagne wrote:
It's not require to have it in M2, it's just a timing question. I
don't mind merging it after your green light. Hi devs,
As I said in another mail I'm working on a diff/merge module to use in
XWiki, the first target being Extension Manager and document history
(since both are going to use the same code, see Marius mails).
You can see the detail on https://github.com/xwiki/xwiki-commons/pull/2.
TODO/QUESTIONS:
* improve the generic 3 ways merge to be at least as good as the
List<String> 3 ways merge and get rid of JDiff
* not sure where/if I should put String related helpers (things that
do a diff on two String instead of having to cut List<String> or
List<Character> and call the diff API etc.)
I'm ready to merge it into master so I'm waiting your vote.
Caleb is it OK to put new stuff in master already or should I wait the
complete release to be done ?
I'd rather the build be as stable as possible for M2, if you need it then you
don't need my permission :) Anyway +1 for me either way.
Caleb
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
Caleb
Here is my +1.
Thanks,
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
31 May
31 May
3:31 p.m.
5 +1 and no other vote, lets merge it.
On Tue, May 29, 2012 at 4:07 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
Hi devs,
As I said in another mail I'm working on a diff/merge module to use in
XWiki, the first target being Extension Manager and document history
(since both are going to use the same code, see Marius mails).
You can see the detail on https://github.com/xwiki/xwiki-commons/pull/2.
TODO/QUESTIONS:
* improve the generic 3 ways merge to be at least as good as the
List<String> 3 ways merge and get rid of JDiff
* not sure where/if I should put String related helpers (things that
do a diff on two String instead of having to cut List<String> or
List<Character> and call the diff API etc.)
I'm ready to merge it into master so I'm waiting your vote.
Caleb is it OK to put new stuff in master already or should I wait the
complete release to be done ?
Here is my +1.
Thanks,
--
Thomas Mortagne
--
Thomas Mortagne
4544
days inactive
4546
days old
19 comments
5 participants
participants (5)
-
Caleb James DeLisle -
Eduard Moraru -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol