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
>