On Mar 19, 2008, at 8:18 AM, Archibald Singleton wrote:
> On 18 Mar 2008, at 14:51, Chuck Hill wrote:
>> On Mar 18, 2008, at 6:12 AM, Archibald Singleton wrote:
>>> On 17 Mar 2008, at 17:16, Xavier Destombes wrote:
>>>
>>>>>>> It seems to work, but now I can't make my project compile
>>>>>>> because it looks like the frameworks in /User (53) have a
>>>>>>> higher priority than the ones in /Library (Wonder ones)...
>>>>>>> And I can't make them behave like the ones in /System...
>>>>>>>
>>>>>>> Xavier... lost
>>>>>>
>>>>>> Put them in /Library then, but don't copy JavaWebObjects. I
>>>>>> have all of my frameworks (including Wonder) installed in ~/
>>>>>> Library/Frameworks.
>>>>> That doesn't seem right ... There is no difference between the
>>>>> ones in System and frameworks being somewhere else. It's
>>>>> controlled entirely by that wobuild.properties setting. You're
>>>>> not doing something right, but I don't know what.
>>>>
>>>> Actually I have removed my build.properties file from /Users but
>>>> still have my classpath files written with HOMEROOT instead of
>>>> WOROOT?!
>>>>
>>>> Anyway, it won't save what I check in the jars in the build path
>>>> between restart...
>>>>
>>>> My build.properties was just:
>>>> -----
>>>> wo.wosystemroot = /Users/xavier/
>>>> -----
>>>
>>> You'll want to make sure that the corresponding directory in your
>>> file system needs has the same layout as original WO System
>>> Frameworks layout e.g. /User/xavier/Library/Frameworks/...
>>>
>>> Also if you want your apps to automatically open in the brower,
>>> you'll need to have /User/xavier/System/Library/WebObjects/
>>> Executables/WOOpenURL point to /usr/bin/open
>>
>> Isn't that /User/xavier/Library/WebObjects/Executables/WOOpenURL
>> (no System, IIRC)
>
> Oops, copy/paste typo, sorry. Yes, your path above would be the
> correct one.
>
>> It also depends on how you do it.
>
> Indeed.
That is a problem with WOLips: there are many, many ways to build and
run an app. This is great when you need the flexibility, but makes it
easy to create problems for yourself.
>> For WOLips, I include the frameworks in my home dir. That is what
>> gets loaded when run from Eclipse:
>>
>>> /Users/chuck/Library/Frameworks/JavaEOAccess.framework/Resources/
>>> Java/javaeoaccess.jar
>>> --> Exists
>>> /Users/chuck/Library/Frameworks/JavaEOControl.framework/Resources/
>>> Java/javaeocontrol.jar
>>> --> Exists
>
>> I define wo.wosystemroot in my project's build.xml (actually, a
>> common build.xml) so it is set correct for the Ant builder.
>>
>> WOOpenURL is used from /System/Library
>
> How do you do that?
First, I have a very custom (and strange) build. I also only use the
Ant builder and not the incremental builder.
I don't think that WOLips particularly cares what wo.wosystemroot is.
If you have JavaWebObjects.framework in ~/Library/Frameworks and in /
System/Library/Frameworks, it should pick up the one in ~/Library/
Frameworks. That is what it does for me. wo.wosystemroot gets passed
to the running app, which uses it to look up WOOpenURL. So in ~/
Library/wobuild.properties, I have
wo.wosystemroot=/System
In my build.xml, I have:
<!-- Hack to use WO 5.3.3 on Leopard, remove when good 5.4 released -->
<property name="wo.wosystemroot" value="${user.home}"/>
And in the app task:
<frameworks embed="true"
dir="${system.frameworks.path}"
bundles="${system.frameworks}" />
> After I started using a custom directory for the WO System
> Frameworks, I noticed that Eclipse would print an error message
> mentioning that WOOpenURL could not be found when launching my apps.
> And the apps would of course no longer automatically open in the
> browser (even though I had a WOOpenURL symlink under /System/
> Library...).
>
> It's only weeks later that it occurred to me that maybe it was
> looking for WOOpenURL in my custom WO system frameworks dir (the one
> specified by wo.wosystemroot). After I created the appropriate
> directory and symlink under that directory, the open in browser
> functionality was indeed restored.
Yes, it bases the location on the value of WOSystemRoot.
Chuck
--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
This archive was generated by hypermail 2.0.0 : Wed Mar 19 2008 - 12:51:41 EDT