Re: Jake woes

[Steven Gill]

+1 Grunt


On Thu, Jun 20, 2013 at 7:15 PM, Andrew Grieve  wrote:

> I've burned quite a bit of time trying to get it to work, and I'm a bit
> realizing that it's probably not worth continuing. By fiddling with
> dependencies I can get it to run, but tasks are being run multiple times
> when they shouldn't be, and there's no reason I should need to fiddle the
> deps to get it to run.
>
> So... any objections if I delete Jakefile and replace it with
> a Gruntfile.js?
>

Re: Review Request: Fixing exec bug.

[Andrew Grieve]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/12013/#review9
---



framework/src/org/apache/cordova/api/PluginManager.java


These params don't need to be final.



framework/src/org/apache/cordova/api/PluginManager.java


Definitely need some comments here to explain why this is necessary.



framework/src/org/apache/cordova/api/PluginManager.java


I realized tonight that a boolean here isn't enough. 
Consider this case:

1. set runExecOnUiThread = true
2. runExecOnUiThread=false Runnable queued.
3. Exec call "foo" gets made, Runnable queued.
4. runExecOnUiThread=false runs
5. Exec call "bar" gets made, executes right away
6. Exec call "foo" Runnable is run

We don't want to ever execute calls out-of-order. "bar" shouldn't get run 
before "foo".

I think to fix this, we can use an AtomicInteger. Increment it every time 
an exec is queued, decrement it each time an exec finishes. Turn off 
runExecOnUiThread only once the count reaches 0.

make sense?




- Andrew Grieve


On June 20, 2013, 8:16 p.m., Jeffrey Willms wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12013/
> ---
> 
> (Updated June 20, 2013, 8:16 p.m.)
> 
> 
> Review request for cordova and Andrew Grieve.
> 
> 
> Description
> ---
> 
> Fixing exec bug.
> 
> 
> This addresses bug CB-3927.
> https://issues.apache.org/jira/browse/CB-3927
> 
> 
> Diffs
> -
> 
>   framework/src/org/apache/cordova/api/PluginEntry.java 
> 9b9af6bc303965e7263bca75037256da81868fb2 
>   framework/src/org/apache/cordova/api/PluginManager.java 
> 71fc25817b5d58bb2fbf5a29158ef2c7d424d4ab 
> 
> Diff: https://reviews.apache.org/r/12013/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jeffrey Willms
> 
>

Re: Cordova Blog

[Joe Bowser]

Currently, PhoneGap aggregates the blog posts of many committers at
phonegap.com/blog.  The downside of this is that it's an Adobe blog,
and it's not Apache Cordova.  Apache Cordova should probably have its
own blog, but I see a lot of the same content being in two different
places.

If someone wants to take this on, that'd be awesome.

On Thu, Jun 20, 2013 at 7:12 PM, Andrew Grieve  wrote:
> I brought it up in a separate thread (
> http://callback.markmail.org/thread/y44pmva6gfm257sl) but probably deserves
> its own.
>
> I'd like to create a Blog for Cordova and make all Committers able to post
> to it. We could use it to:
> - Post release announcements & release notes
> - Draw attention to deprecations and upgrade guides
> - Deep dive into significant improvements / changes
>
> Mainly, I think having a blog for the project will be really help by
> providing an authoritative source for Cordova blob posts (as opposed to on
> our personal blogs, which I appreciate, but which I feel are lacking
> authority).
>
> I'm quite inexperienced at blogging, so everyone agrees we should go ahead
> with this, it'd be good if someone more blog-savvy would own setting it up.

Jake woes

[Andrew Grieve]

I've burned quite a bit of time trying to get it to work, and I'm a bit
realizing that it's probably not worth continuing. By fiddling with
dependencies I can get it to run, but tasks are being run multiple times
when they shouldn't be, and there's no reason I should need to fiddle the
deps to get it to run.

So... any objections if I delete Jakefile and replace it with
a Gruntfile.js?

Cordova Blog

[Andrew Grieve]

I brought it up in a separate thread (
http://callback.markmail.org/thread/y44pmva6gfm257sl) but probably deserves
its own.

I'd like to create a Blog for Cordova and make all Committers able to post
to it. We could use it to:
- Post release announcements & release notes
- Draw attention to deprecations and upgrade guides
- Deep dive into significant improvements / changes

Mainly, I think having a blog for the project will be really help by
providing an authoritative source for Cordova blob posts (as opposed to on
our personal blogs, which I appreciate, but which I feel are lacking
authority).

I'm quite inexperienced at blogging, so everyone agrees we should go ahead
with this, it'd be good if someone more blog-savvy would own setting it up.

PhoneGap Day tickets

[Andrew Grieve]

Do I (or other committers thinking of attending) need to buy a ticket?

Re: Multiple plugins with the same dependencies

[Filip Maj]

There is dependency support built into plugman / plugins. So your
developers would only need to install the two plugins - the third shared
one would be installed automatically. See the  element of the
spec [1].

As for your example about two plugins relying on the same third party
plugin, as long as the version of the shared-dep plugin is the same for
both plugins that rely on it, then you are fine.

That is about the extent of dependency support we set out to accomplish
for cordova 3.0.

[1] 
https://github.com/apache/cordova-plugman/blob/master/plugin_spec.md#depend
ency

On 6/20/13 2:59 PM, "Wargo, John"  wrote:

>That's what we thought - perhaps make a plugin out of the common
>dependency, but that becomes more to manage.   I'd have to install three
>plugins to make this work when developers are going to expect that
>plugman manages this for them. What happens for example if two
>non-related plugins rely upon some third party dependency?
>
>John M. Wargo
>Email: john.wa...@sap.com
>Twitter: @johnwargo
>
>
>-Original Message-
>From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew
>Grieve
>Sent: Thursday, June 20, 2013 2:56 PM
>To: dev
>Subject: Re: Multiple plugins with the same dependencies
>
>I think the correct approach here would be to create a plugin that only
>provides SDMCommon-2.3.0.183.jar, and then have your other plugins depend
>on it.
>
>
>On Thu, Jun 20, 2013 at 1:45 PM, Filip Maj  wrote:
>
>> The file collision checking is built in.
>>
>> A -f / --force flag would need to be implemented to support this case.
>>
>> There are a set of common file methods handling things like copying
>>stuff
>> over, deleting files, that kind of stuff [1]. These helper methods all
>> have built-in checking that the source of a file exists [2], as well as
>>a
>> target destination does _not_ exist [3]. It is [3] that would have to be
>> tweaked and hooked into command-line flags to enable this functionality.
>>
>> Additionally, individual platforms handle particular files differently.
>> See for example how Android handles  elements [4], vs. how
>> iOS handles  elements [5]. We'd have to make sure that
>>these
>> platform-specific handlers are also hooked into the command line flag
>> appropriately.
>>
>> There is no issue currently filed for this but I can see this being a
>> useful option. That being said, I am not sure if/when I will be able to
>> tackle this problem, so pull requests/patches are welcome.
>>
>> [1]
>> 
>>https://github.com/apache/cordova-plugman/blob/master/src/platforms/commo
>>n.
>> js
>> [2]
>> 
>>https://github.com/apache/cordova-plugman/blob/master/src/platforms/commo
>>n.
>> js#L10
>> [3]
>> 
>>https://github.com/apache/cordova-plugman/blob/master/src/platforms/commo
>>n.
>> js#L17
>> [4]
>> 
>>https://github.com/apache/cordova-plugman/blob/master/src/platforms/andro
>>id
>> .js#L37
>> [5]
>> 
>>https://github.com/apache/cordova-plugman/blob/master/src/platforms/ios.j
>>s#
>> L35
>>
>> On 6/20/13 10:31 AM, "Wargo, John"  wrote:
>>
>> >We¹re trying to install two plugins that share some of the same
>> >dependencies and we¹re getting an
>> >
>> >error. Is there a way to turn off checking if a file already exists?
>>If
>> >not, do you have any suggestions
>> >
>> >on how to implement this?
>> >
>> >
>> >
>> >Error: "C:\temp\plug\test\libs\SDMCommon-2.3.0.183.jar" already exists!
>> >
>> >
>> >
>> >Looks like we need a -force or -f flag added to plugman to support
>>this.
>> >
>> >John M. Wargo
>> >SAP | Charlotte, NC | USA
>> >Office: +1 704.321.0265 | Mobile: +1 704.249.7476
>> >Email: john.wa...@sap.com
>> >Twitter: @johnwargo
>> >
>>
>>

Re: BB10 bundling of node.js

[Brian LeRoux]

Node is not the problem. But different versions of Node is a problem.

On Thu, Jun 20, 2013 at 2:52 PM, Wargo, John  wrote:
> The way the market is going, node becomes more and more common. I don't think 
> it's inappropriate to expect node to be there (provided you tell them it's a 
> requirement). It's already one for the CLI, right?
>
> John M. Wargo
> SAP | Charlotte, NC | USA
> Office: +1 704.321.0265 | Mobile: +1 704.249.7476
> Email: john.wa...@sap.com
> Twitter: @johnwargo
>
>
> -Original Message-
> From: Bryan Higgins [mailto:br...@bryanhiggins.net]
> Sent: Wednesday, June 19, 2013 3:22 PM
> To: dev@cordova.apache.org
> Subject: Re: BB10 bundling of node.js
>
> So for Cordova 3.0 in general, users will be required to pre-install a
> minimum version of node globally?
>
> We have had issues where upgrading node breaks stuff. I'd like to avoid
> that and give users flexibility with their own system configuration.
>
>
> On Wed, Jun 19, 2013 at 3:09 PM, Gord Tanner  wrote:
>
>> -1
>>
>> I would rather we just use the system version of node which would be the
>> same version as the CLI.  I can't think of any reason a specific platform
>> (aka BlackBerry) would need a special version of a common dependency.
>>
>> Also I don't think you can bundle binaries in an apache release.
>>
>>
>> On Wed, Jun 19, 2013 at 3:01 PM, Bryan Higgins > >wrote:
>>
>> > I'd like to reopen the topic of bundling node js into the blackberry
>> > platform.
>> >
>> > I have personally gotten feedback from users of errors which were caused
>> by
>> > node version inconsistencies. We have since updated the check_req script
>> to
>> > test for the minimum version of node we require, but that is not an ideal
>> > solution since users may need a different node version installed globally
>> > for other software.
>> >
>> > At a minimum, I'd like to give users the option to point to an alternate
>> > version of node. I have logged a JIRA issue for that. [1]
>> >
>> > What I'd prefer to do, is bundle the node binaries into the distribution.
>> > That would completely eliminate the dependency. Users would only need to
>> > worry about setting up the native SDK.
>> >
>> > We already do this in the WebWorks SDK [2]
>> >
>> > I'm interested how the community feels about this. Are there any
>> licensing
>> > concerns in Apache hosting binaries without source?
>> >
>> > [1] https://issues.apache.org/jira/browse/CB-3798
>> > [2]
>> >
>> >
>> https://github.com/blackberry/BB10-Webworks-Packager/tree/master/third_party/node
>> >
>>

RE: Multiple plugins with the same dependencies

[Wargo, John]

That's what we thought - perhaps make a plugin out of the common dependency, 
but that becomes more to manage.   I'd have to install three plugins to make 
this work when developers are going to expect that plugman manages this for 
them. What happens for example if two non-related plugins rely upon some third 
party dependency?

John M. Wargo
Email: john.wa...@sap.com
Twitter: @johnwargo


-Original Message-
From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew Grieve
Sent: Thursday, June 20, 2013 2:56 PM
To: dev
Subject: Re: Multiple plugins with the same dependencies

I think the correct approach here would be to create a plugin that only
provides SDMCommon-2.3.0.183.jar, and then have your other plugins depend
on it.


On Thu, Jun 20, 2013 at 1:45 PM, Filip Maj  wrote:

> The file collision checking is built in.
>
> A -f / --force flag would need to be implemented to support this case.
>
> There are a set of common file methods handling things like copying stuff
> over, deleting files, that kind of stuff [1]. These helper methods all
> have built-in checking that the source of a file exists [2], as well as a
> target destination does _not_ exist [3]. It is [3] that would have to be
> tweaked and hooked into command-line flags to enable this functionality.
>
> Additionally, individual platforms handle particular files differently.
> See for example how Android handles  elements [4], vs. how
> iOS handles  elements [5]. We'd have to make sure that these
> platform-specific handlers are also hooked into the command line flag
> appropriately.
>
> There is no issue currently filed for this but I can see this being a
> useful option. That being said, I am not sure if/when I will be able to
> tackle this problem, so pull requests/patches are welcome.
>
> [1]
> https://github.com/apache/cordova-plugman/blob/master/src/platforms/common.
> js
> [2]
> https://github.com/apache/cordova-plugman/blob/master/src/platforms/common.
> js#L10
> [3]
> https://github.com/apache/cordova-plugman/blob/master/src/platforms/common.
> js#L17
> [4]
> https://github.com/apache/cordova-plugman/blob/master/src/platforms/android
> .js#L37
> [5]
> https://github.com/apache/cordova-plugman/blob/master/src/platforms/ios.js#
> L35
>
> On 6/20/13 10:31 AM, "Wargo, John"  wrote:
>
> >We¹re trying to install two plugins that share some of the same
> >dependencies and we¹re getting an
> >
> >error. Is there a way to turn off checking if a file already exists?  If
> >not, do you have any suggestions
> >
> >on how to implement this?
> >
> >
> >
> >Error: "C:\temp\plug\test\libs\SDMCommon-2.3.0.183.jar" already exists!
> >
> >
> >
> >Looks like we need a -force or -f flag added to plugman to support this.
> >
> >John M. Wargo
> >SAP | Charlotte, NC | USA
> >Office: +1 704.321.0265 | Mobile: +1 704.249.7476
> >Email: john.wa...@sap.com
> >Twitter: @johnwargo
> >
>
>

RE: BB10 bundling of node.js

[Wargo, John]

The way the market is going, node becomes more and more common. I don't think 
it's inappropriate to expect node to be there (provided you tell them it's a 
requirement). It's already one for the CLI, right?

John M. Wargo
SAP | Charlotte, NC | USA
Office: +1 704.321.0265 | Mobile: +1 704.249.7476
Email: john.wa...@sap.com
Twitter: @johnwargo


-Original Message-
From: Bryan Higgins [mailto:br...@bryanhiggins.net] 
Sent: Wednesday, June 19, 2013 3:22 PM
To: dev@cordova.apache.org
Subject: Re: BB10 bundling of node.js

So for Cordova 3.0 in general, users will be required to pre-install a
minimum version of node globally?

We have had issues where upgrading node breaks stuff. I'd like to avoid
that and give users flexibility with their own system configuration.


On Wed, Jun 19, 2013 at 3:09 PM, Gord Tanner  wrote:

> -1
>
> I would rather we just use the system version of node which would be the
> same version as the CLI.  I can't think of any reason a specific platform
> (aka BlackBerry) would need a special version of a common dependency.
>
> Also I don't think you can bundle binaries in an apache release.
>
>
> On Wed, Jun 19, 2013 at 3:01 PM, Bryan Higgins  >wrote:
>
> > I'd like to reopen the topic of bundling node js into the blackberry
> > platform.
> >
> > I have personally gotten feedback from users of errors which were caused
> by
> > node version inconsistencies. We have since updated the check_req script
> to
> > test for the minimum version of node we require, but that is not an ideal
> > solution since users may need a different node version installed globally
> > for other software.
> >
> > At a minimum, I'd like to give users the option to point to an alternate
> > version of node. I have logged a JIRA issue for that. [1]
> >
> > What I'd prefer to do, is bundle the node binaries into the distribution.
> > That would completely eliminate the dependency. Users would only need to
> > worry about setting up the native SDK.
> >
> > We already do this in the WebWorks SDK [2]
> >
> > I'm interested how the community feels about this. Are there any
> licensing
> > concerns in Apache hosting binaries without source?
> >
> > [1] https://issues.apache.org/jira/browse/CB-3798
> > [2]
> >
> >
> https://github.com/blackberry/BB10-Webworks-Packager/tree/master/third_party/node
> >
>

RE: suggested change to "platform ls" command

[Wargo, John]

I think cordova platforms by itself is enough. Why not leave ls but respond 
correctly if ls isn't included on the command line. 

John M. Wargo
SAP | Charlotte, NC | USA
Office: +1 704.321.0265 | Mobile: +1 704.249.7476
Email: john.wa...@sap.com
Twitter: @johnwargo


-Original Message-
From: Filip Maj [mailto:f...@adobe.com] 
Sent: Tuesday, June 18, 2013 1:15 PM
To: dev@cordova.apache.org
Subject: CLI: suggested change to "platform ls" command

I had two issues submitted recently, for suggestions to tweaking that
particular command/api:

[1]: remove the explicit "ls" command
[2]: have "platform(s)" by itself be the ls command, and expand on what it
returns. Not only the currently-installed platforms for a project, but
also which platforms are available and unavailable to install (I.e. Ones
where the check_requirements script passes/fails).

Thoughts?

[1] https://issues.apache.org/jira/browse/CB-3903

[2] https://issues.apache.org/jira/browse/CB-3904

Re: Review Request: Fixing exec bug.

[Jeffrey Willms]

> On June 20, 2013, 8:28 p.m., Braden Shepherdson wrote:
> > framework/src/org/apache/cordova/api/PluginManager.java, line 220
> > 
> >
> > I realize these logs are at a high verbosity level (DEBUG). Are they 
> > intended to be left in?

No, I don't intend to leave them in.


> On June 20, 2013, 8:28 p.m., Braden Shepherdson wrote:
> > framework/src/org/apache/cordova/api/PluginManager.java, line 223
> > 
> >
> > Doesn't the second case need to return true? It seems synchronous to me.

We are planning on removing the return value entirely, which Andrew will do in 
a separate change, so for now the return value doesn't matter.


- Jeffrey


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/12013/#review22184
---


On June 20, 2013, 8:16 p.m., Jeffrey Willms wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12013/
> ---
> 
> (Updated June 20, 2013, 8:16 p.m.)
> 
> 
> Review request for cordova and Andrew Grieve.
> 
> 
> Description
> ---
> 
> Fixing exec bug.
> 
> 
> This addresses bug CB-3927.
> https://issues.apache.org/jira/browse/CB-3927
> 
> 
> Diffs
> -
> 
>   framework/src/org/apache/cordova/api/PluginEntry.java 
> 9b9af6bc303965e7263bca75037256da81868fb2 
>   framework/src/org/apache/cordova/api/PluginManager.java 
> 71fc25817b5d58bb2fbf5a29158ef2c7d424d4ab 
> 
> Diff: https://reviews.apache.org/r/12013/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jeffrey Willms
> 
>

Re: Review Request: Fixing exec bug.

[Braden Shepherdson]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/12013/#review22184
---



framework/src/org/apache/cordova/api/PluginManager.java


I realize these logs are at a high verbosity level (DEBUG). Are they 
intended to be left in?



framework/src/org/apache/cordova/api/PluginManager.java


Doesn't the second case need to return true? It seems synchronous to me.


- Braden Shepherdson


On June 20, 2013, 8:16 p.m., Jeffrey Willms wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12013/
> ---
> 
> (Updated June 20, 2013, 8:16 p.m.)
> 
> 
> Review request for cordova and Andrew Grieve.
> 
> 
> Description
> ---
> 
> Fixing exec bug.
> 
> 
> This addresses bug CB-3927.
> https://issues.apache.org/jira/browse/CB-3927
> 
> 
> Diffs
> -
> 
>   framework/src/org/apache/cordova/api/PluginEntry.java 
> 9b9af6bc303965e7263bca75037256da81868fb2 
>   framework/src/org/apache/cordova/api/PluginManager.java 
> 71fc25817b5d58bb2fbf5a29158ef2c7d424d4ab 
> 
> Diff: https://reviews.apache.org/r/12013/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jeffrey Willms
> 
>

Re: Review Request: Fixing exec bug.

[Jeffrey Willms]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/12014/
---

(Updated June 20, 2013, 8:18 p.m.)


Review request for cordova and Andrew Grieve.


Description
---

Fixing exec bug.


This addresses bug CB-3927.
https://issues.apache.org/jira/browse/CB-3927


Diffs
-

  lib/scripts/bootstrap-android.js 91a6f71bed7081b7f4cc67e79813cb60e8fb3df9 

Diff: https://reviews.apache.org/r/12014/diff/


Testing
---


Thanks,

Jeffrey Willms

Review Request: Fixing exec bug.

[Jeffrey Willms]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/12014/
---

Review request for cordova and Andrew Grieve.


Description
---

Fixing exec bug.


Diffs
-

  lib/scripts/bootstrap-android.js 91a6f71bed7081b7f4cc67e79813cb60e8fb3df9 

Diff: https://reviews.apache.org/r/12014/diff/


Testing
---


Thanks,

Jeffrey Willms

Re: Review Request: Fixing exec bug.

[Jeffrey Willms]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/12013/
---

(Updated June 20, 2013, 8:16 p.m.)


Review request for cordova and Andrew Grieve.


Description
---

Fixing exec bug.


This addresses bug CB-3927.
https://issues.apache.org/jira/browse/CB-3927


Diffs
-

  framework/src/org/apache/cordova/api/PluginEntry.java 
9b9af6bc303965e7263bca75037256da81868fb2 
  framework/src/org/apache/cordova/api/PluginManager.java 
71fc25817b5d58bb2fbf5a29158ef2c7d424d4ab 

Diff: https://reviews.apache.org/r/12013/diff/


Testing
---


Thanks,

Jeffrey Willms

Review Request: Fixing exec bug.

[Jeffrey Willms]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/12013/
---

Review request for cordova.


Description
---

Fixing exec bug.


This addresses bug CB-3927.
https://issues.apache.org/jira/browse/CB-3927


Diffs
-

  framework/src/org/apache/cordova/api/PluginEntry.java 
9b9af6bc303965e7263bca75037256da81868fb2 
  framework/src/org/apache/cordova/api/PluginManager.java 
71fc25817b5d58bb2fbf5a29158ef2c7d424d4ab 

Diff: https://reviews.apache.org/r/12013/diff/


Testing
---


Thanks,

Jeffrey Willms

Re: Multiple plugins with the same dependencies

[Andrew Grieve]

I think the correct approach here would be to create a plugin that only
provides SDMCommon-2.3.0.183.jar, and then have your other plugins depend
on it.


On Thu, Jun 20, 2013 at 1:45 PM, Filip Maj  wrote:

> The file collision checking is built in.
>
> A -f / --force flag would need to be implemented to support this case.
>
> There are a set of common file methods handling things like copying stuff
> over, deleting files, that kind of stuff [1]. These helper methods all
> have built-in checking that the source of a file exists [2], as well as a
> target destination does _not_ exist [3]. It is [3] that would have to be
> tweaked and hooked into command-line flags to enable this functionality.
>
> Additionally, individual platforms handle particular files differently.
> See for example how Android handles  elements [4], vs. how
> iOS handles  elements [5]. We'd have to make sure that these
> platform-specific handlers are also hooked into the command line flag
> appropriately.
>
> There is no issue currently filed for this but I can see this being a
> useful option. That being said, I am not sure if/when I will be able to
> tackle this problem, so pull requests/patches are welcome.
>
> [1]
> https://github.com/apache/cordova-plugman/blob/master/src/platforms/common.
> js
> [2]
> https://github.com/apache/cordova-plugman/blob/master/src/platforms/common.
> js#L10
> [3]
> https://github.com/apache/cordova-plugman/blob/master/src/platforms/common.
> js#L17
> [4]
> https://github.com/apache/cordova-plugman/blob/master/src/platforms/android
> .js#L37
> [5]
> https://github.com/apache/cordova-plugman/blob/master/src/platforms/ios.js#
> L35
>
> On 6/20/13 10:31 AM, "Wargo, John"  wrote:
>
> >We¹re trying to install two plugins that share some of the same
> >dependencies and we¹re getting an
> >
> >error. Is there a way to turn off checking if a file already exists?  If
> >not, do you have any suggestions
> >
> >on how to implement this?
> >
> >
> >
> >Error: "C:\temp\plug\test\libs\SDMCommon-2.3.0.183.jar" already exists!
> >
> >
> >
> >Looks like we need a -force or -f flag added to plugman to support this.
> >
> >John M. Wargo
> >SAP | Charlotte, NC | USA
> >Office: +1 704.321.0265 | Mobile: +1 704.249.7476
> >Email: john.wa...@sap.com
> >Twitter: @johnwargo
> >
>
>

Re: Apache VM for Medic's CouchDB

[Mike Billau]

Great, I created the INFRA issue here:
https://issues.apache.org/jira/browse/INFRA-6422


On Thu, Jun 20, 2013 at 11:53 AM, Anis KADRI  wrote:

> Should we use this for our NPM registry as well ?
>
>
> On Thu, Jun 20, 2013 at 2:24 AM, Brian LeRoux  wrote:
>
> > Right on. Thanks for taking this on Mike.
> >
> > On Wed, Jun 19, 2013 at 7:12 PM, Lorin Beer 
> > wrote:
> > > that would be fantastic!
> > >
> > >
> > > On Wed, Jun 19, 2013 at 9:59 AM, Filip Maj  wrote:
> > >
> > >> Would love to see this, thanks for taking the initiative on this Mike!
> > >>
> > >> On 6/19/13 7:19 AM, "Andrew Grieve"  wrote:
> > >>
> > >> >Sounds great!
> > >> >
> > >> >
> > >> >On Wed, Jun 19, 2013 at 9:39 AM, Mike Billau 
> > >> >wrote:
> > >> >
> > >> >> Hello everyone,
> > >> >>
> > >> >> I have been working the last week on getting medic up and running
> > here
> > >> >>at
> > >> >> our office, and so far things are going pretty well. I would like
> to
> > >> >>start
> > >> >> contributing our tests back to the community pretty soon. However,
> I
> > >> >> contacted Fil about flowing our test results back to the CI
> database,
> > >> >>and
> > >> >> he informed me that unfortunately the EC2 instance has been
> removed.
> > >> >>
> > >> >> I would like to propose that we have the Apache folks set us up
> with
> > a
> > >> >> standard Linux VM that we can use to host the CouchDB server to
> > collect
> > >> >> test results. Using an Apache VM seems to be more in the Apache
> > spirit
> > >> >>as
> > >> >> opposed to an EC2 instance. Since it would be more centralized and
> > >> >> community owned, it would potentially make it easier for other
> > groups to
> > >> >> contribute test results. The VM can also serve as a home for any
> > future
> > >> >> dumps or hosted scripts that we need.
> > >> >>
> > >> >> Any thoughts on this? If there are no problems, then can somebody
> > >> >>involved
> > >> >> with ASF help me create the relevant INFRA issues?
> > >> >>
> > >> >> Thanks,
> > >> >> Mike Billau
> > >> >>
> > >>
> > >>
> >
>

Re: Multiple plugins with the same dependencies

[Filip Maj]

The file collision checking is built in.

A -f / --force flag would need to be implemented to support this case.

There are a set of common file methods handling things like copying stuff
over, deleting files, that kind of stuff [1]. These helper methods all
have built-in checking that the source of a file exists [2], as well as a
target destination does _not_ exist [3]. It is [3] that would have to be
tweaked and hooked into command-line flags to enable this functionality.

Additionally, individual platforms handle particular files differently.
See for example how Android handles  elements [4], vs. how
iOS handles  elements [5]. We'd have to make sure that these
platform-specific handlers are also hooked into the command line flag
appropriately.

There is no issue currently filed for this but I can see this being a
useful option. That being said, I am not sure if/when I will be able to
tackle this problem, so pull requests/patches are welcome.

[1] 
https://github.com/apache/cordova-plugman/blob/master/src/platforms/common.
js
[2] 
https://github.com/apache/cordova-plugman/blob/master/src/platforms/common.
js#L10
[3] 
https://github.com/apache/cordova-plugman/blob/master/src/platforms/common.
js#L17
[4] 
https://github.com/apache/cordova-plugman/blob/master/src/platforms/android
.js#L37
[5] 
https://github.com/apache/cordova-plugman/blob/master/src/platforms/ios.js#
L35

On 6/20/13 10:31 AM, "Wargo, John"  wrote:

>We¹re trying to install two plugins that share some of the same
>dependencies and we¹re getting an
>
>error. Is there a way to turn off checking if a file already exists?  If
>not, do you have any suggestions
>
>on how to implement this?
>
>
>
>Error: "C:\temp\plug\test\libs\SDMCommon-2.3.0.183.jar" already exists!
>
>
>
>Looks like we need a -force or -f flag added to plugman to support this.
>
>John M. Wargo
>SAP | Charlotte, NC | USA
>Office: +1 704.321.0265 | Mobile: +1 704.249.7476
>Email: john.wa...@sap.com
>Twitter: @johnwargo
>

Re: Reviewboard

[Michael Brooks]

Cool, thanks for the info! I've registered.


On Thu, Jun 20, 2013 at 5:59 AM, Andrew Grieve  wrote:

> Just got word that all of the repos except for the plugin ones are now
> valid targets at http://reviews.apache.org.
>
> 1. Everyone will have to make a reviewboard account
> 2. Make sure to add yourself to the cordova group (via the "My Account"
> link)
> 3. There's a command-line tool for posting reviews that's available under
> the "New Review Request" page. Just commit locally and then run
> "post-review" and the review request opens in the browser. Click "publish"
> to make it live.
>

Multiple plugins with the same dependencies

[Wargo, John]

We¹re trying to install two plugins that share some of the same dependencies 
and we¹re getting an

error. Is there a way to turn off checking if a file already exists?  If not, 
do you have any suggestions

on how to implement this?



Error: "C:\temp\plug\test\libs\SDMCommon-2.3.0.183.jar" already exists!



Looks like we need a -force or -f flag added to plugman to support this.

John M. Wargo
SAP | Charlotte, NC | USA
Office: +1 704.321.0265 | Mobile: +1 704.249.7476
Email: john.wa...@sap.com
Twitter: @johnwargo

Re: Apache VM for Medic's CouchDB

[Anis KADRI]

Should we use this for our NPM registry as well ?


On Thu, Jun 20, 2013 at 2:24 AM, Brian LeRoux  wrote:

> Right on. Thanks for taking this on Mike.
>
> On Wed, Jun 19, 2013 at 7:12 PM, Lorin Beer 
> wrote:
> > that would be fantastic!
> >
> >
> > On Wed, Jun 19, 2013 at 9:59 AM, Filip Maj  wrote:
> >
> >> Would love to see this, thanks for taking the initiative on this Mike!
> >>
> >> On 6/19/13 7:19 AM, "Andrew Grieve"  wrote:
> >>
> >> >Sounds great!
> >> >
> >> >
> >> >On Wed, Jun 19, 2013 at 9:39 AM, Mike Billau 
> >> >wrote:
> >> >
> >> >> Hello everyone,
> >> >>
> >> >> I have been working the last week on getting medic up and running
> here
> >> >>at
> >> >> our office, and so far things are going pretty well. I would like to
> >> >>start
> >> >> contributing our tests back to the community pretty soon. However, I
> >> >> contacted Fil about flowing our test results back to the CI database,
> >> >>and
> >> >> he informed me that unfortunately the EC2 instance has been removed.
> >> >>
> >> >> I would like to propose that we have the Apache folks set us up with
> a
> >> >> standard Linux VM that we can use to host the CouchDB server to
> collect
> >> >> test results. Using an Apache VM seems to be more in the Apache
> spirit
> >> >>as
> >> >> opposed to an EC2 instance. Since it would be more centralized and
> >> >> community owned, it would potentially make it easier for other
> groups to
> >> >> contribute test results. The VM can also serve as a home for any
> future
> >> >> dumps or hosted scripts that we need.
> >> >>
> >> >> Any thoughts on this? If there are no problems, then can somebody
> >> >>involved
> >> >> with ASF help me create the relevant INFRA issues?
> >> >>
> >> >> Thanks,
> >> >> Mike Billau
> >> >>
> >>
> >>
>

Re: Media API, DataResource, and empty URLs

[Andrew Grieve]

WebView.getUrl() ?


On Thu, Jun 20, 2013 at 9:49 AM, Braden Shepherdson wrote:

> So the current state of handling URLs in DataResource is: if it has a
> scheme, all good; if it doesn't and is absolute, also good; if it is
> relative and has no scheme, throw new IllegalArgumentException.
>
> I agree that this behavior is dumb and there should be a sane default for
> relative URLs, and DataResource should rewrite them. The tricky bit is what
> they should be relative to. file:///android_asset/www? The currently loaded
> page in the WebView? Can we reliably check that in the presence of
> CordovaView and InAppBrowser?
>
> Braden
>
>
> On Thu, Jun 20, 2013 at 12:34 AM, Andrew Grieve  >wrote:
>
> > Agree that we should make Media() an error, but we don't want to change
> the
> > semantics of relative URLs for APIs without proper deprecation.
> >
> >
> > On Thu, Jun 20, 2013 at 12:00 AM, Ian Clelland 
> > wrote:
> >
> > > On Wed, Jun 19, 2013 at 7:41 PM, Andrew Grieve 
> > > wrote:
> > >
> > > > "null" could be interpreted as a relative URL I think. The current
> > > handling
> > > > of relative URLs by plugins is sadly plugin-specific.
> > > >
> > >
> > > Isn't that one of the things that DataResource is supposed to
> > standardize?
> > >
> > >
> > > The string "null" is certainly a relative URL, and all plugins should
> > > interpret that as one. The empty string is a relative url as well. (See
> > the
> > > 'image src=""' problem). DataResource should probably handle relative
> > URLs;
> > > that seems like a deficiency if it can't.
> > >
> > > We shouldn't be representing the JavaScript null value as "null", or as
> > "",
> > > though. I don't think there's any rational reason to support new
> Media()
> > as
> > > a construct. Media is fairly clearly documented as taking two required
> > > parameters, and two optional ones. I don't think Media() makes sense --
> > it
> > > doesn't give you a useful object. The calls to Media() are likely just
> in
> > > mobile-spec, and we should clean those up.
> > >
> > >
> > >
> > >
> > > >
> > > > On Wed, Jun 19, 2013 at 4:04 PM, Braden Shepherdson <
> > bra...@chromium.org
> > > > >wrote:
> > > >
> > > > > The automated tests for Media frequently call new Media() with no
> > URL,
> > > > > which sends a null to the "create" action. In the past, this got
> > turned
> > > > > into the string "null" in Java, which was handled as a file named
> > > "null"
> > > > > that didn't exist, and nothing crashed.
> > > > >
> > > > > DataResource is fine with the files not existing, but it's not fine
> > > with
> > > > > "null" as a filename since it neither has a URL scheme nor is it an
> > > > > absolute path.
> > > > >
> > > > > Is there a reason why new Media() should work rather than throwing
> > > > > IllegalArgumentExceptions for trying to read files with relative
> > paths?
> > > > > Should I detect and gracefully handle null being given as the media
> > URL
> > > > in
> > > > > Javascript? In Java? Should I instead change the mobile-spec tests
> to
> > > use
> > > > > "file:///dummy" or similar?
> > > > >
> > > > > Braden
> > > > >
> > > >
> > >
> >
>

Re: Opinions Needed: Platform specific features and mobilespec tests

[Jesse MacFadyen]

My 2 cents
- APIs that should exist on all devices go in mobile spec
- Platform specific ones go in each platforms repo

I assume this is a vanishing issue as all mobile spec test will be
broken out into each plugin repo, and would be easily run by mobile
spec.

Cheers,
  Jesse

Sent from my iPhone5

On Jun 20, 2013, at 7:27 AM, Jeffrey Heifetz  wrote:

+1

> On 13-06-20 9:06 AM, "Andrew Grieve"  wrote:
>
> Definitely torn on this one. On one hand, if there are features
> implemented
> on some platforms that should be implemented on others than having them
> fail is a constant reminder that your platform needs to implement the
> missing functionality. OTOH, things like camera clean-up are meant to be
> platform specific, so it's nothing but an annoyance if that fails on other
> platforms.
>
> So, I think my take on it is:
>
> 1. Have them shared and failing if the API should eventually be
> implemented
> on all platforms
> 2. Wrap tests in if (platform.name == 'ios') {} if they are meant to only
> work on one platform.
>
>
>
>
>
>
> On Thu, Jun 20, 2013 at 8:44 AM, Lisa Seacat DeLuca
> wrote:
>
>> One issue I ran with respects to the mobile spec is some tests are only
>> applicable to certain device types.  We have a couple options when it
>> comes to those types of tests:
>>
>> 1. Not include them in the automated tests
>> 2. Include them knowing that they *might* cause failures with certain
>> device types (see example)
>> 3. Add javascript logic to check for device type before performing the
>> tests
>> 4. OR we could create platform specific automated tests that should be
>> ran
>> in addition to the base automated test per device. ex. automatedAndroid,
>> automatedIOS, etc.
>>
>> An example is:
>> https://issues.apache.org/jira/browse/CB-3484
>> camera.cleanup is only supported on iOS.
>>
>> I added a test case to verify that the function existed.  But it doesn't
>> actually run camera.cleanup so there are no failure on other platforms.
>> So
>> really there shouldn't be any harm in keeping the test.
>>
>>
>> What are everyone's opinions on a good approach to handle this type of
>> situation?
>>
>> Lisa Seacat DeLuca


-
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute
non-public information. Any use of this information by anyone other
than the intended recipient is prohibited. If you have received this
transmission in error, please immediately reply to the sender and
delete this information from your system. Use, dissemination,
distribution, or reproduction of this transmission by unintended
recipients is not authorized and may be unlawful.

Re: Opinions Needed: Platform specific features and mobilespec tests

[Jeffrey Heifetz]

+1

On 13-06-20 9:06 AM, "Andrew Grieve"  wrote:

>Definitely torn on this one. On one hand, if there are features
>implemented
>on some platforms that should be implemented on others than having them
>fail is a constant reminder that your platform needs to implement the
>missing functionality. OTOH, things like camera clean-up are meant to be
>platform specific, so it's nothing but an annoyance if that fails on other
>platforms.
>
>So, I think my take on it is:
>
>1. Have them shared and failing if the API should eventually be
>implemented
>on all platforms
>2. Wrap tests in if (platform.name == 'ios') {} if they are meant to only
>work on one platform.
>
>
>
>
>
>
>On Thu, Jun 20, 2013 at 8:44 AM, Lisa Seacat DeLuca
>wrote:
>
>> One issue I ran with respects to the mobile spec is some tests are only
>> applicable to certain device types.  We have a couple options when it
>> comes to those types of tests:
>>
>> 1. Not include them in the automated tests
>> 2. Include them knowing that they *might* cause failures with certain
>> device types (see example)
>> 3. Add javascript logic to check for device type before performing the
>> tests
>> 4. OR we could create platform specific automated tests that should be
>>ran
>> in addition to the base automated test per device. ex. automatedAndroid,
>> automatedIOS, etc.
>>
>> An example is:
>> https://issues.apache.org/jira/browse/CB-3484
>> camera.cleanup is only supported on iOS.
>>
>> I added a test case to verify that the function existed.  But it doesn't
>> actually run camera.cleanup so there are no failure on other platforms.
>>So
>> really there shouldn't be any harm in keeping the test.
>>
>>
>> What are everyone's opinions on a good approach to handle this type of
>> situation?
>>
>> Lisa Seacat DeLuca


-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

Re: BB10 bundling of node.js

[Braden Shepherdson]

Those dependencies are, as I recently noted elsewhere, artificially high. I
think 0.8.6 or so is sufficient if we switch to using os.tmpDir() (the 0.8
name for it, and a synonym for the new, 0.10 name os.tmpdir()).

Braden


On Wed, Jun 19, 2013 at 5:28 PM, Filip Maj  wrote:

> Plugman and cordova-cli both require a minimum 0.9.9 node.
>
> See the "engines" and "engineStrict" flags in package.json for the two
> repos. engineStrict when set to true will force npm to make sure the
> user's version of node adheres to what is listed under the "engines" prop.
>
> On 6/19/13 1:15 PM, "Gord Tanner"  wrote:
>
> >Still a -1, cordova (and all it's projects) should use the globally
> >installed version of node.
> >
> >If someone needs multiple versions of node the should probably use nvm [1]
> >to manage it.  IMHO this is a user problem and not something we should
> >magically solve via bundled copies of node or hardcoded paths to specific
> >versions of node.
> >
> >I agree we should have a version of node we support, it just needs to be
> >consistent and common across all of our tools and require the user to have
> >that version range in their path.
> >
> >[1] - https://github.com/creationix/nvm
> >
> >
> >On Wed, Jun 19, 2013 at 3:57 PM, Bryan Higgins
> >wrote:
> >
> >> For 3.0 will there still be a ZIP file released by Apache? Will the
> >> instructions be download the latest version of node then run "npm
> >>install
> >> -g "?
> >>
> >> My assumption was the individual project templates will continue to work
> >> independently of CLI.
> >>
> >> Also, keep in mind that CLI invokes BB via shell scripts which in turn
> >>call
> >> node. So for environments where people need different versions of node
> >> installed, invoking CLI with an alternate node version will cause BB to
> >>be
> >> invoked via the globally installed version. Perhaps that is an edge
> >>case,
> >> but it's still something that needs to be supported by allowing them to
> >> configure node path for BB.
> >>
> >>
> >> On Wed, Jun 19, 2013 at 3:30 PM, Gord Tanner  wrote:
> >>
> >> > I would expect they would have a supported node version when they
> >>type:
> >> >
> >> > "npm install cordova"
> >> >
> >> > which would do any version checks in the package.json [1] for
> >>supported
> >> > node versions
> >> >
> >> > [1] -
> >> >
> >> >
> >>
> >>
> https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=blob_plain;f=
> >>package.json;hb=HEAD
> >> >
> >> >
> >> > On Wed, Jun 19, 2013 at 3:22 PM, Bryan Higgins <
> br...@bryanhiggins.net
> >> > >wrote:
> >> >
> >> > > So for Cordova 3.0 in general, users will be required to
> >>pre-install a
> >> > > minimum version of node globally?
> >> > >
> >> > > We have had issues where upgrading node breaks stuff. I'd like to
> >>avoid
> >> > > that and give users flexibility with their own system configuration.
> >> > >
> >> > >
> >> > > On Wed, Jun 19, 2013 at 3:09 PM, Gord Tanner 
> >> wrote:
> >> > >
> >> > > > -1
> >> > > >
> >> > > > I would rather we just use the system version of node which would
> >>be
> >> > the
> >> > > > same version as the CLI.  I can't think of any reason a specific
> >> > platform
> >> > > > (aka BlackBerry) would need a special version of a common
> >>dependency.
> >> > > >
> >> > > > Also I don't think you can bundle binaries in an apache release.
> >> > > >
> >> > > >
> >> > > > On Wed, Jun 19, 2013 at 3:01 PM, Bryan Higgins <
> >> > bhigg...@blackberry.com
> >> > > > >wrote:
> >> > > >
> >> > > > > I'd like to reopen the topic of bundling node js into the
> >> blackberry
> >> > > > > platform.
> >> > > > >
> >> > > > > I have personally gotten feedback from users of errors which
> >>were
> >> > > caused
> >> > > > by
> >> > > > > node version inconsistencies. We have since updated the
> >>check_req
> >> > > script
> >> > > > to
> >> > > > > test for the minimum version of node we require, but that is
> >>not an
> >> > > ideal
> >> > > > > solution since users may need a different node version installed
> >> > > globally
> >> > > > > for other software.
> >> > > > >
> >> > > > > At a minimum, I'd like to give users the option to point to an
> >> > > alternate
> >> > > > > version of node. I have logged a JIRA issue for that. [1]
> >> > > > >
> >> > > > > What I'd prefer to do, is bundle the node binaries into the
> >> > > distribution.
> >> > > > > That would completely eliminate the dependency. Users would only
> >> need
> >> > > to
> >> > > > > worry about setting up the native SDK.
> >> > > > >
> >> > > > > We already do this in the WebWorks SDK [2]
> >> > > > >
> >> > > > > I'm interested how the community feels about this. Are there any
> >> > > > licensing
> >> > > > > concerns in Apache hosting binaries without source?
> >> > > > >
> >> > > > > [1] https://issues.apache.org/jira/browse/CB-3798
> >> > > > > [2]
> >> > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >>
> https://github.com/blackberry/BB10-Webworks-Packager/tree/master/third_pa
> >>rty/node
> >> > 

Re: Media API, DataResource, and empty URLs

[Braden Shepherdson]

So the current state of handling URLs in DataResource is: if it has a
scheme, all good; if it doesn't and is absolute, also good; if it is
relative and has no scheme, throw new IllegalArgumentException.

I agree that this behavior is dumb and there should be a sane default for
relative URLs, and DataResource should rewrite them. The tricky bit is what
they should be relative to. file:///android_asset/www? The currently loaded
page in the WebView? Can we reliably check that in the presence of
CordovaView and InAppBrowser?

Braden


On Thu, Jun 20, 2013 at 12:34 AM, Andrew Grieve wrote:

> Agree that we should make Media() an error, but we don't want to change the
> semantics of relative URLs for APIs without proper deprecation.
>
>
> On Thu, Jun 20, 2013 at 12:00 AM, Ian Clelland 
> wrote:
>
> > On Wed, Jun 19, 2013 at 7:41 PM, Andrew Grieve 
> > wrote:
> >
> > > "null" could be interpreted as a relative URL I think. The current
> > handling
> > > of relative URLs by plugins is sadly plugin-specific.
> > >
> >
> > Isn't that one of the things that DataResource is supposed to
> standardize?
> >
> >
> > The string "null" is certainly a relative URL, and all plugins should
> > interpret that as one. The empty string is a relative url as well. (See
> the
> > 'image src=""' problem). DataResource should probably handle relative
> URLs;
> > that seems like a deficiency if it can't.
> >
> > We shouldn't be representing the JavaScript null value as "null", or as
> "",
> > though. I don't think there's any rational reason to support new Media()
> as
> > a construct. Media is fairly clearly documented as taking two required
> > parameters, and two optional ones. I don't think Media() makes sense --
> it
> > doesn't give you a useful object. The calls to Media() are likely just in
> > mobile-spec, and we should clean those up.
> >
> >
> >
> >
> > >
> > > On Wed, Jun 19, 2013 at 4:04 PM, Braden Shepherdson <
> bra...@chromium.org
> > > >wrote:
> > >
> > > > The automated tests for Media frequently call new Media() with no
> URL,
> > > > which sends a null to the "create" action. In the past, this got
> turned
> > > > into the string "null" in Java, which was handled as a file named
> > "null"
> > > > that didn't exist, and nothing crashed.
> > > >
> > > > DataResource is fine with the files not existing, but it's not fine
> > with
> > > > "null" as a filename since it neither has a URL scheme nor is it an
> > > > absolute path.
> > > >
> > > > Is there a reason why new Media() should work rather than throwing
> > > > IllegalArgumentExceptions for trying to read files with relative
> paths?
> > > > Should I detect and gracefully handle null being given as the media
> URL
> > > in
> > > > Javascript? In Java? Should I instead change the mobile-spec tests to
> > use
> > > > "file:///dummy" or similar?
> > > >
> > > > Braden
> > > >
> > >
> >
>

Re: Opinions Needed: Platform specific features and mobilespec tests

[Andrew Grieve]

Definitely torn on this one. On one hand, if there are features implemented
on some platforms that should be implemented on others than having them
fail is a constant reminder that your platform needs to implement the
missing functionality. OTOH, things like camera clean-up are meant to be
platform specific, so it's nothing but an annoyance if that fails on other
platforms.

So, I think my take on it is:

1. Have them shared and failing if the API should eventually be implemented
on all platforms
2. Wrap tests in if (platform.name == 'ios') {} if they are meant to only
work on one platform.






On Thu, Jun 20, 2013 at 8:44 AM, Lisa Seacat DeLuca wrote:

> One issue I ran with respects to the mobile spec is some tests are only
> applicable to certain device types.  We have a couple options when it
> comes to those types of tests:
>
> 1. Not include them in the automated tests
> 2. Include them knowing that they *might* cause failures with certain
> device types (see example)
> 3. Add javascript logic to check for device type before performing the
> tests
> 4. OR we could create platform specific automated tests that should be ran
> in addition to the base automated test per device. ex. automatedAndroid,
> automatedIOS, etc.
>
> An example is:
> https://issues.apache.org/jira/browse/CB-3484
> camera.cleanup is only supported on iOS.
>
> I added a test case to verify that the function existed.  But it doesn't
> actually run camera.cleanup so there are no failure on other platforms. So
> really there shouldn't be any harm in keeping the test.
>
>
> What are everyone's opinions on a good approach to handle this type of
> situation?
>
> Lisa Seacat DeLuca

Re: Review Request: cordova.VERSION.js -> cordova.js

[Shazron Abdullah]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/11312/#review22163
---

Ship it!


Ship It!

- Shazron Abdullah


On May 21, 2013, 4:17 p.m., Andrew Grieve wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11312/
> ---
> 
> (Updated May 21, 2013, 4:17 p.m.)
> 
> 
> Review request for cordova.
> 
> 
> Description
> ---
> 
> cordova.VERSION.js -> cordova.js
> 
> 
> Diffs
> -
> 
>   bin/templates/project/www/README.md 
> 61256fe522a3f12d63e1f31c7b97b9f00661500d 
>   bin/templates/project/www/index.html 
> ce767eb56ce53596327a86e7ebbbcd62265c6e6d 
>   build.xml dcddbb66e74b0239c792be6db28194a77b33bb31 
> 
> Diff: https://reviews.apache.org/r/11312/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andrew Grieve
> 
>

Reviewboard

[Andrew Grieve]

Just got word that all of the repos except for the plugin ones are now
valid targets at http://reviews.apache.org.

1. Everyone will have to make a reviewboard account
2. Make sure to add yourself to the cordova group (via the "My Account"
link)
3. There's a command-line tool for posting reviews that's available under
the "New Review Request" page. Just commit locally and then run
"post-review" and the review request opens in the browser. Click "publish"
to make it live.

Opinions Needed: Platform specific features and mobilespec tests

[Lisa Seacat DeLuca]

One issue I ran with respects to the mobile spec is some tests are only 
applicable to certain device types.  We have a couple options when it 
comes to those types of tests:

1. Not include them in the automated tests
2. Include them knowing that they *might* cause failures with certain 
device types (see example)
3. Add javascript logic to check for device type before performing the 
tests
4. OR we could create platform specific automated tests that should be ran 
in addition to the base automated test per device. ex. automatedAndroid, 
automatedIOS, etc.

An example is:
https://issues.apache.org/jira/browse/CB-3484
camera.cleanup is only supported on iOS.

I added a test case to verify that the function existed.  But it doesn't 
actually run camera.cleanup so there are no failure on other platforms. So 
really there shouldn't be any harm in keeping the test.


What are everyone's opinions on a good approach to handle this type of 
situation?

Lisa Seacat DeLuca

Security Error in FirefoxOS on reading window.navigator properties

[Piotr Zalewa]

I came to a point where I need to use the group wisdom.

In 
https://github.com/apache/cordova-firefoxos/blob/master/lib/cordova.firefoxos.js#L5929
 Cordova is trying to replace window.navigator with something which looks like 
a copy of itself. window.navigator is protected in FirefoxOS - even browsing 
through its properties is not allowed.

alert('pre'); for (var key in window.navigator) {window.navigator[key]}; 
alert('post');

Above code will work in browser, but not on the device or Simulator. It will 
throw "SecurityError: The operation is insecure." and 'post' will not get 
alerted. Example in JSFiddle - http://jsfiddle.net/zalun/VkCyH/embedded/result/ 
(just install in Simulator)

I'm looking for a solution for that issue.

Is the step with replacing window.navigator needed? The comment in the code 
says 
// We replace it so that properties that can't be clobbered can instead be 
overridden.


Piotr

Re: Apache VM for Medic's CouchDB

[Brian LeRoux]

Right on. Thanks for taking this on Mike.

On Wed, Jun 19, 2013 at 7:12 PM, Lorin Beer  wrote:
> that would be fantastic!
>
>
> On Wed, Jun 19, 2013 at 9:59 AM, Filip Maj  wrote:
>
>> Would love to see this, thanks for taking the initiative on this Mike!
>>
>> On 6/19/13 7:19 AM, "Andrew Grieve"  wrote:
>>
>> >Sounds great!
>> >
>> >
>> >On Wed, Jun 19, 2013 at 9:39 AM, Mike Billau 
>> >wrote:
>> >
>> >> Hello everyone,
>> >>
>> >> I have been working the last week on getting medic up and running here
>> >>at
>> >> our office, and so far things are going pretty well. I would like to
>> >>start
>> >> contributing our tests back to the community pretty soon. However, I
>> >> contacted Fil about flowing our test results back to the CI database,
>> >>and
>> >> he informed me that unfortunately the EC2 instance has been removed.
>> >>
>> >> I would like to propose that we have the Apache folks set us up with a
>> >> standard Linux VM that we can use to host the CouchDB server to collect
>> >> test results. Using an Apache VM seems to be more in the Apache spirit
>> >>as
>> >> opposed to an EC2 instance. Since it would be more centralized and
>> >> community owned, it would potentially make it easier for other groups to
>> >> contribute test results. The VM can also serve as a home for any future
>> >> dumps or hosted scripts that we need.
>> >>
>> >> Any thoughts on this? If there are no problems, then can somebody
>> >>involved
>> >> with ASF help me create the relevant INFRA issues?
>> >>
>> >> Thanks,
>> >> Mike Billau
>> >>
>>
>>

Re: BB10 bundling of node.js

[Brian LeRoux]

I'm a fan of shipping dependencies shrink wrapped but as mentioned
this is not generally done at Apache. (Except for when it is like
Maven.)

I wonder if there's a bootstrap way we could look at? One less install
step, and assurance of a sane (or at least expected) runtime is nice.


On Wed, Jun 19, 2013 at 11:28 PM, Filip Maj  wrote:
> Plugman and cordova-cli both require a minimum 0.9.9 node.
>
> See the "engines" and "engineStrict" flags in package.json for the two
> repos. engineStrict when set to true will force npm to make sure the
> user's version of node adheres to what is listed under the "engines" prop.
>
> On 6/19/13 1:15 PM, "Gord Tanner"  wrote:
>
>>Still a -1, cordova (and all it's projects) should use the globally
>>installed version of node.
>>
>>If someone needs multiple versions of node the should probably use nvm [1]
>>to manage it.  IMHO this is a user problem and not something we should
>>magically solve via bundled copies of node or hardcoded paths to specific
>>versions of node.
>>
>>I agree we should have a version of node we support, it just needs to be
>>consistent and common across all of our tools and require the user to have
>>that version range in their path.
>>
>>[1] - https://github.com/creationix/nvm
>>
>>
>>On Wed, Jun 19, 2013 at 3:57 PM, Bryan Higgins
>>wrote:
>>
>>> For 3.0 will there still be a ZIP file released by Apache? Will the
>>> instructions be download the latest version of node then run "npm
>>>install
>>> -g "?
>>>
>>> My assumption was the individual project templates will continue to work
>>> independently of CLI.
>>>
>>> Also, keep in mind that CLI invokes BB via shell scripts which in turn
>>>call
>>> node. So for environments where people need different versions of node
>>> installed, invoking CLI with an alternate node version will cause BB to
>>>be
>>> invoked via the globally installed version. Perhaps that is an edge
>>>case,
>>> but it's still something that needs to be supported by allowing them to
>>> configure node path for BB.
>>>
>>>
>>> On Wed, Jun 19, 2013 at 3:30 PM, Gord Tanner  wrote:
>>>
>>> > I would expect they would have a supported node version when they
>>>type:
>>> >
>>> > "npm install cordova"
>>> >
>>> > which would do any version checks in the package.json [1] for
>>>supported
>>> > node versions
>>> >
>>> > [1] -
>>> >
>>> >
>>>
>>>https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=blob_plain;f=
>>>package.json;hb=HEAD
>>> >
>>> >
>>> > On Wed, Jun 19, 2013 at 3:22 PM, Bryan Higgins >> > >wrote:
>>> >
>>> > > So for Cordova 3.0 in general, users will be required to
>>>pre-install a
>>> > > minimum version of node globally?
>>> > >
>>> > > We have had issues where upgrading node breaks stuff. I'd like to
>>>avoid
>>> > > that and give users flexibility with their own system configuration.
>>> > >
>>> > >
>>> > > On Wed, Jun 19, 2013 at 3:09 PM, Gord Tanner 
>>> wrote:
>>> > >
>>> > > > -1
>>> > > >
>>> > > > I would rather we just use the system version of node which would
>>>be
>>> > the
>>> > > > same version as the CLI.  I can't think of any reason a specific
>>> > platform
>>> > > > (aka BlackBerry) would need a special version of a common
>>>dependency.
>>> > > >
>>> > > > Also I don't think you can bundle binaries in an apache release.
>>> > > >
>>> > > >
>>> > > > On Wed, Jun 19, 2013 at 3:01 PM, Bryan Higgins <
>>> > bhigg...@blackberry.com
>>> > > > >wrote:
>>> > > >
>>> > > > > I'd like to reopen the topic of bundling node js into the
>>> blackberry
>>> > > > > platform.
>>> > > > >
>>> > > > > I have personally gotten feedback from users of errors which
>>>were
>>> > > caused
>>> > > > by
>>> > > > > node version inconsistencies. We have since updated the
>>>check_req
>>> > > script
>>> > > > to
>>> > > > > test for the minimum version of node we require, but that is
>>>not an
>>> > > ideal
>>> > > > > solution since users may need a different node version installed
>>> > > globally
>>> > > > > for other software.
>>> > > > >
>>> > > > > At a minimum, I'd like to give users the option to point to an
>>> > > alternate
>>> > > > > version of node. I have logged a JIRA issue for that. [1]
>>> > > > >
>>> > > > > What I'd prefer to do, is bundle the node binaries into the
>>> > > distribution.
>>> > > > > That would completely eliminate the dependency. Users would only
>>> need
>>> > > to
>>> > > > > worry about setting up the native SDK.
>>> > > > >
>>> > > > > We already do this in the WebWorks SDK [2]
>>> > > > >
>>> > > > > I'm interested how the community feels about this. Are there any
>>> > > > licensing
>>> > > > > concerns in Apache hosting binaries without source?
>>> > > > >
>>> > > > > [1] https://issues.apache.org/jira/browse/CB-3798
>>> > > > > [2]
>>> > > > >
>>> > > > >
>>> > > >
>>> > >
>>> >
>>>
>>>https://github.com/blackberry/BB10-Webworks-Packager/tree/master/third_pa
>>>rty/node
>>> > > > >
>>> > > >
>>> > >
>>> >
>>>
>