> -----Original Message-----
> From: Jon Elson-Green [mailto:[EMAIL PROTECTED]
>
> Stephen McConnell wrote:
>
> > Jon Elson-Green wrote:
> >
> >> Now that I've had a test case fail, how can I achieve jar:install
> >> when I can't achieve test:test because Merlin is only looking
> >> at jars in the repository, (chicken and the egg paradox)?
> >> Is there a way to get it to use target/classes?
> >
> >
> > The test is already using target/classes. If you add a
> > merlin.properties file to the working directory and add
> >
> Indeed, in fact it's some classloader strangeness which I don't
> quite grok.
> I'm unable to load a dynamic class from a jar that's in the block inside
> the
> testcase though I am able to load the same class outside of junit.
>
Sounds a lot like the exact same problem I had with AbstractMerlinTestCase
some months ago (you could search this list for messages by me containing
AbstractMerlinTestCase). The long and short of it was, IIRC: Don't declare
Merlin IMPLEMENTATION classes as dependencies in Maven, i.e. NO
<dependency>
<groupId>merlin</groupId>
<artifactId>merlin-impl</artifactId>
<version>3.3</version>
</dependency>
in your project.xml. I am not sure I completely understand what's going on
here, but this is what I gleaned from Stephen's words: The Merlin CL becomes
a child CL of the Maven CL. Now suppose a Merlin implementation class A
loaded by the Merlin CL references a class B loaded by the Maven CL. B in
turn references a Merlin implementation class C already loaded by the Merlin
CL. Now C/MavenCL and C/MerlinCL are two different classes and you will get
a rather strange CL related error. I think this is the reason why
AbstractMerlinTestCase uses reflection and does not reference the Merlin
implementation classes directly.
Take care,
Olaf
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
