This also brings up a couple of more general issues about unit tests
and the functioning of the model. For unit tests, I think we should
avoid loading of external resources such as side files. This will
get around these types of issues as well as maintain a shorter run
time for the unit tests, some of which take as long as 6 seconds on
my pokey Mac. In some cases, eliminating loading of external
resources may not be possible, but then that is arguably an
integration test :-).
In terms of how the model works, what do people think about
refactoring it to be given a resource loader, which can provide
resources from anywhere, including from an in-memory source. For
example, in JavaImplementationImpl, the following code could be changed:
// todo load the sidefile using EMF - should this be
using SDO?
Resource res = new XMLResourceFactoryImpl
().createResource(URI.createURI(implClass.getName()));
res.load(sideFile, null);
DocumentRoot root = (DocumentRoot) res.getContents
().get(0);
componentType = (ComponentType) root.getComponentType
();
componentType.initialize(modelContext);
to something like:
ComponentType componentType = (ComponentType)
resourceLoader.loadResource(URI.createURI(implClass.getName()));
We could create resource loaders that just introspect the Java class
for specific unit tests, or that take a stream and parse the XML,
avoiding the need to access the file system.
Jim
On Jan 12, 2006, at 6:43 PM, Jean-Sebastien Delfino wrote:
Jack,
I'm just guessing, but maybe HelloWorldImpl.componentType (this is
the SCDL side file defining the HelloWorldImpl component type and
in particular its component property) is not found by the
classloader used to run the Junit test cases.
Can you try to add the following to JavaImplementationTestCase:
System.out.println(">>>>" + HelloWorldImpl.class.getResource
("HelloWorldImpl.componentType"));
and see what you get? My guess is that you get null in your
environment.
If it's the case, then we should look at how Maven 2 configures the
classloader used to run the Junit test cases, how you specify that
you want to include resources, where the resources should be, and
if the classloader sees resources under src/test/java or if they
have to be under src/test/resources.
Also I remember that at some point we ran into similar problems
with Maven 1.0.2 which forced us to move Maven 1.1b2 (the problem
was with the AntClassLoader used by Maven to run the Junit test
cases). We might be running into the same problem again with Maven
2.0 now...
Hope this helps.
--
Jean-Sebastien Delfino
Jeremy Boynes wrote:
[EMAIL PROTECTED] wrote:
Jeremy wrote:
Thanks for the update. The unit-tests might be failing
due to differences in the classpath between M1 and M2
- if you can post details of the failures we may be able
to help debug them.
This turned out to be due to my not yet realizing how to
configure the surefire plugin to specify the include patterns
for picking up *TestCase.java. I fixed that :-)
I'm now getting one failure in the runtime tests that I'm
not sure how to solve:
junit.framework.AssertionFailedError: expected:<1> but was:<0>
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:282)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:201)
at junit.framework.Assert.assertEquals(Assert.java:207)
at
org.apache.tuscany.container.java.assembly.impl.JavaImplementationTe
stCase.testHelloWorldWithSidefile(JavaImplementationTestCase.java:
88)
This might be because the xml sidefile
(HelloWorldImpl.componentType) is
not being copied to the classes directory. With M1 we had a custom
resource definition which added **/*.componentType from the source
tree
to the set of resources to include. This was done as people felt that
having the componentType file right next to the Java source was more
intuitive than having it in a separate tree.
I'd check target/classes and see if that file is there - if it isn't
then this testcase will fail.
--
Jeremy
