date:20130625

onNativeReady and FirefoxOS

2013-06-25 Thread Piotr Zalewa

Hi,

Here is me again.

I commented out the reinstantiating window.navigator to make it not throw 
SecurityError under FxOS.

I then realized the 'deviceready' isn't fired.
It should be fired in 
https://github.com/apache/cordova-firefoxos/blob/master/lib/cordova.firefoxos.js#L5977
 after channel.onDOMContentLoaded, channel.onNativeReady, 
channel.onPluginsReady.
onDOMContentLoaded and onPluginsReady are fired, but onNativeReady is not.

The only place in this file which is related to this event is this: 
https://github.com/apache/cordova-firefoxos/blob/master/lib/cordova.firefoxos.js#L5954

// _nativeReady is global variable that the native side can set
// to signify that the native code is ready. It is a global since
// it may be called before any cordova JS is ready.
if (window._nativeReady) {
channel.onNativeReady.fire();
}

Is this event not fired because of my change to cordova-firefoxos.js 
(commenting out 
https://github.com/apache/cordova-firefoxos/blob/master/lib/cordova.firefoxos.js#L5945)?

Please help
zalun

PS. 
There is also an issue later on with onCordovaConnectionReady (but I forced 
onNativeReady before, so too many variables to play)

Re: onNativeReady and FirefoxOS

2013-06-25 Thread Andrew Grieve

likely you want to add a bootstrap.firefoxos.js file


On Tue, Jun 25, 2013 at 3:40 AM, Piotr Zalewa pzal...@mozilla.com wrote:

 Hi,

 Here is me again.

 I commented out the reinstantiating window.navigator to make it not
 throw SecurityError under FxOS.

 I then realized the 'deviceready' isn't fired.
 It should be fired in
 https://github.com/apache/cordova-firefoxos/blob/master/lib/cordova.firefoxos.js#L5977after
  channel.onDOMContentLoaded, channel.onNativeReady,
 channel.onPluginsReady.
 onDOMContentLoaded and onPluginsReady are fired, but onNativeReady is not.

 The only place in this file which is related to this event is this:
 https://github.com/apache/cordova-firefoxos/blob/master/lib/cordova.firefoxos.js#L5954

 // _nativeReady is global variable that the native side can set
 // to signify that the native code is ready. It is a global since
 // it may be called before any cordova JS is ready.
 if (window._nativeReady) {
 channel.onNativeReady.fire();
 }

 Is this event not fired because of my change to cordova-firefoxos.js
 (commenting out
 https://github.com/apache/cordova-firefoxos/blob/master/lib/cordova.firefoxos.js#L5945
 )?

 Please help
 zalun

 PS.
 There is also an issue later on with onCordovaConnectionReady (but I
 forced onNativeReady before, so too many variables to play)

Re: Android - Removing the .api namespace

2013-06-25 Thread Marcel Kinard

Sounds like I missed something. What firm date?

On Jun 24, 2013, at 2:04 PM, Joe Bowser bows...@gmail.com wrote:

 Unlike other releases, 3.0 is the only one with a firm date.

Re: onNativeReady and FirefoxOS

2013-06-25 Thread Gord Tanner

I could have swore there was one at one point ;)

but it is going to look exactly like the webos one [1]

[1] -
https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=blob_plain;f=lib/scripts/bootstrap-webos.js;hb=HEAD


On Tue, Jun 25, 2013 at 10:52 AM, Andrew Grieve agri...@chromium.orgwrote:

 likely you want to add a bootstrap.firefoxos.js file


 On Tue, Jun 25, 2013 at 3:40 AM, Piotr Zalewa pzal...@mozilla.com wrote:

  Hi,
 
  Here is me again.
 
  I commented out the reinstantiating window.navigator to make it not
  throw SecurityError under FxOS.
 
  I then realized the 'deviceready' isn't fired.
  It should be fired in
 
 https://github.com/apache/cordova-firefoxos/blob/master/lib/cordova.firefoxos.js#L5977afterchannel.onDOMContentLoaded,
  channel.onNativeReady,
  channel.onPluginsReady.
  onDOMContentLoaded and onPluginsReady are fired, but onNativeReady is
 not.
 
  The only place in this file which is related to this event is this:
 
 https://github.com/apache/cordova-firefoxos/blob/master/lib/cordova.firefoxos.js#L5954
 
  // _nativeReady is global variable that the native side can set
  // to signify that the native code is ready. It is a global since
  // it may be called before any cordova JS is ready.
  if (window._nativeReady) {
  channel.onNativeReady.fire();
  }
 
  Is this event not fired because of my change to cordova-firefoxos.js
  (commenting out
 
 https://github.com/apache/cordova-firefoxos/blob/master/lib/cordova.firefoxos.js#L5945
  )?
 
  Please help
  zalun
 
  PS.
  There is also an issue later on with onCordovaConnectionReady (but I
  forced onNativeReady before, so too many variables to play)

Re: Cordova Blog

2013-06-25 Thread Brian LeRoux

ya for sure, its basically a jekyll like clone now

On Mon, Jun 24, 2013 at 9:05 PM, Carlos Santana csantan...@gmail.com wrote:
 Brian you mean port the whole site to JekyII?


 On Tue, Jun 25, 2013 at 12:03 AM, Brian LeRoux b...@brian.io wrote:

 +1 lets port the whole template over
 On Jun 24, 2013 7:42 PM, Andrew Grieve agri...@chromium.org wrote:

  I think if you want to take a stab at it, Carlos, that would be great!
 You
  can see how the website currently works by looking at:
 
  https://svn.apache.org/repos/asf/cordova/site/README.md
 
  I've created https://issues.apache.org/jira/browse/CB-3997 to track this
  and assigned it to you.
 
  If you can get a prototype going, maybe just post a diff of your changes
  via svn diff and attach it to the JIRA ticket.
 
  I think timeline-wise, as soon as it gets done and we have a blog post
  written, we can ship it! :)
 
 
 
  On Mon, Jun 24, 2013 at 8:27 PM, Carlos Santana csantan...@gmail.com
  wrote:
 
   I took a look today at JekyII and got excited at the simplicity.
  
   I love simple solutions to simple problems.
  
   Should we try to launch a new site/blog for 3.0 time frame?
  
   How can I help? (admin, setup, tutorials, screencasts, migration, ideas
  for
   posts, etc..)
  
   --Carlos
  
  
   On Fri, Jun 21, 2013 at 1:09 PM, Brian LeRoux b...@brian.io wrote:
  
OR we could use Github pages for the Cordova org and just host on a
subdomain:
   
http://blog.cordova.io
   
???
   
Seems like the least friction.
   
On Fri, Jun 21, 2013 at 9:56 AM, Carlos Santana 
 csantan...@gmail.com
wrote:
 Yes mirror to Github, official and live content will be stored on
   apache
 servers.

 +1 on the repo name cordova-blog


 On Fri, Jun 21, 2013 at 12:52 PM, Shazron shaz...@gmail.com
 wrote:

 +1 on Jekyll and Github. All we need is to request a cordova-blog
  repo
on
 git-wip-us, and then the Github mirror does all the work (I think)
  :)

  https://help.github.com/articles/user-organization-and-project-pages

 So if the repo is cordova-blog, the url would then be
 http://cordova.github.io/cordova-blog


 On Fri, Jun 21, 2013 at 9:41 AM, Carlos Santana 
  csantan...@gmail.com
 wrote:

  @Brian
 
 I'm not married to WordPress was just referring as an
 example,
JekyII
  will do fine ,
 
  Can we see if we can host the content on git/github instead of
  svn?,
this
  way, I think it will be easier to contribute and maintain.
 
 
  --Carlos
 
 
  On Fri, Jun 21, 2013 at 12:29 PM, Brian LeRoux b...@brian.io
  wrote:
 
   +1 on a blog but I'd like to do something static if possible.
(Jekyll,
   Scotch, Docpad are all nice enough). We used to use Wordpress
  for
   http://phonegap.com and it was a complete struggle to keep it
  up
   to
   date and online. The running joke when were dealing w/ this
 was
   'static sites are web scale'. And its true, since moving to
  Jekyll
   we've had basically zero downtime.
  
   While our current setup is not ideal (svn) it does accommodate
   anything static. I will talk w/ Yohei about doing a slight
  refresh
to
   that (if cool w/ everyone here).
  
  
  
   On Fri, Jun 21, 2013 at 8:06 AM, Carlos Santana 
csantan...@gmail.com
   wrote:
This is great idea.
   
I don't mind the same content in both places. (PhoneGap and
Cordova)
Phonegap is spelled Cordova anyway :-)
   
   
Some of the blog posts in PhoneGap point to personal blogs.
I would thin that the Cordova Blog will do the same have
 blogs
hosted
  on
its site or point to personal blog posts.
   
What about having Pages (i.e. WordPress) on the Cordova Blog
  in
  addition
   of
Posts?
Ideas for Pages:
- Release Notes
- Roadmap/Timeline
- Videos
- Tutorials
- List 3rd Party Plugins
   
Here is another one, if Blog (i.e. WordPress) is created why
  not
host
  the
whole site (cordova.io) with WordPress (Posts and Pages)
 and
   move
 away
   from
Ruby for the website :-). If not then you will be
 maintaining
   two
 sites
with two different technologies.
   
--Carlos
   
On Thu, Jun 20, 2013 at 10:19 PM, Joe Bowser 
  bows...@gmail.com
   
  wrote:
   
Currently, PhoneGap aggregates the blog posts of many
   committers
at
phonegap.com/blog.  The downside of this is that it's an
  Adobe
 blog,
and it's not Apache Cordova.  Apache Cordova should
 probably
   have
 its
own blog, but I see a lot of the same content being in two
different
places.
   
If someone wants to take this on, that'd be awesome.
   
On Thu, Jun

Re: Cordova 2.9.0 Final

2013-06-25 Thread Andrew Grieve

Coho introduces no change in process, but it does automate some steps of
the existing process.


On Mon, Jun 24, 2013 at 6:51 PM, Brian LeRoux b...@brian.io wrote:

 Yes. The idea would be, as it always has been, the platform
 maintainers tag as their vote. That tag says, 'hey this part is
 tested, stable, and works'.


 On Mon, Jun 24, 2013 at 3:00 PM, Joe Bowser bows...@gmail.com wrote:
  So, we're using coho for tagging everything now?  That seems like a
  major process change.
 
  On Mon, Jun 24, 2013 at 7:10 AM, Andrew Grieve agri...@chromium.org
 wrote:
  Created Release bug: https://issues.apache.org/jira/browse/CB-3981
 
  Please update the subtasks if I've missed any steps.
 
 
  On Fri, Jun 21, 2013 at 10:06 PM, Filip Maj f...@adobe.com wrote:
 
  Sgtm!
 
  On 6/21/13 6:27 PM, Steven Gill stevengil...@gmail.com wrote:
 
  I say we begin the tagging process for 2.9.0 final on Monday. That
 gives
  us
  a couple of days to get everything tested, tagged and released before
 the
  end of the month. We can also merge in 3.0.0 branches after the 2.9
  release.

Re: Android - Removing the .api namespace

2013-06-25 Thread Brian LeRoux

July 19. In the past we've aimed at the last tues of every month.

On Tue, Jun 25, 2013 at 8:34 AM, Marcel Kinard cmarc...@gmail.com wrote:
 Sounds like I missed something. What firm date?

 On Jun 24, 2013, at 2:04 PM, Joe Bowser bows...@gmail.com wrote:

 Unlike other releases, 3.0 is the only one with a firm date.

Which repo?

2013-06-25 Thread Don Coleman

Should fixes for Media Capture go in cordova-android or
cordova-plugin-media-capture or both?

Re: Which repo?

2013-06-25 Thread Simon MacDonald

Bug fixes should probably go into both. The cordova-android repo will
be the long lived one for the 2.9.x stream and
cordova-plugin-media-capture will be used in 3.x.

Simon Mac Donald
http://hi.im/simonmacdonald


On Tue, Jun 25, 2013 at 12:00 PM, Don Coleman don.cole...@gmail.com wrote:
 Should fixes for Media Capture go in cordova-android or
 cordova-plugin-media-capture or both?

Re: Cordova 2.9.0 Final

2013-06-25 Thread Joe Bowser

Coho does introduce a change in the process, because instead of all
the platform maintainers tagging their code, we have one person
tagging everything.  If a tag is the vote, this is stuffing the ballot
box.  It's bad enough that we can vote twice.

Now, I'm personally OK with us decoupling automation from the rest of
the process, but right now I'm not OK with tagging this release.
Also, I'm having some issues with tagging the existing cordova-js,
whenever I try and use the cordova tool, I keep getting an error about
it not being on a named branch:

/Users/jbowser/cordova-coho/coho:488
throw new Error('Aborted due to repo ' + shjs.pwd() + ' not being on a
  ^
Error: Aborted due to repo /Users/jbowser/cordova-js not being on a named branch
at retrieveCurrentBranchName (/Users/jbowser/cordova-coho/coho:488:15)
at /Users/jbowser/cordova-coho/coho:778:9
at /Users/jbowser/cordova-coho/coho:290:9
at Array.forEach (native)
at forEachRepo (/Users/jbowser/cordova-coho/coho:281:11)
at updateRepos (/Users/jbowser/cordova-coho/coho:776:5)
at Object.prepareReleaseBranchCommand [as entryPoint]
(/Users/jbowser/cordova-coho/coho:898:5)
at main (/Users/jbowser/cordova-coho/coho:1118:25)
at Object.anonymous (/Users/jbowser/cordova-coho/coho:1120:1)
at Module._compile (module.js:456:26)

Are there additional steps that we need to do to get this to work?

Finally, can we not change how we do things until after the 3.0
release is out? I'm really not liking all these proposed changes to
both our process and APIs at the 11th hour.  There's some good ideas
here, but this is slowing things down considerably.

Joe

On Tue, Jun 25, 2013 at 8:56 AM, Andrew Grieve agri...@chromium.org wrote:
 Coho introduces no change in process, but it does automate some steps of
 the existing process.


 On Mon, Jun 24, 2013 at 6:51 PM, Brian LeRoux b...@brian.io wrote:

 Yes. The idea would be, as it always has been, the platform
 maintainers tag as their vote. That tag says, 'hey this part is
 tested, stable, and works'.


 On Mon, Jun 24, 2013 at 3:00 PM, Joe Bowser bows...@gmail.com wrote:
  So, we're using coho for tagging everything now?  That seems like a
  major process change.
 
  On Mon, Jun 24, 2013 at 7:10 AM, Andrew Grieve agri...@chromium.org
 wrote:
  Created Release bug: https://issues.apache.org/jira/browse/CB-3981
 
  Please update the subtasks if I've missed any steps.
 
 
  On Fri, Jun 21, 2013 at 10:06 PM, Filip Maj f...@adobe.com wrote:
 
  Sgtm!
 
  On 6/21/13 6:27 PM, Steven Gill stevengil...@gmail.com wrote:
 
  I say we begin the tagging process for 2.9.0 final on Monday. That
 gives
  us
  a couple of days to get everything tested, tagged and released before
 the
  end of the month. We can also merge in 3.0.0 branches after the 2.9
  release.

Clone Plugin Repos via coho

2013-06-25 Thread Andrew Grieve

To quickly clone all plugin repos:

./cordova-coho/coho repo-clone -r plugins

Re: Cordova 2.9.0 Final

2013-06-25 Thread Andrew Grieve

Ahh, okay, I see what you mean about the change. The jira bug says to tag
them all in one command, which doesn't fit in with the using a tag as a
vote idea. I'll update the JIRA issue to not use -r active-platform flag.

Joe - I just pushed a change that adds a --pretend flag to the tag-release
command. Probably should have had this from the start to ensure it's doing
the right thing.

Can you post your log, and also tell me the output of running git
symbolic-ref --short HEAD from cordova-js?


On Tue, Jun 25, 2013 at 12:23 PM, Joe Bowser bows...@gmail.com wrote:

 Coho does introduce a change in the process, because instead of all
 the platform maintainers tagging their code, we have one person
 tagging everything.  If a tag is the vote, this is stuffing the ballot
 box.  It's bad enough that we can vote twice.

 Now, I'm personally OK with us decoupling automation from the rest of
 the process, but right now I'm not OK with tagging this release.
 Also, I'm having some issues with tagging the existing cordova-js,
 whenever I try and use the cordova tool, I keep getting an error about
 it not being on a named branch:

 /Users/jbowser/cordova-coho/coho:488
 throw new Error('Aborted due to repo ' + shjs.pwd() + ' not being
 on a
   ^
 Error: Aborted due to repo /Users/jbowser/cordova-js not being on a named
 branch
 at retrieveCurrentBranchName (/Users/jbowser/cordova-coho/coho:488:15)
 at /Users/jbowser/cordova-coho/coho:778:9
 at /Users/jbowser/cordova-coho/coho:290:9
 at Array.forEach (native)
 at forEachRepo (/Users/jbowser/cordova-coho/coho:281:11)
 at updateRepos (/Users/jbowser/cordova-coho/coho:776:5)
 at Object.prepareReleaseBranchCommand [as entryPoint]
 (/Users/jbowser/cordova-coho/coho:898:5)
 at main (/Users/jbowser/cordova-coho/coho:1118:25)
 at Object.anonymous (/Users/jbowser/cordova-coho/coho:1120:1)
 at Module._compile (module.js:456:26)

 Are there additional steps that we need to do to get this to work?

 Finally, can we not change how we do things until after the 3.0
 release is out? I'm really not liking all these proposed changes to
 both our process and APIs at the 11th hour.  There's some good ideas
 here, but this is slowing things down considerably.

 Joe

 On Tue, Jun 25, 2013 at 8:56 AM, Andrew Grieve agri...@chromium.org
 wrote:
  Coho introduces no change in process, but it does automate some steps of
  the existing process.
 
 
  On Mon, Jun 24, 2013 at 6:51 PM, Brian LeRoux b...@brian.io wrote:
 
  Yes. The idea would be, as it always has been, the platform
  maintainers tag as their vote. That tag says, 'hey this part is
  tested, stable, and works'.
 
 
  On Mon, Jun 24, 2013 at 3:00 PM, Joe Bowser bows...@gmail.com wrote:
   So, we're using coho for tagging everything now?  That seems like a
   major process change.
  
   On Mon, Jun 24, 2013 at 7:10 AM, Andrew Grieve agri...@chromium.org
  wrote:
   Created Release bug: https://issues.apache.org/jira/browse/CB-3981
  
   Please update the subtasks if I've missed any steps.
  
  
   On Fri, Jun 21, 2013 at 10:06 PM, Filip Maj f...@adobe.com wrote:
  
   Sgtm!
  
   On 6/21/13 6:27 PM, Steven Gill stevengil...@gmail.com wrote:
  
   I say we begin the tagging process for 2.9.0 final on Monday. That
  gives
   us
   a couple of days to get everything tested, tagged and released
 before
  the
   end of the month. We can also merge in 3.0.0 branches after the 2.9
   release.

Re: Cordova 2.9.0 Final

2013-06-25 Thread Andrew Grieve

Also - if coho is not working for you or that you feel like it's slowing
you down, feel free to just run the same old git commands directly.


On Tue, Jun 25, 2013 at 12:49 PM, Andrew Grieve agri...@chromium.orgwrote:

 Ahh, okay, I see what you mean about the change. The jira bug says to tag
 them all in one command, which doesn't fit in with the using a tag as a
 vote idea. I'll update the JIRA issue to not use -r active-platform flag.

 Joe - I just pushed a change that adds a --pretend flag to the tag-release
 command. Probably should have had this from the start to ensure it's doing
 the right thing.

 Can you post your log, and also tell me the output of running git
 symbolic-ref --short HEAD from cordova-js?


 On Tue, Jun 25, 2013 at 12:23 PM, Joe Bowser bows...@gmail.com wrote:

 Coho does introduce a change in the process, because instead of all
 the platform maintainers tagging their code, we have one person
 tagging everything.  If a tag is the vote, this is stuffing the ballot
 box.  It's bad enough that we can vote twice.

 Now, I'm personally OK with us decoupling automation from the rest of
 the process, but right now I'm not OK with tagging this release.
 Also, I'm having some issues with tagging the existing cordova-js,
 whenever I try and use the cordova tool, I keep getting an error about
 it not being on a named branch:

 /Users/jbowser/cordova-coho/coho:488
 throw new Error('Aborted due to repo ' + shjs.pwd() + ' not being
 on a
   ^
 Error: Aborted due to repo /Users/jbowser/cordova-js not being on a named
 branch
 at retrieveCurrentBranchName (/Users/jbowser/cordova-coho/coho:488:15)
 at /Users/jbowser/cordova-coho/coho:778:9
 at /Users/jbowser/cordova-coho/coho:290:9
 at Array.forEach (native)
 at forEachRepo (/Users/jbowser/cordova-coho/coho:281:11)
 at updateRepos (/Users/jbowser/cordova-coho/coho:776:5)
 at Object.prepareReleaseBranchCommand [as entryPoint]
 (/Users/jbowser/cordova-coho/coho:898:5)
 at main (/Users/jbowser/cordova-coho/coho:1118:25)
 at Object.anonymous (/Users/jbowser/cordova-coho/coho:1120:1)
 at Module._compile (module.js:456:26)

 Are there additional steps that we need to do to get this to work?

 Finally, can we not change how we do things until after the 3.0
 release is out? I'm really not liking all these proposed changes to
 both our process and APIs at the 11th hour.  There's some good ideas
 here, but this is slowing things down considerably.

 Joe

 On Tue, Jun 25, 2013 at 8:56 AM, Andrew Grieve agri...@chromium.org
 wrote:
  Coho introduces no change in process, but it does automate some steps of
  the existing process.
 
 
  On Mon, Jun 24, 2013 at 6:51 PM, Brian LeRoux b...@brian.io wrote:
 
  Yes. The idea would be, as it always has been, the platform
  maintainers tag as their vote. That tag says, 'hey this part is
  tested, stable, and works'.
 
 
  On Mon, Jun 24, 2013 at 3:00 PM, Joe Bowser bows...@gmail.com wrote:
   So, we're using coho for tagging everything now?  That seems like a
   major process change.
  
   On Mon, Jun 24, 2013 at 7:10 AM, Andrew Grieve agri...@chromium.org
 
  wrote:
   Created Release bug: https://issues.apache.org/jira/browse/CB-3981
  
   Please update the subtasks if I've missed any steps.
  
  
   On Fri, Jun 21, 2013 at 10:06 PM, Filip Maj f...@adobe.com wrote:
  
   Sgtm!
  
   On 6/21/13 6:27 PM, Steven Gill stevengil...@gmail.com wrote:
  
   I say we begin the tagging process for 2.9.0 final on Monday. That
  gives
   us
   a couple of days to get everything tested, tagged and released
 before
  the
   end of the month. We can also merge in 3.0.0 branches after the
 2.9
   release.

Re: [plugins] xmls in cordova plugin.xml

2013-06-25 Thread Filip Maj

For the record the spec doc is located inside the cordova-plugman repo [1].

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

On 6/24/13 2:23 PM, Benn Mapes benn.ma...@gmail.com wrote:

I've noticed two different xmls namespaces for the core cordova plugins :

xmlns=http://www.phonegap.com/ns/plugins/1.0;
and
xmlns=http://cordova.apache.org/ns/plugins/1.0;

I believe we want the second namespace but the documented plugin spec [1]
uses the first one (probably hasn't been updated).

Is it safe to say that we want http://cordova.apache.org/ns/plugins/1.0 as
the namespace for the core cordova plugins?

[1]: https://github.com/alunny/cordova-plugin-spec

Re: Cordova 2.9.0 Final

2013-06-25 Thread Joe Bowser

I don't have a --short for symbolic-ref, and I already posted the stack trace:

Here's what I get when I'm on the 2.9.x branch.  Am I supposed to be
on something else?  Shouldn't coho be smart enough to deal? Can we
make it easier to debug when things go off the rails?

jbowser-MacBookPro:cordova-js jbowser$ git symbolic-ref HEAD
refs/heads/2.9.x



On Tue, Jun 25, 2013 at 9:49 AM, Andrew Grieve agri...@chromium.org wrote:
 Ahh, okay, I see what you mean about the change. The jira bug says to tag
 them all in one command, which doesn't fit in with the using a tag as a
 vote idea. I'll update the JIRA issue to not use -r active-platform flag.

 Joe - I just pushed a change that adds a --pretend flag to the tag-release
 command. Probably should have had this from the start to ensure it's doing
 the right thing.

 Can you post your log, and also tell me the output of running git
 symbolic-ref --short HEAD from cordova-js?


 On Tue, Jun 25, 2013 at 12:23 PM, Joe Bowser bows...@gmail.com wrote:

 Coho does introduce a change in the process, because instead of all
 the platform maintainers tagging their code, we have one person
 tagging everything.  If a tag is the vote, this is stuffing the ballot
 box.  It's bad enough that we can vote twice.

 Now, I'm personally OK with us decoupling automation from the rest of
 the process, but right now I'm not OK with tagging this release.
 Also, I'm having some issues with tagging the existing cordova-js,
 whenever I try and use the cordova tool, I keep getting an error about
 it not being on a named branch:

 /Users/jbowser/cordova-coho/coho:488
 throw new Error('Aborted due to repo ' + shjs.pwd() + ' not being
 on a
   ^
 Error: Aborted due to repo /Users/jbowser/cordova-js not being on a named
 branch
 at retrieveCurrentBranchName (/Users/jbowser/cordova-coho/coho:488:15)
 at /Users/jbowser/cordova-coho/coho:778:9
 at /Users/jbowser/cordova-coho/coho:290:9
 at Array.forEach (native)
 at forEachRepo (/Users/jbowser/cordova-coho/coho:281:11)
 at updateRepos (/Users/jbowser/cordova-coho/coho:776:5)
 at Object.prepareReleaseBranchCommand [as entryPoint]
 (/Users/jbowser/cordova-coho/coho:898:5)
 at main (/Users/jbowser/cordova-coho/coho:1118:25)
 at Object.anonymous (/Users/jbowser/cordova-coho/coho:1120:1)
 at Module._compile (module.js:456:26)

 Are there additional steps that we need to do to get this to work?

 Finally, can we not change how we do things until after the 3.0
 release is out? I'm really not liking all these proposed changes to
 both our process and APIs at the 11th hour.  There's some good ideas
 here, but this is slowing things down considerably.

 Joe

 On Tue, Jun 25, 2013 at 8:56 AM, Andrew Grieve agri...@chromium.org
 wrote:
  Coho introduces no change in process, but it does automate some steps of
  the existing process.
 
 
  On Mon, Jun 24, 2013 at 6:51 PM, Brian LeRoux b...@brian.io wrote:
 
  Yes. The idea would be, as it always has been, the platform
  maintainers tag as their vote. That tag says, 'hey this part is
  tested, stable, and works'.
 
 
  On Mon, Jun 24, 2013 at 3:00 PM, Joe Bowser bows...@gmail.com wrote:
   So, we're using coho for tagging everything now?  That seems like a
   major process change.
  
   On Mon, Jun 24, 2013 at 7:10 AM, Andrew Grieve agri...@chromium.org
  wrote:
   Created Release bug: https://issues.apache.org/jira/browse/CB-3981
  
   Please update the subtasks if I've missed any steps.
  
  
   On Fri, Jun 21, 2013 at 10:06 PM, Filip Maj f...@adobe.com wrote:
  
   Sgtm!
  
   On 6/21/13 6:27 PM, Steven Gill stevengil...@gmail.com wrote:
  
   I say we begin the tagging process for 2.9.0 final on Monday. That
  gives
   us
   a couple of days to get everything tested, tagged and released
 before
  the
   end of the month. We can also merge in 3.0.0 branches after the 2.9
   release.

Gave up on coho for now, errors with grunt

2013-06-25 Thread Joe Bowser

Hey

I gave up on coho, so just to do sanity, I tried using grunt to
generate the packages, and I get the following after the unit tests
finish.

Fatal error: undefined is not a function

So, what runs after the tests again? Should we just not care about
this? I'm not familiar with grunt enough to know why I would get this
once the tests are done.  I seem to have the JS, so I'm OK to roll
with it, but I would like to know why.

Joe

Re: building cordova 3.0

2013-06-25 Thread Filip Maj

One method that I've used is with cordova-cli. You can point cordova-cli
to use a local copy of a particular platform implementation. So, I would
clone down and check out the 3.0 branch for cordova-ios, android, etc.
Create a project with `cordova create tmp`. Edit tmp/.cordova/config.json
so it has this structure:

{
  lib:{
android:{
  id:'cordova-with-no-plugins',
  version:'3.0',
  uri:'/Users/fil/src/cordova-android'
}
  }
}

So in the above example, I am telling cordova-cli to look under
/Users/fil/src/cordova-android for cordova-android and use it instead of
what comes standard with cordova-cli.

Then if I run:

`cordova platform add android`

It will use my custom location for cordova-android to create a project. At
that point, I can `cordova plugin add
https://git-wip-us.apache.org/repos/asf/cordova-plugin-whatever.git` to
install any of the core broken-out plugins.

On 6/25/13 2:10 PM, Steven Gill stevengil...@gmail.com wrote:

Hey Don,

Currently, all of the platform repos have 3.0 branches. These branches
have
the plugins ripped out. You can run the usual creates scripts for each
platform to create a project. You would then use plugman to install the
plugins into your created projects.

Anis is working on a discovery mechanism for plugins currently.

You can take a look at
http://github.com/brianleroux/plugin-breakout-release-test-harness/ to see
how we have been testing all of the plugins.

-Steve


On Tue, Jun 25, 2013 at 11:56 AM, Don Coleman don.cole...@gmail.com
wrote:

 Has anyone documented the process for building Cordova 3.0 for
development?

 I see all the cordova-plugin-* repos.  Is there a base project with
build
 scripts?

Re: Cordova 2.9.0 Final

2013-06-25 Thread Andrew Grieve

Hey Joe - not sure what happened, but would love to know what errors you're
now seeing.

Looks like the tagging of Android didn't go quite right:
https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=log;h=df1536ea77e97b7d362a19582f8beddd168c5ec3

There shouldn't be a merge commit (I don't think anyways), and the tag
points past the branch head. Did you forget to push the 2.9.x branch?

On Tue, Jun 25, 2013 at 6:41 PM, Steven Gill stevengil...@gmail.com wrote:

Hey All,

I would really appreciate if we could get the tags rolling. I am heading
out for nodeconf on Thursday and want to get the release out tomorrow
before I leave. Are there any issues holding people back from tagging?
Android is the only platform tagged so far.

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

Cheers,
-Steve

On Tue, Jun 25, 2013 at 1:50 PM, Joe Bowser bows...@gmail.com wrote:

I'm now getting even worse errors with coho. I've fully abandoned
using that tool for this release and I'm tagging everything the old
fashioned way. We should create tickets for each of the platform
maintainers to tag their releases so we can get this rolling.

On Tue, Jun 25, 2013 at 12:25 PM, Andrew Grieve agri...@chromium.org
wrote:
The tool logs most of the commands that it executes, it prints out
stack
traces when it fails, and you can step through the code using
node_inspector. Do you have any suggestions on how to make it easier to
debug?

If you don't have a --short, then that would certainly be the problem.
Perhaps your git version is older than mine and that flag was a new
addition? I just pushed a change to not use --short.

On Tue, Jun 25, 2013 at 2:52 PM, Joe Bowser bows...@gmail.com wrote:

I don't have a --short for symbolic-ref, and I already posted the
stack
trace:

Here's what I get when I'm on the 2.9.x branch. Am I supposed to be
on something else? Shouldn't coho be smart enough to deal? Can we
make it easier to debug when things go off the rails?

jbowser-MacBookPro:cordova-js jbowser$ git symbolic-ref HEAD
refs/heads/2.9.x

On Tue, Jun 25, 2013 at 9:49 AM, Andrew Grieve agri...@chromium.org
wrote:
Ahh, okay, I see what you mean about the change. The jira bug says
to
tag
them all in one command, which doesn't fit in with the using a tag
as
a
vote idea. I'll update the JIRA issue to not use -r active-platform
flag.

Joe - I just pushed a change that adds a --pretend flag to the
tag-release
command. Probably should have had this from the start to ensure it's
doing
the right thing.

Can you post your log, and also tell me the output of running git
symbolic-ref --short HEAD from cordova-js?

On Tue, Jun 25, 2013 at 12:23 PM, Joe Bowser bows...@gmail.com
wrote:

Coho does introduce a change in the process, because instead of all
the platform maintainers tagging their code, we have one person
tagging everything. If a tag is the vote, this is stuffing the
ballot
box. It's bad enough that we can vote twice.

Now, I'm personally OK with us decoupling automation from the rest
of
the process, but right now I'm not OK with tagging this release.
Also, I'm having some issues with tagging the existing cordova-js,
whenever I try and use the cordova tool, I keep getting an error
about
it not being on a named branch:

/Users/jbowser/cordova-coho/coho:488
throw new Error('Aborted due to repo ' + shjs.pwd() + ' not
being
on a
^
Error: Aborted due to repo /Users/jbowser/cordova-js not being on a
named
branch
at retrieveCurrentBranchName
(/Users/jbowser/cordova-coho/coho:488:15)
at /Users/jbowser/cordova-coho/coho:778:9
at /Users/jbowser/cordova-coho/coho:290:9
at Array.forEach (native)
at forEachRepo (/Users/jbowser/cordova-coho/coho:281:11)
at updateRepos (/Users/jbowser/cordova-coho/coho:776:5)
at Object.prepareReleaseBranchCommand [as entryPoint]
(/Users/jbowser/cordova-coho/coho:898:5)
at main (/Users/jbowser/cordova-coho/coho:1118:25)
at Object.anonymous (/Users/jbowser/cordova-coho/coho:1120:1)
at Module._compile (module.js:456:26)

Are there additional steps that we need to do to get this to work?

Finally, can we not change how we do things until after the 3.0
release is out? I'm really not liking all these proposed changes to
both our process and APIs at the 11th hour. There's some good
ideas
here, but this is slowing things down considerably.

Joe

On Tue, Jun 25, 2013 at 8:56 AM, Andrew Grieve
agri...@chromium.org

wrote:
Coho introduces no change in process, but it does automate some
steps
of
the existing process.

On Mon, Jun 24, 2013 at 6:51 PM, Brian LeRoux b...@brian.io
wrote:

Yes. The

Re: cordova-plugin-vibration?

2013-06-25 Thread Andrew Grieve

Okay, filed a JIRA issue: https://issues.apache.org/jira/browse/INFRA-6458


On Tue, Jun 25, 2013 at 4:53 PM, Steven Gill stevengil...@gmail.com wrote:

 Sorry I wasn't very clear. Vibration code will go into
 cordova-plugin-vibration. This is where the vibration + notification code
 currently lives. Notification specific code needs to be broken out and put
 into cordova-plugin-dialogs.


 On Tue, Jun 25, 2013 at 12:25 PM, Simon MacDonald 
 simon.macdon...@gmail.com
  wrote:

  Naw, I think this should have it's own repo as it has it's own W3C spec.
 
  http://www.w3.org/TR/vibration/
 
  Simon Mac Donald
  http://hi.im/simonmacdonald
 
 
  On Tue, Jun 25, 2013 at 3:04 PM, Steven Gill stevengil...@gmail.com
  wrote:
   Notifications should go into the cordova-plugin-dialogs repo that is
   already created. Shaz is looking into doing this for iOS.
   https://issues.apache.org/jira/browse/CB-3970
  
  
   On Tue, Jun 25, 2013 at 10:57 AM, Filip Maj f...@adobe.com wrote:
  
   Yep labs seems the perfect fit for this
  
   On 6/25/13 10:47 AM, Andrew Grieve agri...@chromium.org wrote:
  
   Lisa's made progress on CB 2971. It separates vibration from
   notifications.
   This would mean creating another repo for 3.0 though. Shall I file an
   INFRA
   ticket? are there any other repos that are pending creation atm?
   
   As a follow up, I think it'd be nice to have a staging repo for new
   plugins
   so that we're never blocked on waiting for plugin repos to be
 created.
   Probably can use cordova-labs for this?

Re: cordova-plugin-vibration?

2013-06-25 Thread Steven Gill

Both of the repos already exist! Cordova-plugin-vibration has all of the
vibration + notification code already. The notification code needs to be
split up from vibration and moved into the cordova-plugin-dialogs repo.


On Tue, Jun 25, 2013 at 4:08 PM, Andrew Grieve agri...@chromium.org wrote:

 Okay, filed a JIRA issue: https://issues.apache.org/jira/browse/INFRA-6458


 On Tue, Jun 25, 2013 at 4:53 PM, Steven Gill stevengil...@gmail.com
 wrote:

  Sorry I wasn't very clear. Vibration code will go into
  cordova-plugin-vibration. This is where the vibration + notification code
  currently lives. Notification specific code needs to be broken out and
 put
  into cordova-plugin-dialogs.
 
 
  On Tue, Jun 25, 2013 at 12:25 PM, Simon MacDonald 
  simon.macdon...@gmail.com
   wrote:
 
   Naw, I think this should have it's own repo as it has it's own W3C
 spec.
  
   http://www.w3.org/TR/vibration/
  
   Simon Mac Donald
   http://hi.im/simonmacdonald
  
  
   On Tue, Jun 25, 2013 at 3:04 PM, Steven Gill stevengil...@gmail.com
   wrote:
Notifications should go into the cordova-plugin-dialogs repo that is
already created. Shaz is looking into doing this for iOS.
https://issues.apache.org/jira/browse/CB-3970
   
   
On Tue, Jun 25, 2013 at 10:57 AM, Filip Maj f...@adobe.com wrote:
   
Yep labs seems the perfect fit for this
   
On 6/25/13 10:47 AM, Andrew Grieve agri...@chromium.org wrote:
   
Lisa's made progress on CB 2971. It separates vibration from
notifications.
This would mean creating another repo for 3.0 though. Shall I file
 an
INFRA
ticket? are there any other repos that are pending creation atm?

As a follow up, I think it'd be nice to have a staging repo for new
plugins
so that we're never blocked on waiting for plugin repos to be
  created.
Probably can use cordova-labs for this?

[cordova-js] Order of internal cordova events and docs

2013-06-25 Thread Benn Mapes

Not sure if this is doc'ed anywhere, I looked on the wiki but I didn't see
anything.

Currently the order of events for page-load/cordova start-up is this (on
windows phone):
1.) onDOMContentLoaded
2.) onPluginsReady
3.) onNativeReady
4.) onCordovaReady
5.) onCordovaInfoReady
6.) deviceready

After digging though some old mailing lists I found this mention about the
topic [1].

For plugins on windows phone we need to patch the browser and inject some
scripts so that the xhr will run, this is hard to do if onPluginsReady gets
fired before onNativeReady because we have no way to ensure that the xhr is
patched before the plugins get loaded.

What do people think about documenting the order of these events firing so
that it will be consistent across all platforms, as well as waiting for
onNativeReady to fire before loading the plugins?


[1]:
http://callback.markmail.org/message/bziya43ztqo6oqrs?q=cordova+list:org%2Eapache%2Eincubator%2Ecallback-dev+order+channel+fire

Re: Cordova 2.9.0 Final

2013-06-25 Thread Joe Bowser

I pushed to the 2.9.0 branch, but someone snuck a commit in on run. I
then decided to re-tag it, since this is a script change, and not
anything that required re-testing.

On Tue, Jun 25, 2013 at 4:04 PM, Andrew Grieve agri...@chromium.org wrote:
Hey Joe - not sure what happened, but would love to know what errors you're
now seeing.