You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Don Coleman <do...@gmail.com> on 2013/05/28 06:28:24 UTC
cordova-cli problems on linux
"cordova platform add android" was failing on linux with an error
about the android-sdk-macosx
don@localhost:~/tmp/foo$ cordova platform add android
[Error: An error occured during creation of android sub-project.
BUILD FAILED
/usr/local/lib/node_modules/cordova/lib/cordova-android/framework/build.xml:133:
Cannot find /Applications/android-sdk-macosx/tools/ant/build.xml
imported from /usr/local/lib/node_modules/cordova/lib/cordova-android/framework/build.xml
cordova 2.7.4 node 0.10.8 npm 1.2.23 Ubuntu 12.04.2 LTS | crouton | ChromeOS
==
The problem was cordova was installed with sudo.
The eventual solution was to chown -R the cordova npm directory. At
first I tried editing sdk.dir in
/usr/local/lib/node_modules/cordova/lib/cordova-android/framework/local.properties
which seemed like a bad idea.
CB-2604 says there should have been a warning about a root install but
I never got one.
https://issues.apache.org/jira/browse/CB-2604?focusedCommentId=13637291&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13637291
Thoughts on the best way to handle this?
Re: inAppBrowser API issue
Posted by Andrew Grieve <ag...@chromium.org>.
I'd be open to discussing a different API.
I like using window.open() for the simple case, but as we add more
non-standard APIs to it (e.g. insertCSS, evaluateJavascript, and upcoming:
.show()), then I think it would make more sense to just have a custom API
instead of using window.open.
On Tue, May 28, 2013 at 12:08 PM, Braden Shepherdson <br...@google.com>wrote:
> This is not an accident of Javascript implementations that we're relying
> on. It is absolutely essential and fully specified that Javascript engines
> have this async behavior. One task completes before any others run.
>
> The handling of onError is our responsibility; I assume that our code uses
> setTimeout(..., 0); to enqueue the error in a new task, and give the user
> code a chance to add handlers. Take a look at the (standard) IndexedDB API;
> it is packed with this style.
>
> Braden
>
>
> On Tue, May 28, 2013 at 12:04 PM, Li, Jonathan <jo...@sap.com>
> wrote:
>
> > It is a little bit different from window.open defined by w3c. As
> > window.open, the onload, onerror events can be embedded in the html page,
> > they will be automatically attached to DOM when parsing the page, there
> is
> > no need to add the event handler by separate calls, so no event will be
> > missed.
> >
> > In fact, if calling the similar code shown below on a regular page, the
> > onload method will not be called.
> >
> > var ref = window.open('http://apache.org');
> > ref.addEventListener('loadstart', function() { alert(event.url); });
> >
> >
> > The design should not heavily depend on the current browser's javascript
> > thread implementation. Besides it is not safe to always assume the event
> > will only be fired asynchronously from native code. For example, if
> invalid
> > parameters are passed to open method, the validator may need to call
> > onError to report the error, it will not work if onError event handler
> > cannot be added before the operation.
> >
> > Jonathan
> >
> >
> > -----Original Message-----
> > From: braden@google.com [mailto:braden@google.com] On Behalf Of Braden
> > Shepherdson
> > Sent: Tuesday, May 28, 2013 11:10 AM
> > To: dev@cordova.apache.org
> > Subject: Re: inAppBrowser API issue
> >
> > If the event really did fire before the event listener was added, the
> > Javascript engine is broken. When the event is triggered (which may
> happen
> > in another browser thread or something) it will be added to the event
> queue
> > in the Javascript engine. That event will not be processed until the
> > currently executing Javascript chunk is done - the next time the
> Javascript
> > cedes control (setTimeout, returning from all functions, etc.). That
> won't
> > happen until after the event handler is attached in the second line.
> >
> > We didn't design this API, it's the same window.open API is is used
> > elsewhere. Cordova tends to use existing W3C specs where appropriate.
> >
> > Braden
> >
> >
> > On Tue, May 28, 2013 at 10:47 AM, Li, Jonathan <jo...@sap.com>
> > wrote:
> >
> > > Not sure whether this is a right place for this issue, but the
> javascript
> > > interface for InAppBrowser does not make much sense. The below code is
> > > from cordova document:
> > >
> > > var ref = window.open('http://apache.org', '_blank', 'location=yes');
> > > ref.addEventListener('loadstart', function() { alert(event.url); });
> > >
> > > The event handler is added after the open method is returned, so it is
> > > possible the event gets fired before developer has a chance to add the
> > > event handler for the open operation. Although it is async operation,
> it
> > > is still a good design, and may cause timing or other issues depending
> on
> > > native side implementation.
> > >
> > > Just wonder whether this is a known issue, or could it be changed to a
> > > better interface design?
> > >
> > > Thanks
> > > Jonathan
> > >
> > >
> >
>
Re: inAppBrowser API issue
Posted by Braden Shepherdson <br...@google.com>.
This is not an accident of Javascript implementations that we're relying
on. It is absolutely essential and fully specified that Javascript engines
have this async behavior. One task completes before any others run.
The handling of onError is our responsibility; I assume that our code uses
setTimeout(..., 0); to enqueue the error in a new task, and give the user
code a chance to add handlers. Take a look at the (standard) IndexedDB API;
it is packed with this style.
Braden
On Tue, May 28, 2013 at 12:04 PM, Li, Jonathan <jo...@sap.com> wrote:
> It is a little bit different from window.open defined by w3c. As
> window.open, the onload, onerror events can be embedded in the html page,
> they will be automatically attached to DOM when parsing the page, there is
> no need to add the event handler by separate calls, so no event will be
> missed.
>
> In fact, if calling the similar code shown below on a regular page, the
> onload method will not be called.
>
> var ref = window.open('http://apache.org');
> ref.addEventListener('loadstart', function() { alert(event.url); });
>
>
> The design should not heavily depend on the current browser's javascript
> thread implementation. Besides it is not safe to always assume the event
> will only be fired asynchronously from native code. For example, if invalid
> parameters are passed to open method, the validator may need to call
> onError to report the error, it will not work if onError event handler
> cannot be added before the operation.
>
> Jonathan
>
>
> -----Original Message-----
> From: braden@google.com [mailto:braden@google.com] On Behalf Of Braden
> Shepherdson
> Sent: Tuesday, May 28, 2013 11:10 AM
> To: dev@cordova.apache.org
> Subject: Re: inAppBrowser API issue
>
> If the event really did fire before the event listener was added, the
> Javascript engine is broken. When the event is triggered (which may happen
> in another browser thread or something) it will be added to the event queue
> in the Javascript engine. That event will not be processed until the
> currently executing Javascript chunk is done - the next time the Javascript
> cedes control (setTimeout, returning from all functions, etc.). That won't
> happen until after the event handler is attached in the second line.
>
> We didn't design this API, it's the same window.open API is is used
> elsewhere. Cordova tends to use existing W3C specs where appropriate.
>
> Braden
>
>
> On Tue, May 28, 2013 at 10:47 AM, Li, Jonathan <jo...@sap.com>
> wrote:
>
> > Not sure whether this is a right place for this issue, but the javascript
> > interface for InAppBrowser does not make much sense. The below code is
> > from cordova document:
> >
> > var ref = window.open('http://apache.org', '_blank', 'location=yes');
> > ref.addEventListener('loadstart', function() { alert(event.url); });
> >
> > The event handler is added after the open method is returned, so it is
> > possible the event gets fired before developer has a chance to add the
> > event handler for the open operation. Although it is async operation, it
> > is still a good design, and may cause timing or other issues depending on
> > native side implementation.
> >
> > Just wonder whether this is a known issue, or could it be changed to a
> > better interface design?
> >
> > Thanks
> > Jonathan
> >
> >
>
RE: inAppBrowser API issue
Posted by "Li, Jonathan" <jo...@sap.com>.
It is a little bit different from window.open defined by w3c. As window.open, the onload, onerror events can be embedded in the html page, they will be automatically attached to DOM when parsing the page, there is no need to add the event handler by separate calls, so no event will be missed.
In fact, if calling the similar code shown below on a regular page, the onload method will not be called.
var ref = window.open('http://apache.org');
ref.addEventListener('loadstart', function() { alert(event.url); });
The design should not heavily depend on the current browser's javascript thread implementation. Besides it is not safe to always assume the event will only be fired asynchronously from native code. For example, if invalid parameters are passed to open method, the validator may need to call onError to report the error, it will not work if onError event handler cannot be added before the operation.
Jonathan
-----Original Message-----
From: braden@google.com [mailto:braden@google.com] On Behalf Of Braden Shepherdson
Sent: Tuesday, May 28, 2013 11:10 AM
To: dev@cordova.apache.org
Subject: Re: inAppBrowser API issue
If the event really did fire before the event listener was added, the
Javascript engine is broken. When the event is triggered (which may happen
in another browser thread or something) it will be added to the event queue
in the Javascript engine. That event will not be processed until the
currently executing Javascript chunk is done - the next time the Javascript
cedes control (setTimeout, returning from all functions, etc.). That won't
happen until after the event handler is attached in the second line.
We didn't design this API, it's the same window.open API is is used
elsewhere. Cordova tends to use existing W3C specs where appropriate.
Braden
On Tue, May 28, 2013 at 10:47 AM, Li, Jonathan <jo...@sap.com> wrote:
> Not sure whether this is a right place for this issue, but the javascript
> interface for InAppBrowser does not make much sense. The below code is
> from cordova document:
>
> var ref = window.open('http://apache.org', '_blank', 'location=yes');
> ref.addEventListener('loadstart', function() { alert(event.url); });
>
> The event handler is added after the open method is returned, so it is
> possible the event gets fired before developer has a chance to add the
> event handler for the open operation. Although it is async operation, it
> is still a good design, and may cause timing or other issues depending on
> native side implementation.
>
> Just wonder whether this is a known issue, or could it be changed to a
> better interface design?
>
> Thanks
> Jonathan
>
>
Re: inAppBrowser API issue
Posted by Braden Shepherdson <br...@chromium.org>.
If the event really did fire before the event listener was added, the
Javascript engine is broken. When the event is triggered (which may happen
in another browser thread or something) it will be added to the event queue
in the Javascript engine. That event will not be processed until the
currently executing Javascript chunk is done - the next time the Javascript
cedes control (setTimeout, returning from all functions, etc.). That won't
happen until after the event handler is attached in the second line.
We didn't design this API, it's the same window.open API is is used
elsewhere. Cordova tends to use existing W3C specs where appropriate.
Braden
On Tue, May 28, 2013 at 10:47 AM, Li, Jonathan <jo...@sap.com> wrote:
> Not sure whether this is a right place for this issue, but the javascript
> interface for InAppBrowser does not make much sense. The below code is
> from cordova document:
>
> var ref = window.open('http://apache.org', '_blank', 'location=yes');
> ref.addEventListener('loadstart', function() { alert(event.url); });
>
> The event handler is added after the open method is returned, so it is
> possible the event gets fired before developer has a chance to add the
> event handler for the open operation. Although it is async operation, it
> is still a good design, and may cause timing or other issues depending on
> native side implementation.
>
> Just wonder whether this is a known issue, or could it be changed to a
> better interface design?
>
> Thanks
> Jonathan
>
>
Re: cordova-cli problems on linux
Posted by Filip Maj <fi...@adobe.com>.
Wait we check for that anywaysŠ
*scratches head*
On 5/28/13 10:35 AM, "Don Coleman" <do...@gmail.com> wrote:
>I re-did the NPM install but didn't see the message. I'll retry on a fresh
>machine today.
>
>
>On Tue, May 28, 2013 at 10:25 AM, Braden Shepherdson
><br...@chromium.org>wrote:
>
>> I note also the "macosx" in some paths there.
>>
>> And isn't there are message during the npm install that warns about
>> chmodding that directory? I agree that this sucks and it would be great
>>to
>> fix it.
>>
>> Braden
>>
>>
>> On Tue, May 28, 2013 at 8:46 AM, Andrew Grieve <ag...@chromium.org>
>> wrote:
>>
>> > One hope here is that the problem will go away once we lazily fetch
>>the
>> > platform repos.
>> >
>> >
>> > On Tue, May 28, 2013 at 12:28 AM, Don Coleman <do...@gmail.com>
>> > wrote:
>> >
>> > > "cordova platform add android" was failing on linux with an error
>> > > about the android-sdk-macosx
>> > >
>> > > don@localhost:~/tmp/foo$ cordova platform add android
>> > > [Error: An error occured during creation of android sub-project.
>> > > BUILD FAILED
>> > >
>> > >
>> >
>>
>>/usr/local/lib/node_modules/cordova/lib/cordova-android/framework/build.x
>>ml:133:
>> > > Cannot find /Applications/android-sdk-macosx/tools/ant/build.xml
>> > > imported from
>> > >
>> >
>>
>>/usr/local/lib/node_modules/cordova/lib/cordova-android/framework/build.x
>>ml
>> > >
>> > > cordova 2.7.4 node 0.10.8 npm 1.2.23 Ubuntu 12.04.2 LTS | crouton |
>> > > ChromeOS
>> > >
>> > > ==
>> > >
>> > > The problem was cordova was installed with sudo.
>> > >
>> > > The eventual solution was to chown -R the cordova npm directory. At
>> > > first I tried editing sdk.dir in
>> > >
>> > >
>> >
>>
>>/usr/local/lib/node_modules/cordova/lib/cordova-android/framework/local.p
>>roperties
>> > > which seemed like a bad idea.
>> > >
>> > > CB-2604 says there should have been a warning about a root install
>>but
>> > > I never got one.
>> > >
>> > >
>> >
>>
>>https://issues.apache.org/jira/browse/CB-2604?focusedCommentId=13637291&p
>>age=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comm
>>ent-13637291
>> > >
>> > > Thoughts on the best way to handle this?
>> > >
>> >
>>
Re: cordova-cli problems on linux
Posted by Filip Maj <fi...@adobe.com>.
Yeah the install script does a check for root user:
https://github.com/apache/cordova-cli/blob/master/bootstrap.js#L61
Interesting that that is not working out..
On 5/28/13 10:35 AM, "Don Coleman" <do...@gmail.com> wrote:
>I re-did the NPM install but didn't see the message. I'll retry on a fresh
>machine today.
>
>
>On Tue, May 28, 2013 at 10:25 AM, Braden Shepherdson
><br...@chromium.org>wrote:
>
>> I note also the "macosx" in some paths there.
>>
>> And isn't there are message during the npm install that warns about
>> chmodding that directory? I agree that this sucks and it would be great
>>to
>> fix it.
>>
>> Braden
>>
>>
>> On Tue, May 28, 2013 at 8:46 AM, Andrew Grieve <ag...@chromium.org>
>> wrote:
>>
>> > One hope here is that the problem will go away once we lazily fetch
>>the
>> > platform repos.
>> >
>> >
>> > On Tue, May 28, 2013 at 12:28 AM, Don Coleman <do...@gmail.com>
>> > wrote:
>> >
>> > > "cordova platform add android" was failing on linux with an error
>> > > about the android-sdk-macosx
>> > >
>> > > don@localhost:~/tmp/foo$ cordova platform add android
>> > > [Error: An error occured during creation of android sub-project.
>> > > BUILD FAILED
>> > >
>> > >
>> >
>>
>>/usr/local/lib/node_modules/cordova/lib/cordova-android/framework/build.x
>>ml:133:
>> > > Cannot find /Applications/android-sdk-macosx/tools/ant/build.xml
>> > > imported from
>> > >
>> >
>>
>>/usr/local/lib/node_modules/cordova/lib/cordova-android/framework/build.x
>>ml
>> > >
>> > > cordova 2.7.4 node 0.10.8 npm 1.2.23 Ubuntu 12.04.2 LTS | crouton |
>> > > ChromeOS
>> > >
>> > > ==
>> > >
>> > > The problem was cordova was installed with sudo.
>> > >
>> > > The eventual solution was to chown -R the cordova npm directory. At
>> > > first I tried editing sdk.dir in
>> > >
>> > >
>> >
>>
>>/usr/local/lib/node_modules/cordova/lib/cordova-android/framework/local.p
>>roperties
>> > > which seemed like a bad idea.
>> > >
>> > > CB-2604 says there should have been a warning about a root install
>>but
>> > > I never got one.
>> > >
>> > >
>> >
>>
>>https://issues.apache.org/jira/browse/CB-2604?focusedCommentId=13637291&p
>>age=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comm
>>ent-13637291
>> > >
>> > > Thoughts on the best way to handle this?
>> > >
>> >
>>
Re: cordova-cli problems on linux
Posted by Filip Maj <fi...@adobe.com>.
OK, just tested this on Brent's (one of the ripple guys) computer, he's
running archlinux, and apparently "process.env.user" is undefined.
HOWEVER, process.env.USER is.
So, I'll quickly patch that conditional so we check both cases. But yes,
eventually this should all get ripped out anyways.
On 5/28/13 10:35 AM, "Don Coleman" <do...@gmail.com> wrote:
>I re-did the NPM install but didn't see the message. I'll retry on a fresh
>machine today.
>
>
>On Tue, May 28, 2013 at 10:25 AM, Braden Shepherdson
><br...@chromium.org>wrote:
>
>> I note also the "macosx" in some paths there.
>>
>> And isn't there are message during the npm install that warns about
>> chmodding that directory? I agree that this sucks and it would be great
>>to
>> fix it.
>>
>> Braden
>>
>>
>> On Tue, May 28, 2013 at 8:46 AM, Andrew Grieve <ag...@chromium.org>
>> wrote:
>>
>> > One hope here is that the problem will go away once we lazily fetch
>>the
>> > platform repos.
>> >
>> >
>> > On Tue, May 28, 2013 at 12:28 AM, Don Coleman <do...@gmail.com>
>> > wrote:
>> >
>> > > "cordova platform add android" was failing on linux with an error
>> > > about the android-sdk-macosx
>> > >
>> > > don@localhost:~/tmp/foo$ cordova platform add android
>> > > [Error: An error occured during creation of android sub-project.
>> > > BUILD FAILED
>> > >
>> > >
>> >
>>
>>/usr/local/lib/node_modules/cordova/lib/cordova-android/framework/build.x
>>ml:133:
>> > > Cannot find /Applications/android-sdk-macosx/tools/ant/build.xml
>> > > imported from
>> > >
>> >
>>
>>/usr/local/lib/node_modules/cordova/lib/cordova-android/framework/build.x
>>ml
>> > >
>> > > cordova 2.7.4 node 0.10.8 npm 1.2.23 Ubuntu 12.04.2 LTS | crouton |
>> > > ChromeOS
>> > >
>> > > ==
>> > >
>> > > The problem was cordova was installed with sudo.
>> > >
>> > > The eventual solution was to chown -R the cordova npm directory. At
>> > > first I tried editing sdk.dir in
>> > >
>> > >
>> >
>>
>>/usr/local/lib/node_modules/cordova/lib/cordova-android/framework/local.p
>>roperties
>> > > which seemed like a bad idea.
>> > >
>> > > CB-2604 says there should have been a warning about a root install
>>but
>> > > I never got one.
>> > >
>> > >
>> >
>>
>>https://issues.apache.org/jira/browse/CB-2604?focusedCommentId=13637291&p
>>age=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comm
>>ent-13637291
>> > >
>> > > Thoughts on the best way to handle this?
>> > >
>> >
>>
inAppBrowser API issue
Posted by "Li, Jonathan" <jo...@sap.com>.
Not sure whether this is a right place for this issue, but the javascript
interface for InAppBrowser does not make much sense. The below code is
from cordova document:
var ref = window.open('http://apache.org', '_blank', 'location=yes');
ref.addEventListener('loadstart', function() { alert(event.url); });
The event handler is added after the open method is returned, so it is
possible the event gets fired before developer has a chance to add the
event handler for the open operation. Although it is async operation, it
is still a good design, and may cause timing or other issues depending on
native side implementation.
Just wonder whether this is a known issue, or could it be changed to a
better interface design?
Thanks
Jonathan
Re: cordova-cli problems on linux
Posted by Don Coleman <do...@gmail.com>.
I re-did the NPM install but didn't see the message. I'll retry on a fresh
machine today.
On Tue, May 28, 2013 at 10:25 AM, Braden Shepherdson <br...@chromium.org>wrote:
> I note also the "macosx" in some paths there.
>
> And isn't there are message during the npm install that warns about
> chmodding that directory? I agree that this sucks and it would be great to
> fix it.
>
> Braden
>
>
> On Tue, May 28, 2013 at 8:46 AM, Andrew Grieve <ag...@chromium.org>
> wrote:
>
> > One hope here is that the problem will go away once we lazily fetch the
> > platform repos.
> >
> >
> > On Tue, May 28, 2013 at 12:28 AM, Don Coleman <do...@gmail.com>
> > wrote:
> >
> > > "cordova platform add android" was failing on linux with an error
> > > about the android-sdk-macosx
> > >
> > > don@localhost:~/tmp/foo$ cordova platform add android
> > > [Error: An error occured during creation of android sub-project.
> > > BUILD FAILED
> > >
> > >
> >
> /usr/local/lib/node_modules/cordova/lib/cordova-android/framework/build.xml:133:
> > > Cannot find /Applications/android-sdk-macosx/tools/ant/build.xml
> > > imported from
> > >
> >
> /usr/local/lib/node_modules/cordova/lib/cordova-android/framework/build.xml
> > >
> > > cordova 2.7.4 node 0.10.8 npm 1.2.23 Ubuntu 12.04.2 LTS | crouton |
> > > ChromeOS
> > >
> > > ==
> > >
> > > The problem was cordova was installed with sudo.
> > >
> > > The eventual solution was to chown -R the cordova npm directory. At
> > > first I tried editing sdk.dir in
> > >
> > >
> >
> /usr/local/lib/node_modules/cordova/lib/cordova-android/framework/local.properties
> > > which seemed like a bad idea.
> > >
> > > CB-2604 says there should have been a warning about a root install but
> > > I never got one.
> > >
> > >
> >
> https://issues.apache.org/jira/browse/CB-2604?focusedCommentId=13637291&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13637291
> > >
> > > Thoughts on the best way to handle this?
> > >
> >
>
Re: cordova-cli problems on linux
Posted by Braden Shepherdson <br...@chromium.org>.
I note also the "macosx" in some paths there.
And isn't there are message during the npm install that warns about
chmodding that directory? I agree that this sucks and it would be great to
fix it.
Braden
On Tue, May 28, 2013 at 8:46 AM, Andrew Grieve <ag...@chromium.org> wrote:
> One hope here is that the problem will go away once we lazily fetch the
> platform repos.
>
>
> On Tue, May 28, 2013 at 12:28 AM, Don Coleman <do...@gmail.com>
> wrote:
>
> > "cordova platform add android" was failing on linux with an error
> > about the android-sdk-macosx
> >
> > don@localhost:~/tmp/foo$ cordova platform add android
> > [Error: An error occured during creation of android sub-project.
> > BUILD FAILED
> >
> >
> /usr/local/lib/node_modules/cordova/lib/cordova-android/framework/build.xml:133:
> > Cannot find /Applications/android-sdk-macosx/tools/ant/build.xml
> > imported from
> >
> /usr/local/lib/node_modules/cordova/lib/cordova-android/framework/build.xml
> >
> > cordova 2.7.4 node 0.10.8 npm 1.2.23 Ubuntu 12.04.2 LTS | crouton |
> > ChromeOS
> >
> > ==
> >
> > The problem was cordova was installed with sudo.
> >
> > The eventual solution was to chown -R the cordova npm directory. At
> > first I tried editing sdk.dir in
> >
> >
> /usr/local/lib/node_modules/cordova/lib/cordova-android/framework/local.properties
> > which seemed like a bad idea.
> >
> > CB-2604 says there should have been a warning about a root install but
> > I never got one.
> >
> >
> https://issues.apache.org/jira/browse/CB-2604?focusedCommentId=13637291&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13637291
> >
> > Thoughts on the best way to handle this?
> >
>
Re: cordova-cli problems on linux
Posted by Andrew Grieve <ag...@chromium.org>.
One hope here is that the problem will go away once we lazily fetch the
platform repos.
On Tue, May 28, 2013 at 12:28 AM, Don Coleman <do...@gmail.com> wrote:
> "cordova platform add android" was failing on linux with an error
> about the android-sdk-macosx
>
> don@localhost:~/tmp/foo$ cordova platform add android
> [Error: An error occured during creation of android sub-project.
> BUILD FAILED
>
> /usr/local/lib/node_modules/cordova/lib/cordova-android/framework/build.xml:133:
> Cannot find /Applications/android-sdk-macosx/tools/ant/build.xml
> imported from
> /usr/local/lib/node_modules/cordova/lib/cordova-android/framework/build.xml
>
> cordova 2.7.4 node 0.10.8 npm 1.2.23 Ubuntu 12.04.2 LTS | crouton |
> ChromeOS
>
> ==
>
> The problem was cordova was installed with sudo.
>
> The eventual solution was to chown -R the cordova npm directory. At
> first I tried editing sdk.dir in
>
> /usr/local/lib/node_modules/cordova/lib/cordova-android/framework/local.properties
> which seemed like a bad idea.
>
> CB-2604 says there should have been a warning about a root install but
> I never got one.
>
> https://issues.apache.org/jira/browse/CB-2604?focusedCommentId=13637291&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13637291
>
> Thoughts on the best way to handle this?
>