Re: Bundle loading during unit testing outside Eclipse
Re: Bundle loading during unit testing outside Eclipse
- Subject: Re: Bundle loading during unit testing outside Eclipse
- From: Chuck Hill <email@hidden>
- Date: Tue, 20 Sep 2011 15:21:00 -0700
On 2011-09-20, at 1:57 AM, Paul Hoadley wrote:
> On 20/09/2011, at 7:33 AM, Chuck Hill wrote:
>
>>>>> That is, it can't find JavaMemoryAdaptor.framework when it needs it. I'm having this problem when running unit tests in both application and framework bundles of my own. JavaMemoryAdaptor.framework is on the .classpath (confirmed by running 'ant -v'),
>>>>
>>>> The jar file in Resources/Java is on the classpath? That is what gets used to locate the bundle.
>>>
>>> Yes. This is in Ant's classpath as it's running the test case:
>>>
>>> /Users/paulh/tmp/WT/workspace/Root/Library/Frameworks/JavaMemoryAdaptor.framework/Resources/Java/JavaMemoryAdaptor.jar
>>
>> And that file is really there and you have permissions? :-)
>
> Yep.
>
>>>> I doubt this is a WOUnit problem. For Hudson, are you wanting to use the source project as the bundle (project bundles enabled) or the built .woa or .framework directory as the bundle? If you can tell me how you have things setup, I should be able to help you figure out what needs to be done.
>>>
>>> I'm using the .woa directory as the bundle.
>>
>> The .woa directory inside the source project (dist/Foo.woa)? Or built someplace else?
>
> The former. The source project gets checked out into a Hudson workspace, and it builds in dist/WT2.woa. (Yes, the WO project name differs from the Hudson project name by one character, which is why the paths I've quoted just have "WT" in them. In retrospect this is not ideal, but I don't _think_ it's causing any problems.)
So the project is at /whatever/WT/ and built into /whatever/WT/dist/WT2.woa? That might cause confusion. Are the frameworks embedded in that bundle? I am trying to work out how NSBundle is not seeing these. There are some Funky Things (tm) in Eclipse to detect bundles that don't happen when run from the comment line.
>>> I call junit like this:
>>>
>>> <junit haltonfailure="false"
>>> fork="true"
>>> dir="${dest.dir}/${project.name}.woa"
>>> printsummary="true"
>>> failureproperty="test.failed">
>>> <classpath refid="testing.classpath" />
>>> <classpath>
>>> <pathelement location="bin" />
>>
>> What is that for? Those are the compiled classes in the app?
>
> Exactly. Does that not need to be there?
I think this might make main bundle identification hard. Though that does not seem to be the issue. I'd use
<pathelement location="${dest.dir}/${project.name}.woa/Contents/Resources/Java/${project.name}.jar" />
(or is that ${project.name.lowercase}.jar ?)
>>> <pathelement location="${junit.jar}" />
>>> <pathelement location="${wounit.jar}" />
>>> <pathelement location="${bin.tests}" />
Those should be OK if those are not built into the project jar.
>>> <!-- WTModel models -->
>>> <pathelement location="Root/Library/Frameworks/WTModel.framework" />
>>> </classpath>
>>> <formatter type="brief" usefile="false" />
>>> <formatter type="xml" />
>>> <batchtest todir="${junit.results}">
>>> <fileset dir="${bin.tests}">
>>> <include name="**/*Test.class" />
>>> </fileset>
>>> </batchtest>
>>> </junit>
>>>
>>> There's a bit of additional stuff in the 'junit' target (test results and so on), but I doubt it's relevant. 'testing.classpath' is defined like this:
>>>
>>> <typedef name="wopath" classname="org.objectstyle.woproject.ant.WOPath" />
>>> <wopath id="testing.classpath">
>>> <frameworks root="User" eclipse="true" />
>>> <frameworks root="Local" eclipse="true" />
>>> <frameworks root="System" eclipse="true" />
>>> </wopath>
>>
>> It sounds like that this your problem. I think this is only going to work if you are running this in the project source dir where the .classpath file is. Is that the case?
>
> Yes… well, I think so. Define "running this". :-) That's where Hudson and I are launching 'ant … junit' from, but in the junit task I have the dir="${dest.dir}/${project.name}.woa" attribute.
That should get evaluated in the context of the project then and be OK.
>
>> Try adding
>> <pathconvert property="junit.testing.classpath" refid="testing.classpath"/>
>> <echo> testing.classpath is ${testing.classpath} />
>>
>> And see if the result is what you expect.
>
> Did you mean ${junit.testing.classpath}?
er, yes. That one.
> Yes, it's exactly what I would expect: all of the frameworks, including JavaMemoryAdapter.framework/Resources/Java/JavaMemoryAdaptor.jar.
Relative or absolute paths?
> They're also all on the classpath for the JVM that's launching the JUnit tests, so that all seems to be working.
Well, you are forking the JVM for junit.
> The only place they're _not_ is wherever they need to be to get NSBundle to load them. I remain stumped.
Try getting the classloader in one of your tests and print out the classpath that it really is using.
Chuck
--
Chuck Hill Senior Consultant / VP Development
Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden