You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2006/06/22 14:34:08 UTC
XML Comparison
I want to add a little automated testing to the interop suite to compare
input XML files with output XML files. I note that there is XML comparison
function in
org.apache.tuscany.sdo.test.TestUtil
However this test compares everything and I am hitting the problem which is
touched on in http://issues.apache.org/jira/browse/TUSCANY-427, i.e. my
input xml files have comments and my output XML files don't so the current
equalXML... function always returns false. For my local testing what I have
done is edited the class to:
1/ Change all the static operations to non static operations
2/ Add a member variable to describe what should be ignored when testing for
equality
3/ Add outputs in each failure case to record what causes XML files to be
marked as not equal
4/ Added a string output stream member variable to capture all of this
output
5/ Added a getReport method to return the contents of this output stream if
you are interested in why the XMLs differ
Now this is all very well and good but of course this breaks anything that
relies on this class having static methods (it's used in about 50 places).
So I can make a slight change to maintain the static interface. The question
is would you rather I:
A/ Make a special version for me and not patch the original (not ideal)
B/ Create a patch for the original
As an aside there already seems to be two copies of this file, in:
tuscany\java\sdo\impl\src\test\java\org\apache\tuscany\sdo\test
tuscany\java\sdo\tools\src\test\java\org\apache\tuscany\sdo\test
Is there a good reason for this? If not, which one stays?
Simon
Re: XML Comparison
Posted by ant elder <an...@gmail.com>.
It has a BSD style license so it would likely be fine even if we did want to
redistribute it, but as you say, we'll only be using it for testing.
If its sounds like it suits you're needs I'd say go for it. Its in ibiblio
so just add it to your pom.xml:
<dependency>
<artifactId>xmlunit</artifactId>
<groupId>xmlunit</groupId>
<version>1.0</version>
<scope>test</scope>
</dependency>
...ant
On 6/23/06, Simon Laws <si...@googlemail.com> wrote:
>
> Hi ant, what is the process to determine whether the license for this
> piece
> of software is acceptable for use during Tuscany development. I assume, if
> we use it, we woudln't use it during runtime and hence wouldn't need to
> redistribute or reference it from released packages.
>
> S
>
> On 6/22/06, ant elder <an...@gmail.com> wrote:
> >
> > What about using http://xmlunit.sourceforge.net/, i think some of the
> > other
> > Apache WS projects use that.
> >
> > ...ant
> >
> > On 6/22/06, Simon Laws <si...@googlemail.com> wrote:
> > >
> > > I want to add a little automated testing to the interop suite to
> compare
> > > input XML files with output XML files. I note that there is XML
> > comparison
> > > function in
> > >
> > > org.apache.tuscany.sdo.test.TestUtil
> > >
> > > However this test compares everything and I am hitting the problem
> which
> > > is
> > > touched on in http://issues.apache.org/jira/browse/TUSCANY-427, i.e.
> my
> > > input xml files have comments and my output XML files don't so the
> > current
> > > equalXML... function always returns false. For my local testing what I
> > > have
> > > done is edited the class to:
> > >
> > > 1/ Change all the static operations to non static operations
> > > 2/ Add a member variable to describe what should be ignored when
> testing
> > > for
> > > equality
> > > 3/ Add outputs in each failure case to record what causes XML files to
> > be
> > > marked as not equal
> > > 4/ Added a string output stream member variable to capture all of this
> > > output
> > > 5/ Added a getReport method to return the contents of this output
> stream
> > > if
> > > you are interested in why the XMLs differ
> > >
> > > Now this is all very well and good but of course this breaks anything
> > that
> > > relies on this class having static methods (it's used in about 50
> > places).
> > > So I can make a slight change to maintain the static interface. The
> > > question
> > > is would you rather I:
> > >
> > > A/ Make a special version for me and not patch the original (not
> ideal)
> > > B/ Create a patch for the original
> > >
> > > As an aside there already seems to be two copies of this file, in:
> > >
> > > tuscany\java\sdo\impl\src\test\java\org\apache\tuscany\sdo\test
> > > tuscany\java\sdo\tools\src\test\java\org\apache\tuscany\sdo\test
> > >
> > > Is there a good reason for this? If not, which one stays?
> > >
> > > Simon
> > >
> > >
> >
> >
>
>
Re: XML Comparison
Posted by Simon Laws <si...@googlemail.com>.
Hi ant, what is the process to determine whether the license for this piece
of software is acceptable for use during Tuscany development. I assume, if
we use it, we woudln't use it during runtime and hence wouldn't need to
redistribute or reference it from released packages.
S
On 6/22/06, ant elder <an...@gmail.com> wrote:
>
> What about using http://xmlunit.sourceforge.net/, i think some of the
> other
> Apache WS projects use that.
>
> ...ant
>
> On 6/22/06, Simon Laws <si...@googlemail.com> wrote:
> >
> > I want to add a little automated testing to the interop suite to compare
> > input XML files with output XML files. I note that there is XML
> comparison
> > function in
> >
> > org.apache.tuscany.sdo.test.TestUtil
> >
> > However this test compares everything and I am hitting the problem which
> > is
> > touched on in http://issues.apache.org/jira/browse/TUSCANY-427, i.e. my
> > input xml files have comments and my output XML files don't so the
> current
> > equalXML... function always returns false. For my local testing what I
> > have
> > done is edited the class to:
> >
> > 1/ Change all the static operations to non static operations
> > 2/ Add a member variable to describe what should be ignored when testing
> > for
> > equality
> > 3/ Add outputs in each failure case to record what causes XML files to
> be
> > marked as not equal
> > 4/ Added a string output stream member variable to capture all of this
> > output
> > 5/ Added a getReport method to return the contents of this output stream
> > if
> > you are interested in why the XMLs differ
> >
> > Now this is all very well and good but of course this breaks anything
> that
> > relies on this class having static methods (it's used in about 50
> places).
> > So I can make a slight change to maintain the static interface. The
> > question
> > is would you rather I:
> >
> > A/ Make a special version for me and not patch the original (not ideal)
> > B/ Create a patch for the original
> >
> > As an aside there already seems to be two copies of this file, in:
> >
> > tuscany\java\sdo\impl\src\test\java\org\apache\tuscany\sdo\test
> > tuscany\java\sdo\tools\src\test\java\org\apache\tuscany\sdo\test
> >
> > Is there a good reason for this? If not, which one stays?
> >
> > Simon
> >
> >
>
>
Re: XML Comparison
Posted by ant elder <an...@gmail.com>.
What about using http://xmlunit.sourceforge.net/, i think some of the other
Apache WS projects use that.
...ant
On 6/22/06, Simon Laws <si...@googlemail.com> wrote:
>
> I want to add a little automated testing to the interop suite to compare
> input XML files with output XML files. I note that there is XML comparison
> function in
>
> org.apache.tuscany.sdo.test.TestUtil
>
> However this test compares everything and I am hitting the problem which
> is
> touched on in http://issues.apache.org/jira/browse/TUSCANY-427, i.e. my
> input xml files have comments and my output XML files don't so the current
> equalXML... function always returns false. For my local testing what I
> have
> done is edited the class to:
>
> 1/ Change all the static operations to non static operations
> 2/ Add a member variable to describe what should be ignored when testing
> for
> equality
> 3/ Add outputs in each failure case to record what causes XML files to be
> marked as not equal
> 4/ Added a string output stream member variable to capture all of this
> output
> 5/ Added a getReport method to return the contents of this output stream
> if
> you are interested in why the XMLs differ
>
> Now this is all very well and good but of course this breaks anything that
> relies on this class having static methods (it's used in about 50 places).
> So I can make a slight change to maintain the static interface. The
> question
> is would you rather I:
>
> A/ Make a special version for me and not patch the original (not ideal)
> B/ Create a patch for the original
>
> As an aside there already seems to be two copies of this file, in:
>
> tuscany\java\sdo\impl\src\test\java\org\apache\tuscany\sdo\test
> tuscany\java\sdo\tools\src\test\java\org\apache\tuscany\sdo\test
>
> Is there a good reason for this? If not, which one stays?
>
> Simon
>
>
Re: XML Comparison
Posted by Simon Laws <si...@googlemail.com>.
Doh, thanks Oisin. I was looking in the wrong file.
S
On 6/23/06, Oisin Hurley <oh...@iona.com> wrote:
>
>
> On 22 Jun 2006, at 22:24, Simon Laws wrote:
>
> > Thanks Oisin, I don't seen anything at [1] that specifically mentions
> > canonicalization. Is the sample code you refer to the
> > DocumentTracer.java?
>
> The code itself is just a writer, but it has an option to have the
> output canonicalized - if you look in the java src [0] you will
> see
>
> /** Sets whether output is canonical. */
> public void setCanonical(boolean canonical) {
> fCanonical = canonical;
> } // setCanonical(boolean)
>
>
> regards
> Oisin
>
>
> [0] http://svn.apache.org/viewvc/xerces/java/trunk/samples/sax/
> Writer.java?view=markup
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: XML Comparison
Posted by Oisin Hurley <oh...@iona.com>.
On 22 Jun 2006, at 22:24, Simon Laws wrote:
> Thanks Oisin, I don't seen anything at [1] that specifically mentions
> canonicalization. Is the sample code you refer to the
> DocumentTracer.java?
The code itself is just a writer, but it has an option to have the
output canonicalized - if you look in the java src [0] you will
see
/** Sets whether output is canonical. */
public void setCanonical(boolean canonical) {
fCanonical = canonical;
} // setCanonical(boolean)
regards
Oisin
[0] http://svn.apache.org/viewvc/xerces/java/trunk/samples/sax/
Writer.java?view=markup
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: XML Comparison
Posted by Simon Laws <si...@googlemail.com>.
Thanks Oisin, I don't seen anything at [1] that specifically mentions
canonicalization. Is the sample code you refer to the DocumentTracer.java?
S
On 6/22/06, Oisin Hurley <oh...@iona.com> wrote:
>
> Hi Simon,
>
> > However this test compares everything and I am hitting the problem
> > which is
> > touched on in http://issues.apache.org/jira/browse/TUSCANY-427,
> > i.e. my
> > input xml files have comments and my output XML files don't so the
> > current
> > equalXML... function always returns false.
>
> What might be useful here is some XML Canonicalization (c14n) code that
> will munge both XML sources to a canonical form and then compare
> those forms.
> This does things like elide extraneous whitespace in the elements,
> reorder attributes using a particular algorithm, optionally remove
> comments and that kind of thing. The Canonical XML spec is at [0],
> but you might be more interested in the example implementation which you
> can find in the Xerces samples at [1]. A candidate for that testutils
> jar that Dan was talking about, perhaps.
>
> regards
> Oisin
>
> [0] http://www.w3.org/TR/xml-c14n
> [1] http://svn.apache.org/viewvc/xerces/java/trunk/samples/sax/
> Writer.java
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: XML Comparison
Posted by Oisin Hurley <oh...@iona.com>.
Hi Simon,
> However this test compares everything and I am hitting the problem
> which is
> touched on in http://issues.apache.org/jira/browse/TUSCANY-427,
> i.e. my
> input xml files have comments and my output XML files don't so the
> current
> equalXML... function always returns false.
What might be useful here is some XML Canonicalization (c14n) code that
will munge both XML sources to a canonical form and then compare
those forms.
This does things like elide extraneous whitespace in the elements,
reorder attributes using a particular algorithm, optionally remove
comments and that kind of thing. The Canonical XML spec is at [0],
but you might be more interested in the example implementation which you
can find in the Xerces samples at [1]. A candidate for that testutils
jar that Dan was talking about, perhaps.
regards
Oisin
[0] http://www.w3.org/TR/xml-c14n
[1] http://svn.apache.org/viewvc/xerces/java/trunk/samples/sax/
Writer.java
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: XML Comparison
Posted by Simon Laws <si...@googlemail.com>.
OK, thanks Dan
If I interpret what you are saying correctly, while, in this particular
case, the tuscany\java\sdo\tools project depends on the
tuscany\java\sdo\impl project (actually the tuscany-sdo-impl artifact) the
test resource of the impl project are not included so someone was forced to
make a manual copy of the file in question.
Of your options IMHO the first one sounds most practical to me.
S
On 6/22/06, Daniel Kulp <da...@iona.com> wrote:
>
>
> It's a maven thing that causes this type of duplication. Maven only
> puts
> the non-test code of one project on the classpath of the other. Thus,
> the
> file in the first project is not usable in the second.
>
> There are two ways around it:
>
> 1) Create a new "testutils" project that creates a jar of test utilites.
> One
> project can depend on that with scope of tests.
>
> 2) Force creation of a "test-jar" in the first project. Basically, add
> jar:test-jar to the package lifecycle. Then depend on that in the test
> scope with a test classifier. The problem is, this REQUIRES an "install"
> in
> the first project to get the jar in place. A "mvn test" won't work as
> maven
> still won't put the stuff in target/classes-test on the classpath.
>
> I know Jeremy, Jim, and I discussed something similar when I started the
> Celtix stuff. There are a bunch of "mock" objects that are duplicated in
> several of the SCA projects for the same reason. We have considered
> pulling
> them out into a testutils project to remove some of that duplication.
>
> Dan
>
>
> On Thursday June 22 2006 9:47 am, Frank Budinsky wrote:
> > Simon, I think that a patch with your changes sounds good. We were
> already
> > thinking that we will want an ignoreComments option anyway.
> >
> > I'm not sure how there got to be two versions. Jeremy added the first
> one
> > (in the impl project), I believe. Not sure when the tools one crept in,
> > but since the tools project depends on the impl project, I would think
> > that it should be able to reuse the one from there - unless there's
> > something special about it. Does anybody know why there are two?
> >
> > Frank.
> >
> > "Simon Laws" <si...@googlemail.com> wrote on 06/22/2006 08:34:08
> AM:
> > > I want to add a little automated testing to the interop suite to
> compare
> > > input XML files with output XML files. I note that there is XML
> >
> > comparison
> >
> > > function in
> > >
> > > org.apache.tuscany.sdo.test.TestUtil
> > >
> > > However this test compares everything and I am hitting the problem
> which
> >
> > is
> >
> > > touched on in http://issues.apache.org/jira/browse/TUSCANY-427, i.e.
> my
> > > input xml files have comments and my output XML files don't so the
> >
> > current
> >
> > > equalXML... function always returns false. For my local testing what I
> >
> > have
> >
> > > done is edited the class to:
> > >
> > > 1/ Change all the static operations to non static operations
> > > 2/ Add a member variable to describe what should be ignored when
> testing
> >
> > for
> >
> > > equality
> > > 3/ Add outputs in each failure case to record what causes XML files to
> >
> > be
> >
> > > marked as not equal
> > > 4/ Added a string output stream member variable to capture all of this
> > > output
> > > 5/ Added a getReport method to return the contents of this output
> stream
> >
> > if
> >
> > > you are interested in why the XMLs differ
> > >
> > > Now this is all very well and good but of course this breaks anything
> >
> > that
> >
> > > relies on this class having static methods (it's used in about 50
> >
> > places).
> >
> > > So I can make a slight change to maintain the static interface. The
> >
> > question
> >
> > > is would you rather I:
> > >
> > > A/ Make a special version for me and not patch the original (not
> ideal)
> > > B/ Create a patch for the original
> > >
> > > As an aside there already seems to be two copies of this file, in:
> > >
> > > tuscany\java\sdo\impl\src\test\java\org\apache\tuscany\sdo\test
> > > tuscany\java\sdo\tools\src\test\java\org\apache\tuscany\sdo\test
> > >
> > > Is there a good reason for this? If not, which one stays?
> > >
> > > Simon
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> --
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727 C: 508-380-7194 F:781-902-8001
> daniel.kulp@iona.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Tests & Mocks, was: XML Comparison
Posted by Jeremy Boynes <jb...@apache.org>.
Daniel Kulp wrote:
>
> I know Jeremy, Jim, and I discussed something similar when I started the
> Celtix stuff. There are a bunch of "mock" objects that are duplicated in
> several of the SCA projects for the same reason. We have considered pulling
> them out into a testutils project to remove some of that duplication.
>
In the sandbox there is a "test" module that does just that - it
provides mock implementations of things from the SPI so that you can
test against it.
We have also started to use jMock as a mock-object framework. It is able
to generate mock implementations that automatically validate that they
are being called correctly. It takes a lot of the work out of mocking
things up.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: XML Comparison
Posted by Daniel Kulp <da...@iona.com>.
It's a maven thing that causes this type of duplication. Maven only puts
the non-test code of one project on the classpath of the other. Thus, the
file in the first project is not usable in the second.
There are two ways around it:
1) Create a new "testutils" project that creates a jar of test utilites. One
project can depend on that with scope of tests.
2) Force creation of a "test-jar" in the first project. Basically, add
jar:test-jar to the package lifecycle. Then depend on that in the test
scope with a test classifier. The problem is, this REQUIRES an "install" in
the first project to get the jar in place. A "mvn test" won't work as maven
still won't put the stuff in target/classes-test on the classpath.
I know Jeremy, Jim, and I discussed something similar when I started the
Celtix stuff. There are a bunch of "mock" objects that are duplicated in
several of the SCA projects for the same reason. We have considered pulling
them out into a testutils project to remove some of that duplication.
Dan
On Thursday June 22 2006 9:47 am, Frank Budinsky wrote:
> Simon, I think that a patch with your changes sounds good. We were already
> thinking that we will want an ignoreComments option anyway.
>
> I'm not sure how there got to be two versions. Jeremy added the first one
> (in the impl project), I believe. Not sure when the tools one crept in,
> but since the tools project depends on the impl project, I would think
> that it should be able to reuse the one from there - unless there's
> something special about it. Does anybody know why there are two?
>
> Frank.
>
> "Simon Laws" <si...@googlemail.com> wrote on 06/22/2006 08:34:08 AM:
> > I want to add a little automated testing to the interop suite to compare
> > input XML files with output XML files. I note that there is XML
>
> comparison
>
> > function in
> >
> > org.apache.tuscany.sdo.test.TestUtil
> >
> > However this test compares everything and I am hitting the problem which
>
> is
>
> > touched on in http://issues.apache.org/jira/browse/TUSCANY-427, i.e. my
> > input xml files have comments and my output XML files don't so the
>
> current
>
> > equalXML... function always returns false. For my local testing what I
>
> have
>
> > done is edited the class to:
> >
> > 1/ Change all the static operations to non static operations
> > 2/ Add a member variable to describe what should be ignored when testing
>
> for
>
> > equality
> > 3/ Add outputs in each failure case to record what causes XML files to
>
> be
>
> > marked as not equal
> > 4/ Added a string output stream member variable to capture all of this
> > output
> > 5/ Added a getReport method to return the contents of this output stream
>
> if
>
> > you are interested in why the XMLs differ
> >
> > Now this is all very well and good but of course this breaks anything
>
> that
>
> > relies on this class having static methods (it's used in about 50
>
> places).
>
> > So I can make a slight change to maintain the static interface. The
>
> question
>
> > is would you rather I:
> >
> > A/ Make a special version for me and not patch the original (not ideal)
> > B/ Create a patch for the original
> >
> > As an aside there already seems to be two copies of this file, in:
> >
> > tuscany\java\sdo\impl\src\test\java\org\apache\tuscany\sdo\test
> > tuscany\java\sdo\tools\src\test\java\org\apache\tuscany\sdo\test
> >
> > Is there a good reason for this? If not, which one stays?
> >
> > Simon
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194 F:781-902-8001
daniel.kulp@iona.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: XML Comparison
Posted by Frank Budinsky <fr...@ca.ibm.com>.
Simon, I think that a patch with your changes sounds good. We were already
thinking that we will want an ignoreComments option anyway.
I'm not sure how there got to be two versions. Jeremy added the first one
(in the impl project), I believe. Not sure when the tools one crept in,
but since the tools project depends on the impl project, I would think
that it should be able to reuse the one from there - unless there's
something special about it. Does anybody know why there are two?
Frank.
"Simon Laws" <si...@googlemail.com> wrote on 06/22/2006 08:34:08 AM:
> I want to add a little automated testing to the interop suite to compare
> input XML files with output XML files. I note that there is XML
comparison
> function in
>
> org.apache.tuscany.sdo.test.TestUtil
>
> However this test compares everything and I am hitting the problem which
is
> touched on in http://issues.apache.org/jira/browse/TUSCANY-427, i.e. my
> input xml files have comments and my output XML files don't so the
current
> equalXML... function always returns false. For my local testing what I
have
> done is edited the class to:
>
> 1/ Change all the static operations to non static operations
> 2/ Add a member variable to describe what should be ignored when testing
for
> equality
> 3/ Add outputs in each failure case to record what causes XML files to
be
> marked as not equal
> 4/ Added a string output stream member variable to capture all of this
> output
> 5/ Added a getReport method to return the contents of this output stream
if
> you are interested in why the XMLs differ
>
> Now this is all very well and good but of course this breaks anything
that
> relies on this class having static methods (it's used in about 50
places).
> So I can make a slight change to maintain the static interface. The
question
> is would you rather I:
>
> A/ Make a special version for me and not patch the original (not ideal)
> B/ Create a patch for the original
>
> As an aside there already seems to be two copies of this file, in:
>
> tuscany\java\sdo\impl\src\test\java\org\apache\tuscany\sdo\test
> tuscany\java\sdo\tools\src\test\java\org\apache\tuscany\sdo\test
>
> Is there a good reason for this? If not, which one stays?
>
> Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org