xmlunit-general — Everything XMLUnit ;0)

Re: [Xmlunit-general] xmlunit.org

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

Hi,

for better Explanations, here are my checkins:

All changes for implementing DiffBuilder and ComparisonFormatter so far:
https://github.com/brabenetz/xmlunit/commit/f4408ea23eca8afaff28b5b11dfea6bc67735f4e

"DifferenceEvaluators.sequence(...)" (I has updated the DifferenceEvaluatorsTest in the next commit):
https://github.com/brabenetz/xmlunit/commit/cd88ac571d72582451a59f21b7a8cdffbff8b903

DiffBuilder.withDifferenceEvaluators(...) and withDifferenceEvaluators.deactivateDefaultDifferenceEvaluator():
https://github.com/brabenetz/xmlunit/commit/f05706c13a4d4a19602857b052971bb865f5ae06

Let me know what you think,
I will merge all you want together for a single push request.

with friendly regards,
Harald


> Gesendet: Samstag, 17. Januar 2015 um 00:27 Uhr
> Von: "Harald Brabenetz" <bra...@gm...>
> An: "Stefan Bodewig" <bo...@ap...>, xml...@li...
> Betreff: Re: [Xmlunit-general] xmlunit.org
>
> 
> Hi,
> 
> I have a few questions about the DifferenceEvaluators:
> 
> >> But I think that one DifferenceEvaluator is not enough.
> >> At least DifferenceEvaluators.Default should always be part of,
> >> otherwise there is no ComparisonResult.SIMILAR.
> >
> >IMHO this is something the user of the API should take care of. If they
> >want to have DEFAULT's behaviour then they should include it explicitly.
> >
> You think, that the code should look like the following?:
> ----------
> Diff myDiff = DiffBuilder.compare(control).withTest(test)
> 		.withDifferenceEvaluator(DifferenceEvaluators.first(
> 			DifferenceEvaluators.Default,
> 			new IgnoreAttributeDifferenceEvaluator("attr")))
> 		.checkForSimilar()
> 		.build();
> ----------
> I think "checkForSimilar" will be the preferred method to compare two XMLs.
> But checkForSimilar() makes no sense without "DifferenceEvaluators.Default".
> On the other site I can't think of a situation where the "DifferenceEvaluators.Default" must be ignored to get a special goal?
>   Even this rare cases could simply be handled with a method ".deactivateDefaultDifferenceEvaluator()"
> 
> I checked in the UnitTest:
> https://github.com/brabenetz/xmlunit/commit/4a8e5eb676809344a6dbaf814289a6495db80728
> 
> >> But then I need a method like DifferenceEvaluators.inSequence(...)
> >> instead of DifferenceEvaluators.first(...).
> >
> >first() picks the first that changes the outcome, what would be the
> >result of inSequence()?
> >
> Simply passes the result to the next evaluator.
> Reason: The custom DifferenceEvaluator should also be triggered (e.g.: for Ignore) even if a Node was marked as "similar" before.
> 		And maybe the custom DifferenceEvaluator want to check if the Difference was "similar".
> 
> 
> >> I also think about a general SimpleIgnoreNodesDifferenceEvaluator
> >> (ignore some nodes) or a SimpleBigDecimalNodesDifferenceEvaluator
> >> (which evaluates "1" similar "1.00") implementations.
> >
> >The first one hints at the missing feature of ignoring parts completely.
> >I don't think DifferenceEvaluator is the best place for this. The
> >second one sounds like a third jar of xmlunit-library rather than -core?
> >
> Yes, it could be a third jar of xmlunit-library.
> What you mean with "DifferenceEvaluator is not the best place for this"? Is there another way?
> 
> 
> Thanks,
> Harald
> 
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> Xmlunit-general mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlunit-general
> 

Re: [Xmlunit-general] xmlunit.org

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

Hi,

I have a few questions about the DifferenceEvaluators:

>> But I think that one DifferenceEvaluator is not enough.
>> At least DifferenceEvaluators.Default should always be part of,
>> otherwise there is no ComparisonResult.SIMILAR.
>
>IMHO this is something the user of the API should take care of. If they
>want to have DEFAULT's behaviour then they should include it explicitly.
>
You think, that the code should look like the following?:
----------
Diff myDiff = DiffBuilder.compare(control).withTest(test)
		.withDifferenceEvaluator(DifferenceEvaluators.first(
			DifferenceEvaluators.Default,
			new IgnoreAttributeDifferenceEvaluator("attr")))
		.checkForSimilar()
		.build();
----------
I think "checkForSimilar" will be the preferred method to compare two XMLs.
But checkForSimilar() makes no sense without "DifferenceEvaluators.Default".
On the other site I can't think of a situation where the "DifferenceEvaluators.Default" must be ignored to get a special goal?
  Even this rare cases could simply be handled with a method ".deactivateDefaultDifferenceEvaluator()"

I checked in the UnitTest:
https://github.com/brabenetz/xmlunit/commit/4a8e5eb676809344a6dbaf814289a6495db80728

>> But then I need a method like DifferenceEvaluators.inSequence(...)
>> instead of DifferenceEvaluators.first(...).
>
>first() picks the first that changes the outcome, what would be the
>result of inSequence()?
>
Simply passes the result to the next evaluator.
Reason: The custom DifferenceEvaluator should also be triggered (e.g.: for Ignore) even if a Node was marked as "similar" before.
		And maybe the custom DifferenceEvaluator want to check if the Difference was "similar".


>> I also think about a general SimpleIgnoreNodesDifferenceEvaluator
>> (ignore some nodes) or a SimpleBigDecimalNodesDifferenceEvaluator
>> (which evaluates "1" similar "1.00") implementations.
>
>The first one hints at the missing feature of ignoring parts completely.
>I don't think DifferenceEvaluator is the best place for this. The
>second one sounds like a third jar of xmlunit-library rather than -core?
>
Yes, it could be a third jar of xmlunit-library.
What you mean with "DifferenceEvaluator is not the best place for this"? Is there another way?


Thanks,
Harald

Re: [Xmlunit-general] Build Using Maven

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

On 2015-01-10, Harald Brabenetz wrote:

> Looks great!

merged into master now.

> I only don't understand the SystemProperty "testresourcebasedir"
> ("test_Constants.java" line 48):

This is set inside the surefire configuration on legacy's pom.  Yes,
this may go away once I'm satisfied with the way test resources are
shared.

> The "mvn javadoc:aggregate" command already generates an overall
> Javadoc into "target/site/apidocs".

Ah, thanks, I'll have a look.

Cheers

        Stefan

Re: [Xmlunit-general] Build Using Maven

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

Looks great!

I only don't understand the SystemProperty "testresourcebasedir" ("test_Constants.java" line 48):
    public static final String BASEDIR = System.getProperty("testresourcebasedir");
My IDE doesn't have this Property per Default. I would simply hard code it:
    public static final String BASEDIR = new File("..").getAbsolutePath();
But I think you have some plans with this property according to the shared test-resources with .NET you mentioned.

The "mvn javadoc:aggregate" command already generates an overall Javadoc into "target/site/apidocs".
http://maven.apache.org/plugins/maven-javadoc-plugin/examples/aggregate.html#Using_The_aggregate_Goals

with friendly regards,
Harald

> Gesendet: Samstag, 10. Januar 2015 um 14:59 Uhr
> Von: "Stefan Bodewig" <bo...@ap...>
> An: xml...@li...
> Betreff: [Xmlunit-general] Build Using Maven
>
> Hi all
> 
> the maven branch[1] now builds using Maven.  It is a combination of
> Harald's branch and ideas of my own based on Sonatype's parent.  I've
> uploaded 2.0.0-SNAPSHOTs to [2] in order to verify the build.
> 
> Right now the Travis build fails (for Java6 and 7, not for 8) inside the
> legacy tests, I'll need to look into that.  I also want to add the
> "sumo" jar of the Ant build and need some way to create the overall
> javadocs.  And finally I want to extract the test resources in order to
> share them between Java and .NET (which is in a repo of its own by now).
> 
> But before I wade in even further, I'd appreciate any feedback.
> 
> Cheers
> 
>         Stefan
> 
> [1] https://github.com/xmlunit/xmlunit/tree/maven
> [2] https://oss.sonatype.org/content/repositories/snapshots/org/xmlunit/
> 
> ------------------------------------------------------------------------------
> 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
> 

[Xmlunit-general] Build Using Maven

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

Hi all

the maven branch[1] now builds using Maven.  It is a combination of
Harald's branch and ideas of my own based on Sonatype's parent.  I've
uploaded 2.0.0-SNAPSHOTs to [2] in order to verify the build.

Right now the Travis build fails (for Java6 and 7, not for 8) inside the
legacy tests, I'll need to look into that.  I also want to add the
"sumo" jar of the Ant build and need some way to create the overall
javadocs.  And finally I want to extract the test resources in order to
share them between Java and .NET (which is in a repo of its own by now).

But before I wade in even further, I'd appreciate any feedback.

Cheers

        Stefan

[1] https://github.com/xmlunit/xmlunit/tree/maven
[2] https://oss.sonatype.org/content/repositories/snapshots/org/xmlunit/

Re: [Xmlunit-general] xmlunit.org

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

On 2015-01-06, Harald Brabenetz wrote:

>> Is all of the JAXB builder in the single commit
>> https://github.com/brabenetz/xmlunit/commit/54923ce18be30aa340792a1e53dd420ff5e44a8a

> Not everything. e.g.: JavaDoc and Input.fromUnknown returns a Source instead of a Builder.
> I will create a separate branch "XmlUnit_2.x_ready_to_push".

The best workflow is to create one branch per feature you want to
contribute and create a pull request from that.  After review you'd
rebase the branch to a single commit (squash it) and I'll merge that
commit.

Of course this is cumbersome if you are working on several
interdependent things at once and it may not always be possible, so
we'll have to adjust.

I prefer to have you make changes over me picking commits and modifying
them as it will be easier for you to rebase your branches once the PR is
merged this way.  Also it will show you as the contributor more clearly.

I hope this is not feeling like I was playing "fetch me a rock" with
you, I very much appreciate your work and your patience.  Thanks!

>> It is also inside the patch that introduced the JAXBBuilder. I
>> understand the idea, maybe just "from" would be a better name - and I'd
>> rather use a Map that a chain of instanceofs.
> I'm not sure if "instanceof" can be handled by a Map.

The idea in Java8 code

static Map<Class<?>, Function<?, Builder>>  KNOWN_BUILDERS ...
static {
    KNOWN_BUILDER.put(URI.class, u -> Input.fromUri((Uri) u));
}

Builder from(Object source) {
    Function<?, Builder> f = KNOWN_BUILDERS.get(source.getClass());
    return f == null ? f.apply(source) : fromJaxb(source);
}

of course the target is Java 1.6 so the "functions" will be anonymous
inner classes and the static block will look ugly.

>> One problem I see is how to interpret a String arg - you've decided to
>> use fromMemory but fromFile or fromUri would also be legitimate choices.
> It's only a simple short-cut. Certainly, you can always use a
> Source/Builderby e.g.: Input.fromUri("...").

You could try to be smart and guess whether the String is an XML
document (starts with a "<") or looks like an URI.  I'm not sure it
would be worth the effort, though.

> I would more like to write:
> 	DiffBuilder.compare(control).withTest(test);
> then
> 	DiffBuilder.compare(Input.fromSomething(control)).withTest(Input.fromSomething(test));

> I think that was the only indention for Input.fromUnknown(...) :)
> And there are no disadvantages. You can always use a Source or
> Input.Builder as input.

Likely depends on how much you do with the "Source" in the rest of your
tests, but I get your point.

>> The IDE visualization is certainly nice. An approach that might work is
>> having an optional dependency and a fallback solution if
>> ComparisonFailure is not there (like not throwing that exception and
>> return false from matches).
> I could create the ComparisonFailure by reflections only if it exists.
> Then, not even the build-script to compile main/java-matcher will need
> the dependency.

We'd better cache the reflection result in order to save runtime cost,
though.  Yes, that would be alternative to an optional dependency.

>> * Comparison is not good enough to capture a difference as the
>> ComparisonResult is missing. So Diff should use a (new) class
>> containing Comparison and outcome.

> Yep, e.g. a "Difference.java" with Comparison and ComparisonResult as
> members.
> My second thought was: ComparisonResult will be per default CRITICAL
> (required for break up after first difference)

I may want to look at the "SIMILAR" differences anyway?  Or I may want
to get all differences like 1.x's DetailedDiff.

>> * I'd likely remove Diff#getFirstDifference completely

> But how? I need the first Difference to create a nice
> Exception-Message (or in Diff.toString())

differences.get(0) in toString?  It just doesn't need to be public.

> But I think that one DifferenceEvaluator is not enough.
> At least DifferenceEvaluators.Default should always be part of,
> otherweise there is no ComparisonResult.SIMILAR.

IMHO this is something the user of the API should take care of.  If they
want to have DEFAULT's behavior then they should include it explicitly.

> But then I need a method like DifferenceEvaluators.inSequence(...)
> instead of DifferenceEvaluators.first(...).

first() picks the first that changes the outcome, what would be the
result of inSequence()?

> I also think about a general SimpleIgnoreNodesDifferenceEvaluator
> (ignore some nodes) or a SimpleBigDecimalNodesDifferenceEvaluator
> (which evaluates "1" similar "1.00") implementations.

The first one hints at the missing feature of ignoring parts completely.
I don't think DifferenceEvaluator is the best place for this.  The
second one sounds like a third jar of xmlunit-library rather than -core?

>> * my design would have ComparisonMatcher be a Matcher<Diff> and force
>> people to create the Diff using DiffBuilder
>> Diff diffResult = DiffBuilder...
>> assertThat(diffResult, DiffMatcher.isSimilar());
>> that way we didn't have to duplicate ignoreWhitespace and friends in
>> two or three builders.
>> Maybe have a DiffMatcher and a ComparisonMatcher as separate classes

> This feels not right: In this case the Matcher doesn't make the
> matching.

true

>> with ComparisonMatcher being Matcher<Source>?
>> This would also reduce the need for Input.fromUnknown.

> Yes, would be no Problem, but it would made my tests a little bit
> uglier :)

understood.

>  - I will crate a branch "XmlUnit_2.x_ready_to_push" with only the
>  Input.fromJaxb(...). Later I will copy my other changes into this
>  branch.

Since I'll merge your JAXB branch as soon as you open a pull request you
better create a new branch for the rest ;-)

>  - Input.fromUnknown(): I can rename or remove it. Let me know.

I'm not completely against including it.  Others?

>  - Create the ComparisonFailure by reflections if it exists (remove junit-dependency).
>  - Create "Difference.java" with Comparison and ComparisonResult as members.
>  - Create Diff.toString(ComparisonFormatter);
>  - Diff.getDifferences() returns Iterator<Difference>
>  - Add DiffBuilder.withDifferenceListeners(DifferenceListener...);
>  - DiffBuilder.allDifferences(): default is DifferenceEvaluators.stopAt(...) depending on checkFirstSimilar() or checkForIdentical()
>  - Move DiffBuilder into builder package

Thanks.

> But it could take a while. From now on, I have only time on weekends.
> The most of it I can do at the upcoming weekend.

I'm not sure about my time constraints either, this is just your normal
"I do work I find time for it and want to do so" pattern of open source.
Don't feel obligated to do anything, this is supposed to be fun.

As next steps I want to add a bit of javadocs and publish them from the
xmlunit.org website and after that start migrating things (i.e. the Java
part) to Maven.

Stefan

Re: [Xmlunit-general] xmlunit.org

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

Hi,

thanks for the quick review.

> I understand. In general I'd prefer finer grained PRs (even squashed to
> a single commit) as they are easier to review but I understand this is a
> problem to ask for them after the fact.
> Is all of the JAXB builder in the single commit
> https://github.com/brabenetz/xmlunit/commit/54923ce18be30aa340792a1e53dd420ff5e44a8a

Not everything. e.g.: JavaDoc and Input.fromUnknown returns a Source instead of a Builder.
I will create a separate branch "XmlUnit_2.x_ready_to_push".

> It is also inside the patch that introduced the JAXBBuilder. I
> understand the idea, maybe just "from" would be a better name - and I'd
> rather use a Map that a chain of instanceofs.
I'm not sure if "instanceof" can be handled by a Map.

> One problem I see is how to interpret a String arg - you've decided to
> use fromMemory but fromFile or fromUri would also be legitimate choices.
It's only a simple short-cut. Certainly, you can always use a Source/Builder by e.g.: Input.fromUri("...").

> I guess I need to review the DiffBuilder stuff to understand how you
> intend to use it. Usually people will know what builder method they
> want to invoke :-)
Sure I know the input, but it makes my tests ugly :)
I would more like to write:
	DiffBuilder.compare(control).withTest(test);
then
	DiffBuilder.compare(Input.fromSomething(control)).withTest(Input.fromSomething(test));

I think that was the only indention for Input.fromUnknown(...) :)
And there are no disadvantages. You can always use a Source or Input.Builder as input.

> The IDE visualization is certainly nice. An approach that might work is
> having an optional dependency and a fallback solution if
> ComparisonFailure is not there (like not throwing that exception and
> return false from matches).
I could create the ComparisonFailure by reflections only if it exists.
Then, not even the build-script to compile main/java-matcher will need the dependency.


> * Comparison is not good enough to capture a difference as the
> ComparisonResult is missing. So Diff should use a (new) class
> containing Comparison and outcome.
Yep, e.g. a "Difference.java" with Comparison and ComparisonResult as members.
My second thought was: ComparisonResult will be per default CRITICAL (required for break up after first difference)

> * I hadn't thought of ComparisonFormatter but your IDE example is an
> intriguing one. My choice would be to have a toString method with a
> ComparisonFormatter argument rather than an instance variable. The
> no-arg toString would always use the default fomatter and
> ComparisonMatcher could pass in a different one when needed.
looks great

> * nit-pick I'd use Iterable rather than List as return value
No problem.

> * I'd likely remove Diff#getFirstDifference completely
But how? I need the first Difference to create a nice Exception-Message (or in Diff.toString())

> * there can only be one DifferenceEvaluator, so the var-args versions
> are not needed - we may want to have a var-args
> withDifferenceListeners in DiffBuilder
withDifferenceListeners(): I forgot about that.

I have not tested withDifferenceEvaluator() well enough.
But I think that one DifferenceEvaluator is not enough.
At least DifferenceEvaluators.Default should always be part of, otherweise there is no ComparisonResult.SIMILAR.
But then I need a method like DifferenceEvaluators.inSequence(...) instead of DifferenceEvaluators.first(...).

I also think about a general SimpleIgnoreNodesDifferenceEvaluator (ignore some nodes)
or a SimpleBigDecimalNodesDifferenceEvaluator (which evaluates "1" similar "1.00") implementations.

> * DiffBuilder may want an option to short-cut the comparison as soon as
> the outcome is clear. I.e. return CRITICAL from the
> DifferenceEvaluator as soon as a DIFFERNT (or potentially a SIMILAR)
> result has been received.
Like DifferenceEvaluators.stopWhenDifferent(...) but more like:
DifferenceEvaluators.stopAt(ComparisonResult)
=> DiffBuilder.allDifferences(): return all differences (like now). Default is DifferenceEvaluators.stopAt(...) depending on checkFirstSimilar() or checkForIdentical()

> * my design would have ComparisonMatcher be a Matcher<Diff> and force
> people to create the Diff using DiffBuilder
> Diff diffResult = DiffBuilder...
> assertThat(diffResult, DiffMatcher.isSimilar());
> that way we didn't have to duplicate ignoreWhitespace and friends in
> two or three builders.
> Maybe have a DiffMatcher and a ComparisonMatcher as separate classes
This feels not right: In this case the Matcher doesn't make the matching.
A normal Matcher always contains the control Object to matching with.
I'm not sure if "CompareMatcher extends DiffBuilder" makes sense only to avoid the delegate methods,
but it could be a possibility.


> with ComparisonMatcher being Matcher<Source>?
> This would also reduce the need for Input.fromUnknown.
Yes, would be no Problem, but it would made my tests a little bit uglier :)

> * DiffBuilder should be in the builder package
Thanks.

---------------------
Summary
---------------------
 - I will crate a branch "XmlUnit_2.x_ready_to_push" with only the Input.fromJaxb(...). Later I will copy my other changes into this branch.
 - Input.fromUnknown(): I can rename or remove it. Let me know.
 - Create the ComparisonFailure by reflections if it exists (remove junit-dependency).
 - Create "Difference.java" with Comparison and ComparisonResult as members.
 - Create Diff.toString(ComparisonFormatter);
 - Diff.getDifferences() returns Iterator<Difference>
 - Add DiffBuilder.withDifferenceListeners(DifferenceListener...);
 - DiffBuilder.allDifferences(): default is DifferenceEvaluators.stopAt(...) depending on checkFirstSimilar() or checkForIdentical()
 - Move DiffBuilder into builder package

But it could take a while. From now on, I have only time on weekends.
The most of it I can do at the upcoming weekend.

Cheers
Harald

Re: [Xmlunit-general] xmlunit.org

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

On 2015-01-05, Stefan Bodewig wrote:

>> -------------
>> Diff & DiffBuilder.
>> -------------
>> I'm now finished with Diff & DiffBuilder.

> I'll try to have a look and provide feedback soon.

What I had in mind is slightly different, but not much.  Let me explain
what I would have done differently and we can then figure out together
what seems to be the best.

* Comparison is not good enough to capture a difference as the
  ComparisonResult is missing.  So Diff should use a (new) class
  containing Comparison and outcome.
* I hadn't thought of ComparisonFormatter but your IDE example is an
  intriguing one.  My choice would be to have a toString method with a
  ComparisonFormatter argument rather than an instance variable.  The
  no-arg toString would always use the default fomatter and
  ComparisonMatcher could pass in a different one when needed.
* nit-pick I'd use Iterable rather than List as return value
* I'd likely remove Diff#getFirstDifference completely
* there can only be one DifferenceEvaluator, so the var-args versions
  are not needed - we may want to have a var-args
  withDifferenceListeners in DiffBuilder
* DiffBuilder may want an option to short-cut the comparison as soon as
  the outcome is clear.  I.e. return CRITICAL from the
  DifferenceEvaluator as soon as a DIFFERNT (or potentially a SIMILAR)
  result has been received.
* my design would have ComparisonMatcher be a Matcher<Diff> and force
  people to create the Diff using DiffBuilder

  Diff diffResult = DiffBuilder...
  assertThat(diffResult, DiffMatcher.isSimilar());

  that way we didn't have to duplicate ignoreWhitespace and friends in
  two or three builders.
  Maybe have a DiffMatcher and a ComparisonMatcher as separate classes
  with ComparisonMatcher being Matcher<Source>?
  This would also reduce the need for Input.fromUnknown.
* DiffBuilder should be in the builder package

While writing this list I've come to realize the DifferenceEvaluator
contract is probably wrong.  In order to short-cut a comparison it has
to modify the comparison result.  This likely means we need something
akin to ComparisonController of 1.x.  WDYT?

Stefan

Re: [Xmlunit-general] xmlunit.org

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

On 2015-01-05, Harald Brabenetz wrote:

>>> Also I implemented the Method Input.fromJaxb(Object) ....
>> Ah, nice catch.  Could you create a separate pull request just for the
>> missing JAXBSource part?
> difficult: I must create a separate branch and checkin the different
> features.

I understand.  In general I'd prefer finer grained PRs (even squashed to
a single commit) as they are easier to review but I understand this is a
problem to ask for them after the fact.

Is all of the JAXB builder in the single commit

https://github.com/brabenetz/xmlunit/commit/54923ce18be30aa340792a1e53dd420ff5e44a8a

if so, I can easily pick just this one.

>>> Input.fromUnknown(Object)
> It is in my branch:
> https://github.com/brabenetz/xmlunit/blob/master/src/main/java-core/org/xmlunit/builder/Input.java#L109

It is also inside the patch that introduced the JAXBBuilder.  I
understand the idea, maybe just "from" would be a better name - and I'd
rather use a Map that a chain of instanceofs.

One problem I see is how to interpret a String arg - you've decided to
use fromMemory but fromFile or fromUri would also be legitimate choices.

I guess I need to review the DiffBuilder stuff to understand how you
intend to use it.  Usually people will know what builder method they
want to invoke :-)

> -------------
> Nice Diff-View with org.junit.ComparisionFailure.
> -------------
> Can I add junit 4 library to xmlunit-hamecrest?

Please don't.  I wouldn't want to introduce a JUnit dependency for users
of TestNG which can also use Hamcrest matchers.

> I think it's only optional: It will not throw a ClassCastException if
> the following feature (CompareMatcher.throwComparisonFailure()) is not
> used.

The IDE visualization is certainly nice.  An approach that might work is
having an optional dependency and a fallback solution if
ComparisonFailure is not there (like not throwing that exception and
return false from matches).

> I added a Sceencast and Screenshot as attachement.

Thanks, this is helpful.

Cheers

        Stefan

Re: [Xmlunit-general] xmlunit.org

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

Hi,

>> [even if it seems that your messages don't make it through, please keep the list in CC]
sorry, I forgot.

>> Input.fromUnknown(Object)
It is in my branch:
https://github.com/brabenetz/xmlunit/blob/master/src/main/java-core/org/xmlunit/builder/Input.java#L109

> I'll try to have a look and provide feedback soon.
Thanks, today I will checkin the CompareMatcher implementation.

> > Also I implemented the Method Input.fromJaxb(Object) ....
> Ah, nice catch.  Could you create a separate pull request just for the
> missing JAXBSource part?
difficult: I must create a separate branch and checkin the different features.
I don't know how good the GIT-Merge of my master branch then works. Maybe I must copy manually all features to the new branch for there pull-requests.
Maybe I can separate three Features/Pull-Requests:
   "Input.fromJaxb with JaxbBuilder",
   "Diff & DiffBuilder with ComparisonFormatter" (I used the DiffBuilder for the UnitTests of the ComparisonFormatter),
   "CompareMarshaller"
Easier would be one pull request all together from my master branch.

-------------
Nice Diff-View with org.junit.ComparisionFailure.
-------------
Can I add junit 4 library to xmlunit-hamecrest?
I think it's only optional: It will not throw a ClassCastException if the following feature (CompareMatcher.throwComparisonFailure()) is not used.
I added a Sceencast and Screenshot as attachement.

The CompareMatcher could also be used to throw an org.junit.ComparisionFailure.
Eclipse can open a nice Diff-View of the two nodes (see Screencast).
IntelliJ should also have this feature: https://youtrack.jetbrains.com/issue/IDEA-57880
Also NetBeans: http://wiki.netbeans.org/NewAndNoteWorthyNB67#JUnit_Integration

The syntax is like:
  assertThat(testSource, CompareMatcher.isSimilar(controlSource).throwComparisonFailure());

with friendly regards,
Harald

> Gesendet: Montag, 05. Januar 2015 um 14:39 Uhr
> Von: "Stefan Bodewig" <bo...@ap...>
> An: "Harald Brabenetz" <bra...@gm...>
> Cc: xml...@li...
> Betreff: Re: xmlunit.org
>
> [even if it seems that your messages don't make it through, please keep
> the list in CC]
> 
> On 2015-01-04, Harald Brabenetz wrote:
> 
> > I think the DiffBuilder is the right place, because CommentLessSource,
> > WhitespaceStrippedSource, WhitespaceNormalizedSource makes mostly
> > sense if they are used on Control- and Test-Source in the same way.
> 
> "the right place" for specifying, that you want to ignore comments?  The
> argument that I'll have to treat boths inputs the same is compelling.
> 
> > But the Input.Builder could have the same implementation (maybe by an
> > AbstractBuilder implementation?).
> 
> > -------------
> > Diff & DiffBuilder.
> > -------------
> > I'm now finished with Diff & DiffBuilder.
> 
> I'll try to have a look and provide feedback soon.
> 
> > -------------
> > Input
> > -------------
> > Valid inputs for control and test are all Objects supported by
> > Input.fromUnknown(Object).
> 
> From the sound of it I'm not fond of fromUnknown but will first look at
> the code before commenting any further.
> 
> > Also I implemented the Method Input.fromJaxb(Object) with the same
> > default marshaller rules from javax.xml.bind.JAXB (but with the
> > Input.Builder as Result).
> 
> Ah, nice catch.  Could you create a separate pull request just for the
> missing JAXBSource part?
> 
> > -------------
> > ComparisonFormatter => used in Diff.toString()
> > -------------
> 
> Again, I'll have to defer commenting until I've found time to look at
> the code.
> 
> > I created UnitTestCases for each ComparisonType in
> > ComparisonFormatterDefaultTest.  Only
> > ComparisonType.NO_NAMESPACE_SCHEMA_LOCATION I couldn't reproduce: I
> > got only ComparisonType.ATTR_VALUE:
> >         Diff diff = DiffBuilder.compare(
> >                         "<a xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" "
> >                             + "xsi:noNamspaceSchemaLocation=\"Book.xsd\"/>",
> 
> there is a typo in the attribute name - a missing "e" in Nam*e*space.
> 
> Cheers
> 
>         Stefan
> 

[Xmlunit-general] Developer Documentation of XMLUnit 2.x

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

Hi all

I've started to write down a few things about the current API - more as
a rationale for why things are like they are:

https://github.com/xmlunit/xmlunit/wiki/Design-Decisions

The more important part to me are the "discussion" sections where I
listed all the things that I know aren't done, yet, feel wrong or seem
incomplete.

Please feel free to jump in and add additional discussion point, refine
what I've written (but don't make it a user documentation, that's not
the right place for that) or just tell me where I'm wrong.

If you want to discuss things on this list, this is more than just fine,
please do.

Cheers

        Stefan

Re: [Xmlunit-general] xmlunit.org

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

[even if it seems that your messages don't make it through, please keep
the list in CC]

On 2015-01-04, Harald Brabenetz wrote:

> I think the DiffBuilder is the right place, because CommentLessSource,
> WhitespaceStrippedSource, WhitespaceNormalizedSource makes mostly
> sense if they are used on Control- and Test-Source in the same way.

"the right place" for specifying, that you want to ignore comments?  The
argument that I'll have to treat boths inputs the same is compelling.

> But the Input.Builder could have the same implementation (maybe by an
> AbstractBuilder implementation?).

> -------------
> Diff & DiffBuilder.
> -------------
> I'm now finished with Diff & DiffBuilder.

I'll try to have a look and provide feedback soon.

> -------------
> Input
> -------------
> Valid inputs for control and test are all Objects supported by
> Input.fromUnknown(Object).

>From the sound of it I'm not fond of fromUnknown but will first look at
the code before commenting any further.

> Also I implemented the Method Input.fromJaxb(Object) with the same
> default marshaller rules from javax.xml.bind.JAXB (but with the
> Input.Builder as Result).

Ah, nice catch.  Could you create a separate pull request just for the
missing JAXBSource part?

> -------------
> ComparisonFormatter => used in Diff.toString()
> -------------

Again, I'll have to defer commenting until I've found time to look at
the code.

> I created UnitTestCases for each ComparisonType in
> ComparisonFormatterDefaultTest.  Only
> ComparisonType.NO_NAMESPACE_SCHEMA_LOCATION I couldn't reproduce: I
> got only ComparisonType.ATTR_VALUE:
>         Diff diff = DiffBuilder.compare(
>                         "<a xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" "
>                             + "xsi:noNamspaceSchemaLocation=\"Book.xsd\"/>",

there is a typo in the attribute name - a missing "e" in Nam*e*space.

Cheers

        Stefan

Re: [Xmlunit-general] xmlunit.org

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

On 2015-01-03, Eric Siegerman wrote:

> [I've pasted back in a few lines from Harald's post that Stefan snipped]

sorry :-)

> On 12/26/2014 06:12 AM, Stefan Bodewig wrote:
>> On 2014-12-24, Harald Brabenetz wrote:
>>> The advances would be the following
>>>   - Modern IDEs can read the pom.xml and configure the Projects
> automatically (no manual selection where the source folders or the
> libraries are).
>>>   - You doesn't need to check-in libraries like hamcrest or junit
>>>   - It's much easier to deploy to the maven central repo (with the
> maven-release-plugin and some configurations for the Sonatype's OSSRH)

>> I guess what I'm asking is: can I be sure there will be a result that
>> goes beyond replacing a build system I like with one I don't like :-)

> Instead of switching completely over to Maven, why not use a
> hybrid approach?

Yes, that would certainly be an option, but I'm not sure maintaining two
different build systems (for example when a new version of JUnit is
released) and fighting against Maven conventions will be worth it.

Also, I'm not sure this really solves the IDE point.  Developers still
had to tell their IDE where to look for the sources.  At least I think
they'd have to.

I've tried to capture the discusion here
<https://github.com/xmlunit/xmlunit/wiki/Building-XMLUnit#discussion>

Stefan

Re: [Xmlunit-general] xmlunit.org

[Eric S. <pub...@da...>]

[I've pasted back in a few lines from Harald's post that Stefan snipped]

On 12/26/2014 06:12 AM, Stefan Bodewig wrote:
 > On 2014-12-24, Harald Brabenetz wrote:
 > > The advances would be the following
 > >   - Modern IDEs can read the pom.xml and configure the Projects 
automatically (no manual selection where the source folders or the 
libraries are).
 > >   - You doesn't need to check-in libraries like hamcrest or junit
 > >   - It's much easier to deploy to the maven central repo (with the 
maven-release-plugin and some configurations for the Sonatype's OSSRH)
 >
 > I guess what I'm asking is: can I be sure there will be a result that
 > goes beyond replacing a build system I like with one I don't like :-)

Instead of switching completely over to Maven, why not use a
hybrid approach?  Keep Ant, but write a minimal POM for
consumption by the general public.  It could specify the external
dependencies, but delegate to Ant and build.xml for the actual
build. [1]

That way, you (i.e. Stefan) get the first of the advantages that
are claimed for Maven -- and the second one too, if you want it,
with a bit of finagling.
But:
   - you can keep using the build system you prefer
   - you don't have to completely reorganize your project
     structure
   - you don't have to wrestle with the release plugin

[1] For calling out to Ant, one option is:
     http://maven.apache.org/plugins/maven-antrun-plugin/

Eric

Re: [Xmlunit-general] [RESEND] Re: xmlunit.org

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

On 2015-01-02, Stefan Bodewig wrote:

> On 2014-12-31, Harald Brabenetz wrote:

>> I will also implement some of the old methods from XmlUnit with code
>> like "new DiffBuilder().ignoreComments()".

> If you think they are useful, yes.  Otherwise people could always wrap
> their inputs in a CommentLessSource.

On second thought, no, I'd rather add this to the Input-Builder than the
DiffBuilder.

Stefan

Re: [Xmlunit-general] [RESEND] Re: xmlunit.org

[Stefan B. <ste...@fr...>]

Happy new year,

On 2014-12-31, Harald Brabenetz wrote:

> I moved the Maven-Changes to a branch (So i can work in master-branch on the Diff, DiffMatcher and CompareMatcher):
> https://github.com/brabenetz/xmlunit/tree/2.0-maven-changes

Good.

> ---------------------------
> Diff & DiffBuilder
> ---------------------------
>> Diff myDiff = DiffBuilder.compareControl(Input.fromMemory(myControlXML))
>> .withTest(Input.fromMemory(myTestXML))
>> .build();
>> assertTrue("XML similar " + myDiff.toString(), myDiff.isSimilar());
> Thanks! That's exactally what I have searched for :)

I should be able to write down my design ideas in the wiki this coming
weekend, feel free to comment there and show me where I went wrong while
designing in some kind of a vacuum. :-)

> I will try to implement the Diff and DiffBuilder in xmmlunit-core.
> Can I move the isSimilar() method to the Builder (e.g.: DiffBuilder.checkForSimilar()).
> In case of similar-compare I'm not interested in all the "[not identical] ..." messages from the toString() method (this was a little irritating from XmlUnit 1.x).

Well, Diff doesn't have to be the same as it is in 1.x, quite the
opposite.  Right now I'd say an overall result (maybe accessible via
isSimilar/isDifferent) and an Iterable of Differences found would be all
it takes.  I haven't thought about the toString implementation so far.

> ---------------------------
> Legacy-Code
> ---------------------------
> I will also implement some of the old methods from XmlUnit with code
> like "new DiffBuilder().ignoreComments()".

If you think they are useful, yes.  Otherwise people could always wrap
their inputs in a CommentLessSource.

> Are my assumptions correct?:
> XMLUnit.setIgnoreAttributeOrder() => 2.x will always ignore the
> attribute order, right?
> XMLUnit.setIgnoreComments() => use of "new CommentLessSource(...)"
> XMLUnit.setIgnoreDiffBetweenTextAndCDATA() => in 2.x already marked with ComparisonType.NODE_TYPE with ComparisonResult.SIMILAR (another behaviour would require a custom DifferenceEvaluator)
> XMLUnit.setIgnoreWhitespace() => use of "new WhitespaceStrippedSource(...)"
> XMLUnit.setNormalizeWhitespace => use of "new WhitespaceNormalizedSource(...)"

yes, this is what I planned.

> ---------------------------
> Documentation
> ---------------------------
> If I'm finished with it, I will start the Wiki Pages:

Great, please use the wiki inside the userguide repository.  It should
be writable for everybody.

Cheers

        Stefan

Re: [Xmlunit-general] [RESEND] Re: xmlunit.org

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

Hi,

---------------------------
MAVEN
---------------------------
I moved the Maven-Changes to a branch (So i can work in master-branch on the Diff, DiffMatcher and CompareMatcher):
https://github.com/brabenetz/xmlunit/tree/2.0-maven-changes
There are no big changes: moving some folders and creating the pom.xmls
   You can copy the pom.xmls from the branch.
   About the pom.xmls:
      - maven-release-plugin is not important for other contributors.
         I only added it because I think that it makes releases easier.
         Let me know if you want the pom.xmls without release-plugin, I will cleanup the pom.xmls in my branch.
         (than a release must be done manually by: update version, create Github-TAG, deploy to sonatype, update to next SNAPSHOT version).
      - pom.xml of xnlunit-legacy. I configured the "BSD 3-Clause License": http://opensource.org/licenses/BSD-3-Clause (it matches the header-texts)
   About the tests:
      - I changed the paths to "/test/" (Maven standard folder name) instead "/tests/",
         but better would be to add the test-dependencies of the core module and load the files from classpath.
         This would solve the problem with the shared test-resources.
         And not only for resources, I want add some Jaxb-Objects for some tests with javax.xml.bind.util.JAXBSource (e.g.: Input.fromJaxbObject(Object obj))

---------------------------
Diff & DiffBuilder
---------------------------
> Diff myDiff = DiffBuilder.compareControl(Input.fromMemory(myControlXML))
> .withTest(Input.fromMemory(myTestXML))
> .build();
> assertTrue("XML similar " + myDiff.toString(), myDiff.isSimilar());
Thanks! That's exactally what I have searched for :)
I will try to implement the Diff and DiffBuilder in xmmlunit-core.
Can I move the isSimilar() method to the Builder (e.g.: DiffBuilder.checkForSimilar()).
In case of similar-compare I'm not interested in all the "[not identical] ..." messages from the toString() method (this was a little irritating from XmlUnit 1.x).
// Example:
// (DiffBuilder-Default: collect ComparisonResult.SIMILAR, DIFFERENT and CRITICAL)
Diff myDiff = DiffBuilder.compareControl(Input.fromMemory(myControlXML))
   .withTest(Input.fromMemory(myTestXML))
   .checkForSimilar() // collect only ComparisonResult.DIFFERENT and CRITICAL
   .build();
assertTrue("XML similar " + myDiff.toString(), myDiff.hasDifferences());


---------------------------
Legacy-Code
---------------------------
I will also implement some of the old methods from XmlUnit with code like "new DiffBuilder().ignoreComments()".
Are my assumptions correct?:
XMLUnit.setIgnoreAttributeOrder() => 2.x will always ignore the attribute order, right?
XMLUnit.setIgnoreComments() => use of "new CommentLessSource(...)"
XMLUnit.setIgnoreDiffBetweenTextAndCDATA() => in 2.x already marked with ComparisonType.NODE_TYPE with ComparisonResult.SIMILAR (another behaviour would require a custom DifferenceEvaluator)
XMLUnit.setIgnoreWhitespace() => use of "new WhitespaceStrippedSource(...)"
XMLUnit.setNormalizeWhitespace => use of "new WhitespaceNormalizedSource(...)"

---------------------------
Documentation
---------------------------
If I'm finished with it, I will start the Wiki Pages:
   - "Writing XML comparison tests" (basically the updated documentation from 1.x "1.5. Writing XML comparison tests")
      + TestCase with a Diff instance
      + TestCase with a Hamcrest CompareMatcher
      + Example with DifferenceEvaluator
      + Example with NodeMatcher, DefaultNodeMatcher and NodeTypeMatcher

happy new Year,
Harald


> Gesendet: Sonntag, 28. Dezember 2014 um 22:40 Uhr
> Von: "Stefan Bodewig" <ste...@fr...>
> An: xml...@li...
> Cc: "Harald Brabenetz" <bra...@gm...>
> Betreff: Re: [Xmlunit-general] [RESEND] Re: xmlunit.org
>
> On 2014-12-28, Harald Brabenetz wrote:
> 
> > I'm certain, that with maven it is easier to contribute to xmlunit.
> 
> Maybe.  I'll think about it but don't promise anything.
> 
> If we move things around to make Maven happy, this might be the best
> point in time to split the Java and .NET implementations.  Which also
> requires a solution for the shared test resources (yet another repo and
> submodules or subtrees, likely).  So please dont put too much effort
> into it now, we'd only end up with merge conflicts.
> 
> My short term focus is getting XMLUnit Java 1.6 out.  I've been working
> on https://sourceforge.net/p/xmlunit/bugs/65/ for a while and have
> uncovered two bugs in xmlunit-legacy while porting a not yet committed
> solution from XMLUnit 1.x - interesting.
> 
> All this while juggling some real-live responsibilities, please bear
> with me. :-)
> 
> > I would like to contribute a CompareMatcher with fluent style:
> 
> This sounds great.
> 
> > But I must rewrite my code for the new XmlUnit-API (e.g.: use
> > NodeMatcher instead ElementQualifier).
> 
> I'd shoot for ElementSelector and DefaultNodeMatcher when replacing
> ElementQualifier.
> 
> > Is there a documentation for the new API?
> 
> Unfortunately nothing beyond Javadocs and the tests.  I wanted to
> document the design ideas behind some parts of the new API in the Wiki
> and even discuss things there as I'm sure there are a few things that
> could be solved in a nicer way.
> 
> > What is the new Syntax for a comparission for "similar":
> >     Diff myDiff = new Diff(myControlXML, myTestXML);
> >     assertTrue("XML similar " + myDiff.toString(), myDiff.similar());
> 
> Yet another missing piece.
> 
> > I found no default implementation of a ComparisonListener.java (only
> > in tests and legacy).
> 
> I'm not sure there is a default implementation that is of wider use.
> 
> The sketch in my head that needs to get written down goes along the
> lines of
> 
> Diff myDiff = DiffBuilder.compareControl(Input.fromMemory(myControlXML))
>                         .withTest(Input.fromMemory(myTestXML))
>                         .build();
> assertTrue("XML similar " + myDiff.toString(), myDiff.isSimilar());
> 
> where DiffBuilder uses an internal implementation of ComparisonListener
> and turns the collected results into a(n imutable) Diff object which
> captures the outcome.  The DiffBuilder would have additional methods for
> specifying custom NodeMatchers, DifferenceEvaluators and so on.
> 
> I can easily see your ComparisonMatcher work on top of DiffBuilder.
> 
> One thing that is important to me is to keep external dependencies - and
> JUnit is one - out of core.  I can easily envision a graphical XML diff
> tool on top of DifferenceEngine that visualizes differences based on
> information obtained via ComparisonListener callbacks.
> 
> Cheers
> 
>         Stefan
> 

[Xmlunit-general] [ANN] XMLUnit for Java 1.6 Released!

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

XMLUnit for Java 1.6 is mostly a bugfix release adressing four issues:

* If the sought for attribute in ATTR_NAME_NOT_FOUND or node in
  CHILD_NODE_NOT_FOUND differences is inside an XML namespace, the
  difference's value is now Java5-QName like {NS-URI}LOCAL-NAME rather
  than just the local name.
  https://sourceforge.net/p/xmlunit/bugs/65/
* for ATTR_NAME_NOT_FOUND differences the XPath on the side where
  the attribute exists now points to the attribute itself rather than
  the parent element.
  https://sourceforge.net/p/xmlunit/feature-requests/33/
* a new assertXpathEvaluatesTo assertion in XMLAssert combined
  with a new QualifiedName class allows stringified XPath values to be
  interpreted as qualified names.
  https://sourceforge.net/p/xmlunit/feature-requests/25/
* The JAXP 1.3 based validator ignored now uses the
  xsi:namespaceLocation and xsi:noNamespaceLocation attributes if
  you specify no schema sources at all.
  https://sourceforge.net/p/xmlunit/bugs/64/

Note the first two changes may be breaking backwards compatibility in
rare cases.

Source and binary distributions are available from SourceForge's File
Service at
<https://sourceforge.net/projects/xmlunit/files/xmlunit%20for%20Java/XMLUnit%20for%20Java%201.6/>,
the checksums and PGP signatures can be found at the website
<http://xmlunit.sourceforge.net/checksums/>.

Cheers

        Stefan Bodewig
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAlSkJlwACgkQohFa4V9ri3LFEACfXp3pIKIJAN41NysPeSpZnhIC
N/MAmQEtYnciQQREFEOSxwPZigwtlmh4
=lGis
-----END PGP SIGNATURE-----

Re: [Xmlunit-general] xmlunit.org

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

On 2014-12-24, Harald Brabenetz wrote:

> I would like to provide the changes to a standard maven Project.

Somehow I knew this would happen, I just didn't expect it to be the
first thing that comes up :-)

I could counter all of your arguments with a "it's not a problem for
me".  For example xmlunit 1.x is in maven central, so I obviously know
how to get it there without using the release plugin ;-)

But I'm willing to accept that my view of the world is not shared by too
many people.  So I may switch to using Maven and a multi-module layout
even though it would hurt me, but I'd *really* like to understand what
the benefit for XMLUnit would be.

To explain what I mean: when I started writing the user guide for
XMLUnit for Java 1.x I've been talked into using docbook rather than
LaTeX against my personal preferences (at least that's my
recollection).  In the end I never received a single contribution to the
user guide and ended up using a system I didn't want to use.  I'd prefer
to not see the same happen again.

I guess what I'm asking is: can I be sure there will be a result that
goes beyond replacing a build system I like with one I don't like :-)

Is there anything in particular you'd want to work on?

> There is "maybe" only one Problem:
> 	I have no clue how the .Net part works.

Which shows a totally different but real problem.  I cannot expect
people to be equally familiar with or even just interested in the Java
and .NET implementations.  It may be better to finally split the two
implementations so contributors don't feel they have to contribute to
both parts at the same time.

Oh, the .NET part builds using NAnt, at least until anybody suggests to
move to MSBuild/xbuild.

Cheers

        Stefan

Re: [Xmlunit-general] xmlunit.org

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

Hi,

I made the first working draft:
https://github.com/brabenetz/xmlunit
 
checkout and "mvn install" works fine with unit-tests.

I changed the groupId to "org.xmlunit" (according to the new homepage)
If this is OK for you, I will release an alpha release "2.0-alpha1" to test the release plugin (and all depending parts like Sonatype, GitHub).

with friendly regards,
Harald


> Gesendet: Mittwoch, 24. Dezember 2014 um 19:32 Uhr
> Von: "Harald Brabenetz" <bra...@gm...>
> An: "Stefan Bodewig" <bo...@ap...>, xml...@li...
> Betreff: Re: [Xmlunit-general] xmlunit.org
>
> Hi,
> 
> I would like to provide the changes to a standard maven Project.
> 
> The advances would be the following
> 	- Modern IDEs can read the pom.xml and configure the Projects automatically (no manual selection where the source folders or the libraries are).
> 	- You doesn't need to check-in libraries like hamcrest or junit
> 	- It's much easier to deploy to the maven central repo (with the maven-release-plugin and some configurations for the Sonatype's OSSRH)
> 	
> I would change the folder Structure to a standard multi-project structure
> 
> + xmlunit
>    + xmlunit-core
>    |  + src
>    |     + main
>    |     |  + java
>    |     |  + resources
>    |     + test
>    |        + java
>    |        + resources
>    + xmlunit-hamcrest
>    |  + src
>    |     + main
>    |     |  + java
>    |     |  + resources
>    |     + test
>    |        + java
>    |        + resources
>    + xmlunit-legacy (The old code-base for a smoothly update to 2.x?)
>    |  + src
>    |     + main
>    |     |  + java
>    |     |  + resources
>    |     + test
>    |        + java
>    |        + resources
>    + xmlunit-net (basically all remaining folders; I have no idea how do build this)
>       + main
>       |  + net-constraints
>       |  + net-core
>       + tests
>       |  + net-constraints
>       |  + net-core
>       + lib (nunit.framework.dll, NUnitSummary.xsl, toolkit.xsl)
> 
> 
> There is "maybe" only one Problem:
> 	I have no clue how the .Net part works.
> 
> with friendly regards,
> Harald Brabenetz
> 
> > Gesendet: Mittwoch, 10. Dezember 2014 um 06:09 Uhr
> > Von: "Stefan Bodewig" <bo...@ap...>
> > An: xml...@li...
> > Betreff: [Xmlunit-general] xmlunit.org
> >
> > Hi all
> > 
> > I've decided to register xmlunit.org, donate it to this project (albeit
> > there is nobody I can formally donate it to) and direct it to the
> > xmlunit organization's github page.
> > 
> > I'll be changing the Java packages/.NET namespaces from net.sf.xmlunit
> > to org.xmlunit in the git master branch for 2.x soon.
> > 
> > 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=164703151&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Xmlunit-general mailing list
> > Xml...@li...
> > https://lists.sourceforge.net/lists/listinfo/xmlunit-general
> > 
> 
> ------------------------------------------------------------------------------
> 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] xmlunit.org

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

Hi,

something must be wrong with the mailing-list.
I doesn't got your answer.
And my mail also not appears on the mailing-list archive.

I think (or fear...) everyone get permission on sonatype who asks friendly :)

In the xmlunit/pom.xml you must change the scm section to the main xmlunit repository:
  <scm>
    <connection>scm:git:https://github.com/xmlunit/xmlunit.git</connection>
    <developerConnection>scm:git:https://github.com/xmlunit/xmlunit.git</developerConnection>
    <url>https://github.com/xmlunit/xmlunit/</url>
  </scm>

 - "mvn install" : works fine and run all unittests
 - "mvn deploy" : should deploy the SNAPSHOT release to sonatype
 - "mvn release:prepare" : should prepare the TAG, update Versions and push to GitHub
 - "mvn release:perform" : checkout the TAGed version and deploy the release to Sonatype, where it can be tested and sync to central.
  
For "mvn deploy" I only got "permission denied" (I doesn't have asked friendly now :) ).
I couldn't test the release tasks (therefor was the alpha release).

with friendly regards
Harald

> Gesendet: Freitag, 26. Dezember 2014 um 19:01 Uhr
> Von: "Stefan Bodewig" <bo...@ap...>
> An: "Harald Brabenetz" <bra...@gm...>
> Cc: xml...@li...
> Betreff: Re: [Xmlunit-general] xmlunit.org
>
> On 2014-12-26, Harald Brabenetz wrote:
> 
> > I made the first working draft:
> > https://github.com/brabenetz/xmlunit
> 
> > checkout and "mvn install" works fine with unit-tests.
> 
> I'll take a look at it soon, not sure whether I'll get there today,
> thanks!
> 
> Not sure whether you've received my response I sent to the list (I don't
> see it inside the archives, yet).
> 
> > I changed the groupId to "org.xmlunit" (according to the new homepage)
> 
> Sounds right.
> 
> > If this is OK for you, I will release an alpha release "2.0-alpha1" to
> > test the release plugin (and all depending parts like Sonatype,
> > GitHub).
> 
> I'd sincerly hope Sonatype won't let you push artifacts to the
> org.xmlunit groupId, at least not yet.  Currently I've got the
> privileges to push to xmlunit and wanted to obtain them for org.xmlunit
> soon.
> 
> Content wise I don't feel we are ready for an alpha release, but would
> be fine with SNAPSHOTs.  Those should be created from the main xmlunit
> repository, of course.
> 
> Cheers
> 
> Stefan
> 

Re: [Xmlunit-general] xmlunit.org

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

[looks as if sourceforge's infra is undergoing serious problems, their
SMTP server is denying connections because it's under too big a load and
when I tried to report the problem via the issue tracker I received a
server error page]

On 2014-12-27, Stefan Bodewig wrote:

> On 2014-12-26, Harald Brabenetz wrote:

>> I made the first working draft:
>> https://github.com/brabenetz/xmlunit

>> checkout and "mvn install" works fine with unit-tests.

> I'll take a look at it soon, not sure whether I'll get there today,
> thanks!

Again, many thanks Harald.  Before you put any more effort into it,
let's try to figure out what we really need.

I think we should inherit from Sonatype's OSS parent which will
immediately give us a lot of stuff you've put into the profile and
pluginManagement.

I'd like to have xmlunit-core use the artifactId xmlunit-core and I'm
pretty sure it doesn't need JUnit at compile time.

The Ant build currently creates xmlunit-sumo that I intended as a
drop-in replacement for xmlunit.jar of 1.x.  It really just is the
combined content of xmlunit-core and xmlunit-legacy, something we can
probably achieve with some shading.

Cheers

        Stefan

Re: [Xmlunit-general] [RESEND] Re: xmlunit.org

[Stefan B. <ste...@fr...>]

On 2014-12-28, Harald Brabenetz wrote:

> I'm certain, that with maven it is easier to contribute to xmlunit.

Maybe.  I'll think about it but don't promise anything.

If we move things around to make Maven happy, this might be the best
point in time to split the Java and .NET implementations.  Which also
requires a solution for the shared test resources (yet another repo and
submodules or subtrees, likely).  So please dont put too much effort
into it now, we'd only end up with merge conflicts.

My short term focus is getting XMLUnit Java 1.6 out.  I've been working
on https://sourceforge.net/p/xmlunit/bugs/65/ for a while and have
uncovered two bugs in xmlunit-legacy while porting a not yet committed
solution from XMLUnit 1.x - interesting.

All this while juggling some real-live responsibilities, please bear
with me. :-)

> I would like to contribute a CompareMatcher with fluent style:

This sounds great.

> But I must rewrite my code for the new XmlUnit-API (e.g.: use
> NodeMatcher instead ElementQualifier).

I'd shoot for ElementSelector and DefaultNodeMatcher when replacing
ElementQualifier.

> Is there a documentation for the new API?

Unfortunately nothing beyond Javadocs and the tests.  I wanted to
document the design ideas behind some parts of the new API in the Wiki
and even discuss things there as I'm sure there are a few things that
could be solved in a nicer way.

> What is the new Syntax for a comparission for "similar":
>     Diff myDiff = new Diff(myControlXML, myTestXML);
>     assertTrue("XML similar " + myDiff.toString(), myDiff.similar());

Yet another missing piece.

> I found no default implementation of a ComparisonListener.java (only
> in tests and legacy).

I'm not sure there is a default implementation that is of wider use.

The sketch in my head that needs to get written down goes along the
lines of

Diff myDiff = DiffBuilder.compareControl(Input.fromMemory(myControlXML))
                        .withTest(Input.fromMemory(myTestXML))
                        .build();
assertTrue("XML similar " + myDiff.toString(), myDiff.isSimilar());

where DiffBuilder uses an internal implementation of ComparisonListener
and turns the collected results into a(n imutable) Diff object which
captures the outcome.  The DiffBuilder would have additional methods for
specifying custom NodeMatchers, DifferenceEvaluators and so on.

I can easily see your ComparisonMatcher work on top of DiffBuilder.

One thing that is important to me is to keep external dependencies - and
JUnit is one - out of core.  I can easily envision a graphical XML diff
tool on top of DifferenceEngine that visualizes differences based on
information obtained via ComparisonListener callbacks.

Cheers

        Stefan

Re: [Xmlunit-general] [RESEND] Re: xmlunit.org

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

Hi,

I'm certain, that with maven it is easier to contribute to xmlunit.
The first time I checked out xmlunit I must do the following:
 - search and add the source-folders to my project
 - search and add the libraries to my project
 - hope that I doesn't forgot something (in which case I must study the ANT script)
Also I doesn't got the Source/JavaDoc for JUnit and Hamecrest libraries

With Maven there is only one step after cloning the GIT-Repo:
 - import project as Maven Project
And I get also the Sources and JavaDoc of the dependent libraries
This works for all modern IDEs like Eclipse, NetBeans, IntelliJ.

I understand you completely, if you don't want change anything without "real" contributions to the project :)

I would like to contribute a CompareMatcher with fluent style:

public final class MyProjectSpecificTestUtils {
	public static CompareMatcher isSimilarTo(final File file) {
		return new CompareMatcher(file)
			.useDifferenceListener(createDifferenceListener())
			.useElementQualifier(createElementQualifier());
	}
	...
}

The JUnitTests looks like the following:

	// run test which returns a JaxB Object
	final MyJaxbResponse jaxbResponse = callMyWebserviceImplementation("request.xml");
	// validate result
	assertThat(jaxbResponse, MyProjectSpecificTestUtils.isSimilarTo(getTestFile("expectedResponse.xml")));

But I must rewrite my code for the new XmlUnit-API (e.g.: use NodeMatcher instead ElementQualifier).
Is there a documentation for the new API?
What is the new Syntax for a comparission for "similar":
    Diff myDiff = new Diff(myControlXML, myTestXML);
    assertTrue("XML similar " + myDiff.toString(), myDiff.similar());

I found no default implementation of a ComparisonListener.java (only in tests and legacy).

with friendly regards,
Harald



> Gesendet: Samstag, 27. Dezember 2014 um 14:37 Uhr
> Von: "Stefan Bodewig" <ste...@fr...>
> An: xml...@li...
> Betreff: [Xmlunit-general] [RESEND] Re: xmlunit.org
>
> [looks as if there has been some kind of hickup yesterday]
> 
> From: Stefan Bodewig <bo...@ap...>
> To: xml...@li...
> Subject: Re: [Xmlunit-general] xmlunit.org
> References: <87b...@v3...>
> 	<trinity-71edbf3b-e880-4568-a6d7-c90c9d574357-1419445946480@3capp-gmx-bs51>
> Date: Fri, 26 Dec 2014 12:12:05 +0100
> In-Reply-To: <trinity-71edbf3b-e880-4568-a6d7-c90c9d574357-1419445946480@3capp-gmx-bs51>
> 	(Harald Brabenetz's message of "Wed, 24 Dec 2014 19:32:26 +0100")
> Message-ID: <87o...@v3...>
> 
> On 2014-12-24, Harald Brabenetz wrote:
> 
> > I would like to provide the changes to a standard maven Project.
> 
> Somehow I knew this would happen, I just didn't expect it to be the
> first thing that comes up :-)
> 
> I could counter all of your arguments with a "it's not a problem for
> me".  For example xmlunit 1.x is in maven central, so I obviously know
> how to get it there without using the release plugin ;-)
> 
> But I'm willing to accept that my view of the world is not shared by too
> many people.  So I may switch to using Maven and a multi-module layout
> even though it would hurt me, but I'd *really* like to understand what
> the benefit for XMLUnit would be.
> 
> To explain what I mean: when I started writing the user guide for
> XMLUnit for Java 1.x I've been talked into using docbook rather than
> LaTeX against my personal preferences (at least that's my
> recollection).  In the end I never received a single contribution to the
> user guide and ended up using a system I didn't want to use.  I'd prefer
> to not see the same happen again.
> 
> I guess what I'm asking is: can I be sure there will be a result that
> goes beyond replacing a build system I like with one I don't like :-)
> 
> Is there anything in particular you'd want to work on?
> 
> > There is "maybe" only one Problem:
> > 	I have no clue how the .Net part works.
> 
> Which shows a totally different but real problem.  I cannot expect
> people to be equally familiar with or even just interested in the Java
> and .NET implementations.  It may be better to finally split the two
> implementations so contributors don't feel they have to contribute to
> both parts at the same time.
> 
> Oh, the .NET part builds using NAnt, at least until anybody suggests to
> move to MSBuild/xbuild.
> 
> 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] xmlunit.org

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

On 2014-12-26, Harald Brabenetz wrote:

> I made the first working draft:
> https://github.com/brabenetz/xmlunit

> checkout and "mvn install" works fine with unit-tests.

I'll take a look at it soon, not sure whether I'll get there today,
thanks!

Not sure whether you've received my response I sent to the list (I don't
see it inside the archives, yet).

> I changed the groupId to "org.xmlunit" (according to the new homepage)

Sounds right.

> If this is OK for you, I will release an alpha release "2.0-alpha1" to
> test the release plugin (and all depending parts like Sonatype,
> GitHub).

I'd sincerly hope Sonatype won't let you push artifacts to the
org.xmlunit groupId, at least not yet.  Currently I've got the
privileges to push to xmlunit and wanted to obtain them for org.xmlunit
soon.

Content wise I don't feel we are ready for an alpha release, but would
be fine with SNAPSHOTs.  Those should be created from the main xmlunit
repository, of course.

Cheers

Stefan