xmlunit-general — Everything XMLUnit ;0)

Re: [Xmlunit-general] Wiki documentation

[Harald B. <bra...@gm...>]

Hi,

are there some problems to merge the changes? from
https://github.com/brabenetz/user-guide/wiki
to
https://github.com/xmlunit/user-guide/wiki

Should I change something first?

thanks,
Harald


> Gesendet: Freitag, 24. Juli 2015 um 16:54 Uhr
> Von: "Stefan Bodewig" <bo...@ap...>
> An: xml...@li...
> Cc: "Harald Brabenetz" <bra...@gm...>
> Betreff: Re: [Xmlunit-general]  Wiki documentation
>
> On 2015-07-24, Harald Brabenetz wrote:
> 
> > sorry for my long absence.
> 
> I'm glad you are here.
> 
> > I added a description for Java Hamcrest CompareMatcher, ComparisonFormatter, DifferenceEvaluator, NodeMatcher, ComparisionListener and DiffBuilder:
> > https://github.com/brabenetz/user-guide/wiki
> 
> > For the InputBuilder I tried also to describe the .NET part.
> > But honestly I have no clue about the .NET part :)
> > https://github.com/brabenetz/user-guide/wiki/Providing-Input-to-XMLUnit#inputbuilder
> 
> > I edited the pages locally as Git-Repository (I believe this is the only way to add Screen-shots correctly)
> > But there is no nice "Pull-Request"-Button for the GIT-Wiki:
> > https://github.com/brabenetz/user-guide.wiki.git
> 
> Not only that, it is also not possible to receive notifications of
> changes to wikis.  This is a bummer, to be honest.
> 
> > Can you merge it? Is this workflow ok for you?
> 
> Yes, please go ahead.
> 
> Many thanks
> 
>      Stefan
> 

Re: [Xmlunit-general] Wiki documentation

[Stefan B. <bo...@ap...>]

On 2015-07-24, Harald Brabenetz wrote:

> sorry for my long absence.

I'm glad you are here.

> I added a description for Java Hamcrest CompareMatcher, ComparisonFormatter, DifferenceEvaluator, NodeMatcher, ComparisionListener and DiffBuilder:
> https://github.com/brabenetz/user-guide/wiki

> For the InputBuilder I tried also to describe the .NET part.
> But honestly I have no clue about the .NET part :)
> https://github.com/brabenetz/user-guide/wiki/Providing-Input-to-XMLUnit#inputbuilder

> I edited the pages locally as Git-Repository (I believe this is the only way to add Screen-shots correctly)
> But there is no nice "Pull-Request"-Button for the GIT-Wiki:
> https://github.com/brabenetz/user-guide.wiki.git

Not only that, it is also not possible to receive notifications of
changes to wikis.  This is a bummer, to be honest.

> Can you merge it? Is this workflow ok for you?

Yes, please go ahead.

Many thanks

     Stefan

[Xmlunit-general] Wiki documentation

[Harald B. <bra...@gm...>]

Hi,

sorry for my long absence.

I added a description for Java Hamcrest CompareMatcher, ComparisonFormatter, DifferenceEvaluator, NodeMatcher, ComparisionListener and DiffBuilder:
https://github.com/brabenetz/user-guide/wiki

For the InputBuilder I tried also to describe the .NET part.
But honestly I have no clue about the .NET part :)
https://github.com/brabenetz/user-guide/wiki/Providing-Input-to-XMLUnit#inputbuilder

I edited the pages locally as Git-Repository (I believe this is the only way to add Screen-shots correctly)
But there is no nice "Pull-Request"-Button for the GIT-Wiki:
https://github.com/brabenetz/user-guide.wiki.git

Can you merge it? Is this workflow ok for you?

Sorry for my pure English.
I'm sure there are many English 'bugs' to correct, but at least the code examples should be fine.
Hope it helps.

with friendly regards,
Harald

[Xmlunit-general] Changing ElementSelector interface

[Stefan B. <bo...@ap...>]

Hi all

I'm still experimenting with ways to make it easier to write (or
combine) custom ElementSelectors.  It occured to me it might be useful
for an ElementSelector to not only know the Elements it is supposed to
evaluate but also their position inside the respective documents.  In
the branch https://github.com/xmlunit/xmlunit/tree/two-arg-element-selector
I've modified the signature to be

    boolean canBeCompared(Element controlElement, XPathContext controlXPath,
                              Element testElement, XPathContext testXPath);

which also meant I had to modify NodeMatcher's interface.  The branch
still isn't complete - ElementSelectors#byXPath doesn't properly
provide the XPathContexts for the NodeMatcher it uses internally - but
close enough to ask for comments now.  Unless anything significant
happens, I should be able to complete the branch today.

Is this a good idea or am I just adding complexity without gaining too
much?  Any feedback is more than welcome

Cheers

        Stefan

[In case you've been following along: I cherry-picked some refactorings
from and then rebased the branch, sorry for the noise.]

Re: [Xmlunit-general] Advanced ElementSelectors

[Stefan B. <bo...@ap...>]

On 2015-02-10, Stefan Bodewig wrote:

> I can also see some nice builder syntax forming

> ElementSelector es = Builder
>     .whenElementIsNamed("foo").thenUse(byNameAndText)
>     .whenElementIsNamed("bar").thenUse(byNameAndAttributes("id"))
>     .otherwise(byName)
>     .build();

I've used defaultTo rather than otherwise, but this is now available
- most of it in
https://github.com/xmlunit/xmlunit/commit/eed0b2a6f2b16d54668990daabcd9513999df93c

> To get rid of RecursiveElementNameAndTextQualifier this is not enough,

...

> Taking
> http://stackoverflow.com/questions/23752354/xmlunit-recursiveelementnameandtextqualifier-not-working
> as example one could use something like

>     byXPath(".//a", byNameAndText)

> and apply that to "td" and "tr" elements.

https://github.com/xmlunit/xmlunit/commit/b6c24bf33f205676839bfce6fa8db59d089cf43c

> But I'm not sure this really is easy enough to understand and I'm afraid
> it would become repetitive.  So a better idea is more than welcome.

> Also ElementSelector only receives Elements as context, therefore the
> big brother of selectorForElementNamed - conditionalSelector - works
> with a Predicate<Element> to see whether it should apply.  This may be
> cumbersome and I can easily see problems where the element name is not
> enough and I need to know where the element is, something like the
> XPathContext would be helpful.  This might require a change to the
> ElementSelector and likely the NodeMatcher APIs.  Any ideas?

I'd still be thankful for any kind of feedback.

Stefan

Re: [Xmlunit-general] Comparison.getControlDetails().getTarget()

[Stefan B. <bo...@ap...>]

On 2015-02-28, Harald Brabenetz wrote:

> I made the changes:
> https://github.com/brabenetz/xmlunit/commit/3f824ef2b7cb348efea76b85d3d5a35da7fe8550

> If the DOMDifferenceEngine is the one and only implementation, then I
> think embrace DOM as part of XMLUnit's diff API is fine,

> But if there is another implementation then DOMDifferenceEngine
> planned, then it's maybe (depends on the other implementations) better
> to reject the changes.

Somewhere in the back of my head is the idea of a pull model based
DifferencEngine that would need to sacrifice certain features (most
importantly it could only match nodes in order so we'd lose the whole
ElementSelector business) but would be way more memory efficient for big
documents.  DOM really is a memory hog on both platforms we support.

For .NET constructing XmlNodes for the state of an XmlReader would be
easy, for Java we'd be burdened by providing our own implementations of
the DOM interfaces on top of StAX.  Not a big deal, but still something
that had to be done.

OTOH I'm not convinced said "stream" DifferenceEngine would be used
much.  After all most people - at least those who report problems with
XMLUnit - seem to be using ElementQualifiers (now ElementSelectors) of
some sort in order to deal with permutations of elements.

Stefan

[Xmlunit-general] Comparison.getControlDetails().getTarget()

[Harald B. <bra...@gm...>]

Hi,

I made the changes: 
https://github.com/brabenetz/xmlunit/commit/3f824ef2b7cb348efea76b85d3d5a35da7fe8550

If the DOMDifferenceEngine is the one and only implementation, then I think embrace DOM as part of XMLUnit's diff API is fine,

But if there is another implementation then DOMDifferenceEngine planned, then it's maybe (depends on the other implementations) better to reject the changes. 

with friendly regards,

Harald


> Gesendet: Sonntag, 15. Februar 2015 um 19:51 Uhr
> Von: "Stefan Bodewig" <bo...@ap...>
> An: "Harald Brabenetz" <bra...@gm...>
> Cc: xml...@li...
> Betreff: Re: [Xmlunit-general] ComparisonControllers.StopWhenSimilar
>
> ...
>
> > But one Question:
> > Why is the return type of "Comparison.getControlDetails().getTarget()" an Object?
> > Is there any case where the return Object is not a org.w3c.dom.Node?
> 
> This is likely part of the somewhat ambiguos API in the diff package.
> Parts of it try to abstract from DOM, other parts are tied to it.  If we
> agreed to embrace DOM as part of XMLUnit's diff API, then we may as well
> switch to Node here.
> 
> Stefan
> 

Re: [Xmlunit-general] Updated Snapshots?

[Stefan B. <bo...@ap...>]

On 2015-02-23, Will Herrmann wrote:

> XMLUnit.org says that snapshots are available here
> <https://oss.sonatype.org/content/repositories/snapshots/org/xmlunit/>, but
> it doesn't look like they have been updated since February 9th.

I update them manually, yes.  I don't really feel like providing my
sonatype credentials to a CI server.  Actually I've done so about the
same time you asked for it :-)

Stefan

[Xmlunit-general] Updated Snapshots?

[Will H. <wjh...@gm...>]

XMLUnit.org says that snapshots are available here
<https://oss.sonatype.org/content/repositories/snapshots/org/xmlunit/>, but
it doesn't look like they have been updated since February 9th. Is this
something that needs to be manually triggered? Or is there somewhere else
that I can get a more recent snapshot?

Thanks,
-Will Herrmann

[Xmlunit-general] Anyone built XMLUnit.NET on Windows so far?

[Stefan B. <bo...@ap...>]

Hi all

just started my VM and tried to build XMLUnit.NET - I had to adapt a few
things so the compiler of 3.5 is willing to build our sources (and had
to remove ISet).

Still I'm getting 18 test failures I don't see on Mono - all of them in
DefaultComparisonFormatterTest, so it looks as if there is was a bug
hidden or a difference between .NET's and Mono's XML stack is showing
through.  Before I dig deeper, has anybody else seen this?

Stefan

Re: [Xmlunit-general] NuGet and Build issues

[Joe H. <joe...@gm...>]

Agreed. Opened issue #4 to covert this (
https://github.com/xmlunit/xmlunit.net/issues/4)

J

On Sat, Feb 21, 2015 at 4:54 PM, Will Herrmann <wjh...@gm...> wrote:

> >>> As for the nuspec content, I'm not sure about the authors and owners
> >>> elements, it seems authors is required.  I'm sure I'd forget to update
> >>> that line after accepting PRs.  Can we use "XMLUnit contributors" as
> >>> authors or is this frowned upon?
> >
> >> I'm not sure but I'm happy to change it.
> >
> > I'd prefer to not put names in there.  It may be just me and maybe
> > others who have contributed feel differently.
>
>
> I think that I too would prefer to not put names in there, partly for
> privacy but also because if multiple people wind up working on that aspect,
> the list might get very long. It just seems more practical for an open
> source project to say "XMLUnit contributors" and be done with it.
>
> -Will Herrmann
>
> On Feb 21, 2015, at 3:29 PM, Stefan Bodewig <bo...@ap...> wrote:
>
> > On 2015-02-21, Joe Hayes wrote:
> >
> >> On Sat, Feb 21, 2015 at 11:35 AM, Stefan Bodewig <bo...@ap...>
> wrote:
> >
> >
> >>> Note pack currently doesn't work on Linux, even after changing exec to
> >>> invoke mono explicitly:
> >
> >>>     [exec] Attempting to build package from 'xmlunit.nuspec'.
> >>>     [exec] File not found: 'build\net\bin\xmlunit-core.dll'.
> >
> >>> the file is there, using forward slashes, of course.  I guess it is the
> >>> file element in the nuspec file but didn't dare to change it to forward
> >>> slashes.  Looking through the nuget issue tracker "pack" seems to have
> >>> other problems as well, so I'll have to resort to a Windows VM.
> >
> >
> >> I'll get a linux VM with mono up and running so I can be aware of these
> >> issues before I send a pull request! :-)
> >
> > Thanks.  It is not the most important thing, since said "Windows VM"
> > actually exists.
> >
> >>> As for the nuspec content, I'm not sure about the authors and owners
> >>> elements, it seems authors is required.  I'm sure I'd forget to update
> >>> that line after accepting PRs.  Can we use "XMLUnit contributors" as
> >>> authors or is this frowned upon?
> >
> >> I'm not sure but I'm happy to change it.
> >
> > I'd prefer to not put names in there.  It may be just me and maybe
> > others who have contributed feel differently.
> >
> >>>> Some additional build/NuGet related TODOs (which I'm happy to work
> on):
> >>>>   - create an additional nuspec for the constraints assembly
> >>>>   - create a symbols package (
> >
> >>> https://docs.nuget.org/create/creating-and-publishing-a-symbol-package
> )
> >
> >>> does this include publishing the sources?
> >
> >> It can but I do not believed it is required. Do you have a preference?
> >
> > Include them, please.
> >
> >>>>   - adopt semantic version-ing for .NET build
> >
> >>> We are already publishing XMLUnit for Java SNAPSHOT builds (whenever I
> >>> feel like it, not automatically).  For nuget packages something like
> >>> 2.0.0-alpha-01 would likely be a good initial version.
> >
> >> Sounds good.
> >
> >>>>   - .NET framework targeting
> >
> >>> are we missing anything?
> >
> >> We should explicitly set the target framework in the NAnt build script
> (by
> >> default, it uses the framework on which it is running) and change the
> >> nuspec file accordingly.
> >
> > I see.  I've tried to keep it at .NET 3.5 compatibility right now,
> > basically requiring LINQ.
> >
> >> I can add these issues to the XmlUnit.NET GitHub issue tracker unless
> you
> >> have another preference.
> >
> > Sounds good.
> >
> >       Stefan
> >
> >
> ------------------------------------------------------------------------------
> > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> > from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> > with Interactivity, Sharing, Native Excel Exports, App Integration & more
> > Get technology previously reserved for billion-dollar corporations, FREE
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Xmlunit-general mailing list
> > Xml...@li...
> > https://lists.sourceforge.net/lists/listinfo/xmlunit-general
>
>

Re: [Xmlunit-general] NuGet and Build issues

[Will H. <wjh...@gm...>]

>>> As for the nuspec content, I'm not sure about the authors and owners
>>> elements, it seems authors is required.  I'm sure I'd forget to update
>>> that line after accepting PRs.  Can we use "XMLUnit contributors" as
>>> authors or is this frowned upon?
> 
>> I'm not sure but I'm happy to change it.
> 
> I'd prefer to not put names in there.  It may be just me and maybe
> others who have contributed feel differently.


I think that I too would prefer to not put names in there, partly for privacy but also because if multiple people wind up working on that aspect, the list might get very long. It just seems more practical for an open source project to say "XMLUnit contributors" and be done with it.

-Will Herrmann

On Feb 21, 2015, at 3:29 PM, Stefan Bodewig <bo...@ap...> wrote:

> On 2015-02-21, Joe Hayes wrote:
> 
>> On Sat, Feb 21, 2015 at 11:35 AM, Stefan Bodewig <bo...@ap...> wrote:
> 
> 
>>> Note pack currently doesn't work on Linux, even after changing exec to
>>> invoke mono explicitly:
> 
>>>     [exec] Attempting to build package from 'xmlunit.nuspec'.
>>>     [exec] File not found: 'build\net\bin\xmlunit-core.dll'.
> 
>>> the file is there, using forward slashes, of course.  I guess it is the
>>> file element in the nuspec file but didn't dare to change it to forward
>>> slashes.  Looking through the nuget issue tracker "pack" seems to have
>>> other problems as well, so I'll have to resort to a Windows VM.
> 
> 
>> I'll get a linux VM with mono up and running so I can be aware of these
>> issues before I send a pull request! :-)
> 
> Thanks.  It is not the most important thing, since said "Windows VM"
> actually exists.
> 
>>> As for the nuspec content, I'm not sure about the authors and owners
>>> elements, it seems authors is required.  I'm sure I'd forget to update
>>> that line after accepting PRs.  Can we use "XMLUnit contributors" as
>>> authors or is this frowned upon?
> 
>> I'm not sure but I'm happy to change it.
> 
> I'd prefer to not put names in there.  It may be just me and maybe
> others who have contributed feel differently.
> 
>>>> Some additional build/NuGet related TODOs (which I'm happy to work on):
>>>>   - create an additional nuspec for the constraints assembly
>>>>   - create a symbols package (
> 
>>> https://docs.nuget.org/create/creating-and-publishing-a-symbol-package)
> 
>>> does this include publishing the sources?
> 
>> It can but I do not believed it is required. Do you have a preference?
> 
> Include them, please.
> 
>>>>   - adopt semantic version-ing for .NET build
> 
>>> We are already publishing XMLUnit for Java SNAPSHOT builds (whenever I
>>> feel like it, not automatically).  For nuget packages something like
>>> 2.0.0-alpha-01 would likely be a good initial version.
> 
>> Sounds good.
> 
>>>>   - .NET framework targeting
> 
>>> are we missing anything?
> 
>> We should explicitly set the target framework in the NAnt build script (by
>> default, it uses the framework on which it is running) and change the
>> nuspec file accordingly.
> 
> I see.  I've tried to keep it at .NET 3.5 compatibility right now,
> basically requiring LINQ.
> 
>> I can add these issues to the XmlUnit.NET GitHub issue tracker unless you
>> have another preference.
> 
> Sounds good.
> 
>       Stefan
> 
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Xmlunit-general mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlunit-general

Re: [Xmlunit-general] NuGet and Build issues

[Stefan B. <bo...@ap...>]

On 2015-02-21, Joe Hayes wrote:

> On Sat, Feb 21, 2015 at 11:35 AM, Stefan Bodewig <bo...@ap...> wrote:


>> Note pack currently doesn't work on Linux, even after changing exec to
>> invoke mono explicitly:

>>      [exec] Attempting to build package from 'xmlunit.nuspec'.
>>      [exec] File not found: 'build\net\bin\xmlunit-core.dll'.

>> the file is there, using forward slashes, of course.  I guess it is the
>> file element in the nuspec file but didn't dare to change it to forward
>> slashes.  Looking through the nuget issue tracker "pack" seems to have
>> other problems as well, so I'll have to resort to a Windows VM.


> I'll get a linux VM with mono up and running so I can be aware of these
> issues before I send a pull request! :-)

Thanks.  It is not the most important thing, since said "Windows VM"
actually exists.

>> As for the nuspec content, I'm not sure about the authors and owners
>> elements, it seems authors is required.  I'm sure I'd forget to update
>> that line after accepting PRs.  Can we use "XMLUnit contributors" as
>> authors or is this frowned upon?

> I'm not sure but I'm happy to change it.

I'd prefer to not put names in there.  It may be just me and maybe
others who have contributed feel differently.

>>> Some additional build/NuGet related TODOs (which I'm happy to work on):
>>>    - create an additional nuspec for the constraints assembly
>>>    - create a symbols package (

>> https://docs.nuget.org/create/creating-and-publishing-a-symbol-package)

>> does this include publishing the sources?

> It can but I do not believed it is required. Do you have a preference?

Include them, please.

>>>    - adopt semantic version-ing for .NET build

>> We are already publishing XMLUnit for Java SNAPSHOT builds (whenever I
>> feel like it, not automatically).  For nuget packages something like
>> 2.0.0-alpha-01 would likely be a good initial version.

> Sounds good.

>>>    - .NET framework targeting

>> are we missing anything?

> We should explicitly set the target framework in the NAnt build script (by
> default, it uses the framework on which it is running) and change the
> nuspec file accordingly.

I see.  I've tried to keep it at .NET 3.5 compatibility right now,
basically requiring LINQ.

> I can add these issues to the XmlUnit.NET GitHub issue tracker unless you
> have another preference.

Sounds good.

       Stefan

Re: [Xmlunit-general] NuGet and Build issues

[Joe H. <joe...@gm...>]

On Sat, Feb 21, 2015 at 11:35 AM, Stefan Bodewig <bo...@ap...> wrote:

>
> Note pack currently doesn't work on Linux, even after changing exec to
> invoke mono explicitly:
>
>      [exec] Attempting to build package from 'xmlunit.nuspec'.
>      [exec] File not found: 'build\net\bin\xmlunit-core.dll'.
>
> the file is there, using forward slashes, of course.  I guess it is the
> file element in the nuspec file but didn't dare to change it to forward
> slashes.  Looking through the nuget issue tracker "pack" seems to have
> other problems as well, so I'll have to resort to a Windows VM.
>
>
I'll get a linux VM with mono up and running so I can be aware of these
issues before I send a pull request! :-)


> As for the nuspec content, I'm not sure about the authors and owners
> elements, it seems authors is required.  I'm sure I'd forget to update
> that line after accepting PRs.  Can we use "XMLUnit contributors" as
> authors or is this frowned upon?
>
>
I'm not sure but I'm happy to change it.


> > Some additional build/NuGet related TODOs (which I'm happy to work on):
> >    - create an additional nuspec for the constraints assembly
> >    - create a symbols package (
> >
> https://docs.nuget.org/create/creating-and-publishing-a-symbol-package)
>
> does this include publishing the sources?
>

It can but I do not believed it is required. Do you have a preference?


> >    - adopt semantic version-ing for .NET build
>
> We are already publishing XMLUnit for Java SNAPSHOT builds (whenever I
> feel like it, not automatically).  For nuget packages something like
> 2.0.0-alpha-01 would likely be a good initial version.
>

Sounds good.


>
> >    - .NET framework targeting
>
> are we missing anything?
>
>
We should explicitly set the target framework in the NAnt build script (by
default, it uses the framework on which it is running) and change the
nuspec file accordingly.


> >    - port build from NAnt to xBuild / MSBuild (a project file that can
> also
> >    support IDEs)
>
>
I can add these issues to the XmlUnit.NET GitHub issue tracker unless you
have another preference.

J

Re: [Xmlunit-general] Adding toString() for Comparison

[Stefan B. <bo...@ap...>]

No, I don't think I've seen that pattern used in the wild.

If we wanted a singleton we could put it into
DefaultComparisonFormatter.

Thanks

        Stefan

On 2015-02-21, Will Herrmann wrote:

> I'm not sure that I've ever seen that design pattern before; having a public static final variable of a concrete implementation within an interface. There's the benefit of being a singleton to be sure, but it just seems like an odd construct to me especially since core Java never uses it. If we want to go that route, I think I'd prefer a static method (c.f. java.lang.Charset.defaultCharset()). Then again, interfaces can't have implementations.

> Thanks,
> -Will Herrmann

> On Feb 19, 2015, at 5:54 AM, Stefan Bodewig <bo...@ap...> wrote:

>> On 2015-02-18, Will Herrmann wrote:

>>> I finally got a chance to make this change. I created a pull request for
>>> GitHub.

>> Many thanks.

>>> I'm still new to open source stuff, so let me know if I missed
>>> something about the procedure.

>> All is fine.

>> Harald's original ComparisonFormatter proposal had a static final
>> ComparisonFormatter field (DEFAULT, I think) which contained a
>> DefaultComparisonFormatter - ah, yes -
>> https://github.com/xmlunit/xmlunit/commit/e457399addf2db7d399e2d06d07064d3bee5ca03#diff-417caeda82b46db9f1bafca5765b3ff4R26

>> I later removed it because I thought only Diff would need it.  With your
>> change maybe it is time to bring it back and use it from Difference and
>> Comparison as well?

>> Stefan


> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Xmlunit-general mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlunit-general

Re: [Xmlunit-general] Adding toString() for Comparison

[Will H. <wjh...@gm...>]

I'm not sure that I've ever seen that design pattern before; having a public static final variable of a concrete implementation within an interface. There's the benefit of being a singleton to be sure, but it just seems like an odd construct to me especially since core Java never uses it. If we want to go that route, I think I'd prefer a static method (c.f. java.lang.Charset.defaultCharset()). Then again, interfaces can't have implementations. 

Thanks,
-Will Herrmann

On Feb 19, 2015, at 5:54 AM, Stefan Bodewig <bo...@ap...> wrote:

> On 2015-02-18, Will Herrmann wrote:
> 
>> I finally got a chance to make this change. I created a pull request for
>> GitHub.
> 
> Many thanks.
> 
>> I'm still new to open source stuff, so let me know if I missed
>> something about the procedure.
> 
> All is fine.
> 
> Harald's original ComparisonFormatter proposal had a static final
> ComparisonFormatter field (DEFAULT, I think) which contained a
> DefaultComparisonFormatter - ah, yes -
> https://github.com/xmlunit/xmlunit/commit/e457399addf2db7d399e2d06d07064d3bee5ca03#diff-417caeda82b46db9f1bafca5765b3ff4R26
> 
> I later removed it because I thought only Diff would need it.  With your
> change maybe it is time to bring it back and use it from Difference and
> Comparison as well?
> 
> Stefan

Re: [Xmlunit-general] NuGet and Build issues

[Stefan B. <bo...@ap...>]

On 2015-02-21, Joe Hayes wrote:

> My name is Joe Hayes and I've just joined the list.

welcome Joe.

> Recently Stefan kindly accepted my pull request for creating and publishing
> XmlUnit.NET NuGet packages.

Note pack currently doesn't work on Linux, even after changing exec to
invoke mono explicitly:

     [exec] Attempting to build package from 'xmlunit.nuspec'.
     [exec] File not found: 'build\net\bin\xmlunit-core.dll'.

the file is there, using forward slashes, of course.  I guess it is the
file element in the nuspec file but didn't dare to change it to forward
slashes.  Looking through the nuget issue tracker "pack" seems to have
other problems as well, so I'll have to resort to a Windows VM.

As for the nuspec content, I'm not sure about the authors and owners
elements, it seems authors is required.  I'm sure I'd forget to update
that line after accepting PRs.  Can we use "XMLUnit contributors" as
authors or is this frowned upon?

> Some additional build/NuGet related TODOs (which I'm happy to work on):
>    - create an additional nuspec for the constraints assembly
>    - create a symbols package (
>    https://docs.nuget.org/create/creating-and-publishing-a-symbol-package)

does this include publishing the sources?

>    - adopt semantic version-ing for .NET build

We are already publishing XMLUnit for Java SNAPSHOT builds (whenever I
feel like it, not automatically).  For nuget packages something like
2.0.0-alpha-01 would likely be a good initial version.

>    - .NET framework targeting

are we missing anything?

>    - port build from NAnt to xBuild / MSBuild (a project file that can also
>    support IDEs)

Your help is very much appreciated.

Cheers

        Stefan

[Xmlunit-general] NuGet and Build issues

[Joe H. <joe...@gm...>]

Hi,

My name is Joe Hayes and I've just joined the list.

Recently Stefan kindly accepted my pull request for creating and publishing
XmlUnit.NET NuGet packages.

Some additional build/NuGet related TODOs (which I'm happy to work on):


   - create an additional nuspec for the constraints assembly
   - create a symbols package (
   https://docs.nuget.org/create/creating-and-publishing-a-symbol-package)
   - adopt semantic version-ing for .NET build
   - .NET framework targeting
   - port build from NAnt to xBuild / MSBuild (a project file that can also
   support IDEs)


Best,

Joe Hayes

Re: [Xmlunit-general] Suggestion to Rename Input.fromMemory()

[Stefan B. <bo...@ap...>]

On 2015-02-21, Will Herrmann wrote:

> In the Input class, we have a number of methods such as the following (with
> their Javadoc):

> - fromChannel(ReadableByteChannel c): Build a Source from a channel.
> - fromFile(File f): Build a Source from a file.
> - fromJaxb(Object jaxbObject): Build a Source from a Jaxb-Object.
> - fromURI(URI uri): Build a Source from an URI.

> These are all intuitive enough. Their names match the name of the class
> that they take as input. And then we have these two:

> - fromMemory(byte[] b): Build a Source from an array of bytes.
> - fromMemory(String s): Build a Source from a string.

> Unlike all of the other methods, the names of these two do not match the
> names of the classes that they take as inputs. This is rather unintuitive
> and I've seen it cause problems "in the field".

Oh, that never occured to me.  I don't see any problem with renaming
them.  Of course we'd need to adjust code internally but we are still in
alpha so breaking things is totally fine.

While we are talking about names (and I'm notoriously bad at naming), I
think I posted this one:
https://sourceforge.net/p/xmlunit/mailman/message/33305879/

Cheers

        Stefan

[Xmlunit-general] Suggestion to Rename Input.fromMemory()

[Will H. <wjh...@gm...>]

In the Input class, we have a number of methods such as the following (with
their Javadoc):

- fromChannel(ReadableByteChannel c): Build a Source from a channel.
- fromFile(File f): Build a Source from a file.
- fromJaxb(Object jaxbObject): Build a Source from a Jaxb-Object.
- fromURI(URI uri): Build a Source from an URI.

These are all intuitive enough. Their names match the name of the class
that they take as input. And then we have these two:

- fromMemory(byte[] b): Build a Source from an array of bytes.
- fromMemory(String s): Build a Source from a string.

Unlike all of the other methods, the names of these two do not match the
names of the classes that they take as inputs. This is rather unintuitive
and I've seen it cause problems "in the field". My coworker was frustrated
that there was no Input.fromString() method and wound up doing a workaround
by writing the string to the file system and then doing Input.fromFile().
It never occurred to him to look at fromMemory()

I would like to suggest that we rename these methods to
fromByteArray(byte[] b) and fromString(String s) respectively. This will
make the names more intuitive by matching the name of the input class and
being consistent with the other methods in this class.

I realize that this may have implications elsewhere, so if others agree,
I'll go ahead and make the changes and create a pull request for it. I'm
guessing that I would need to deprecate the old methods while I'm at it?

Thanks,
-Will Herrmann

Re: [Xmlunit-general] Adding toString() for Comparison

[Stefan B. <bo...@ap...>]

On 2015-02-18, Will Herrmann wrote:

> I finally got a chance to make this change. I created a pull request for
> GitHub.

Many thanks.

> I'm still new to open source stuff, so let me know if I missed
> something about the procedure.

All is fine.

Harald's original ComparisonFormatter proposal had a static final
ComparisonFormatter field (DEFAULT, I think) which contained a
DefaultComparisonFormatter - ah, yes -
https://github.com/xmlunit/xmlunit/commit/e457399addf2db7d399e2d06d07064d3bee5ca03#diff-417caeda82b46db9f1bafca5765b3ff4R26

I later removed it because I thought only Diff would need it.  With your
change maybe it is time to bring it back and use it from Difference and
Comparison as well?

Stefan

Re: [Xmlunit-general] CompareMatcher (was Re: ComparisonControllers.StopWhenSimilar)

[Stefan B. <bo...@ap...>]

On 2015-02-17, Harald Brabenetz wrote:

> I found a third and better way:
> I will wrap instead extend the CompareMatcher.
> So the constructor of CompareMatcher can be leaved private and non-extendable:
> https://github.com/brabenetz/xmlunit/commit/642cd29b34494da1f444ea47ce546957b07cb4e2

> At least for XmlUnit it's much cleaner.

+1

Thanks

        Stefan

Re: [Xmlunit-general] Adding toString() for Comparison

[Will H. <wjh...@gm...>]

I finally got a chance to make this change. I created a pull request for
GitHub. I'm still new to open source stuff, so let me know if I missed
something about the procedure.

-Will Herrmann

On Wed, Feb 11, 2015 at 11:08 PM, Stefan Bodewig <bo...@ap...> wrote:

> Hi Will
>
> On 2015-02-11, Will Herrmann wrote:
>
> > Stefan had suggested delegating the creation of the toString() to
> > ComparisonFormatter and it looks like DefaultComparisonFormatter would
> > do the trick and be pretty simple to implement. Would this be an
> > acceptable solution?
>
> Yes, it would.  Maybe do something similar to Diff with a toString
> overload that accepts a ComparisonFormatter.  It would probably be a
> good idea to take care of the Difference class at the same time.
>
> Cheers
>
>         Stefan
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Xmlunit-general mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlunit-general
>

Re: [Xmlunit-general] CompareMatcher (was Re: ComparisonControllers.StopWhenSimilar)

[Harald B. <bra...@gm...>]

Hi,
I found a third and better way:
I will wrap instead extend the CompareMatcher.
So the constructor of CompareMatcher can be leaved private and non-extendable:
https://github.com/brabenetz/xmlunit/commit/642cd29b34494da1f444ea47ce546957b07cb4e2

At least for XmlUnit it's much cleaner.

with friendly regards,
Harald


> Gesendet: Montag, 16. Februar 2015 um 12:52 Uhr
> Von: "Stefan Bodewig" <bo...@ap...>
> An: "Harald Brabenetz" <bra...@gm...>
> Cc: xml...@li...
> Betreff: CompareMatcher (was Re: ComparisonControllers.StopWhenSimilar)
>
> On 2015-02-16, Harald Brabenetz wrote:
> 
> > I would like to make the CompareMatcher extendable.  This means that
> > the constructor and two methods must be protected instead private.
> 
> The two protected methods would be the checkFor methods?  You need those
> so you can have your own factory methods, AFAIU.  If this was the only
> usecase they could be final.
> 
> > This example is basically what I do with the Matcher on my current
> > Project: I write the test-Input into the FileSystem, where I can
> > manual review it.  And when the changes are OK I can simply overwrite
> > my control-File with the written Test-File.
> 
> You are cheating ;-)
> 
> > On the other hand it is more difficult to maintain a Class which can
> > be extended.
> 
> A protected constructor will signal "this class is extension friendly"
> so we better review its API and implementation to see whether this
> really is the case.  Other than that, I don't see any issue.
> 
> Stefan
> 

[Xmlunit-general] CompareMatcher (was Re: ComparisonControllers.StopWhenSimilar)

[Stefan B. <bo...@ap...>]

On 2015-02-16, Harald Brabenetz wrote:

> I would like to make the CompareMatcher extendable.  This means that
> the constructor and two methods must be protected instead private.

The two protected methods would be the checkFor methods?  You need those
so you can have your own factory methods, AFAIU.  If this was the only
usecase they could be final.

> This example is basically what I do with the Matcher on my current
> Project: I write the test-Input into the FileSystem, where I can
> manual review it.  And when the changes are OK I can simply overwrite
> my control-File with the written Test-File.

You are cheating ;-)

> On the other hand it is more difficult to maintain a Class which can
> be extended.

A protected constructor will signal "this class is extension friendly"
so we better review its API and implementation to see whether this
really is the case.  Other than that, I don't see any issue.

Stefan