code review [CB-4992] BlackBerry10 never fires deviceready using cordova-js 3.1.0-rc1

[Carlos Santana]

Can someone review this?

https://issues.apache.org/jira/browse/CB-4942

https://github.com/apache/cordova-js/pull/51

-- 
Carlos Santana

Re: What's the story with cordova.blackberry10.js in 3.1.x?

[Carlos Santana]

nevermind I figure it out and have a pull request

https://github.com/apache/cordova-js/pull/51

--Carlos


On Fri, Sep 27, 2013 at 7:36 PM, Carlos Santana wrote:

> I was trying to test BB10 and got very confuse with the state of
> cordova.js in cordova-blackerry
>
> The version of cordova.js in (BB10 3.1.x & 3.1.0-rc1) is from cordova-js
> 3.0
>
>
> https://github.com/apache/cordova-blackberry/blob/3.1.x/blackberry10/javascript/cordova.blackberry10.js
>
> var CORDOVA_JS_BUILD_LABEL = '3.0.0-0-ge670de9';
>
> I'm looking at this piece as a suspect:
>
> -document.addEventListener("DOMContentLoaded", function () {
> -document.addEventListener("webworksready", function () {
> -require('cordova/channel').onNativeReady.fire();
> -});
> -});
>
> Isn't coho:updateJsSnapshot suppose to make sure that the correct version
> of cordova.js is in the platform repo?
>
> --
> Carlos Santana
> 
>



-- 
Carlos Santana

Re: Adding Cordova-CLI Windows8 support to 3.1.0

[Carlos Santana]

Jesse I think for 3.1.0 most important is to be able to add/rm platforms
and plugins.

For run/emulate we can try do something for 3.2.0 and even if its not
possible by then, I think is a very low priority

--Carlos


On Fri, Sep 27, 2013 at 8:18 PM, Jesse  wrote:

> I have added windows8 support to the cli, and sent a pull request. [1]
> I would like this to be included in the 3.1.0 release if possible.  Please
> review the pull request and feel free to try it out.  There should be no
> impact outside of windows8, and should not affect other platforms.
>
> Note that there are currently some issues with the windows8 platforms
> scripts that prevent the CLI from being able to run/emulate windows8
> projects, these are known issues and have to do with the way that windows8
> signs apps, and the fact that you are actually building on the platform
> where you will run, ie no attached device needed.
>
> The additions allow at least that you can add windows8 as a platform, and
> add / remove plugins.
>
> Cheers,
>   Jesse
>
> [1]
> https://github.com/apache/cordova-cli/pull/44
>
>
>
> @purplecabbage
> risingj.com
>



-- 
Carlos Santana

Adding Cordova-CLI Windows8 support to 3.1.0

[Jesse]

I have added windows8 support to the cli, and sent a pull request. [1]
I would like this to be included in the 3.1.0 release if possible.  Please
review the pull request and feel free to try it out.  There should be no
impact outside of windows8, and should not affect other platforms.

Note that there are currently some issues with the windows8 platforms
scripts that prevent the CLI from being able to run/emulate windows8
projects, these are known issues and have to do with the way that windows8
signs apps, and the fact that you are actually building on the platform
where you will run, ie no attached device needed.

The additions allow at least that you can add windows8 as a platform, and
add / remove plugins.

Cheers,
  Jesse

[1]
https://github.com/apache/cordova-cli/pull/44



@purplecabbage
risingj.com

What's the story with cordova.blackberry10.js in 3.1.x?

[Carlos Santana]

I was trying to test BB10 and got very confuse with the state of cordova.js
in cordova-blackerry

The version of cordova.js in (BB10 3.1.x & 3.1.0-rc1) is from cordova-js 3.0

https://github.com/apache/cordova-blackberry/blob/3.1.x/blackberry10/javascript/cordova.blackberry10.js

var CORDOVA_JS_BUILD_LABEL = '3.0.0-0-ge670de9';

I'm looking at this piece as a suspect:

-document.addEventListener("DOMContentLoaded", function () {
-document.addEventListener("webworksready", function () {
-require('cordova/channel').onNativeReady.fire();
-});
-});

Isn't coho:updateJsSnapshot suppose to make sure that the correct version
of cordova.js is in the platform repo?

-- 
Carlos Santana

Re: Android platform scripts

[Brian LeRoux]

Giver. Now, instead if the grand rewrite how about a refactor  of a single
method for review. Easier for us to buy in and perhaps collab on w you.
On Sep 27, 2013 7:31 PM, "Braden Shepherdson"  wrote:

> I had since learned that shelljs is used for other things. That's fine,
> it's not hurting anything unless we use synchronous exec.
>
> Braden
>
>
> On Fri, Sep 27, 2013 at 12:47 PM, Andrew Grieve  >wrote:
>
> > SGTM. shelljs is used for other things though, so we won't be able to get
> > rid of it.
> >
> >
> > On Fri, Sep 27, 2013 at 4:13 PM, Braden Shepherdson  > >wrote:
> >
> > > The Android platform scripts use shelljs.exec's synchronous mode. This
> > is a
> > > terrible hack that leaks filehandles by the hundred, wastes lots of CPU
> > > cycles, and can cause EMFILE on OSX because it runs out of filehandles.
> > >
> > > I wanted to rewrite the scripts to be async and use child_process.exec
> or
> > > .spawn. I started to, but rapidly found that the tangle of callbacks
> that
> > > resulted was terrible and confusing.
> > >
> > > I propose using Q.js here as well (and dropping shelljs as a
> dependency,
> > if
> > > it was only ever used for .exec).
> > >
> > > Any objections?
> > >
> > > Braden
> > >
> >
>

Re: Review Request 14356: Plugins Release draft blog post

[Andrew Grieve]

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



/www/_posts/2013-09-26-plugins-release.md


nit: add a comma before "which"



/www/_posts/2013-09-26-plugins-release.md


I think it would be good to show an example of how to update the plugins.

E.g. To update your camera plugin:

cordova plugin rm org.apache.cordova.core.camera
cordova plugin add org.apache.cordova.camera


- Andrew Grieve


On Sept. 27, 2013, 1:16 a.m., Steven Gill wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14356/
> ---
> 
> (Updated Sept. 27, 2013, 1:16 a.m.)
> 
> 
> Review request for cordova.
> 
> 
> Repository: cordova-site
> 
> 
> Description
> ---
> 
> I think you have to download the diff. Having a tough time getting it to 
> upload properly. This is the blog post for plugins release. Blog post is at 
> the bottom of the diff. 
> 
> 
> Diffs
> -
> 
>   /public/artwork.html 1526343 
>   /public/blog/index.html 1526343 
>   /public/index.html 1526343 
>   /public/rss.xml 1526343 
>   /www/_posts/2013-09-26-plugins-release.md PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/14356/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Steven Gill
> 
>

Re: Plugins Release blog post

[Andrew Grieve]

best to review the .md file instead.
I don't think there's a good way to host it somewhere, other than for you
to download and apply the patch, and run "rake serve" yourself.


On Fri, Sep 27, 2013 at 7:49 PM, Tim Kim  wrote:

> Can we serve the html doc somewhere? I'd rather not read a diff on html.
>
>
> On 26 September 2013 18:08, Steven Gill  wrote:
>
> > Looks like I forgot to click publish on the review page. I also found a
> > bunch of spelling mistakes I made in my rush to create this. I just fixed
> > them and uploaded a new diff. The review site should be available for all
> > now to leave feedback.
> >
> >
> > On Thu, Sep 26, 2013 at 5:42 PM, Steven Gill 
> > wrote:
> >
> > > Today we are doing a big plugin release in preperation for Apache
> Cordova
> > > 3.1.0 which is scheduled to come out next week.
> > >
> > > The main change for this release is removing core from all of the
> plugin
> > > ID fields. This was done to make installing plugins easier in 3.1.0. We
> > are
> > > switching over to using plugin IDs and ourplugin registery<
> > http://plugins.cordova.io/> for
> > > plugin installation instead of directly installing from the plugin git
> > urls.
> > >
> > > These plugins are compatitable with Cordova 3.0.0. Feel free to upgrade
> > > your current plugins if you can’t wait for 3.1.0 next week. Keep in
> mind
> > > that after you install these update plugins, if you decide to remove
> > these
> > > plugins from your project, you will have to reference the new IDs
> instead
> > > of the old ones that our docs show. Ex: ‘cordova rm
> > > org.apache.cordova.camera’ instead of ‘org.apache.cordova.core.camera’.
> > >
> > > *Other Notable Changes:*
> > >
> > >- Firefox OS support for Vibration and Device Plugin
> > >- Windows 8 support for multiple plugins
> > >- Fixed warnings that arose with XCode 5
> > >- CB-4847 iOS 7 microphone access requires user permission (media
> > >plugin)
> > >- CB-4799 Fix incorrect JS references within native code for iOS &
> > >Andrid (media plugin)
> > >- CB-4806 Update splashscreen image bounds for iOS 7 (splashscreen
> > >plugin)
> > >- CB-4593 Added vibration support for BB10 (vibration plugin)
> > >
> > > You can check out the individual release notes in each of the plugin
> > repos
> > > for more details.
> > >
> > >
> > > On Thu, Sep 26, 2013 at 5:37 PM, Steven Gill  > >wrote:
> > >
> > >> I have no idea how this review stuff works. I will post the blog here
> > >> On Sep 26, 2013 4:59 PM, "Tim Kim"  wrote:
> > >>
> > >>> >
> > >>> > "You don't have access to this review request.
> > >>> > This review request is private. You must be a requested reviewer,
> > >>> either
> > >>> > directly or on a requested group, and have permission to access the
> > >>> > repository in order to view this review request."
> > >>>
> > >>> Ya, same here
> > >>>
> > >>>
> > >>> On 26 September 2013 16:37, Shazron  wrote:
> > >>>
> > >>> > Does everyone have access to this? I get:
> > >>> >
> > >>> > "You don't have access to this review request.
> > >>> > This review request is private. You must be a requested reviewer,
> > >>> either
> > >>> > directly or on a requested group, and have permission to access the
> > >>> > repository in order to view this review request."
> > >>> >
> > >>> >
> > >>> > On Thu, Sep 26, 2013 at 4:30 PM, Steven Gill <
> stevengil...@gmail.com
> > >
> > >>> > wrote:
> > >>> >
> > >>> > > Can you guys review it at https://reviews.apache.org/r/14356/
> > >>> > >
> > >>> > > I don't think post-review was working properly for me...
> > >>> > >
> > >>> >
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> Timothy Kim
> > >>>
> > >>
> > >
> >
>
>
>
> --
> Timothy Kim
>

Re: ios-sim and Xcode 5

[Jan Becicka]

Thanks,
  I reported issue there.
Jan


On Sep 27, 2013, at 8:17 PM, Shazron  wrote:

> ios-sim issues should be discussed in
> https://github.com/phonegap/ios-sim/issues?state=open
> 
> 
> On Fri, Sep 27, 2013 at 11:09 AM, Jan Becicka wrote:
> 
>> Hi,
>>  I'm a NetBeans developer. We have support for developing HTML5 apps in
>> Chrome and also in mobile browsers (We support on device debugging and also
>> simulators). We support cordova packaging as well.
>> Now I upgraded to new Xcode and suddenly I'm not able to open MobileSafari
>> from command line:
>>> ios-sim launch
>> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk/Applications/MobileSafari.app
>> --args -u http://google.com
>> 
>> Session could not be started: Error Domain=DTiPhoneSimulatorErrorDomain
>> Code=1 "iOS Simulator failed to install the application."
>> UserInfo=0x7fe289c1a570 {NSLocalizedDescription=iOS Simulator failed to
>> install the application., DTiPhoneSimulatorUnderlyingErrorCodeKey=-1}
>> 
>> This command worked with Xcode 4, but does not work any more.
>> 
>> Any ideas how to make it work again?
>> I tried to reset simulator and it didn't help.
>> 
>> Thanks,
>> Jan
>> 
>> 

Re: Plugins Release blog post

[Tim Kim]

Can we serve the html doc somewhere? I'd rather not read a diff on html.


On 26 September 2013 18:08, Steven Gill  wrote:

> Looks like I forgot to click publish on the review page. I also found a
> bunch of spelling mistakes I made in my rush to create this. I just fixed
> them and uploaded a new diff. The review site should be available for all
> now to leave feedback.
>
>
> On Thu, Sep 26, 2013 at 5:42 PM, Steven Gill 
> wrote:
>
> > Today we are doing a big plugin release in preperation for Apache Cordova
> > 3.1.0 which is scheduled to come out next week.
> >
> > The main change for this release is removing core from all of the plugin
> > ID fields. This was done to make installing plugins easier in 3.1.0. We
> are
> > switching over to using plugin IDs and ourplugin registery<
> http://plugins.cordova.io/> for
> > plugin installation instead of directly installing from the plugin git
> urls.
> >
> > These plugins are compatitable with Cordova 3.0.0. Feel free to upgrade
> > your current plugins if you can’t wait for 3.1.0 next week. Keep in mind
> > that after you install these update plugins, if you decide to remove
> these
> > plugins from your project, you will have to reference the new IDs instead
> > of the old ones that our docs show. Ex: ‘cordova rm
> > org.apache.cordova.camera’ instead of ‘org.apache.cordova.core.camera’.
> >
> > *Other Notable Changes:*
> >
> >- Firefox OS support for Vibration and Device Plugin
> >- Windows 8 support for multiple plugins
> >- Fixed warnings that arose with XCode 5
> >- CB-4847 iOS 7 microphone access requires user permission (media
> >plugin)
> >- CB-4799 Fix incorrect JS references within native code for iOS &
> >Andrid (media plugin)
> >- CB-4806 Update splashscreen image bounds for iOS 7 (splashscreen
> >plugin)
> >- CB-4593 Added vibration support for BB10 (vibration plugin)
> >
> > You can check out the individual release notes in each of the plugin
> repos
> > for more details.
> >
> >
> > On Thu, Sep 26, 2013 at 5:37 PM, Steven Gill  >wrote:
> >
> >> I have no idea how this review stuff works. I will post the blog here
> >> On Sep 26, 2013 4:59 PM, "Tim Kim"  wrote:
> >>
> >>> >
> >>> > "You don't have access to this review request.
> >>> > This review request is private. You must be a requested reviewer,
> >>> either
> >>> > directly or on a requested group, and have permission to access the
> >>> > repository in order to view this review request."
> >>>
> >>> Ya, same here
> >>>
> >>>
> >>> On 26 September 2013 16:37, Shazron  wrote:
> >>>
> >>> > Does everyone have access to this? I get:
> >>> >
> >>> > "You don't have access to this review request.
> >>> > This review request is private. You must be a requested reviewer,
> >>> either
> >>> > directly or on a requested group, and have permission to access the
> >>> > repository in order to view this review request."
> >>> >
> >>> >
> >>> > On Thu, Sep 26, 2013 at 4:30 PM, Steven Gill  >
> >>> > wrote:
> >>> >
> >>> > > Can you guys review it at https://reviews.apache.org/r/14356/
> >>> > >
> >>> > > I don't think post-review was working properly for me...
> >>> > >
> >>> >
> >>>
> >>>
> >>>
> >>> --
> >>> Timothy Kim
> >>>
> >>
> >
>



-- 
Timothy Kim

Review Request 14376: Update cli prepare to make platform config.xml a build artifact

[Jeffrey Heifetz]

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

Review request for cordova.


Bugs: CB-4774
https://issues.apache.org/jira/browse/CB-4774


Repository: cordova-cli


Description
---

Updates the prepare flow to generate the platform config.xml every time by 
combining www/config.xml and platforms/cordova/defaults.xml.

If defaults.xml is not present, the original file is saved there and treated as 
the defaults file.


Diffs
-

  spec/cli.spec.js 999ce62 

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


Testing
---

Tested and Working for BlackBerry use cases


Thanks,

Jeffrey Heifetz

Re: 2.9.0 Support

[Ian Clelland]

On Fri, Sep 27, 2013 at 6:34 PM, Joe Bowser  wrote:

>
> So, are we going to do a 2.9.1? Should I be going through all the
> plugins and making sure that everything is backported?
>

I like the idea of releasing 2.9.1 close to Cordova 3.1 -- could we
continue with that up to 2.9.5 with Cordova 3.5? (Cadence-release, of
course :) )

Re: Updating plugin code on prepare

[Michal Mocny]

On Fri, Sep 27, 2013 at 2:10 PM, Andrew Grieve  wrote:

> Just tried some symlinks in Xcode 5:
> - Copying assets work (due to our custom build step)
> - Building works (compiler follows links just fine)
> - Editing a fail (big fail. Files open but changes cannot be saved.)
>

Hmm, changes via xcode to symlinks fail, you mean?  That would be hard to
fix, but perhaps at least its feedback to the user not to make direct edits
there, when using CLI workflow ;) so may still be a valid change to make.


>
> For Xcode though, it is an option to change our installation step to have
> Xcode reference the native files within plugins/ rather than within
> platforms/.
>
>
> Symlinks in Eclipse:
> - Copying assets works out-of-the-box
> - Build works fine
> - Editing seems to work fine (edits saved to symlinked location).
>
>
>
> Still though, maybe the best solution would be a combination of the two?
> Have prepare know when an remove+add is necessary?
>

Yes, I think thats what we are suggesting.

The original email mentioned prepare knowing when remove+add are necessary,
which I think is already settled as a good idea.  Not sure if you had more
to add about how prepare should know when to do this (currently, its only
on plugin.xml changes).
The more recent suggestions about making links between platform&plugins
were additional requests to address the rest of the workflow issues (ie,
most users prefer to edit inside platforms/ folder because of IDE
integration etc).

Were you implying anything different here?


>
> On Fri, Sep 27, 2013 at 6:25 PM, Michal Mocny  wrote:
>
> > Have we not previously solved the symlink problem in xcode with a build
> > hook, or was that for prepare step?
> >
> > The --link concept doesn't do anything for that platforms -> plugins file
> > mapping.  Its useful for mapping plugins/ to local source, but it doesn't
> > help with the problem Tyler mentions, right?
> >
> > -Michal
> >
> >
> > On Fri, Sep 27, 2013 at 1:20 PM, Braden Shepherdson  > >wrote:
> >
> > > Symlinks in platforms/ are a problem because Xcode doesn't honour them,
> > at
> > > least last time we tried it.
> > >
> > > I'm much more enthused about the --link concept than any syncing,
> though.
> > > Also if someone wants to sync, they can already use rsync to do it
> > > manually.
> > >
> > > Braden
> > >
> > >
> > > On Fri, Sep 27, 2013 at 11:45 AM, Andrew Grieve  > > >wrote:
> > >
> > > > I think it'd be good to enumerate our options for workflow before we
> > > > decided on which to implement (or maybe choose multiple).
> > > >
> > > > Tyler's idea about a sync command seems like it would be handy. Edit
> > your
> > > > plugin files within platforms/, and then run `cordova plugin
> > copychanges
> > > > org.my.plugin` to do a reverse copy of the source files back to the
> > > install
> > > > source location of the plugin. Big caveat though is that you run the
> > risk
> > > > of prepare clobbering your changes. I think that's too killer a risk.
> > > >
> > > > Another thought is that we could use symlinks when running prepare.
> > Have
> > > > files within platforms/ symlink to files within plugins/, then
> symlink
> > > > again back to their original sources. Would this work with editors in
> > > > practice? I don't know, but worth exploring. Wikipedia says symlinks
> > work
> > > > on NTFS as of Vista.
> > > >
> > > > Braden / Michael - I think yours is a good idea as well. Although, I
> > > don't
> > > > think we should encourage people to edit files within plugins/. They
> > > should
> > > > edit their plugins from install point. We should record the install
> > path,
> > > > and maybe have prepare have a prepare --update-local-plugins.
> > > >
> > > > Any other ideas?
> > > >
> > > >
> > > >
> > > > On Fri, Sep 27, 2013 at 3:13 PM, Michael Sierra 
> > > wrote:
> > > >
> > > > > Can you please file JIRAs on doc problems like this?   Existing
> > > overview
> > > > > doc says you can use the CLI to bootstrap & hand off to an SDK &
> > > > supporting
> > > > > platform command-line utilities.  I take your comment to mean doc
> > > should
> > > > > better stress that once you start working with platform tools
> > > downstream,
> > > > > you can't go back to the CLI. Correct?
> > > > >
> > > > > --Mike Sierra
> > > > >
> > > > >
> > > > > 
> > > > > From: Tyler Wilson [twil...@pulse-robotics.com]
> > > > > Sent: Thursday, September 26, 2013 8:19 PM
> > > > > To: dev@cordova.apache.org
> > > > > Subject: Re: Updating plugin code on prepare
> > > > >
> > > > > Re: IDEs: if it is the case that the CLI should not be used along
> > with
> > > an
> > > > > IDE, perhaps the documentation - including Getting Started Guides,
> > > etc. -
> > > > > ought to be much clearer about this. Perhaps a big warning that
> > "Xcode
> > > > > project files are created by the CLI, but they should not be opened
> > and
> > > > > used by Xcode. And you definitely should not edit code within the
> > IDE".

Re: ios-sim and Xcode 5

[Shazron]

ios-sim issues should be discussed in
https://github.com/phonegap/ios-sim/issues?state=open


On Fri, Sep 27, 2013 at 11:09 AM, Jan Becicka wrote:

> Hi,
>   I'm a NetBeans developer. We have support for developing HTML5 apps in
> Chrome and also in mobile browsers (We support on device debugging and also
> simulators). We support cordova packaging as well.
> Now I upgraded to new Xcode and suddenly I'm not able to open MobileSafari
> from command line:
> > ios-sim launch
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk/Applications/MobileSafari.app
> --args -u http://google.com
>
> Session could not be started: Error Domain=DTiPhoneSimulatorErrorDomain
> Code=1 "iOS Simulator failed to install the application."
> UserInfo=0x7fe289c1a570 {NSLocalizedDescription=iOS Simulator failed to
> install the application., DTiPhoneSimulatorUnderlyingErrorCodeKey=-1}
>
> This command worked with Xcode 4, but does not work any more.
>
> Any ideas how to make it work again?
> I tried to reset simulator and it didn't help.
>
> Thanks,
> Jan
>
>

Re: Updating plugin code on prepare

[Andrew Grieve]

Just tried some symlinks in Xcode 5:
- Copying assets work (due to our custom build step)
- Building works (compiler follows links just fine)
- Editing a fail (big fail. Files open but changes cannot be saved.)

For Xcode though, it is an option to change our installation step to have
Xcode reference the native files within plugins/ rather than within
platforms/.


Symlinks in Eclipse:
- Copying assets works out-of-the-box
- Build works fine
- Editing seems to work fine (edits saved to symlinked location).



Still though, maybe the best solution would be a combination of the two?
Have prepare know when an remove+add is necessary?


On Fri, Sep 27, 2013 at 6:25 PM, Michal Mocny  wrote:

> Have we not previously solved the symlink problem in xcode with a build
> hook, or was that for prepare step?
>
> The --link concept doesn't do anything for that platforms -> plugins file
> mapping.  Its useful for mapping plugins/ to local source, but it doesn't
> help with the problem Tyler mentions, right?
>
> -Michal
>
>
> On Fri, Sep 27, 2013 at 1:20 PM, Braden Shepherdson  >wrote:
>
> > Symlinks in platforms/ are a problem because Xcode doesn't honour them,
> at
> > least last time we tried it.
> >
> > I'm much more enthused about the --link concept than any syncing, though.
> > Also if someone wants to sync, they can already use rsync to do it
> > manually.
> >
> > Braden
> >
> >
> > On Fri, Sep 27, 2013 at 11:45 AM, Andrew Grieve  > >wrote:
> >
> > > I think it'd be good to enumerate our options for workflow before we
> > > decided on which to implement (or maybe choose multiple).
> > >
> > > Tyler's idea about a sync command seems like it would be handy. Edit
> your
> > > plugin files within platforms/, and then run `cordova plugin
> copychanges
> > > org.my.plugin` to do a reverse copy of the source files back to the
> > install
> > > source location of the plugin. Big caveat though is that you run the
> risk
> > > of prepare clobbering your changes. I think that's too killer a risk.
> > >
> > > Another thought is that we could use symlinks when running prepare.
> Have
> > > files within platforms/ symlink to files within plugins/, then symlink
> > > again back to their original sources. Would this work with editors in
> > > practice? I don't know, but worth exploring. Wikipedia says symlinks
> work
> > > on NTFS as of Vista.
> > >
> > > Braden / Michael - I think yours is a good idea as well. Although, I
> > don't
> > > think we should encourage people to edit files within plugins/. They
> > should
> > > edit their plugins from install point. We should record the install
> path,
> > > and maybe have prepare have a prepare --update-local-plugins.
> > >
> > > Any other ideas?
> > >
> > >
> > >
> > > On Fri, Sep 27, 2013 at 3:13 PM, Michael Sierra 
> > wrote:
> > >
> > > > Can you please file JIRAs on doc problems like this?   Existing
> > overview
> > > > doc says you can use the CLI to bootstrap & hand off to an SDK &
> > > supporting
> > > > platform command-line utilities.  I take your comment to mean doc
> > should
> > > > better stress that once you start working with platform tools
> > downstream,
> > > > you can't go back to the CLI. Correct?
> > > >
> > > > --Mike Sierra
> > > >
> > > >
> > > > 
> > > > From: Tyler Wilson [twil...@pulse-robotics.com]
> > > > Sent: Thursday, September 26, 2013 8:19 PM
> > > > To: dev@cordova.apache.org
> > > > Subject: Re: Updating plugin code on prepare
> > > >
> > > > Re: IDEs: if it is the case that the CLI should not be used along
> with
> > an
> > > > IDE, perhaps the documentation - including Getting Started Guides,
> > etc. -
> > > > ought to be much clearer about this. Perhaps a big warning that
> "Xcode
> > > > project files are created by the CLI, but they should not be opened
> and
> > > > used by Xcode. And you definitely should not edit code within the
> IDE".
> > > >
> > > > I just went to the main documentation site here -
> > > >
> > >
> >
> http://cordova.apache.org/docs/en/3.0.0/guide_overview_index.md.html#Overview-anditappears
>  it only mentions the new CLI interface. No mention of the
> > > > old bin/create method. Seems to me there may be communication problem
> > > here.
> > > >
> > > > Thanks,
> > > > Tyler
> > > >
> > > > On Sep 26, 2013, at 6:11 PM, Anis KADRI 
> wrote:
> > > >
> > > > > @purplecabbage: I have the same workflow but I think the proposed
> > > > > solution is a step in the right direction. It would allow us to
> > easily
> > > > > develop platform plugins without having to delete project/create
> > > > > project/install plugin/uninstall plugin constantly. The plugin
> would
> > > > > be packaged (plugin.xml) from day 1 and one can only focus on
> > > > > development.
> > > > >
> > > > > As far as IDEs, the answer is simple. You should not use IDEs and
> > > > > cordova-cli at the same time. Until IDEs are aware of cordova-cli
> > > > > there is no point in creating projects with cordova-cli b

ios-sim and Xcode 5

[Jan Becicka]

Hi,
  I'm a NetBeans developer. We have support for developing HTML5 apps in Chrome 
and also in mobile browsers (We support on device debugging and also 
simulators). We support cordova packaging as well.
Now I upgraded to new Xcode and suddenly I'm not able to open MobileSafari from 
command line:
> ios-sim launch 
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk/Applications/MobileSafari.app
>  --args -u http://google.com

Session could not be started: Error Domain=DTiPhoneSimulatorErrorDomain Code=1 
"iOS Simulator failed to install the application." UserInfo=0x7fe289c1a570 
{NSLocalizedDescription=iOS Simulator failed to install the application., 
DTiPhoneSimulatorUnderlyingErrorCodeKey=-1}

This command worked with Xcode 4, but does not work any more.

Any ideas how to make it work again?
I tried to reset simulator and it didn't help.

Thanks,
Jan

Re: w3c DAP WG discussing vibration strength

[Jesse]

FYI, none of the device SDKs currently support this ( maybe BB? ), which is
what I implied previously.  It will be ignored everywhere for awhile.

@purplecabbage
risingj.com


On Fri, Sep 27, 2013 at 10:15 AM, Shazron  wrote:

> iOS has no way to control vibration strength FYI, so it will just ignore
> this parameter if implemented
>
>
> On Thu, Sep 26, 2013 at 10:17 AM, Jesse  wrote:
>
> > It would be even nicer if any of the platforms we support had APIs to
> > change the 'volume' of the vibration. :(
> >
> > @purplecabbage
> > risingj.com
> >
> >
> > On Thu, Sep 26, 2013 at 9:58 AM, Brian LeRoux  wrote:
> >
> > > Would be great to get our plugins aligned with the latest specs. (And
> now
> > > that we have independent revisiting we can!)
> > >
> > >
> > > On Thu, Sep 26, 2013 at 4:26 PM, Lisa Seacat DeLuca <
> ldel...@us.ibm.com
> > > >wrote:
> > >
> > > > FYI, the w3c Device API's Working Group is discussing the idea of
> > adding
> > > > strength to the vibration command.  more information can be found
> here:
> > > > http://www.w3.org/2009/dap/track/issues/146
> > > >
> > > > Does anyone here have any opinion one way or another on this change
> and
> > > > how it might affect our cordova vibration spec?
> > > >
> > > > proposal example:
> > > >
> > > > Vibration API strength proposal with stair-stepping/smooth volume
> > > > reduce/increase:
> > > >
> > > > navigator.vibrate([
> > > > {
> > > > "time": 200, // Required property.
> > > > "volume": [0, 80] // Minimum 0, maximum 100, default 100. [0, 80]
> > smooth
> > > > volume increase - starts volume strength at 0 and smoothly increases
> to
> > > 80
> > > > till end.
> > > > },
> > > > {
> > > > "time": 1000, // 1000 ms
> > > > "delay": 50, // Will start vibrate after 50 ms. Default 0 ms
> > > > "volume": [0, 100, 0] // Smooth volume reduce-increas-reduce - starts
> > at
> > > > 0, smoothly increases to 100 in 50 ms and smooth reduce to 0 at end.
> > > > },
> > > > {
> > > > "time": 200,
> > > > "volume": [50] // Stair-stepping volume - will start and end volume
> > > > strength 50.
> > > > }
> > > > ]);
> > > >
> > > > or the same in simplified version without strings:
> > > >
> > > > navigator.vibrate([{200, [0, 80]}, {1000, 50, [0, 100, 0]}, {200,
> > > [50]}]);
> > > >
> > > >
> > > >
> > > > Lisa Seacat DeLuca
> > > > ldel...@apache.org
> > >
> >
>

Re: Updating plugin code on prepare

[Michal Mocny]

Have we not previously solved the symlink problem in xcode with a build
hook, or was that for prepare step?

The --link concept doesn't do anything for that platforms -> plugins file
mapping.  Its useful for mapping plugins/ to local source, but it doesn't
help with the problem Tyler mentions, right?

-Michal


On Fri, Sep 27, 2013 at 1:20 PM, Braden Shepherdson wrote:

> Symlinks in platforms/ are a problem because Xcode doesn't honour them, at
> least last time we tried it.
>
> I'm much more enthused about the --link concept than any syncing, though.
> Also if someone wants to sync, they can already use rsync to do it
> manually.
>
> Braden
>
>
> On Fri, Sep 27, 2013 at 11:45 AM, Andrew Grieve  >wrote:
>
> > I think it'd be good to enumerate our options for workflow before we
> > decided on which to implement (or maybe choose multiple).
> >
> > Tyler's idea about a sync command seems like it would be handy. Edit your
> > plugin files within platforms/, and then run `cordova plugin copychanges
> > org.my.plugin` to do a reverse copy of the source files back to the
> install
> > source location of the plugin. Big caveat though is that you run the risk
> > of prepare clobbering your changes. I think that's too killer a risk.
> >
> > Another thought is that we could use symlinks when running prepare. Have
> > files within platforms/ symlink to files within plugins/, then symlink
> > again back to their original sources. Would this work with editors in
> > practice? I don't know, but worth exploring. Wikipedia says symlinks work
> > on NTFS as of Vista.
> >
> > Braden / Michael - I think yours is a good idea as well. Although, I
> don't
> > think we should encourage people to edit files within plugins/. They
> should
> > edit their plugins from install point. We should record the install path,
> > and maybe have prepare have a prepare --update-local-plugins.
> >
> > Any other ideas?
> >
> >
> >
> > On Fri, Sep 27, 2013 at 3:13 PM, Michael Sierra 
> wrote:
> >
> > > Can you please file JIRAs on doc problems like this?   Existing
> overview
> > > doc says you can use the CLI to bootstrap & hand off to an SDK &
> > supporting
> > > platform command-line utilities.  I take your comment to mean doc
> should
> > > better stress that once you start working with platform tools
> downstream,
> > > you can't go back to the CLI. Correct?
> > >
> > > --Mike Sierra
> > >
> > >
> > > 
> > > From: Tyler Wilson [twil...@pulse-robotics.com]
> > > Sent: Thursday, September 26, 2013 8:19 PM
> > > To: dev@cordova.apache.org
> > > Subject: Re: Updating plugin code on prepare
> > >
> > > Re: IDEs: if it is the case that the CLI should not be used along with
> an
> > > IDE, perhaps the documentation - including Getting Started Guides,
> etc. -
> > > ought to be much clearer about this. Perhaps a big warning that "Xcode
> > > project files are created by the CLI, but they should not be opened and
> > > used by Xcode. And you definitely should not edit code within the IDE".
> > >
> > > I just went to the main documentation site here -
> > >
> >
> http://cordova.apache.org/docs/en/3.0.0/guide_overview_index.md.html#Overview-andit
>  appears it only mentions the new CLI interface. No mention of the
> > > old bin/create method. Seems to me there may be communication problem
> > here.
> > >
> > > Thanks,
> > > Tyler
> > >
> > > On Sep 26, 2013, at 6:11 PM, Anis KADRI  wrote:
> > >
> > > > @purplecabbage: I have the same workflow but I think the proposed
> > > > solution is a step in the right direction. It would allow us to
> easily
> > > > develop platform plugins without having to delete project/create
> > > > project/install plugin/uninstall plugin constantly. The plugin would
> > > > be packaged (plugin.xml) from day 1 and one can only focus on
> > > > development.
> > > >
> > > > As far as IDEs, the answer is simple. You should not use IDEs and
> > > > cordova-cli at the same time. Until IDEs are aware of cordova-cli
> > > > there is no point in creating projects with cordova-cli because
> > > > everything gets blown on every build. I am not even sure we can make
> > > > Xcode aware of cordova-cli. We've already talked about this prior to
> > > > the 3.0 release and that is why we have the create scripts and
> plugman
> > > > approach. You should not be using cordova-cli either if you're doing
> > > > some custom native dev that can't be pluginized (changing the main
> > > > Activity.java or AppDelegate.m or whatever). If you're using
> > > > cordova-cli just to create a project and then open an IDE to develop,
> > > > you're probably doing it wrong. You should be creating a native
> > > > project and using plugman instead.
> > > >
> > > > On Thu, Sep 26, 2013 at 9:01 PM, Michal Mocny 
> > > wrote:
> > > >> On Thu, Sep 26, 2013 at 1:39 PM, Jesse 
> > wrote:
> > > >>
> > > >>> What does a watch mean?
> > > >>> - if I reboot, is it still watched?
> > > >>>
> > > >>
> > > >> No, this would start 

Re: Android platform scripts

[Braden Shepherdson]

I had since learned that shelljs is used for other things. That's fine,
it's not hurting anything unless we use synchronous exec.

Braden


On Fri, Sep 27, 2013 at 12:47 PM, Andrew Grieve wrote:

> SGTM. shelljs is used for other things though, so we won't be able to get
> rid of it.
>
>
> On Fri, Sep 27, 2013 at 4:13 PM, Braden Shepherdson  >wrote:
>
> > The Android platform scripts use shelljs.exec's synchronous mode. This
> is a
> > terrible hack that leaks filehandles by the hundred, wastes lots of CPU
> > cycles, and can cause EMFILE on OSX because it runs out of filehandles.
> >
> > I wanted to rewrite the scripts to be async and use child_process.exec or
> > .spawn. I started to, but rapidly found that the tangle of callbacks that
> > resulted was terrible and confusing.
> >
> > I propose using Q.js here as well (and dropping shelljs as a dependency,
> if
> > it was only ever used for .exec).
> >
> > Any objections?
> >
> > Braden
> >
>

Re: Updating plugin code on prepare

[Michal Mocny]

On Fri, Sep 27, 2013 at 11:45 AM, Andrew Grieve wrote:

> I think it'd be good to enumerate our options for workflow before we
> decided on which to implement (or maybe choose multiple).
>
> Tyler's idea about a sync command seems like it would be handy. Edit your
> plugin files within platforms/, and then run `cordova plugin copychanges
> org.my.plugin` to do a reverse copy of the source files back to the install
> source location of the plugin. Big caveat though is that you run the risk
> of prepare clobbering your changes. I think that's too killer a risk.
>
> Another thought is that we could use symlinks when running prepare. Have
> files within platforms/ symlink to files within plugins/, then symlink
> again back to their original sources. Would this work with editors in
> practice? I don't know, but worth exploring. Wikipedia says symlinks work
> on NTFS as of Vista.
>

I would love to see this explored.  Its not quite perfect, since you cannot
add/remove files to your plugins from within platform/ copy (i.e. from
IDE), but at least you can edit what's already there.


>
> Braden / Michael - I think yours is a good idea as well. Although, I don't
> think we should encourage people to edit files within plugins/. They should
> edit their plugins from install point. We should record the install path,
> and maybe have prepare have a prepare --update-local-plugins.
>

I agree you should edit the source location of your plugin, but this
happens to be plugins/ quite often:

- When you fetch from registry.  Sure, its not the canonical source, but
its probably too much overhead to tell the dev to clone the original repo
somewhere local and reinstall from path just to try a local change.  They
can do that once they have a patch ready to share/etc.
- When you install with --link, which we should do by default for local
paths
- When you 'plugin create' using CLI, which is not implemented yet, but
we've got on our list

Basically, in almost all cases, I think it should be fine to make edits
inside plugins, and expect to see them reflected after a prepare.


>
> Any other ideas?
>
>
>
> On Fri, Sep 27, 2013 at 3:13 PM, Michael Sierra  wrote:
>
> > Can you please file JIRAs on doc problems like this?   Existing overview
> > doc says you can use the CLI to bootstrap & hand off to an SDK &
> supporting
> > platform command-line utilities.  I take your comment to mean doc should
> > better stress that once you start working with platform tools downstream,
> > you can't go back to the CLI. Correct?
> >
> > --Mike Sierra
> >
> >
> > 
> > From: Tyler Wilson [twil...@pulse-robotics.com]
> > Sent: Thursday, September 26, 2013 8:19 PM
> > To: dev@cordova.apache.org
> > Subject: Re: Updating plugin code on prepare
> >
> > Re: IDEs: if it is the case that the CLI should not be used along with an
> > IDE, perhaps the documentation - including Getting Started Guides, etc. -
> > ought to be much clearer about this. Perhaps a big warning that "Xcode
> > project files are created by the CLI, but they should not be opened and
> > used by Xcode. And you definitely should not edit code within the IDE".
> >
> > I just went to the main documentation site here -
> >
> http://cordova.apache.org/docs/en/3.0.0/guide_overview_index.md.html#Overview-and
>  it appears it only mentions the new CLI interface. No mention of the
> > old bin/create method. Seems to me there may be communication problem
> here.
> >
> > Thanks,
> > Tyler
> >
> > On Sep 26, 2013, at 6:11 PM, Anis KADRI  wrote:
> >
> > > @purplecabbage: I have the same workflow but I think the proposed
> > > solution is a step in the right direction. It would allow us to easily
> > > develop platform plugins without having to delete project/create
> > > project/install plugin/uninstall plugin constantly. The plugin would
> > > be packaged (plugin.xml) from day 1 and one can only focus on
> > > development.
> > >
> > > As far as IDEs, the answer is simple. You should not use IDEs and
> > > cordova-cli at the same time. Until IDEs are aware of cordova-cli
> > > there is no point in creating projects with cordova-cli because
> > > everything gets blown on every build. I am not even sure we can make
> > > Xcode aware of cordova-cli. We've already talked about this prior to
> > > the 3.0 release and that is why we have the create scripts and plugman
> > > approach. You should not be using cordova-cli either if you're doing
> > > some custom native dev that can't be pluginized (changing the main
> > > Activity.java or AppDelegate.m or whatever). If you're using
> > > cordova-cli just to create a project and then open an IDE to develop,
> > > you're probably doing it wrong. You should be creating a native
> > > project and using plugman instead.
> > >
> > > On Thu, Sep 26, 2013 at 9:01 PM, Michal Mocny 
> > wrote:
> > >> On Thu, Sep 26, 2013 at 1:39 PM, Jesse 
> wrote:
> > >>
> > >>> What does a watch mean?
> > >>> - if I reboot, is it still watched?

Re: Updating plugin code on prepare

[Braden Shepherdson]

Symlinks in platforms/ are a problem because Xcode doesn't honour them, at
least last time we tried it.

I'm much more enthused about the --link concept than any syncing, though.
Also if someone wants to sync, they can already use rsync to do it manually.

Braden


On Fri, Sep 27, 2013 at 11:45 AM, Andrew Grieve wrote:

> I think it'd be good to enumerate our options for workflow before we
> decided on which to implement (or maybe choose multiple).
>
> Tyler's idea about a sync command seems like it would be handy. Edit your
> plugin files within platforms/, and then run `cordova plugin copychanges
> org.my.plugin` to do a reverse copy of the source files back to the install
> source location of the plugin. Big caveat though is that you run the risk
> of prepare clobbering your changes. I think that's too killer a risk.
>
> Another thought is that we could use symlinks when running prepare. Have
> files within platforms/ symlink to files within plugins/, then symlink
> again back to their original sources. Would this work with editors in
> practice? I don't know, but worth exploring. Wikipedia says symlinks work
> on NTFS as of Vista.
>
> Braden / Michael - I think yours is a good idea as well. Although, I don't
> think we should encourage people to edit files within plugins/. They should
> edit their plugins from install point. We should record the install path,
> and maybe have prepare have a prepare --update-local-plugins.
>
> Any other ideas?
>
>
>
> On Fri, Sep 27, 2013 at 3:13 PM, Michael Sierra  wrote:
>
> > Can you please file JIRAs on doc problems like this?   Existing overview
> > doc says you can use the CLI to bootstrap & hand off to an SDK &
> supporting
> > platform command-line utilities.  I take your comment to mean doc should
> > better stress that once you start working with platform tools downstream,
> > you can't go back to the CLI. Correct?
> >
> > --Mike Sierra
> >
> >
> > 
> > From: Tyler Wilson [twil...@pulse-robotics.com]
> > Sent: Thursday, September 26, 2013 8:19 PM
> > To: dev@cordova.apache.org
> > Subject: Re: Updating plugin code on prepare
> >
> > Re: IDEs: if it is the case that the CLI should not be used along with an
> > IDE, perhaps the documentation - including Getting Started Guides, etc. -
> > ought to be much clearer about this. Perhaps a big warning that "Xcode
> > project files are created by the CLI, but they should not be opened and
> > used by Xcode. And you definitely should not edit code within the IDE".
> >
> > I just went to the main documentation site here -
> >
> http://cordova.apache.org/docs/en/3.0.0/guide_overview_index.md.html#Overview-and
>  it appears it only mentions the new CLI interface. No mention of the
> > old bin/create method. Seems to me there may be communication problem
> here.
> >
> > Thanks,
> > Tyler
> >
> > On Sep 26, 2013, at 6:11 PM, Anis KADRI  wrote:
> >
> > > @purplecabbage: I have the same workflow but I think the proposed
> > > solution is a step in the right direction. It would allow us to easily
> > > develop platform plugins without having to delete project/create
> > > project/install plugin/uninstall plugin constantly. The plugin would
> > > be packaged (plugin.xml) from day 1 and one can only focus on
> > > development.
> > >
> > > As far as IDEs, the answer is simple. You should not use IDEs and
> > > cordova-cli at the same time. Until IDEs are aware of cordova-cli
> > > there is no point in creating projects with cordova-cli because
> > > everything gets blown on every build. I am not even sure we can make
> > > Xcode aware of cordova-cli. We've already talked about this prior to
> > > the 3.0 release and that is why we have the create scripts and plugman
> > > approach. You should not be using cordova-cli either if you're doing
> > > some custom native dev that can't be pluginized (changing the main
> > > Activity.java or AppDelegate.m or whatever). If you're using
> > > cordova-cli just to create a project and then open an IDE to develop,
> > > you're probably doing it wrong. You should be creating a native
> > > project and using plugman instead.
> > >
> > > On Thu, Sep 26, 2013 at 9:01 PM, Michal Mocny 
> > wrote:
> > >> On Thu, Sep 26, 2013 at 1:39 PM, Jesse 
> wrote:
> > >>
> > >>> What does a watch mean?
> > >>> - if I reboot, is it still watched?
> > >>>
> > >>
> > >> No, this would start a process that lives until you CTRL+C.  You could
> > have
> > >> it run it in the background, or set it to start of startup, but that
> > would
> > >> be using local system tools, not part of the command itself.
> > >>
> > >> Ideally, "watch" should run "prepare" whenever you would have wanted
> it
> > to.
> > >> Though obviously that cannot be perfect, it can be a useful tool when
> > >> iterating.
> > >>
> > >>
> > >>>
> > >>> I think it would be best to consider separating development from
> > packaging
> > >>> in your use-case for workflow.
> > >>> If I am going to develop featureX a

Re: w3c DAP WG discussing vibration strength

[Shazron]

iOS has no way to control vibration strength FYI, so it will just ignore
this parameter if implemented


On Thu, Sep 26, 2013 at 10:17 AM, Jesse  wrote:

> It would be even nicer if any of the platforms we support had APIs to
> change the 'volume' of the vibration. :(
>
> @purplecabbage
> risingj.com
>
>
> On Thu, Sep 26, 2013 at 9:58 AM, Brian LeRoux  wrote:
>
> > Would be great to get our plugins aligned with the latest specs. (And now
> > that we have independent revisiting we can!)
> >
> >
> > On Thu, Sep 26, 2013 at 4:26 PM, Lisa Seacat DeLuca  > >wrote:
> >
> > > FYI, the w3c Device API's Working Group is discussing the idea of
> adding
> > > strength to the vibration command.  more information can be found here:
> > > http://www.w3.org/2009/dap/track/issues/146
> > >
> > > Does anyone here have any opinion one way or another on this change and
> > > how it might affect our cordova vibration spec?
> > >
> > > proposal example:
> > >
> > > Vibration API strength proposal with stair-stepping/smooth volume
> > > reduce/increase:
> > >
> > > navigator.vibrate([
> > > {
> > > "time": 200, // Required property.
> > > "volume": [0, 80] // Minimum 0, maximum 100, default 100. [0, 80]
> smooth
> > > volume increase - starts volume strength at 0 and smoothly increases to
> > 80
> > > till end.
> > > },
> > > {
> > > "time": 1000, // 1000 ms
> > > "delay": 50, // Will start vibrate after 50 ms. Default 0 ms
> > > "volume": [0, 100, 0] // Smooth volume reduce-increas-reduce - starts
> at
> > > 0, smoothly increases to 100 in 50 ms and smooth reduce to 0 at end.
> > > },
> > > {
> > > "time": 200,
> > > "volume": [50] // Stair-stepping volume - will start and end volume
> > > strength 50.
> > > }
> > > ]);
> > >
> > > or the same in simplified version without strings:
> > >
> > > navigator.vibrate([{200, [0, 80]}, {1000, 50, [0, 100, 0]}, {200,
> > [50]}]);
> > >
> > >
> > >
> > > Lisa Seacat DeLuca
> > > ldel...@apache.org
> >
>

Re: About plugins in 3.1

[Steven Gill]

Thanks!


On Fri, Sep 27, 2013 at 12:31 AM, Anis KADRI  wrote:

> Plugins have been published! Time to test!
>
> On Fri, Sep 27, 2013 at 9:18 AM, Anis KADRI  wrote:
> > I will publish them from master. There is an issue with permissions
> > right now :-/
> >
> > On Fri, Sep 27, 2013 at 5:03 AM, Steven Gill 
> wrote:
> >> Plugins are ready to be published. I did plugman adduser. Can't publish
> >> plugins yet. Guessing Anis has to give me permission.
> >>
> >>
> >> On Tue, Sep 17, 2013 at 6:10 PM, Andrew Grieve 
> wrote:
> >>
> >>> The ability to clone from a branch/tag already exists. It didn't for
> 3.0,
> >>> but was added afterwards.
> >>>
> >>> I don't think there's much use in changing instructions to install from
> >>> git+tag urls when the registry exists anyways. The registry has
> >>> 3.0-compatible plugins in it, so that's a better solution.
> >>>
> >>> I do think we should wait some time before making the switch to
> developing
> >>> on master (and deleting the dev branches), since it'll take some time
> to
> >>> get the word out. There's even been some tools (yeoman & the like) that
> >>> have been written that hardcode in the git URLs.
> >>>
> >>> Definitely excited about this though! So much nicer!
> >>>
> >>>
> >>> On Tue, Sep 17, 2013 at 5:20 PM, Anis KADRI 
> wrote:
> >>>
> >>> > @maxw: done!
> >>> >
> >>> > On Tue, Sep 17, 2013 at 1:55 PM, Shazron  wrote:
> >>> > > @Anis yeah this could be a documentation issue. We will have to
> update
> >>> > the
> >>> > > 3.0.0 specific docs.
> >>> > >
> >>> > >
> >>> > > On Tue, Sep 17, 2013 at 1:35 PM, Anis KADRI 
> >>> > wrote:
> >>> > >
> >>> > >> @maxw Did you create a user account with plugman adduser ? I do
> not
> >>> > >> see you in the users' list.
> >>> > >>
> >>> > >> Shazron: Very good point. We can always instruct those users to
> clone
> >>> > >> a 3.0.0 compatible branch from the repositories and install that.
> >>> > >> Maybe we can even update the tools to add the ability to clone
> from
> >>> > >> any branch (or maybe it's in there already ? I know it's in there
> for
> >>> > >> dependencies).
> >>> > >>
> >>> > >> On Tue, Sep 17, 2013 at 1:30 PM, Shazron 
> wrote:
> >>> > >> > I'm all for using master as the branch that we do development
> on,
> >>> but
> >>> > if
> >>> > >> we
> >>> > >> > switch, that will mean anyone on existing cordova v3.0.0 will
> get
> >>> > broken
> >>> > >> > plugins, correct?
> >>> > >> >
> >>> > >> >
> >>> > >> > On Tue, Sep 17, 2013 at 1:25 PM, Steven Gill <
> >>> stevengil...@gmail.com>
> >>> > >> wrote:
> >>> > >> >
> >>> > >> >> What would the command look like to install it if we aren't
> using
> >>> git
> >>> > >> urls?
> >>> > >> >> cordova plugin add camera? Would it automatically take the
> latest
> >>> > >> version
> >>> > >> >> off the registery?
> >>> > >> >>
> >>> > >> >> I like the idea of working on master and tagging a plugin when
> it
> >>> is
> >>> > >> ready
> >>> > >> >> to be published.
> >>> > >> >>
> >>> > >> >>
> >>> > >> >>
> >>> > >> >>
> >>> > >> >> On Tue, Sep 17, 2013 at 1:21 PM, Anis KADRI <
> anis.ka...@gmail.com>
> >>> > >> wrote:
> >>> > >> >>
> >>> > >> >> > As far as I understand and following this documentation:
> >>> > >> >> >
> >>> > >> >> >
> >>> > >> >> >
> >>> > >> >>
> >>> > >>
> >>> >
> >>>
> http://cordova.apache.org/docs/en/3.0.0/guide_cli_index.md.html#The%20Command-line%20Interface
> >>> > >> >> >
> >>> > >> >> > Plugins are currently fetched using git from origin/master.
> It
> >>> is a
> >>> > >> >> > major problem in my opinion. The main reason (but there are
> many)
> >>> > is
> >>> > >> >> > that any commit to master can potentially break plugins.
> Yes, we
> >>> > can
> >>> > >> >> > do a dev branch but some people are forgetful and might
> commit to
> >>> > >> >> > master anyway. I think the proper development process for
> plugins
> >>> > >> >> > should be:
> >>> > >> >> > - Always commit to master
> >>> > >> >> > - When you're ready to release a plugin: update the version,
> tag
> >>> it
> >>> > >> >> > and publish it to the cordova registry.
> >>> > >> >> > - Users can then install the latest version without having to
> >>> > remember
> >>> > >> >> > a git URL and without worrying about getting a broken plugin.
> >>> > >> >> >
> >>> > >> >> > Ideally, every Cordova committer should be granted the right
> to
> >>> > >> >> > publish to the registry. Right now, I've only added Andrew
> Grieve
> >>> > (who
> >>> > >> >> > is having issues publishing atm...). If anybody wants to be
> >>> added,
> >>> > let
> >>> > >> >> > me know.
> >>> > >> >> >
> >>> > >> >> > Does that sound good to everyone?
> >>> > >> >> >
> >>> > >> >> > -a
> >>> > >> >> >
> >>> > >> >>
> >>> > >>
> >>> >
> >>>
>

Re: Android platform scripts

[Andrew Grieve]

SGTM. shelljs is used for other things though, so we won't be able to get
rid of it.


On Fri, Sep 27, 2013 at 4:13 PM, Braden Shepherdson wrote:

> The Android platform scripts use shelljs.exec's synchronous mode. This is a
> terrible hack that leaks filehandles by the hundred, wastes lots of CPU
> cycles, and can cause EMFILE on OSX because it runs out of filehandles.
>
> I wanted to rewrite the scripts to be async and use child_process.exec or
> .spawn. I started to, but rapidly found that the tangle of callbacks that
> resulted was terrible and confusing.
>
> I propose using Q.js here as well (and dropping shelljs as a dependency, if
> it was only ever used for .exec).
>
> Any objections?
>
> Braden
>

Re: Android platform scripts

[Joe Bowser]

Do it!

On Fri, Sep 27, 2013 at 8:13 AM, Braden Shepherdson  wrote:
> The Android platform scripts use shelljs.exec's synchronous mode. This is a
> terrible hack that leaks filehandles by the hundred, wastes lots of CPU
> cycles, and can cause EMFILE on OSX because it runs out of filehandles.
>
> I wanted to rewrite the scripts to be async and use child_process.exec or
> .spawn. I started to, but rapidly found that the tangle of callbacks that
> resulted was terrible and confusing.
>
> I propose using Q.js here as well (and dropping shelljs as a dependency, if
> it was only ever used for .exec).
>
> Any objections?
>
> Braden

Re: 2.9.0 Support

[Joe Bowser]

On Thu, Sep 26, 2013 at 7:17 PM, Ian Clelland  wrote:
> We should be supporting 2.9 -- I'm pretty sure we've committed to at least
> fixing bugs as they come up.
>

We've committed to it, but to be honest, I stopped doing the backports
when I heard there wasn't going to be a 2.9.1 release, because if
there's not going to be a release of 2.9.1, there's no reason to keep
supporting 2.9.x.  It doesn't work with plugman the same way 3.x does.

> We never discussed whether we would *only* be fixing things that were
> reported on the 2.9 branch, or whether we were going to test the issues
> that were reported on 3.x and backport the fixes. I think, though, that as
> long as the codebases haven't diverged *so much* (as in a complete re-write
> of a given plugin), that we should at least take the time to verify the
> issue -- and the fix -- on 2.9, and release 2.9.x versions when it makes
> sense.
>

Agreed.

So, are we going to do a 2.9.1? Should I be going through all the
plugins and making sure that everything is backported?

Re: 2.9.0 Support

[Andrew Grieve]

I was in the habit of merging bug fixes back into 2.9.x a while ago, but
have also stopped doing that.

If we want 2.9.x to be bug fixes only, then I think it makes sense to spend
some time and cherry-pick changes.
If we want 2.9.x to be new features + bug fixes, then we could just work on
adding pre-bundling logic so that "bin/create" causes plugins to be already
installed. We want pre-bundling logic anyways for things like Android's
"App" plugin.

I suspect what we want is the bug fixes, but that does leave iOS7 support
out of 2.9.x, which makes it somewhat useless. So maybe we should just work
on pre-bundling?


On Fri, Sep 27, 2013 at 3:14 PM, Ian Clelland wrote:

> On Fri, Sep 27, 2013 at 3:57 PM, Carlos Santana  >wrote:
>
> > What is the support statement for 2.9.x  for new OSs?
> >
> > For example:
> > iOS7 not supported on 2.9.x
> > xCode 5 not supported on 2.9.x
> >
> > 2.9.x + bugs only supports:
> > iOS 5 and 6
> > Xcode 4.6.3
> >
>
> That's a good question: 6 months from now, there will probably be very few
> of us with Xcode 4.6 -- most developers will have automatically updated.
> Are we committed to still supporting that as a development platform? Or is
> 2.9.1 going to be the "Hey, you need to support iOS 7 or be rejected from
> the App Store" release?
>
> Is there any value in continuing to support 4.6, if Apple is going to start
> rejecting apps which are built with it?
>
> Ian
>
>
> >
> >
> >
> >
> > On Fri, Sep 27, 2013 at 5:19 AM, Brian LeRoux  wrote:
> >
> > > It ends in 3.6 (I would think) as per our 6 month deprec policy.
> > >
> > >
> > > On Fri, Sep 27, 2013 at 11:04 AM, Shazron  wrote:
> > >
> > > > This is relevant, for example, with the iOS 7 fixes for media,
> > > > media-capture, and splashscreen core plugins -- should we backport
> the
> > > > code. They haven't diverged too much - but where does it end for
> > support?
> > > > +1 on defects only (although one can argue these are defects as well)
> > > >
> > > >
> > > > On Thu, Sep 26, 2013 at 7:22 PM, Brian LeRoux  wrote:
> > > >
> > > > > You can help!
> > > > > On Sep 27, 2013 2:37 AM, "Smith, Peter" <
> pet...@fast.au.fujitsu.com>
> > > > > wrote:
> > > > >
> > > > > > Back when we adopted 2.9.0 we were a bit apprehensive about early
> > > > > > adoption of 3.x, so were quite encouraged to read:
> > > > > >
> > > > > > "We understand and respect that there is a huge community of
> > projects
> > > > > > built on PhoneGap 2.0 series and we will continue to support 2.x
> > in a
> > > > > > long lived branch."
> > > > > > http://phonegap.com/blog/2013/06/20/coming-soon-phonegap30/
> > > > > >
> > > > > > At the time it seemed quite clear there would be a 2.9.1, but now
> > it
> > > is
> > > > > > not clear at all...
> > > > > >
> > > > > > Peter
> > > > > >
> > > > > > -Original Message-
> > > > > > From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of
> > > Michal
> > > > > > Mocny
> > > > > > Sent: Friday, 27 September 2013 5:24 AM
> > > > > > To: dev; bows...@apache.org
> > > > > > Subject: Re: 2.9.0 Support
> > > > > >
> > > > > > Sounds less than ideal to have to backport, given that we still
> > > support
> > > > > > the old workflow with 3.0.
> > > > > >
> > > > > > However, I think we did discuss keeping 2.9 maintained while we
> > iron
> > > > out
> > > > > > 3.0 issues.  I think we should drop 2.9 as soon as users run out
> of
> > > > > > *valid* reasons for not upgrading to 3.0, right?
> > > > > >
> > > > > > What do users say when you suggest moving to 3.x to get the
> bugfix?
> > > > > >
> > > > > > -Michal
> > > > > >
> > > > > >
> > > > > > On Thu, Sep 26, 2013 at 3:09 PM, Joe Bowser 
> > > wrote:
> > > > > >
> > > > > > > Hey
> > > > > > >
> > > > > > > What did we agree to for supporting the old 2.9.x branch? I'm
> > just
> > > > > > > wondering, since we're still getting tons of bugs filed against
> > > that.
> > > > > > > While most of them are valid in 3.0.x, we probably should be
> > > > > > > backporting to 2.9.
> > > > > > >
> > > > > > > Have people been doing this.  I've been doing this a bit, but I
> > > have
> > > > > > > to admit that I've been slipping up recently.  What are
> people's
> > > > > > > thoughts on this?
> > > > > > >
> > > > > > > Joe
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Carlos Santana
> > 
> >
>

Re: Updating plugin code on prepare

[Andrew Grieve]

I think it'd be good to enumerate our options for workflow before we
decided on which to implement (or maybe choose multiple).

Tyler's idea about a sync command seems like it would be handy. Edit your
plugin files within platforms/, and then run `cordova plugin copychanges
org.my.plugin` to do a reverse copy of the source files back to the install
source location of the plugin. Big caveat though is that you run the risk
of prepare clobbering your changes. I think that's too killer a risk.

Another thought is that we could use symlinks when running prepare. Have
files within platforms/ symlink to files within plugins/, then symlink
again back to their original sources. Would this work with editors in
practice? I don't know, but worth exploring. Wikipedia says symlinks work
on NTFS as of Vista.

Braden / Michael - I think yours is a good idea as well. Although, I don't
think we should encourage people to edit files within plugins/. They should
edit their plugins from install point. We should record the install path,
and maybe have prepare have a prepare --update-local-plugins.

Any other ideas?



On Fri, Sep 27, 2013 at 3:13 PM, Michael Sierra  wrote:

> Can you please file JIRAs on doc problems like this?   Existing overview
> doc says you can use the CLI to bootstrap & hand off to an SDK & supporting
> platform command-line utilities.  I take your comment to mean doc should
> better stress that once you start working with platform tools downstream,
> you can't go back to the CLI. Correct?
>
> --Mike Sierra
>
>
> 
> From: Tyler Wilson [twil...@pulse-robotics.com]
> Sent: Thursday, September 26, 2013 8:19 PM
> To: dev@cordova.apache.org
> Subject: Re: Updating plugin code on prepare
>
> Re: IDEs: if it is the case that the CLI should not be used along with an
> IDE, perhaps the documentation - including Getting Started Guides, etc. -
> ought to be much clearer about this. Perhaps a big warning that "Xcode
> project files are created by the CLI, but they should not be opened and
> used by Xcode. And you definitely should not edit code within the IDE".
>
> I just went to the main documentation site here -
> http://cordova.apache.org/docs/en/3.0.0/guide_overview_index.md.html#Overview-
>  and it appears it only mentions the new CLI interface. No mention of the
> old bin/create method. Seems to me there may be communication problem here.
>
> Thanks,
> Tyler
>
> On Sep 26, 2013, at 6:11 PM, Anis KADRI  wrote:
>
> > @purplecabbage: I have the same workflow but I think the proposed
> > solution is a step in the right direction. It would allow us to easily
> > develop platform plugins without having to delete project/create
> > project/install plugin/uninstall plugin constantly. The plugin would
> > be packaged (plugin.xml) from day 1 and one can only focus on
> > development.
> >
> > As far as IDEs, the answer is simple. You should not use IDEs and
> > cordova-cli at the same time. Until IDEs are aware of cordova-cli
> > there is no point in creating projects with cordova-cli because
> > everything gets blown on every build. I am not even sure we can make
> > Xcode aware of cordova-cli. We've already talked about this prior to
> > the 3.0 release and that is why we have the create scripts and plugman
> > approach. You should not be using cordova-cli either if you're doing
> > some custom native dev that can't be pluginized (changing the main
> > Activity.java or AppDelegate.m or whatever). If you're using
> > cordova-cli just to create a project and then open an IDE to develop,
> > you're probably doing it wrong. You should be creating a native
> > project and using plugman instead.
> >
> > On Thu, Sep 26, 2013 at 9:01 PM, Michal Mocny 
> wrote:
> >> On Thu, Sep 26, 2013 at 1:39 PM, Jesse  wrote:
> >>
> >>> What does a watch mean?
> >>> - if I reboot, is it still watched?
> >>>
> >>
> >> No, this would start a process that lives until you CTRL+C.  You could
> have
> >> it run it in the background, or set it to start of startup, but that
> would
> >> be using local system tools, not part of the command itself.
> >>
> >> Ideally, "watch" should run "prepare" whenever you would have wanted it
> to.
> >> Though obviously that cannot be perfect, it can be a useful tool when
> >> iterating.
> >>
> >>
> >>>
> >>> I think it would be best to consider separating development from
> packaging
> >>> in your use-case for workflow.
> >>> If I am going to develop featureX as a plugin I would :
> >>>
> >>> 1. create a project for a single cordova platform, and develop the
> feature
> >>> as a native piece, and a js piece.
> >>> 2. test thoroughly
> >>> 3. create a project for a second cordova platform, and develop the
> native
> >>> bit, preserving the js from 1
> >>> 4. test thoroughly
> >>> 5. repeat steps 3+4 for any remaining platforms
> >>> 6. package featureX as a plugin by organizing relevant bits in the
> correct
> >>> folder structure, and adding a plugin.xml
> >>> 7. test each pl

Android platform scripts

[Braden Shepherdson]

The Android platform scripts use shelljs.exec's synchronous mode. This is a
terrible hack that leaks filehandles by the hundred, wastes lots of CPU
cycles, and can cause EMFILE on OSX because it runs out of filehandles.

I wanted to rewrite the scripts to be async and use child_process.exec or
.spawn. I started to, but rapidly found that the tangle of callbacks that
resulted was terrible and confusing.

I propose using Q.js here as well (and dropping shelljs as a dependency, if
it was only ever used for .exec).

Any objections?

Braden

Re: mobile-spec and releases: How do we test?

[Braden Shepherdson]

Which one?


On Fri, Sep 27, 2013 at 10:09 AM, Brian LeRoux  wrote:

> I really like your proposal as a starting point. Very simple but would
> allow for in-app testing as well as on the cmd line if we so wish.
>
>
> On Fri, Sep 27, 2013 at 3:28 PM, Michal Mocny  wrote:
>
> > I was looking over some old emails from this list on plugin testing, and
> an
> > idea that was proposed way back was to ship plugin tests as a second
> > plugin.  That way, you can chose to install tests, or not, and know
> > explicitly if they are being copied into your final project.
> >
> > An alternative would be to support build targets a la "release/debug" and
> > have target-specific plugin.xml tags (assets, js-modules, source-file..).
> >
> > -Michal
> >
> >
> > On Fri, Sep 27, 2013 at 4:52 AM, Brian LeRoux  wrote:
> >
> > > I think this is basically what we've been proposing for a while now.
> > >
> > >
> > > On Thu, Sep 26, 2013 at 8:29 PM, Michal Mocny 
> > wrote:
> > >
> > > > I would suggest perhaps a simpler approach, which doesn't add
> anything
> > > new
> > > > to cordova-cli/plugman:
> > > >
> > > > - Each plugin ships with a "tests" js-module, and we document a
> > > convention
> > > > of where they should live, and what signature it should have (i.e.,
> > > > cordova.require('plugin.name.Tests').forEach(...) ).
> > > >   - Will need a common way to describe/report results (others have
> > > > mentioned TAP).
> > > > - Any app is free to run those plugin tests in any which way, but we
> > > ship a
> > > > mobile-spec app which is one opinionated way to do so.
> > > >   - It attempts to require the test module for each installed plugin,
> > > runs
> > > > them, and aggregates results.
> > > >   - It could report results to some shared server, allow toggling of
> > > tests,
> > > > etc, but no plugin should know or care about those features.
> > > >
> > > > Using that as a generic base:
> > > >
> > > > - We ship a "CDVTests" (or whatever) plugin which has a bunch of
> > library
> > > > code for creating tests, and plugins can use it to register their
> > tests.
> > > > - This makes it easier to register manual tests in a common format
> for
> > > core
> > > > plugins, and prevents code duplication for core auto tests.
> > > > - External plugins can chose to use our testing library, or not.
> > > >
> > > > -Michal
> > > >
> > > >
> > > > On Thu, Sep 26, 2013 at 10:34 AM, Braden Shepherdson <
> > > bra...@chromium.org
> > > > >wrote:
> > > >
> > > > > Here's an off-the-top-of-my-head sketch of how we might do Voltron
> > > tests:
> > > > >
> > > > > - Add a tag to plugin.xml that names each test file:
> > > > >  />
> > > > > 
> > > > > - Add a new command, cordova test (maybe prepare-test), that:
> > > > > - Ignores the top-level www.
> > > > > - Instead copies in a basic testing index.html similar to the
> > > current
> > > > > mobile-spec's
> > > > > - That index reads a file akin to cordova_plugins.js
> > > > (cordova_tests.js,
> > > > > maybe?) generated by the CLI, containing the info from the 
> > tags.
> > > > > - It has navigation similar to the current mobile-spec, with
> > > buttons
> > > > > for the automatic and manual sections. Auto has "All" and then each
> > > > module,
> > > > > manual just has the list of modules.
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > Braden
> > > > >
> > > > >
> > > > > On Thu, Sep 26, 2013 at 6:33 AM, Carlos Santana <
> > csantan...@gmail.com
> > > > > >wrote:
> > > > >
> > > > > > I like the idea can we call mobilespec now cordova-voltron and be
> > DRY
> > > > and
> > > > > > use the tests form the plugins.
> > > > > >
> > > > > > Voltron by itself creates an App that tests only core, but as you
> > > > > > use plugman to add plugins to voltron it has more test cases.
> > > > > >
> > > > > > It would not be a bad idea to enhance plugin.xml in the future to
> > > > include
> > > > > > information about testing (i.e. Directory containing tests files,
> > > test
> > > > > > command, etc..)
> > > > > >
> > > > > > --Carlos
> > > > > >
> > > > > > On Thursday, September 26, 2013, Anis KADRI wrote:
> > > > > >
> > > > > > > What's the challenge of having us use the tests that come with
> > the
> > > > > > > individual plugins ?
> > > > > > >
> > > > > > > On Thu, Sep 26, 2013 at 8:13 AM, David Kemp  > > > > > >
> > > > > > > wrote:
> > > > > > > > Currently, the automated test system that we have running
> > > (derived
> > > > > from
> > > > > > > > Medic) uses only the mobilespec tests. It does not yet use
> > tests
> > > > > > > collected
> > > > > > > > from the plugins. Its been talked about, but not gone
> anywhere.
> > > > > > > >
> > > > > > > > David Kemp
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Sep 25, 2013 at 7:58 PM, Jesse <
> > purplecabb...@gmail.com
> > > > > > >
> > > > > > > wrote:
> > > > > > > >
> > > > > > > >> Yeah, I have pushed some changes to mobile-spec, and when I
> > did
> > > I
> > > > > also
> > > > > > > >> c

Re: 2.9.0 Support

[Ian Clelland]

On Fri, Sep 27, 2013 at 3:57 PM, Carlos Santana wrote:

> What is the support statement for 2.9.x  for new OSs?
>
> For example:
> iOS7 not supported on 2.9.x
> xCode 5 not supported on 2.9.x
>
> 2.9.x + bugs only supports:
> iOS 5 and 6
> Xcode 4.6.3
>

That's a good question: 6 months from now, there will probably be very few
of us with Xcode 4.6 -- most developers will have automatically updated.
Are we committed to still supporting that as a development platform? Or is
2.9.1 going to be the "Hey, you need to support iOS 7 or be rejected from
the App Store" release?

Is there any value in continuing to support 4.6, if Apple is going to start
rejecting apps which are built with it?

Ian


>
>
>
>
> On Fri, Sep 27, 2013 at 5:19 AM, Brian LeRoux  wrote:
>
> > It ends in 3.6 (I would think) as per our 6 month deprec policy.
> >
> >
> > On Fri, Sep 27, 2013 at 11:04 AM, Shazron  wrote:
> >
> > > This is relevant, for example, with the iOS 7 fixes for media,
> > > media-capture, and splashscreen core plugins -- should we backport the
> > > code. They haven't diverged too much - but where does it end for
> support?
> > > +1 on defects only (although one can argue these are defects as well)
> > >
> > >
> > > On Thu, Sep 26, 2013 at 7:22 PM, Brian LeRoux  wrote:
> > >
> > > > You can help!
> > > > On Sep 27, 2013 2:37 AM, "Smith, Peter" 
> > > > wrote:
> > > >
> > > > > Back when we adopted 2.9.0 we were a bit apprehensive about early
> > > > > adoption of 3.x, so were quite encouraged to read:
> > > > >
> > > > > "We understand and respect that there is a huge community of
> projects
> > > > > built on PhoneGap 2.0 series and we will continue to support 2.x
> in a
> > > > > long lived branch."
> > > > > http://phonegap.com/blog/2013/06/20/coming-soon-phonegap30/
> > > > >
> > > > > At the time it seemed quite clear there would be a 2.9.1, but now
> it
> > is
> > > > > not clear at all...
> > > > >
> > > > > Peter
> > > > >
> > > > > -Original Message-
> > > > > From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of
> > Michal
> > > > > Mocny
> > > > > Sent: Friday, 27 September 2013 5:24 AM
> > > > > To: dev; bows...@apache.org
> > > > > Subject: Re: 2.9.0 Support
> > > > >
> > > > > Sounds less than ideal to have to backport, given that we still
> > support
> > > > > the old workflow with 3.0.
> > > > >
> > > > > However, I think we did discuss keeping 2.9 maintained while we
> iron
> > > out
> > > > > 3.0 issues.  I think we should drop 2.9 as soon as users run out of
> > > > > *valid* reasons for not upgrading to 3.0, right?
> > > > >
> > > > > What do users say when you suggest moving to 3.x to get the bugfix?
> > > > >
> > > > > -Michal
> > > > >
> > > > >
> > > > > On Thu, Sep 26, 2013 at 3:09 PM, Joe Bowser 
> > wrote:
> > > > >
> > > > > > Hey
> > > > > >
> > > > > > What did we agree to for supporting the old 2.9.x branch? I'm
> just
> > > > > > wondering, since we're still getting tons of bugs filed against
> > that.
> > > > > > While most of them are valid in 3.0.x, we probably should be
> > > > > > backporting to 2.9.
> > > > > >
> > > > > > Have people been doing this.  I've been doing this a bit, but I
> > have
> > > > > > to admit that I've been slipping up recently.  What are people's
> > > > > > thoughts on this?
> > > > > >
> > > > > > Joe
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>
>
>
> --
> Carlos Santana
> 
>

RE: Updating plugin code on prepare

[Michael Sierra]

Can you please file JIRAs on doc problems like this?   Existing overview doc 
says you can use the CLI to bootstrap & hand off to an SDK & supporting 
platform command-line utilities.  I take your comment to mean doc should better 
stress that once you start working with platform tools downstream, you can't go 
back to the CLI. Correct?

--Mike Sierra



From: Tyler Wilson [twil...@pulse-robotics.com]
Sent: Thursday, September 26, 2013 8:19 PM
To: dev@cordova.apache.org
Subject: Re: Updating plugin code on prepare

Re: IDEs: if it is the case that the CLI should not be used along with an IDE, 
perhaps the documentation - including Getting Started Guides, etc. - ought to 
be much clearer about this. Perhaps a big warning that "Xcode project files are 
created by the CLI, but they should not be opened and used by Xcode. And you 
definitely should not edit code within the IDE".

I just went to the main documentation site here - 
http://cordova.apache.org/docs/en/3.0.0/guide_overview_index.md.html#Overview - 
and it appears it only mentions the new CLI interface. No mention of the old 
bin/create method. Seems to me there may be communication problem here.

Thanks,
Tyler

On Sep 26, 2013, at 6:11 PM, Anis KADRI  wrote:

> @purplecabbage: I have the same workflow but I think the proposed
> solution is a step in the right direction. It would allow us to easily
> develop platform plugins without having to delete project/create
> project/install plugin/uninstall plugin constantly. The plugin would
> be packaged (plugin.xml) from day 1 and one can only focus on
> development.
>
> As far as IDEs, the answer is simple. You should not use IDEs and
> cordova-cli at the same time. Until IDEs are aware of cordova-cli
> there is no point in creating projects with cordova-cli because
> everything gets blown on every build. I am not even sure we can make
> Xcode aware of cordova-cli. We've already talked about this prior to
> the 3.0 release and that is why we have the create scripts and plugman
> approach. You should not be using cordova-cli either if you're doing
> some custom native dev that can't be pluginized (changing the main
> Activity.java or AppDelegate.m or whatever). If you're using
> cordova-cli just to create a project and then open an IDE to develop,
> you're probably doing it wrong. You should be creating a native
> project and using plugman instead.
>
> On Thu, Sep 26, 2013 at 9:01 PM, Michal Mocny  wrote:
>> On Thu, Sep 26, 2013 at 1:39 PM, Jesse  wrote:
>>
>>> What does a watch mean?
>>> - if I reboot, is it still watched?
>>>
>>
>> No, this would start a process that lives until you CTRL+C.  You could have
>> it run it in the background, or set it to start of startup, but that would
>> be using local system tools, not part of the command itself.
>>
>> Ideally, "watch" should run "prepare" whenever you would have wanted it to.
>> Though obviously that cannot be perfect, it can be a useful tool when
>> iterating.
>>
>>
>>>
>>> I think it would be best to consider separating development from packaging
>>> in your use-case for workflow.
>>> If I am going to develop featureX as a plugin I would :
>>>
>>> 1. create a project for a single cordova platform, and develop the feature
>>> as a native piece, and a js piece.
>>> 2. test thoroughly
>>> 3. create a project for a second cordova platform, and develop the native
>>> bit, preserving the js from 1
>>> 4. test thoroughly
>>> 5. repeat steps 3+4 for any remaining platforms
>>> 6. package featureX as a plugin by organizing relevant bits in the correct
>>> folder structure, and adding a plugin.xml
>>> 7. test each platform by installing with plugman
>>> 8. publish
>>>
>>
>> As a plugin developer, that is not my workflow.
>>
>> Typically for me its:
>>
>> Write a sample app/manual test for some new feature that isn't implemented
>> yet.
>> Create a new plugin Foo for iOS & Android, and stub the implementation.
>> Implement feature A of plugin Foo for iOS, test, add it for Android, test.
>> Implement feature B of plugin Foo for iOS, test, add it for Android, test.
>> ...
>>
>> Usually the js implementation is shared, the auto tests are shared, and the
>> sample test app is shared.
>>
>> Sure, I do platform specific stuff for testing and implementation, but I
>> certainly wouldn't say I do plugin development in platform isolation.
>>
>> Also, right now we do not have a "plugin create" command, and so leaving
>> the "packaging" step for last doesn't add affect total work.  But once we
>> do have such a command, plugins could start packaged, and adding the small
>> changes to plugin.xml as you need them is likely a good way to go.
>>
>> Finally, this workflow would get people out of the habit of making changes
>> to the platform artifacts directly.  I'm not sure that can be entirely
>> avoided in all cases, but why shouldn't we work towards making that easier?
>>
>>
>>> We seem to have this notion come up repeatedly that our us

Re: mobile-spec and releases: How do we test?

[Brian LeRoux]

I really like your proposal as a starting point. Very simple but would
allow for in-app testing as well as on the cmd line if we so wish.


On Fri, Sep 27, 2013 at 3:28 PM, Michal Mocny  wrote:

> I was looking over some old emails from this list on plugin testing, and an
> idea that was proposed way back was to ship plugin tests as a second
> plugin.  That way, you can chose to install tests, or not, and know
> explicitly if they are being copied into your final project.
>
> An alternative would be to support build targets a la "release/debug" and
> have target-specific plugin.xml tags (assets, js-modules, source-file..).
>
> -Michal
>
>
> On Fri, Sep 27, 2013 at 4:52 AM, Brian LeRoux  wrote:
>
> > I think this is basically what we've been proposing for a while now.
> >
> >
> > On Thu, Sep 26, 2013 at 8:29 PM, Michal Mocny 
> wrote:
> >
> > > I would suggest perhaps a simpler approach, which doesn't add anything
> > new
> > > to cordova-cli/plugman:
> > >
> > > - Each plugin ships with a "tests" js-module, and we document a
> > convention
> > > of where they should live, and what signature it should have (i.e.,
> > > cordova.require('plugin.name.Tests').forEach(...) ).
> > >   - Will need a common way to describe/report results (others have
> > > mentioned TAP).
> > > - Any app is free to run those plugin tests in any which way, but we
> > ship a
> > > mobile-spec app which is one opinionated way to do so.
> > >   - It attempts to require the test module for each installed plugin,
> > runs
> > > them, and aggregates results.
> > >   - It could report results to some shared server, allow toggling of
> > tests,
> > > etc, but no plugin should know or care about those features.
> > >
> > > Using that as a generic base:
> > >
> > > - We ship a "CDVTests" (or whatever) plugin which has a bunch of
> library
> > > code for creating tests, and plugins can use it to register their
> tests.
> > > - This makes it easier to register manual tests in a common format for
> > core
> > > plugins, and prevents code duplication for core auto tests.
> > > - External plugins can chose to use our testing library, or not.
> > >
> > > -Michal
> > >
> > >
> > > On Thu, Sep 26, 2013 at 10:34 AM, Braden Shepherdson <
> > bra...@chromium.org
> > > >wrote:
> > >
> > > > Here's an off-the-top-of-my-head sketch of how we might do Voltron
> > tests:
> > > >
> > > > - Add a tag to plugin.xml that names each test file:
> > > > 
> > > > 
> > > > - Add a new command, cordova test (maybe prepare-test), that:
> > > > - Ignores the top-level www.
> > > > - Instead copies in a basic testing index.html similar to the
> > current
> > > > mobile-spec's
> > > > - That index reads a file akin to cordova_plugins.js
> > > (cordova_tests.js,
> > > > maybe?) generated by the CLI, containing the info from the 
> tags.
> > > > - It has navigation similar to the current mobile-spec, with
> > buttons
> > > > for the automatic and manual sections. Auto has "All" and then each
> > > module,
> > > > manual just has the list of modules.
> > > >
> > > > Thoughts?
> > > >
> > > > Braden
> > > >
> > > >
> > > > On Thu, Sep 26, 2013 at 6:33 AM, Carlos Santana <
> csantan...@gmail.com
> > > > >wrote:
> > > >
> > > > > I like the idea can we call mobilespec now cordova-voltron and be
> DRY
> > > and
> > > > > use the tests form the plugins.
> > > > >
> > > > > Voltron by itself creates an App that tests only core, but as you
> > > > > use plugman to add plugins to voltron it has more test cases.
> > > > >
> > > > > It would not be a bad idea to enhance plugin.xml in the future to
> > > include
> > > > > information about testing (i.e. Directory containing tests files,
> > test
> > > > > command, etc..)
> > > > >
> > > > > --Carlos
> > > > >
> > > > > On Thursday, September 26, 2013, Anis KADRI wrote:
> > > > >
> > > > > > What's the challenge of having us use the tests that come with
> the
> > > > > > individual plugins ?
> > > > > >
> > > > > > On Thu, Sep 26, 2013 at 8:13 AM, David Kemp  > > > > >
> > > > > > wrote:
> > > > > > > Currently, the automated test system that we have running
> > (derived
> > > > from
> > > > > > > Medic) uses only the mobilespec tests. It does not yet use
> tests
> > > > > > collected
> > > > > > > from the plugins. Its been talked about, but not gone anywhere.
> > > > > > >
> > > > > > > David Kemp
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Sep 25, 2013 at 7:58 PM, Jesse <
> purplecabb...@gmail.com
> > > > > >
> > > > > > wrote:
> > > > > > >
> > > > > > >> Yeah, I have pushed some changes to mobile-spec, and when I
> did
> > I
> > > > also
> > > > > > >> copied the tests into the plugin involved.
> > > > > > >> Until we get the magic test runner happening, I think we just
> > keep
> > > > > > >> duplicating.
> > > > > > >>
> > > > > > >> @purplecabbage
> > > > > > >> risingj.com
> > > > > > >>
> > > > > > >>
> > > > > > >> On Wed, Sep 25, 2013 at 4:38 PM, Steven Gill <
> > > > stevengil...@gmail.com
> > 

Re: mobile-spec and releases: How do we test?

[Carlos Santana]

Hum I think keeping tests with the plugin is a better approach, keeps code
and test together on a single repo for a plugin.



Maybe plugman should not install the test folder located on the root of the
plugin by default unless an optional flag "--test" is pass

plugman install --test ...
cordova plugin add com.plugin --test

--Carlos



On Fri, Sep 27, 2013 at 9:28 AM, Michal Mocny  wrote:

> I was looking over some old emails from this list on plugin testing, and an
> idea that was proposed way back was to ship plugin tests as a second
> plugin.  That way, you can chose to install tests, or not, and know
> explicitly if they are being copied into your final project.
>
> An alternative would be to support build targets a la "release/debug" and
> have target-specific plugin.xml tags (assets, js-modules, source-file..).
>
> -Michal
>
>
> On Fri, Sep 27, 2013 at 4:52 AM, Brian LeRoux  wrote:
>
> > I think this is basically what we've been proposing for a while now.
> >
> >
> > On Thu, Sep 26, 2013 at 8:29 PM, Michal Mocny 
> wrote:
> >
> > > I would suggest perhaps a simpler approach, which doesn't add anything
> > new
> > > to cordova-cli/plugman:
> > >
> > > - Each plugin ships with a "tests" js-module, and we document a
> > convention
> > > of where they should live, and what signature it should have (i.e.,
> > > cordova.require('plugin.name.Tests').forEach(...) ).
> > >   - Will need a common way to describe/report results (others have
> > > mentioned TAP).
> > > - Any app is free to run those plugin tests in any which way, but we
> > ship a
> > > mobile-spec app which is one opinionated way to do so.
> > >   - It attempts to require the test module for each installed plugin,
> > runs
> > > them, and aggregates results.
> > >   - It could report results to some shared server, allow toggling of
> > tests,
> > > etc, but no plugin should know or care about those features.
> > >
> > > Using that as a generic base:
> > >
> > > - We ship a "CDVTests" (or whatever) plugin which has a bunch of
> library
> > > code for creating tests, and plugins can use it to register their
> tests.
> > > - This makes it easier to register manual tests in a common format for
> > core
> > > plugins, and prevents code duplication for core auto tests.
> > > - External plugins can chose to use our testing library, or not.
> > >
> > > -Michal
> > >
> > >
> > > On Thu, Sep 26, 2013 at 10:34 AM, Braden Shepherdson <
> > bra...@chromium.org
> > > >wrote:
> > >
> > > > Here's an off-the-top-of-my-head sketch of how we might do Voltron
> > tests:
> > > >
> > > > - Add a tag to plugin.xml that names each test file:
> > > > 
> > > > 
> > > > - Add a new command, cordova test (maybe prepare-test), that:
> > > > - Ignores the top-level www.
> > > > - Instead copies in a basic testing index.html similar to the
> > current
> > > > mobile-spec's
> > > > - That index reads a file akin to cordova_plugins.js
> > > (cordova_tests.js,
> > > > maybe?) generated by the CLI, containing the info from the 
> tags.
> > > > - It has navigation similar to the current mobile-spec, with
> > buttons
> > > > for the automatic and manual sections. Auto has "All" and then each
> > > module,
> > > > manual just has the list of modules.
> > > >
> > > > Thoughts?
> > > >
> > > > Braden
> > > >
> > > >
> > > > On Thu, Sep 26, 2013 at 6:33 AM, Carlos Santana <
> csantan...@gmail.com
> > > > >wrote:
> > > >
> > > > > I like the idea can we call mobilespec now cordova-voltron and be
> DRY
> > > and
> > > > > use the tests form the plugins.
> > > > >
> > > > > Voltron by itself creates an App that tests only core, but as you
> > > > > use plugman to add plugins to voltron it has more test cases.
> > > > >
> > > > > It would not be a bad idea to enhance plugin.xml in the future to
> > > include
> > > > > information about testing (i.e. Directory containing tests files,
> > test
> > > > > command, etc..)
> > > > >
> > > > > --Carlos
> > > > >
> > > > > On Thursday, September 26, 2013, Anis KADRI wrote:
> > > > >
> > > > > > What's the challenge of having us use the tests that come with
> the
> > > > > > individual plugins ?
> > > > > >
> > > > > > On Thu, Sep 26, 2013 at 8:13 AM, David Kemp  > > > > >
> > > > > > wrote:
> > > > > > > Currently, the automated test system that we have running
> > (derived
> > > > from
> > > > > > > Medic) uses only the mobilespec tests. It does not yet use
> tests
> > > > > > collected
> > > > > > > from the plugins. Its been talked about, but not gone anywhere.
> > > > > > >
> > > > > > > David Kemp
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Sep 25, 2013 at 7:58 PM, Jesse <
> purplecabb...@gmail.com
> > > > > >
> > > > > > wrote:
> > > > > > >
> > > > > > >> Yeah, I have pushed some changes to mobile-spec, and when I
> did
> > I
> > > > also
> > > > > > >> copied the tests into the plugin involved.
> > > > > > >> Until we get the magic test runner happening, I think we just
> > keep
> > > > > > >> duplicating.

Re: 2.9.0 Support

[Carlos Santana]

What is the support statement for 2.9.x  for new OSs?

For example:
iOS7 not supported on 2.9.x
xCode 5 not supported on 2.9.x

2.9.x + bugs only supports:
iOS 5 and 6
Xcode 4.6.3





On Fri, Sep 27, 2013 at 5:19 AM, Brian LeRoux  wrote:

> It ends in 3.6 (I would think) as per our 6 month deprec policy.
>
>
> On Fri, Sep 27, 2013 at 11:04 AM, Shazron  wrote:
>
> > This is relevant, for example, with the iOS 7 fixes for media,
> > media-capture, and splashscreen core plugins -- should we backport the
> > code. They haven't diverged too much - but where does it end for support?
> > +1 on defects only (although one can argue these are defects as well)
> >
> >
> > On Thu, Sep 26, 2013 at 7:22 PM, Brian LeRoux  wrote:
> >
> > > You can help!
> > > On Sep 27, 2013 2:37 AM, "Smith, Peter" 
> > > wrote:
> > >
> > > > Back when we adopted 2.9.0 we were a bit apprehensive about early
> > > > adoption of 3.x, so were quite encouraged to read:
> > > >
> > > > "We understand and respect that there is a huge community of projects
> > > > built on PhoneGap 2.0 series and we will continue to support 2.x in a
> > > > long lived branch."
> > > > http://phonegap.com/blog/2013/06/20/coming-soon-phonegap30/
> > > >
> > > > At the time it seemed quite clear there would be a 2.9.1, but now it
> is
> > > > not clear at all...
> > > >
> > > > Peter
> > > >
> > > > -Original Message-
> > > > From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of
> Michal
> > > > Mocny
> > > > Sent: Friday, 27 September 2013 5:24 AM
> > > > To: dev; bows...@apache.org
> > > > Subject: Re: 2.9.0 Support
> > > >
> > > > Sounds less than ideal to have to backport, given that we still
> support
> > > > the old workflow with 3.0.
> > > >
> > > > However, I think we did discuss keeping 2.9 maintained while we iron
> > out
> > > > 3.0 issues.  I think we should drop 2.9 as soon as users run out of
> > > > *valid* reasons for not upgrading to 3.0, right?
> > > >
> > > > What do users say when you suggest moving to 3.x to get the bugfix?
> > > >
> > > > -Michal
> > > >
> > > >
> > > > On Thu, Sep 26, 2013 at 3:09 PM, Joe Bowser 
> wrote:
> > > >
> > > > > Hey
> > > > >
> > > > > What did we agree to for supporting the old 2.9.x branch? I'm just
> > > > > wondering, since we're still getting tons of bugs filed against
> that.
> > > > > While most of them are valid in 3.0.x, we probably should be
> > > > > backporting to 2.9.
> > > > >
> > > > > Have people been doing this.  I've been doing this a bit, but I
> have
> > > > > to admit that I've been slipping up recently.  What are people's
> > > > > thoughts on this?
> > > > >
> > > > > Joe
> > > > >
> > > >
> > > >
> > >
> >
>



-- 
Carlos Santana

Re: Issue with FileTransfer plugin identifier [PR]

[Michael Gauthier]

Steve,

That's wonderful news. Can you mark CB-4902 as a dupe of CB-4889? I have 
closed the pull requests.


Cheers,
Mike

On 2013-09-26 19:10, Steven Gill wrote:

Hey Michael,

I am not sure how that code got on master, but it shouldn't have been.

We have already taken care of this problem on the dev branch and I am in
the process of merging it today. Issue is at
https://issues.apache.org/jira/browse/CB-4889

Thanks for taking the time and sending pull requests.

The pull requests can be closed.

Cheers,
-Steve


On Thu, Sep 26, 2013 at 2:47 PM, Michael Gauthier wrote:


Michal,

Awesome. I've sent in a signed copy of the CLA.

Cheers,
Mike


On 2013-09-26 18:02, Michal Mocny wrote:


Wow, this sounds like the problem I just ran into yesterday, so thanks for
fixing it.  I'm heading out for today so cannot review&pull your patches,
but to get the ball rolling for tomorrow, make sure you have signed the
ICLA 
(http://www.apache.org/**licenses/#clas)
since It looks like you have
not.

Thanks!
-Michal


On Thu, Sep 26, 2013 at 4:51 PM, Michael Gauthier 
wrote:


  Hi,


I opened this issue a couple of days ago:
https://issues.apache.org/jira/browse/CB-4902





The issue was the plugin identifiers were changed and the code wasn't
updated with the new identifiers. I opened two pull requests to fix the
issue but I can't figure out how to add them the to the Jira Issue.

Can someone take a look and approve/reject them?

https://github.com/apache/cordova-plugin-file/pull/6
https://github.com/apache/cordova-plugin-file/pull/6>



https://github.com/apache/cordova-plugin-file-transfer/pull/7






Thanks,
Mike

Re: mobile-spec and releases: How do we test?

[Michal Mocny]

I was looking over some old emails from this list on plugin testing, and an
idea that was proposed way back was to ship plugin tests as a second
plugin.  That way, you can chose to install tests, or not, and know
explicitly if they are being copied into your final project.

An alternative would be to support build targets a la "release/debug" and
have target-specific plugin.xml tags (assets, js-modules, source-file..).

-Michal


On Fri, Sep 27, 2013 at 4:52 AM, Brian LeRoux  wrote:

> I think this is basically what we've been proposing for a while now.
>
>
> On Thu, Sep 26, 2013 at 8:29 PM, Michal Mocny  wrote:
>
> > I would suggest perhaps a simpler approach, which doesn't add anything
> new
> > to cordova-cli/plugman:
> >
> > - Each plugin ships with a "tests" js-module, and we document a
> convention
> > of where they should live, and what signature it should have (i.e.,
> > cordova.require('plugin.name.Tests').forEach(...) ).
> >   - Will need a common way to describe/report results (others have
> > mentioned TAP).
> > - Any app is free to run those plugin tests in any which way, but we
> ship a
> > mobile-spec app which is one opinionated way to do so.
> >   - It attempts to require the test module for each installed plugin,
> runs
> > them, and aggregates results.
> >   - It could report results to some shared server, allow toggling of
> tests,
> > etc, but no plugin should know or care about those features.
> >
> > Using that as a generic base:
> >
> > - We ship a "CDVTests" (or whatever) plugin which has a bunch of library
> > code for creating tests, and plugins can use it to register their tests.
> > - This makes it easier to register manual tests in a common format for
> core
> > plugins, and prevents code duplication for core auto tests.
> > - External plugins can chose to use our testing library, or not.
> >
> > -Michal
> >
> >
> > On Thu, Sep 26, 2013 at 10:34 AM, Braden Shepherdson <
> bra...@chromium.org
> > >wrote:
> >
> > > Here's an off-the-top-of-my-head sketch of how we might do Voltron
> tests:
> > >
> > > - Add a tag to plugin.xml that names each test file:
> > > 
> > > 
> > > - Add a new command, cordova test (maybe prepare-test), that:
> > > - Ignores the top-level www.
> > > - Instead copies in a basic testing index.html similar to the
> current
> > > mobile-spec's
> > > - That index reads a file akin to cordova_plugins.js
> > (cordova_tests.js,
> > > maybe?) generated by the CLI, containing the info from the  tags.
> > > - It has navigation similar to the current mobile-spec, with
> buttons
> > > for the automatic and manual sections. Auto has "All" and then each
> > module,
> > > manual just has the list of modules.
> > >
> > > Thoughts?
> > >
> > > Braden
> > >
> > >
> > > On Thu, Sep 26, 2013 at 6:33 AM, Carlos Santana  > > >wrote:
> > >
> > > > I like the idea can we call mobilespec now cordova-voltron and be DRY
> > and
> > > > use the tests form the plugins.
> > > >
> > > > Voltron by itself creates an App that tests only core, but as you
> > > > use plugman to add plugins to voltron it has more test cases.
> > > >
> > > > It would not be a bad idea to enhance plugin.xml in the future to
> > include
> > > > information about testing (i.e. Directory containing tests files,
> test
> > > > command, etc..)
> > > >
> > > > --Carlos
> > > >
> > > > On Thursday, September 26, 2013, Anis KADRI wrote:
> > > >
> > > > > What's the challenge of having us use the tests that come with the
> > > > > individual plugins ?
> > > > >
> > > > > On Thu, Sep 26, 2013 at 8:13 AM, David Kemp  > > > >
> > > > > wrote:
> > > > > > Currently, the automated test system that we have running
> (derived
> > > from
> > > > > > Medic) uses only the mobilespec tests. It does not yet use tests
> > > > > collected
> > > > > > from the plugins. Its been talked about, but not gone anywhere.
> > > > > >
> > > > > > David Kemp
> > > > > >
> > > > > >
> > > > > > On Wed, Sep 25, 2013 at 7:58 PM, Jesse  > > > >
> > > > > wrote:
> > > > > >
> > > > > >> Yeah, I have pushed some changes to mobile-spec, and when I did
> I
> > > also
> > > > > >> copied the tests into the plugin involved.
> > > > > >> Until we get the magic test runner happening, I think we just
> keep
> > > > > >> duplicating.
> > > > > >>
> > > > > >> @purplecabbage
> > > > > >> risingj.com
> > > > > >>
> > > > > >>
> > > > > >> On Wed, Sep 25, 2013 at 4:38 PM, Steven Gill <
> > > stevengil...@gmail.com
> > > > 
> > > > > >
> > > > > >> wrote:
> > > > > >>
> > > > > >> > We copied over tests into plugins when we first broke them
> out,
> > > but
> > > > I
> > > > > >> don't
> > > > > >> > believe they have been updated.
> > > > > >> >
> > > > > >> > I would say for now to just add the tests to mobile spec, and
> > > > > possibly in
> > > > > >> > the future we go all voltron to build mobile spec and keep
> tests
> > > > with
> > > > > >> their
> > > > > >> > corresponding plugins.
> > > > > >> >
> > > > > >> >
> > > > > >> >

Re: 2.9.0 Support

[Brian LeRoux]

It ends in 3.6 (I would think) as per our 6 month deprec policy.


On Fri, Sep 27, 2013 at 11:04 AM, Shazron  wrote:

> This is relevant, for example, with the iOS 7 fixes for media,
> media-capture, and splashscreen core plugins -- should we backport the
> code. They haven't diverged too much - but where does it end for support?
> +1 on defects only (although one can argue these are defects as well)
>
>
> On Thu, Sep 26, 2013 at 7:22 PM, Brian LeRoux  wrote:
>
> > You can help!
> > On Sep 27, 2013 2:37 AM, "Smith, Peter" 
> > wrote:
> >
> > > Back when we adopted 2.9.0 we were a bit apprehensive about early
> > > adoption of 3.x, so were quite encouraged to read:
> > >
> > > "We understand and respect that there is a huge community of projects
> > > built on PhoneGap 2.0 series and we will continue to support 2.x in a
> > > long lived branch."
> > > http://phonegap.com/blog/2013/06/20/coming-soon-phonegap30/
> > >
> > > At the time it seemed quite clear there would be a 2.9.1, but now it is
> > > not clear at all...
> > >
> > > Peter
> > >
> > > -Original Message-
> > > From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal
> > > Mocny
> > > Sent: Friday, 27 September 2013 5:24 AM
> > > To: dev; bows...@apache.org
> > > Subject: Re: 2.9.0 Support
> > >
> > > Sounds less than ideal to have to backport, given that we still support
> > > the old workflow with 3.0.
> > >
> > > However, I think we did discuss keeping 2.9 maintained while we iron
> out
> > > 3.0 issues.  I think we should drop 2.9 as soon as users run out of
> > > *valid* reasons for not upgrading to 3.0, right?
> > >
> > > What do users say when you suggest moving to 3.x to get the bugfix?
> > >
> > > -Michal
> > >
> > >
> > > On Thu, Sep 26, 2013 at 3:09 PM, Joe Bowser  wrote:
> > >
> > > > Hey
> > > >
> > > > What did we agree to for supporting the old 2.9.x branch? I'm just
> > > > wondering, since we're still getting tons of bugs filed against that.
> > > > While most of them are valid in 3.0.x, we probably should be
> > > > backporting to 2.9.
> > > >
> > > > Have people been doing this.  I've been doing this a bit, but I have
> > > > to admit that I've been slipping up recently.  What are people's
> > > > thoughts on this?
> > > >
> > > > Joe
> > > >
> > >
> > >
> >
>

Is iOS 7 required for submission of an app to the Apple App Store?

[Shazron]

Currently, no.

See this page, section "Test for Compatibility":
https://developer.apple.com/ios7/

"New apps and app updates submitted to the App Store should support iOS 7
and be optimized for iOS devices with Retina display. iPhone apps must also
support the 4-inch display on iPhone 5, iPhone 5s, and iPhone 5c."

The operative word is "should", and as Build has encountered already, they
are still accepting iOS 6 built apps. Most likely the added time is for
developer testing with the new devices. The operative word is "should", it
 used to say "must": https://devforums.apple.com/message/884949#884949

My guess for iOS 7 being required is when they support compiling a fat
binary of 32-bit for iOS 6 and 32 and 64-bit for iOS 7:
https://developer.apple.com/news/index.php?id=9162013a

The ETA for that is "next month" (end of it, most like), when OS X
Mavericks is released (note that Xcode 5.0 GM does not include Mavericks
support) and the new iPads come out.
There are no plans IMO for Cordova to care about 64-bit support until this
fat binary format is supported. At this point, I'm not sure if there are
any performance gains, there is no data for this until we can run
benchmarks on 64-bit devices like the iPhone 5s and the new (future) iPads.


=

LIMITATIONS ON iOS 6 BUILT APPS RUNNING ON iOS 7 DEVICES

=

Microphone access requires user permission now on iOS 7. When an iOS 6
built binary runs on iOS 7, any microphone access is by default *allowed*
but the resulting audio file will be *silent*. The media and media-capture
core plugins can use the microphone - and iOS 7 support for the microphone
have just been tagged in the repos (thanks Steve Gill):

https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-media.git;a=summary

See tag r0.2.3

https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-media-capture.git;a=summary

See tag r0.2.2

The same goes for the splash screen plugin, it has a change for iOS 7
support:

https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-splashscreen.git;a=summary

See tag r0.2.2

These changes are in their master branches as well, and have been pushed to
http://plugins.cordova.io

If CLI and plugman users re-get the plugins (by id), the latest code should
be downloaded.

Re: 2.9.0 Support

[Shazron]

This is relevant, for example, with the iOS 7 fixes for media,
media-capture, and splashscreen core plugins -- should we backport the
code. They haven't diverged too much - but where does it end for support?
+1 on defects only (although one can argue these are defects as well)


On Thu, Sep 26, 2013 at 7:22 PM, Brian LeRoux  wrote:

> You can help!
> On Sep 27, 2013 2:37 AM, "Smith, Peter" 
> wrote:
>
> > Back when we adopted 2.9.0 we were a bit apprehensive about early
> > adoption of 3.x, so were quite encouraged to read:
> >
> > "We understand and respect that there is a huge community of projects
> > built on PhoneGap 2.0 series and we will continue to support 2.x in a
> > long lived branch."
> > http://phonegap.com/blog/2013/06/20/coming-soon-phonegap30/
> >
> > At the time it seemed quite clear there would be a 2.9.1, but now it is
> > not clear at all...
> >
> > Peter
> >
> > -Original Message-
> > From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal
> > Mocny
> > Sent: Friday, 27 September 2013 5:24 AM
> > To: dev; bows...@apache.org
> > Subject: Re: 2.9.0 Support
> >
> > Sounds less than ideal to have to backport, given that we still support
> > the old workflow with 3.0.
> >
> > However, I think we did discuss keeping 2.9 maintained while we iron out
> > 3.0 issues.  I think we should drop 2.9 as soon as users run out of
> > *valid* reasons for not upgrading to 3.0, right?
> >
> > What do users say when you suggest moving to 3.x to get the bugfix?
> >
> > -Michal
> >
> >
> > On Thu, Sep 26, 2013 at 3:09 PM, Joe Bowser  wrote:
> >
> > > Hey
> > >
> > > What did we agree to for supporting the old 2.9.x branch? I'm just
> > > wondering, since we're still getting tons of bugs filed against that.
> > > While most of them are valid in 3.0.x, we probably should be
> > > backporting to 2.9.
> > >
> > > Have people been doing this.  I've been doing this a bit, but I have
> > > to admit that I've been slipping up recently.  What are people's
> > > thoughts on this?
> > >
> > > Joe
> > >
> >
> >
>

Re: mobile-spec and releases: How do we test?

[Brian LeRoux]

I think this is basically what we've been proposing for a while now.


On Thu, Sep 26, 2013 at 8:29 PM, Michal Mocny  wrote:

> I would suggest perhaps a simpler approach, which doesn't add anything new
> to cordova-cli/plugman:
>
> - Each plugin ships with a "tests" js-module, and we document a convention
> of where they should live, and what signature it should have (i.e.,
> cordova.require('plugin.name.Tests').forEach(...) ).
>   - Will need a common way to describe/report results (others have
> mentioned TAP).
> - Any app is free to run those plugin tests in any which way, but we ship a
> mobile-spec app which is one opinionated way to do so.
>   - It attempts to require the test module for each installed plugin, runs
> them, and aggregates results.
>   - It could report results to some shared server, allow toggling of tests,
> etc, but no plugin should know or care about those features.
>
> Using that as a generic base:
>
> - We ship a "CDVTests" (or whatever) plugin which has a bunch of library
> code for creating tests, and plugins can use it to register their tests.
> - This makes it easier to register manual tests in a common format for core
> plugins, and prevents code duplication for core auto tests.
> - External plugins can chose to use our testing library, or not.
>
> -Michal
>
>
> On Thu, Sep 26, 2013 at 10:34 AM, Braden Shepherdson  >wrote:
>
> > Here's an off-the-top-of-my-head sketch of how we might do Voltron tests:
> >
> > - Add a tag to plugin.xml that names each test file:
> > 
> > 
> > - Add a new command, cordova test (maybe prepare-test), that:
> > - Ignores the top-level www.
> > - Instead copies in a basic testing index.html similar to the current
> > mobile-spec's
> > - That index reads a file akin to cordova_plugins.js
> (cordova_tests.js,
> > maybe?) generated by the CLI, containing the info from the  tags.
> > - It has navigation similar to the current mobile-spec, with buttons
> > for the automatic and manual sections. Auto has "All" and then each
> module,
> > manual just has the list of modules.
> >
> > Thoughts?
> >
> > Braden
> >
> >
> > On Thu, Sep 26, 2013 at 6:33 AM, Carlos Santana  > >wrote:
> >
> > > I like the idea can we call mobilespec now cordova-voltron and be DRY
> and
> > > use the tests form the plugins.
> > >
> > > Voltron by itself creates an App that tests only core, but as you
> > > use plugman to add plugins to voltron it has more test cases.
> > >
> > > It would not be a bad idea to enhance plugin.xml in the future to
> include
> > > information about testing (i.e. Directory containing tests files, test
> > > command, etc..)
> > >
> > > --Carlos
> > >
> > > On Thursday, September 26, 2013, Anis KADRI wrote:
> > >
> > > > What's the challenge of having us use the tests that come with the
> > > > individual plugins ?
> > > >
> > > > On Thu, Sep 26, 2013 at 8:13 AM, David Kemp  > > >
> > > > wrote:
> > > > > Currently, the automated test system that we have running (derived
> > from
> > > > > Medic) uses only the mobilespec tests. It does not yet use tests
> > > > collected
> > > > > from the plugins. Its been talked about, but not gone anywhere.
> > > > >
> > > > > David Kemp
> > > > >
> > > > >
> > > > > On Wed, Sep 25, 2013 at 7:58 PM, Jesse  > > >
> > > > wrote:
> > > > >
> > > > >> Yeah, I have pushed some changes to mobile-spec, and when I did I
> > also
> > > > >> copied the tests into the plugin involved.
> > > > >> Until we get the magic test runner happening, I think we just keep
> > > > >> duplicating.
> > > > >>
> > > > >> @purplecabbage
> > > > >> risingj.com
> > > > >>
> > > > >>
> > > > >> On Wed, Sep 25, 2013 at 4:38 PM, Steven Gill <
> > stevengil...@gmail.com
> > > 
> > > > >
> > > > >> wrote:
> > > > >>
> > > > >> > We copied over tests into plugins when we first broke them out,
> > but
> > > I
> > > > >> don't
> > > > >> > believe they have been updated.
> > > > >> >
> > > > >> > I would say for now to just add the tests to mobile spec, and
> > > > possibly in
> > > > >> > the future we go all voltron to build mobile spec and keep tests
> > > with
> > > > >> their
> > > > >> > corresponding plugins.
> > > > >> >
> > > > >> >
> > > > >> > On Wed, Sep 25, 2013 at 4:22 PM, Joe Bowser  > > >
> > > > wrote:
> > > > >> >
> > > > >> > > Hey
> > > > >> > >
> > > > >> > > Right now, I'm working on a weird file issue that requires me
> to
> > > > >> > > update mobile-spec, but I'm wondering where the tests should
> > live.
> > > > >> > > Should it all keep living in mobile-spec, or is it with the
> > > plugins.
> > > > >> > > And if it's with the plugins, will there be scripts to
> assemble
> > > > >> > > mobile-spec all Voltron style?
> > > > >> > >
> > > > >> > > This came up earlier, but I haven't found any fix that needed
> a
> > > > >> > > mobile-spec test.  (Many that need native testing, like
> > recursive
> > > > file
> > > > >> > > copy, etc).  Any thoughts?
> > > > >> > >
> > > > >> > > Joe
> > > > >> > >
> > > >

Re: Updating plugin code on prepare

[Brian LeRoux]

I'd like to point out we're talking about the future and not the present
too. Yes, its a pain to dev a plugin without an IDE today. That isn't a
reason to sit on our hands. Iain has the right of it: our job is to
implement the future not lament the present.

The future is most certainly not waiting for Eclipse to load or Xcode to
beachball. Our dev community by and large uses lightweight text editors and
the command line. A simple watch command (or link function) would go a long
way to help that workflow AND it could be consumed by the IDEs too.



On Fri, Sep 27, 2013 at 4:31 AM, Ian Clelland wrote:

> On Fri, Sep 27, 2013 at 12:11 AM, Anis KADRI  wrote:
>
> > As far as IDEs, the answer is simple. You should not use IDEs and
> > cordova-cli at the same time. Until IDEs are aware of cordova-cli
> > there is no point in creating projects with cordova-cli because
> > everything gets blown on every build. I am not even sure we can make
> > Xcode aware of cordova-cli. We've already talked about this prior to
> > the 3.0 release and that is why we have the create scripts and plugman
> > approach. You should not be using cordova-cli either if you're doing
> > some custom native dev that can't be pluginized (changing the main
> > Activity.java or AppDelegate.m or whatever). If you're using
> > cordova-cli just to create a project and then open an IDE to develop,
> > you're probably doing it wrong. You should be creating a native
> > project and using plugman instead.
> >
> >
> Oh, man, I'm definitely doing it wrong :)
>
> I'm almost always using the CLI to create projects, and then opening the
> platform projects in Eclipse or XCode to run them. When I update code, I
> run prepare, and refresh in the IDE before running again. (In XCode, I
> generally don't even need to refresh; it just knows when the files have
> changed.)
>
> I don't mind using the IDE for debugging if (when) things don't work -- but
> I know that all of the assets are ephemeral, and that I need to make the
> *real* fixes outside of the platforms directory.
>
> I hope that eventually we can have 'cordova prepare' just be part of the
> build step in the IDEs, and let people just edit the master files in www/
> and build from there with the IDE, but I think we're a long way from there.
> Until then, the IDE is occasionally critical for debugging, even on a CLI
> project (wrong as it is ;) )
>
> Ian
>

Re: About plugins in 3.1

[Anis KADRI]

Plugins have been published! Time to test!

On Fri, Sep 27, 2013 at 9:18 AM, Anis KADRI  wrote:
> I will publish them from master. There is an issue with permissions
> right now :-/
>
> On Fri, Sep 27, 2013 at 5:03 AM, Steven Gill  wrote:
>> Plugins are ready to be published. I did plugman adduser. Can't publish
>> plugins yet. Guessing Anis has to give me permission.
>>
>>
>> On Tue, Sep 17, 2013 at 6:10 PM, Andrew Grieve  wrote:
>>
>>> The ability to clone from a branch/tag already exists. It didn't for 3.0,
>>> but was added afterwards.
>>>
>>> I don't think there's much use in changing instructions to install from
>>> git+tag urls when the registry exists anyways. The registry has
>>> 3.0-compatible plugins in it, so that's a better solution.
>>>
>>> I do think we should wait some time before making the switch to developing
>>> on master (and deleting the dev branches), since it'll take some time to
>>> get the word out. There's even been some tools (yeoman & the like) that
>>> have been written that hardcode in the git URLs.
>>>
>>> Definitely excited about this though! So much nicer!
>>>
>>>
>>> On Tue, Sep 17, 2013 at 5:20 PM, Anis KADRI  wrote:
>>>
>>> > @maxw: done!
>>> >
>>> > On Tue, Sep 17, 2013 at 1:55 PM, Shazron  wrote:
>>> > > @Anis yeah this could be a documentation issue. We will have to update
>>> > the
>>> > > 3.0.0 specific docs.
>>> > >
>>> > >
>>> > > On Tue, Sep 17, 2013 at 1:35 PM, Anis KADRI 
>>> > wrote:
>>> > >
>>> > >> @maxw Did you create a user account with plugman adduser ? I do not
>>> > >> see you in the users' list.
>>> > >>
>>> > >> Shazron: Very good point. We can always instruct those users to clone
>>> > >> a 3.0.0 compatible branch from the repositories and install that.
>>> > >> Maybe we can even update the tools to add the ability to clone from
>>> > >> any branch (or maybe it's in there already ? I know it's in there for
>>> > >> dependencies).
>>> > >>
>>> > >> On Tue, Sep 17, 2013 at 1:30 PM, Shazron  wrote:
>>> > >> > I'm all for using master as the branch that we do development on,
>>> but
>>> > if
>>> > >> we
>>> > >> > switch, that will mean anyone on existing cordova v3.0.0 will get
>>> > broken
>>> > >> > plugins, correct?
>>> > >> >
>>> > >> >
>>> > >> > On Tue, Sep 17, 2013 at 1:25 PM, Steven Gill <
>>> stevengil...@gmail.com>
>>> > >> wrote:
>>> > >> >
>>> > >> >> What would the command look like to install it if we aren't using
>>> git
>>> > >> urls?
>>> > >> >> cordova plugin add camera? Would it automatically take the latest
>>> > >> version
>>> > >> >> off the registery?
>>> > >> >>
>>> > >> >> I like the idea of working on master and tagging a plugin when it
>>> is
>>> > >> ready
>>> > >> >> to be published.
>>> > >> >>
>>> > >> >>
>>> > >> >>
>>> > >> >>
>>> > >> >> On Tue, Sep 17, 2013 at 1:21 PM, Anis KADRI 
>>> > >> wrote:
>>> > >> >>
>>> > >> >> > As far as I understand and following this documentation:
>>> > >> >> >
>>> > >> >> >
>>> > >> >> >
>>> > >> >>
>>> > >>
>>> >
>>> http://cordova.apache.org/docs/en/3.0.0/guide_cli_index.md.html#The%20Command-line%20Interface
>>> > >> >> >
>>> > >> >> > Plugins are currently fetched using git from origin/master. It
>>> is a
>>> > >> >> > major problem in my opinion. The main reason (but there are many)
>>> > is
>>> > >> >> > that any commit to master can potentially break plugins. Yes, we
>>> > can
>>> > >> >> > do a dev branch but some people are forgetful and might commit to
>>> > >> >> > master anyway. I think the proper development process for plugins
>>> > >> >> > should be:
>>> > >> >> > - Always commit to master
>>> > >> >> > - When you're ready to release a plugin: update the version, tag
>>> it
>>> > >> >> > and publish it to the cordova registry.
>>> > >> >> > - Users can then install the latest version without having to
>>> > remember
>>> > >> >> > a git URL and without worrying about getting a broken plugin.
>>> > >> >> >
>>> > >> >> > Ideally, every Cordova committer should be granted the right to
>>> > >> >> > publish to the registry. Right now, I've only added Andrew Grieve
>>> > (who
>>> > >> >> > is having issues publishing atm...). If anybody wants to be
>>> added,
>>> > let
>>> > >> >> > me know.
>>> > >> >> >
>>> > >> >> > Does that sound good to everyone?
>>> > >> >> >
>>> > >> >> > -a
>>> > >> >> >
>>> > >> >>
>>> > >>
>>> >
>>>

Re: About plugins in 3.1

[Anis KADRI]

I will publish them from master. There is an issue with permissions
right now :-/

On Fri, Sep 27, 2013 at 5:03 AM, Steven Gill  wrote:
> Plugins are ready to be published. I did plugman adduser. Can't publish
> plugins yet. Guessing Anis has to give me permission.
>
>
> On Tue, Sep 17, 2013 at 6:10 PM, Andrew Grieve  wrote:
>
>> The ability to clone from a branch/tag already exists. It didn't for 3.0,
>> but was added afterwards.
>>
>> I don't think there's much use in changing instructions to install from
>> git+tag urls when the registry exists anyways. The registry has
>> 3.0-compatible plugins in it, so that's a better solution.
>>
>> I do think we should wait some time before making the switch to developing
>> on master (and deleting the dev branches), since it'll take some time to
>> get the word out. There's even been some tools (yeoman & the like) that
>> have been written that hardcode in the git URLs.
>>
>> Definitely excited about this though! So much nicer!
>>
>>
>> On Tue, Sep 17, 2013 at 5:20 PM, Anis KADRI  wrote:
>>
>> > @maxw: done!
>> >
>> > On Tue, Sep 17, 2013 at 1:55 PM, Shazron  wrote:
>> > > @Anis yeah this could be a documentation issue. We will have to update
>> > the
>> > > 3.0.0 specific docs.
>> > >
>> > >
>> > > On Tue, Sep 17, 2013 at 1:35 PM, Anis KADRI 
>> > wrote:
>> > >
>> > >> @maxw Did you create a user account with plugman adduser ? I do not
>> > >> see you in the users' list.
>> > >>
>> > >> Shazron: Very good point. We can always instruct those users to clone
>> > >> a 3.0.0 compatible branch from the repositories and install that.
>> > >> Maybe we can even update the tools to add the ability to clone from
>> > >> any branch (or maybe it's in there already ? I know it's in there for
>> > >> dependencies).
>> > >>
>> > >> On Tue, Sep 17, 2013 at 1:30 PM, Shazron  wrote:
>> > >> > I'm all for using master as the branch that we do development on,
>> but
>> > if
>> > >> we
>> > >> > switch, that will mean anyone on existing cordova v3.0.0 will get
>> > broken
>> > >> > plugins, correct?
>> > >> >
>> > >> >
>> > >> > On Tue, Sep 17, 2013 at 1:25 PM, Steven Gill <
>> stevengil...@gmail.com>
>> > >> wrote:
>> > >> >
>> > >> >> What would the command look like to install it if we aren't using
>> git
>> > >> urls?
>> > >> >> cordova plugin add camera? Would it automatically take the latest
>> > >> version
>> > >> >> off the registery?
>> > >> >>
>> > >> >> I like the idea of working on master and tagging a plugin when it
>> is
>> > >> ready
>> > >> >> to be published.
>> > >> >>
>> > >> >>
>> > >> >>
>> > >> >>
>> > >> >> On Tue, Sep 17, 2013 at 1:21 PM, Anis KADRI 
>> > >> wrote:
>> > >> >>
>> > >> >> > As far as I understand and following this documentation:
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >>
>> > >>
>> >
>> http://cordova.apache.org/docs/en/3.0.0/guide_cli_index.md.html#The%20Command-line%20Interface
>> > >> >> >
>> > >> >> > Plugins are currently fetched using git from origin/master. It
>> is a
>> > >> >> > major problem in my opinion. The main reason (but there are many)
>> > is
>> > >> >> > that any commit to master can potentially break plugins. Yes, we
>> > can
>> > >> >> > do a dev branch but some people are forgetful and might commit to
>> > >> >> > master anyway. I think the proper development process for plugins
>> > >> >> > should be:
>> > >> >> > - Always commit to master
>> > >> >> > - When you're ready to release a plugin: update the version, tag
>> it
>> > >> >> > and publish it to the cordova registry.
>> > >> >> > - Users can then install the latest version without having to
>> > remember
>> > >> >> > a git URL and without worrying about getting a broken plugin.
>> > >> >> >
>> > >> >> > Ideally, every Cordova committer should be granted the right to
>> > >> >> > publish to the registry. Right now, I've only added Andrew Grieve
>> > (who
>> > >> >> > is having issues publishing atm...). If anybody wants to be
>> added,
>> > let
>> > >> >> > me know.
>> > >> >> >
>> > >> >> > Does that sound good to everyone?
>> > >> >> >
>> > >> >> > -a
>> > >> >> >
>> > >> >>
>> > >>
>> >
>>