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 protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
