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" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727 C: 508-380-7194 F:781-902-8001 [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
