xmlunit-general — Everything XMLUnit ;0)

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

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

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

[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

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

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

[looks as if there has been some kind of hickup yesterday]

From: Stefan Bodewig <bo...@ap...>
To: "Harald Brabenetz" <bra...@gm...>
Cc: xml...@li...
Subject: Re: [Xmlunit-general] xmlunit.org
References: <87b...@v3...>
	<trinity-71edbf3b-e880-4568-a6d7-c90c9d574357-1419445946480@3capp-gmx-bs51>
	<trinity-85875985-0f2a-4f29-901b-c68374c7a436-1419615896466@3capp-gmx-bs51>
Date: Fri, 26 Dec 2014 19:01:38 +0100
In-Reply-To: <trinity-85875985-0f2a-4f29-901b-c68374c7a436-1419615896466@3capp-gmx-bs51>
	(Harald Brabenetz's message of "Fri, 26 Dec 2014 18:44:56 +0100")
Message-ID: <87m...@v3...>

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...>]

On 2014-12-27, Harald Brabenetz wrote:

> something must be wrong with the mailing-list.
> I doesn't got your answer.

Yes, strange, I'll try to reach some ops at sourceforge to see what's
going on.  I don't see notifications for the two commits I did at github
yesterday, either.

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

I think you need to do a bit more than that, I recall having to prove I
was associated with xmlunit.  May be wrong.  In either case, I now have
permissions to deploy to the org.xmlunit groupId.

> For "mvn deploy" I only got "permission denied" (I doesn't have asked
> friendly now :) ).

Good.

> I couldn't test the release tasks (therefor was the alpha release).

Honestly I have a love/hate relationship with the release plugin, more
hate than love.  It's not as if I wouldn't know how to use Maven, I've
been using it for years now.  Personally I still prefer not using it at
all, but as I said in my first response (that I forwarded to you), I'm
willing to adapt XMLUnit if there is a benefit beyond changing the build
system.

Cheers

        Stefan

Re: [Xmlunit-general] xmlunit.org

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

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
> 

[Xmlunit-general] xmlunit.org

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

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

Re: [Xmlunit-general] XMLUnit 2.x Plans for Infrastructure Changes

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

On 2014-12-07, Stefan Bodewig wrote:

> On 2014-12-06, Stefan Bodewig wrote:

>> * create three repositories (for now)
>>   * XMLUnit Java 2.x - including the matchers and xmlunit-legacy
>>   * XMLUnit .NET 2.x - including constraints

> actually I'm having second thoughts.  So far I've tried to keep both
> code bases in sync, they even share test documents.  Maybe it would be
> better to keep them toghether.

I've started with the migration, but can still be stopped :-)

https://github.com/xmlunit/xmlunit

for now I'll stick with a single repository for the code, we can always
split it later when/if necessary.

Stefan

Re: [Xmlunit-general] XMLUnit 2.x Plans for Infrastructure Changes

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

On 2014-12-06, Stefan Bodewig wrote:

> * create three repositories (for now)
>   * XMLUnit Java 2.x - including the matchers and xmlunit-legacy
>   * XMLUnit .NET 2.x - including constraints

actually I'm having second thoughts.  So far I've tried to keep both
code bases in sync, they even share test documents.  Maybe it would be
better to keep them toghether.

Thoughts?

Stefan

[Xmlunit-general] XMLUnit 2.x Plans for Infrastructure Changes

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

Hi all

if you are following the commits, you may have seen I've started to work
on XMLUnit 2.x again, nothing big, but I'm trying to get it done this
time.

Apart from re-thinking the abstractions used in the difference engine
the biggest piece missing for a release - even a beta - is
documentation.  Here I realized more and more that I really do not feel
like writing a big docbook document again, I need someting more
ligthweight with more immediate feedback.  A wiki would be fine, but
we've also always had a PDF version and I'd like to keep it that way.

Also I realized I prefer git over subversion by now, so I'd like to move
2.x to git.  I know I could do so on Sourceforge, but right now I feel
it would be best to move active development over to github.  A quick
search showed several forks over there, so we may be able to reconnect
and make this a community effort rather than mostly a one-man-show.

Here is what I intend to do, please let me know if anything looks
completely wrong:

* create an xmlunit organization at github
* create three repositories (for now)
  * XMLUnit Java 2.x - including the matchers and xmlunit-legacy
  * XMLUnit .NET 2.x - including constraints
  * a pure Wiki repository for the user guide.  github markdown works
    well enough for me and pandoc can create PDF or even epub from it
    (thanks to Stefan Tilkov for pointing me at it)
* start using github's issue tracker
* create a github.io site for XMLUnit 2.x
* keep using Sourceforge for XMLUnit 1.x
  * move XMLUnit 1.x back to svn trunk and keep it at sourceforge
  * keep using sourceforge's issue tracker for 1.x
  * keep the xmlunit.sf.net site for 1.x
* keep using the xml...@li... as primary
  communication medium for all versions
* keep the sourceforge forums even though I never liked them (or any web
  forum)

Stefan

Re: [Xmlunit-general] Basic XML Comparison

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

Hi Gordon,

you must set 'XMLUnit.setIgnoreWhitespace(true);' somewhere before:

@Test
public void testXmlTest1() throws Exception {
	Diff compareXML;
	final String source = "<stuff-doc><stuff>Stuff Stuff Stuff</stuff><more-stuff>Some More Stuff</more-stuff></stuff-doc>";
	final String test = "<stuff-doc>\n<stuff>Stuff Stuff Stuff</stuff>\n<more-stuff>Some More Stuff</more-stuff>\n</stuff-doc>";

	// OUTPUT:
	// identical: false
	// similar: false
	compareXML = XMLUnit.compareXML(source, test);
	System.out.println("identical: " + compareXML.identical());
	System.out.println("similar: " + compareXML.similar());

	// OUTPUT with ignoreWhitespaces = true:
	// identical: true
	// similar: true
	XMLUnit.setIgnoreWhitespace(true);
	compareXML = XMLUnit.compareXML(source, test);
	System.out.println("identical: " + compareXML.identical());
	System.out.println("similar: " + compareXML.similar());
	Assert.assertTrue(compareXML.toString(),  compareXML.similar());
	
}

lg,
Harry

On 2014-05-09, Gordon Ross wrote:
> My code is:
> public void testXmlTest1() throws SAXException, IOException
> 	{
> 		String source = "<stuff-doc><stuff>Stuff Stuff Stuff</stuff><more-stuff>Some More Stuff</more-stuff></stuff-doc>";
> 		String test = "<stuff-doc>\n<stuff>Stuff Stuff Stuff</stuff>\n<more-stuff>Some More Stuff</more-stuff>\n</stuff-doc>";
> 		assertXMLEqual(source, test);
> 	}
> XMLUnit is saying they are not the same as the number of children of
> <stuff-doc> is 5, not 2. Well, that’s true because of the whitespace
> creating text nodes. But I thought XMLUnit was supposed to cope with
> this?

Re: [Xmlunit-general] Basic XML Comparison

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

On 2014-05-09, Gordon Ross wrote:

> My code is:

> public void testXmlTest1() throws SAXException, IOException
> 	{
> 		String source = "<stuff-doc><stuff>Stuff Stuff Stuff</stuff><more-stuff>Some More Stuff</more-stuff></stuff-doc>";
> 		String test = "<stuff-doc>\n<stuff>Stuff Stuff Stuff</stuff>\n<more-stuff>Some More Stuff</more-stuff>\n</stuff-doc>";

> 		assertXMLEqual(source, test);
> 	}

> XMLUnit is saying they are not the same as the number of children of
> <stuff-doc> is 5, not 2. Well, that’s true because of the whitespace
> creating text nodes. But I thought XMLUnit was supposed to cope with
> this?

If you tell it to :-)

<http://xmlunit.sourceforge.net/userguide/html/ar01s02.html#Basic:%20Element%20Content%20Whitespace>
<http://xmlunit.sourceforge.net/userguide/html/ar01s03.html#Whitespace%20Handling>

Stefan

[Xmlunit-general] Basic XML Comparison

[Gordon R. <gr...@ui...>]

I’m having trouble getting a basic XML comparison to give me the answer I expect. I’m using Junit4 & XMLUnit 1.5.

My code is:

public void testXmlTest1() throws SAXException, IOException
	{
		String source = "<stuff-doc><stuff>Stuff Stuff Stuff</stuff><more-stuff>Some More Stuff</more-stuff></stuff-doc>";
		String test = "<stuff-doc>\n<stuff>Stuff Stuff Stuff</stuff>\n<more-stuff>Some More Stuff</more-stuff>\n</stuff-doc>";
		
		assertXMLEqual(source, test);
	}

XMLUnit is saying they are not the same as the number of children of <stuff-doc> is 5, not 2. Well, that’s true because of the whitespace creating text nodes. But I thought XMLUnit was supposed to cope with this?

What am I doing wrong? Do I need to specify something like a DTD? Or do I have to create XPaths for every element?

Thanks,

GTG
— 
Gordon Ross

Re: [Xmlunit-general] Diff.similar() seems to cause thread to exit 50%+ of the time

[Bill R. <bil...@xo...>]

    > Try replacing the nap with: System.out.flush(); and see what happens.

Thanks, that would do it. I'm tempted to add it as an @After in testng, just in case. Tempting to ask for it as a built-in feature in testng. 
In this case I didn't need the temporary printlns to show, beyond making sure the test was working correctly.

Bill

-----Original Message-----
From: Eric Siegerman [mailto:pub...@da...] 
Sent: Thursday, October 24, 2013 11:56 AM
To: xml...@li...
Subject: Re: [Xmlunit-general] Diff.similar() seems to cause thread to exit 50%+ of the time

On 10/23/2013 03:31 PM, Bill Ross wrote:
 > It looks like this is an artifact of println rather than XMLUnit: 
when I add this to the end of my test, it triggers ok:
 > System.out.println("@@@");
 > //napMilliSeconds(2000);
 > Assert.fail("Should fail here.");
 >
 > With the 'nap', all the prints appear, but in any case the assert is reached and fires.

So, are you saying that:
- with the nap, you get both the System.out output and the "Should fail here" test failure, as expected?
- without the nap, you get the (still-expected) test failure, but nothing printed on System.out?

If so, it sounds as though, when the test finishes (whether failing, as here, or passing, as in your original post), System.out's buffer is discarded instead of being flushed. I'm not sure why that would be timing-dependent.

Try replacing the nap with:
System.out.flush();
and see what happens.

Also try removing XmlUnit from the equation entirely.

I'd do both of those at once by making a set of tests that do:
{XmlUnit code | nothing}
println // The other 12 combinations, without the println, are of no interest {nap | flush | nothing} {fail | nothing}

And see which ones do or do not produce the println output.

If, as I expect:
- nap and flush both cause the println output to appear, but with neither of them, it's suppressed
- presence or absence of the preceding XmlUnit stuff makes no difference
- presence or absence of the final Assert.fail call also makes no difference then you have a solid bug report for the IntelliJ folks :-)

(Of course, it being timing-dependent, the results may not be entirely identical from run to run. I'd expect nap (and flush, if my theory is
correct) to *reliably* produce the output, but having neither of them to only sometimes suppress it.)

- Eric


------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg..clktrk
_______________________________________________
Xmlunit-general mailing list
Xml...@li...
https://lists.sourceforge.net/lists/listinfo/xmlunit-general
---------------------------------------------------------------------------------
The information transmitted in this email is intended only for the person or entity to which it is addressed, and may contain material confidential to Xoom Corporation, and/or its subsidiary, buyindiaonline.com Inc.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient(s) is prohibited.   If you received this email in error, please contact the sender and delete the material from your files.

Re: [Xmlunit-general] Diff.similar() seems to cause thread to exit 50%+ of the time

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

On 10/23/2013 03:31 PM, Bill Ross wrote:
 > It looks like this is an artifact of println rather than XMLUnit: 
when I add this to the end of my test, it triggers ok:
 > System.out.println("@@@");
 > //napMilliSeconds(2000);
 > Assert.fail("Should fail here.");
 >
 > With the ‘nap’, all the prints appear, but in any case the assert is 
reached and fires.

So, are you saying that:
- with the nap, you get both the System.out output and the "Should fail 
here" test failure, as expected?
- without the nap, you get the (still-expected) test failure, but 
nothing printed on System.out?

If so, it sounds as though, when the test finishes (whether failing, as 
here, or passing, as in your original post), System.out's buffer is 
discarded instead of being flushed. I'm not sure why that would be 
timing-dependent.

Try replacing the nap with:
System.out.flush();
and see what happens.

Also try removing XmlUnit from the equation entirely.

I'd do both of those at once by making a set of tests that do:
{XmlUnit code | nothing}
println // The other 12 combinations, without the println, are of no 
interest
{nap | flush | nothing}
{fail | nothing}

And see which ones do or do not produce the println output.

If, as I expect:
- nap and flush both cause the println output to appear, but with 
neither of them, it's suppressed
- presence or absence of the preceding XmlUnit stuff makes no difference
- presence or absence of the final Assert.fail call also makes no difference
then you have a solid bug report for the IntelliJ folks :-)

(Of course, it being timing-dependent, the results may not be entirely 
identical from run to run. I'd expect nap (and flush, if my theory is 
correct) to *reliably* produce the output, but having neither of them to 
only sometimes suppress it.)

- Eric

Re: [Xmlunit-general] Diff.similar() seems to cause thread to exit 50%+ of the time

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

On 2013-10-23, Bill Ross wrote:

> It looks like this is an artifact of println rather than XMLUnit: when
> I add this to the end of my test, it triggers ok:

>         System.out.println("@@@");
>         //napMilliSeconds(2000);
>         Assert.fail("Should fail here.");

> With the 'nap', all the prints appear, but in any case the assert is
> reached and fires.  I forgot to mention, this is within IntelliJ.

TBH I have no clue.  I've never seen such behavior in tests, but then
again, I don't use IntelliJ either.

Sorry

        Stefan

Re: [Xmlunit-general] Diff.similar() seems to cause thread to exit 50%+ of the time

[Bill R. <bil...@xo...>]

It looks like this is an artifact of println rather than XMLUnit: when I add this to the end of my test, it triggers ok:

        System.out.println("@@@");
        //napMilliSeconds(2000);
        Assert.fail("Should fail here.");

With the 'nap', all the prints appear, but in any case the assert is reached and fires.
I forgot to mention, this is within IntelliJ.

Thanks for looking,
Bill

From: Bill Ross [mailto:bil...@xo...]
Sent: Wednesday, October 23, 2013 11:31 AM
To: xml...@li...
Subject: [Xmlunit-general] Diff.similar() seems to cause thread to exit 50%+ of the time

I'm using XMLUnit 1.5/Java.

More often than not, the println below fails and the (testing) test ends with success without any more code being run:

            actualText = "<msg><uuid>0x00435A8C</uuid></msg>";             // debug
            expectedXmlString = "<msg><uuid>0x00435A8C</uuid></msg>";               // debug

                Diff myDiff = new Diff(XMLUnit.buildTestDocument(expectedXmlString), XMLUnit.buildTestDocument(actualText));
                myDiff.overrideElementQualifier(new RecursiveElementNameAndTextQualifier());
                if(differenceListener != null){
                    myDiff.overrideDifferenceListener(differenceListener);
                }
                System.out.println("@@@ similar: " + myDiff.similar());

If I slow it down in the debugger, it is more likely to succeed.
Same behavior without the DifferenceListener.

Any ideas? Same was seen in 1.3, upgrade didn't help.

Thanks,
Bill


---------------------------------------------------------------------------------

The information transmitted in this email is intended only for the person or entity to which it is addressed, and may contain material confidential to Xoom Corporation, and/or its subsidiary, buyindiaonline.com Inc.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient(s) is prohibited.   If you received this email in error, please contact the sender and delete the material from your files.


---------------------------------------------------------------------------------
The information transmitted in this email is intended only for the person or entity to which it is addressed, and may contain material confidential to Xoom Corporation, and/or its subsidiary, buyindiaonline.com Inc.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient(s) is prohibited.   If you received this email in error, please contact the sender and delete the material from your files.

[Xmlunit-general] Diff.similar() seems to cause thread to exit 50%+ of the time

[Bill R. <bil...@xo...>]

I'm using XMLUnit 1.5/Java.

More often than not, the println below fails and the (testing) test ends with success without any more code being run:

            actualText = "<msg><uuid>0x00435A8C</uuid></msg>";             // debug
            expectedXmlString = "<msg><uuid>0x00435A8C</uuid></msg>";               // debug

                Diff myDiff = new Diff(XMLUnit.buildTestDocument(expectedXmlString), XMLUnit.buildTestDocument(actualText));
                myDiff.overrideElementQualifier(new RecursiveElementNameAndTextQualifier());
                if(differenceListener != null){
                    myDiff.overrideDifferenceListener(differenceListener);
                }
                System.out.println("@@@ similar: " + myDiff.similar());

If I slow it down in the debugger, it is more likely to succeed.
Same behavior without the DifferenceListener.

Any ideas? Same was seen in 1.3, upgrade didn't help.

Thanks,
Bill



---------------------------------------------------------------------------------
The information transmitted in this email is intended only for the person or entity to which it is addressed, and may contain material confidential to Xoom Corporation, and/or its subsidiary, buyindiaonline.com Inc.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient(s) is prohibited.   If you received this email in error, please contact the sender and delete the material from your files.

[Xmlunit-general] XMLUnit for Java 1.5 released

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

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

This new release of XMLUnit for Java creates additional differences when
comparing nodes where one node has children and the other one has none.
While XMLUnit 1.4 would just report a HAS_CHILD_NODES difference,
XMLUnit 1.5 will - in addition - return raise a CHILD_NODELIST_LENGTH as
well as CHILD_NODE_NOT_FOUND differences for each missing node.

The release is available in source and binary form at
https://sourceforge.net/projects/xmlunit/files/xmlunit%20for%20Java/XMLUnit%20for%20Java%201.5/
,
checksums and OpenPGP signatures should be downloaded from
http://xmlunit.sourceforge.net/checksums/ .
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAlI29DkACgkQohFa4V9ri3I2lwCg0qklWFqA6t9inI5QKwrdP3N/
dJcAoIWv14UQvkL5coORSpw37RRvdECY
=NPo5
-----END PGP SIGNATURE-----

Re: [Xmlunit-general] Handling of comments outside the root element

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

On 2013-05-18, Arjan Kok wrote:

> Apparently, comments outside the root element are ignored. Is there a
> way to prevent this? I am using java 1.7, xmlunit version 1.4.

This is a known bug <http://sourceforge.net/p/xmlunit/bugs/48/>.

Cheers

        Stefan

[Xmlunit-general] Handling of comments outside the root element

[Arjan K. <arj...@gm...>]

Hi,

The following test fails.

  @Test
    public void testCommentOutsideRoot() throws Exception {

        String myControlXML = "<?xml version=\"1.0\"
encoding=\"utf-8\"?><xs:schema id=\"kvk_rpt-kvk-g\" xmlns:xs=\"
http://www.w3.org/2001/XMLSchema\"></xs:schema>";

        String myTestXML = "<?xml version=\"1.0\" encoding=\"utf-8\"?>*<!--
Release .. -->*<xs:schema id=\"kvk_rpt-kvk-g\" xmlns:xs=\"
http://www.w3.org/2001/XMLSchema\"></xs:schema>";

        assertXMLNotEqual("Comparing test xml to control xml",
myControlXML, myTestXML);
    }


However, the xml (which is valid) is clearly different. Apparently,
comments outside the root element are ignored. Is there a way to prevent
this? I am using java 1.7, xmlunit version 1.4.

Thanks & Regards,

Arjan Kok.

Re: [Xmlunit-general] XPathContext.getXPath taking bulk of compare time

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

On 2013-04-13, Stefan Bodewig wrote:

> On 2013-04-11, David Rees wrote:

>> On 4/11/13 1:06 PM, David Rees wrote:

>>> I've actually tracked it down to two things in the XPathContext.getXPath.

>>> The biggest is actually the "replace(SEP + SEP, SEP)". When I remove
>>> that my XMLUnit benchmarks go from 0.11 to 0.06. I haven't played with
>>> it enough yet to know enough about why that line is there so I can
>>> replace it.

> I don't recall under which circumstances it happens but there are
> certain edge cases.

The document node itself is used like an element named "" so there is an
initial Level with XPath "/" and when the document element is added we
get two consecutive slashes.  I've rewritten the XPath building to
account for the special case and avoind the replace call.

Actually there is an additional possibility for levels with empty names
in the default case of appendChildren - but I don't think that can be
triggered at all.

Stefan

Re: [Xmlunit-general] XPathContext.getXPath taking bulk of compare time

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

On 2013-04-13, Stefan Bodewig wrote:

>> On 4/11/13 1:06 PM, David Rees wrote:

>>> I also took a first crack at using dynamic programming to store the
>>> xpath expression in the Level objects. So its only computed once for
>>> each level. That took it from 0.06 to 0.04. A patch with that first
>>> crack is at https://sourceforge.net/p/xmlunit/bugs/61/.

> I'll look into it later this weekend.

I've committed your patch and ported it to C#.

Deque#descendingIterator is Java6 while I tried to keep the code base
compatible to Java5 so far.  That seemed to be a good idea three years
ago, not sure whether it really is anymore or whether Java6 as baseline
is acceptable.  If so we might question .NET 2.0 vs 3.5 as well.

Stefan

Re: [Xmlunit-general] how to ignore an attribute

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

On 04/12/2013 10:51 AM, David Rees wrote:
 > Is there a good hook for that in XMLUnit?

I don't know; if there is, I didn't use it.  I just massaged the
two DOM trees before getting XMLUnit involved.

   - Eric

Re: [Xmlunit-general] XPathContext.getXPath taking bulk of compare time

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

On 2013-04-11, David Rees wrote:

> On 4/11/13 1:06 PM, David Rees wrote:

>> I've actually tracked it down to two things in the XPathContext.getXPath.

>> The biggest is actually the "replace(SEP + SEP, SEP)". When I remove
>> that my XMLUnit benchmarks go from 0.11 to 0.06. I haven't played with
>> it enough yet to know enough about why that line is there so I can
>> replace it.

I don't recall under which circumstances it happens but there are
certain edge cases.  If you remove the line there should be failing unit
tests that should tell you why I introduced it.  Sorry, but I haven't
looked at the actual code for three years or so - and thank you for
working on it.

>> I also took a first crack at using dynamic programming to store the
>> xpath expression in the Level objects. So its only computed once for
>> each level. That took it from 0.06 to 0.04. A patch with that first
>> crack is at https://sourceforge.net/p/xmlunit/bugs/61/.

I'll look into it later this weekend.

> Actually, since the Comparison has the nodes themselves can't it just
> compute the xpath using them (on demand)? Are there cases where this
> wouldn't work?

TBH I modeled this after the XMLUnit 1.x difference engine which
calculates the XPath while walking the tree as well and never questioned
that design.  The trickies part would be knowing the sibblings on each
level (what to put into the sqare brackets of /foo/bar[...]/baz on the
XPath of a baz element) - this might benefit from some caching as you
suggest to do for Level instances.

Stefan