If you have a suggestion on how to make this not suck, let me know
and we can look at adding it in to the core ...
On Oct 11, 2005, at 10:04 AM, Bill Michell wrote:
> 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:mschra..dimension.com]
> Sent: Tuesday, October 11, 2005 2:52 PM
> To: woproject-de..bjectstyle.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:mschra..dimension.com]
>> Sent: Tuesday, October 11, 2005 2:18 PM
>> To: woproject-de..bjectstyle.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.Michel..bc.co.uk (Work)
>>> mailto:bil..ics.org.uk (Home)
>>> mailto:billm..range.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:20:33 EDT