Re: Embed a external command-line tool in bundle
Re: Embed a external command-line tool in bundle
- Subject: Re: Embed a external command-line tool in bundle
- From: Yung-Luen Lan <email@hidden>
- Date: Tue, 18 Oct 2011 00:12:14 +0800
My Cocoa bundle is included in the FileSet specified by
woproject/resources.include.patternset.
The problem is how the woapplication task handle it.
According to wiki,
http://wiki.objectstyle.org/confluence/display/WOL/WOProject-Localization
Not localized resource should be copied to the resources directory
preserving subdirectories structure. But the following is my ant -v
output:
[woapplication] Resources/MyTool.app/Contents/Info.plist added as
Info.plist doesn't exist.
[woapplication] Resources/MyTool.app/Contents/MacOS/MyTool added as
MyTool.app/Contents/MacOS/MyTool doesn't exist.
[woapplication] Resources/MyTool.app/Contents/PkgInfo added as
MyTool.app/Contents/PkgInfo doesn't exist.
[woapplication] Resources/MyTool.app/Contents/Resources/MyTool.tif
added as MyTool.app/Contents/Resources/MyTool.tif doesn't exist.
[woapplication]
Resources/MyTool.app/Contents/Resources/en.lproj/InfoPlist.strings
added as en.lproj/InfoPlist.strings doesn't exist.
As you see, the directory structure of Info.plist was flatten. The
en.lproj inside the Cocoa app bundle was treated as a WO localized
resource, which is wrong behavior. I really can't find documents
specify the Info.plist behavior.
Regards,
yllan
On Mon, Oct 17, 2011 at 9:12 PM, Kieran Kelleher <email@hidden> wrote:
> Fiddling with the woproject/resources.*.patternset files is how the contents of the Resources dir is specified for the build logic. In the build.xml, you can see this is in target build.woapp and resources declaration.
>
> So you can modify the the patternset files and/or directly modify the build xml at that declaration if pattern sets alone are not able to do what you want.
>
> HTH, Kieran
>
> On Oct 17, 2011, at 7:56 AM, Yung-Luen Lan wrote:
>
>> Thanks. Now I have another build problem. If I move my command-line
>> tool (actually, it's a cocoa app bundle without UI) under Resources,
>> then the ant build process will move this file
>>
>> MyWOApp.woa/Contents/Resources/MyTools.app/Contents/Resources/Info.plist
>>
>> to
>>
>> MyWOApp.woa/Contents/Resources/Info.plist
>>
>> which leaves both my wo/cocoa apps in corrupt Info.plist state. I look
>> the build.xml without finding anything related to the Info.plist. Why
>> is that happen?
>>
>> Regards,
>> yllan
>>
>> On Mon, Oct 17, 2011 at 3:54 PM, Johann Werner <email@hidden> wrote:
>>> Hi yllan,
>>>
>>> I would put that into the 'Resources' directory and use
>>>
>>> WOResourceManager.pathURLForResourceNamed(
>>> command-line-tool-name, // name of your tool
>>> null, // null if you put this into your app project
>>> null); // null as you are not interested in localized resources
>>>
>>> jw
>>>
>>>
>>> Am 17.10.2011 um 09:31 schrieb Yung-Luen Lan:
>>>
>>>> Hi,
>>>>
>>>> I have some external command-line tools written by Objective-C that
>>>> needs to be invoked in my wo app.
>>>>
>>>> Of course I could put them in somewhere like /usr/local/bin, etc.
>>>>
>>>> But I want to embed these command-line tools inside my wo app bundle
>>>> so that people don't forget to copy the command-line tools when
>>>> install the wo app. However, getting path of NSBundle is deprecated
>>>> API. Which directory should I put these tools in and how do I get the
>>>> path when I want to call them?
>>>>
>>>> The app is a woa bundle so don't have to take jar into account.
>>>>
>>>> Any comment?
>>>>
>>>> Regards,
>>>> yllan
>>>
>>>
>>>
>> _______________________________________________
>> 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
>
>
_______________________________________________
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