No it doesn't work.
The conflicting foundation classes are in some of the frameworks in ${wo.wosystemroot}/Library/Frameworks
Deleting all the frameworks I'm not currently using fixes the problem using any of the classpath sets so far specified. However, I can't do this on my production servers so for the time being, I've created an includesfile that explicitly selects jars only from those system frameworks that the project actually requires.
Unfortunately, this also means that I'm specifying the dependencies in two separate places.
--
Bill Michell
Development Team Leader, Broadcast Platforms, BBC News Interactive.
-----Original Message-----
From: Mike Schrag [mailto:mschrag@mdimension.com]
Sent: Tuesday, October 11, 2005 2:52 PM
To: woproject-dev@objectstyle.org
Subject: Re: Converting Frameworks into path-like structures in ant
If you remove your include of /Library/Frameworks and /System/Library/
Frameworks and replace it with the filesets in my email, does it
still not work? I don't know how conflicting Foundation classes
would get into your classpath otherwise ...
On Oct 11, 2005, at 9:28 AM, Bill Michell wrote:
> No joy - looks like that includesfile is adding stuff (perhaps no
> stuff) to the classpath rather than restricting it at all.
>
>
> --
> Bill Michell
> Development Team Leader, Broadcast Platforms, BBC News Interactive.
>
> -----Original Message-----
> From: Mike Schrag [mailto:mschrag@mdimension.com]
> Sent: Tuesday, October 11, 2005 2:18 PM
> To: woproject-dev@objectstyle.org
> Subject: Re: Converting Frameworks into path-like structures in ant
>
> Try:
>
> <fileset dir="$
> {wo.dir.user.home.library.frameworks}" includesfile = "woproject/
> ant.frameworks.user.home">
> <include name = "**/*.jar"/>
> </fileset>
> <fileset dir="${wo.wolocalroot}"
> includesfile = "woproject/ant.frameworks.wo.wolocalroot">
> <include name = "**/*.jar"/>
> </fileset>
> <fileset dir="${wo.wosystemroot}"
> includesfile = "woproject/ant.frameworks.wo.wosystemroot">
> <include name = "**/*.jar"/>
> </fileset>
> <fileset dir = "yourotherfolder">
> <include name="**/*.jar"/>
> </fileset>
>
> On Oct 11, 2005, at 9:12 AM, Bill Michell wrote:
>
>
>> I’m trying to add unit tests to my ant automated build scripts.
>>
>> The unit testing framework provides its own custom ant task, which
>> expects to be told the runtime classpath for the unit tests using a
>> path-like structure.
>>
>> Obviously, the task knows nothing about the <frameworks> element.
>>
>>
>> Superficially, the following seems to work:
>> <classpath>
>> <fileset dir="${wo.wosystemroot}/Library/Frameworks">
>> <include name="**/*.jar" />
>> <include name="**/*.zip" />
>> </fileset>
>> <fileset dir="${wo.wolocalroot}/Library/Frameworks">
>> <include name="**/*.jar" />
>> <include name="**/*.zip" />
>> </fileset>
>> <fileset dir="${dest.dir}">
>> <include name="**/*.jar" />
>> <include name="**/*.zip" />
>> </fileset>
>> </classpath>
>>
>> Unfortunately, I then hit a problem with the SecurityManager when
>> referring to certain classes in JavaFoundation.framework, notably
>> NSBundle.
>>
>> There also seems to be a version of NSBundle in
>> Foundation.framework, and incompatible signatures mean the test
>> simply won't execute; the java runtime aborts it with a
>> SecurityException.
>>
>> Obviously, traversing such large directory structures also takes
>> significant time.
>>
>> So my question is how best I can convert the dependencies expressed
>> in the woproject/ant.frameworks.wo.wosystemroot into a path-like
>> structure for my testing task to use.
>>
>> I notice that the wocompile task actually goes so far as to
>> subclass the javac task in order to add this framework classpath
>> expansion. Is there some simpler way for me to achieve my goal?
>>
>>
>>
>> --
>> Bill Michell
>> Development Team Leader, Broadcast Platforms, BBC News Interactive.
>> Work: 020 8 752 6850
>> Room 1468, BBC White City, Wood Lane, London. W12 7TS
>> mailto:Bill.Michell@bbc.co.uk (Work)
>> mailto:bill@mics.org.uk (Home)
>> mailto:billm1@orange.net (Mobile)
>>
>>
>>
>> http://www.bbc.co.uk/
>>
>> This e-mail (and any attachments) is confidential and may contain
>> personal views which are not the views of the BBC unless specifically
>> stated.
>> If you have received it in error, please delete it from your system.
>> Do not use, copy or disclose the information in any way nor act in
>> reliance on it and notify the sender immediately. Please note that
>> the
>> BBC monitors e-mails sent or received.
>> Further communication will signify your consent to this.
>>
>>
>
>
>
>
> http://www.bbc.co.uk/
>
> This e-mail (and any attachments) is confidential and may contain
> personal views which are not the views of the BBC unless specifically
> stated.
> If you have received it in error, please delete it from your system.
> Do not use, copy or disclose the information in any way nor act in
> reliance on it and notify the sender immediately. Please note that the
> BBC monitors e-mails sent or received.
> Further communication will signify your consent to this.
>
http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain
personal views which are not the views of the BBC unless specifically
stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in
reliance on it and notify the sender immediately. Please note that the
BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
This archive was generated by hypermail 2.0.0 : Tue Oct 11 2005 - 10:04:38 EDT