Re: [cli] Consolidating platform references

[Michael Brooks]

Great work Benn. Braden echoed exactly my thoughts.


On Tue, Jun 4, 2013 at 7:47 AM, Braden Shepherdson wrote:

> I've wanted to do this since I first opened the files in CLI. It's much
> better these days than it was, at least. Glad to see it's still moving.
>
> Braden
>
>
> On Mon, Jun 3, 2013 at 8:42 PM, Filip Maj  wrote:
>
> > Works well for me on my machine, +1
> >
> > On 6/3/13 5:40 PM, "Benn Mapes"  wrote:
> >
> > >Working with the cordova-cli code I have noticed that there are lots of
> > >repetitive platform-specific references in many of the files. I have
> tried
> > >to consolidate all of these into the platforms.js file at the root of
> the
> > >project. I push up this branch to apache:
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=shortlog;h=ref
> > >s/heads/platform-reorg
> > >
> > >As far as I know, all the test pass on windows and mac, I haven't
> > >physically tested every part yet to make sure this didn't break anything
> > >but I believe not.
> > >
> > >This change is working towards consolidating all platforms so that it's
> > >very easy to add and remove them if needed. The ultimate goal for
> adding a
> > >new platform should be to just add it to platforms.js and create a
> parser
> > >+
> > >tests for it.
> > >
> > >Please let me know what you think, if everyone is in agreeance hen I
> will
> > >add this to the master2 branch.
> > >
> > >~Benn
> >
> >
>

Re: Baby Grieve

[Michael Brooks]

Congrats Andrew!


On Fri, May 31, 2013 at 11:05 PM, Giorgio Natili wrote:

> Congrats!
>
>
> On Fri, May 31, 2013 at 11:49 PM, Tommy Williams 
> wrote:
>
> > Congratulations Andrew!!!
> >
> >
> > Assuming this is your first, you are about to be in for a wild ride :)
> >
> >
> > - tommy
> >
> > —
> > Sent from Mailbox for iPhone
> >
> > On Sat, Jun 1, 2013 at 6:17 AM, Filip Maj  wrote:
> >
> > > Congrats Andrew!
> > > On 5/31/13 3:57 PM, "Gorkem Ercan"  wrote:
> > >>Congrats! My best wishes to Grieve family.
> > >>
> > >>--
> > >>Gorkem
> > >>
> > >>
> > >>On Fri, May 31, 2013 at 2:23 PM, Shazron  wrote:
> > >>
> > >>> Congrats Andrew!! :)
> > >>>
> > >>>
> > >>>
> > >>> On Fri, May 31, 2013 at 7:00 AM, Andrew Grieve  >
> > >>> wrote:
> > >>>
> > >>> > Coming 1 month early
> > >>> >
> > >>> > Everett Arend Grieve born Thursday May 30 at 9:45 am. 5 lbs 15 oz.
> > >>>18.5
> > >>> > inches long.
> > >>> >
> > >>> > Mom is currently in the ACOU and Everett in the ICU. They are on
> > >>>track to
> > >>> > meet today! We will be a few days in the hospital, but everything's
> > >>> looking
> > >>> > good!
> > >>> >
> > >>> > Not sure how much I'll be checking email in the next little while.
> > >>>Good
> > >>> > luck with the release!
> > >>> >
> > >>> > Andrew
> > >>> >
> > >>>
> >
>

Re: svngit2jira

[Michael Brooks]

+1 most of us are already use the commit message practice, so a little
automation would save us time with JIRA.


On Fri, May 24, 2013 at 10:28 AM, Benn Mapes  wrote:

> +1
> "How would you like commits to trigger an update of a JIRA ticket"
>  - it would be nice for it to trigger on commits starting with CB- or
> [CB-], possibly more but I believe those are the most popular.
>
>
> On Fri, May 24, 2013 at 8:09 AM, Andrew Grieve 
> wrote:
>
> > +1000
> >
> >
> > On Fri, May 24, 2013 at 10:12 AM, Braden Shepherdson <
> bra...@chromium.org
> > >wrote:
> >
> > > +1 that jumped out at me from the letter the Infra guys sent out.
> > >
> > > They probably won't be happy when we ask for it on 20 git repos, though
> > :P
> > >
> > > Braden
> > >
> > >
> > > On Fri, May 24, 2013 at 9:52 AM, James Jong 
> > wrote:
> > >
> > > > +1
> > > > Saves an extra step.
> > > >
> > > > -James Jong
> > > >
> > > > On May 24, 2013, at 5:35 AM, Shazron  wrote:
> > > >
> > > > > http://www.apache.org/dev/svngit2jira.html
> > > > >
> > > > > "Is the project in agreement on using this?"
> > > > >
> > > > > I think it's a good idea.
> > > >
> > > >
> > >
> >
>

Re: 2.8.0rc1

[Michael Brooks]

>
> The one thing that I'd like to see finished up is
> https://issues.apache.org/jira/browse/CB-3307 (Renaming cordova.VERSION.js
> -> cordova.js). It's done for iOS & Android, but still needs to be done for
> other platforms. I'll create sub-tasks for them now.


Good catch Andrew.

I've also created tasks for updating the Hello World and CLI as well. I'll
try to have these finished by EOD.


On Tue, May 21, 2013 at 9:13 AM, Filip Maj  wrote:

> Yes good call Andrew definitely need that done across platforms before we
> ship another release.
>
> On 5/21/13 9:11 AM, "Andrew Grieve"  wrote:
>
> >Checking back in to see if anyone has anything they're trying to get in
> >for
> >2.8.
> >
> >If no one has anything by the EOD, then I'll take care of branching &
> >tagging & JIRA'ing this time around. I've been adding branching & tagging
> >powers to coho, so want to test out the changes this release :).
> >
> >The one thing that I'd like to see finished up is
> >https://issues.apache.org/jira/browse/CB-3307 (Renaming
> cordova.VERSION.js
> >-> cordova.js). It's done for iOS & Android, but still needs to be done
> >for
> >other platforms. I'll create sub-tasks for them now.
> >
> >
> >
> >On Fri, May 17, 2013 at 7:29 PM, Steven Gill 
> >wrote:
> >
> >> Sounds good to me.
> >>
> >>
> >> On Fri, May 17, 2013 at 2:48 PM, Filip Maj  wrote:
> >>
> >> > +1!
> >> >
> >> > On 5/17/13 2:44 PM, "Jesse"  wrote:
> >> >
> >> > >Monday is a holiday in Canada, so I propose we aim to do our rc1
> >>ritual
> >> on
> >> > >Tuesday, May 14th
> >> > >This still gives us a little time to close the loop on any
> >>outstanding
> >> > >items, and lots of time to test.
> >> > >Thoughts?
> >> > >
> >> > >@purplecabbage
> >> > >risingj.com
> >> >
> >> >
> >>
>
>

Re: standard slides?

[Michael Brooks]

For sure Marcel:

http://michaelbrooks.ca/#presentations

https://github.com/mwbrooks/michaelbrooks.ca/tree/master/deck


On Tue, May 21, 2013 at 9:23 AM, Brian LeRoux  wrote:

> Kind of Adobe PhoneGap centric but a good starting point:
>
> http://brian.io/slides/phonegap-standard-deck
>
> Src here:
>
> http://github.com/brianleroux/phonegap-standard-deck
>
>
> On Tue, May 21, 2013 at 8:13 AM, Marcel Kinard  wrote:
> > A person in my area has an opportunity to attend a conference and give a
> 7-minute talk on why Cordova is great and why folks should consider using
> it. I suspect that several people here do that on a regular basis, except
> you get more time. Would any of you be willing to share or point me to your
> presentation slides, especially any that cite Cordova usage in apps? Thanks!
> >
> > -- Marcel Kinard
>

Re: Ignore .svn files for building

[Michael Brooks]

I've created CB-3383 [1] to track and fix this issue.

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


On Thu, May 2, 2013 at 8:18 AM, Kerri Shotts  wrote:

> Better yet, respect convention that anything starting with a dot is hidden
> and thus ignored. Checking the Hidden attribute would also seem wise.
>
> Sent from my phone.
>
> ___
> Kerri Shotts
> photoKandy Studios, LLC
>
> On the Web: http://www.photokandy.com/
>
> Social Media:
>   Twitter: @photokandy, http://twitter.com/photokandy
>   Tumblr: http://photokandy.tumblr.com/
>   Github: https://github.com/kerrishotts
> https://github.com/organizations/photokandyStudios
>   CoderWall: https://coderwall.com/kerrishotts
>
> Apps on the Apple Store:
>
> https://itunes.apple.com/us/artist/photokandy-studios-llc/id498577828
>
> Books:
>
> http://www.packtpub.com/phonegap-2-mobile-application-hotshot/book
>   http://www.packtpub.com/phonegap-social-app-development/book
>
> On May 2, 2013, at 8:13, Don Coleman  wrote:
>
> You're seeing this in cordova-cli?
>
> until.findPlugins could filter out .svn too
> https://github.com/apache/cordova-cli/blob/master/src/util.js#L67
> On May 2, 2013 5:33 AM, "tommy-carlos Williams" 
> wrote:
>
> This is a recurring theme.
>
>
> The logic for iterating the folders for things like platforms and plugins
>
> needs a look at.
>
>
> On 02/05/2013, at 19:27, Andreas Sander  wrote:
>
>
> I get an
>
>
> Error: ENOENT, no such file or directory 'plugins/.svn/plugin.xml'
>
>
> So Cordova interprets .svn as a real plugin, isn't it?
>
>
> Occurs in Cordova 2.6.0 and the newest 2.7.2
>
>
> From: andreas.san...@hotmail.de
>
> To: dev@cordova.apache.org
>
> Subject: Ignore .svn files for building
>
> Date: Thu, 2 May 2013 10:34:44 +0200
>
>
> Hi,
>
>
> is there an easy way to set some filetypes (especially .svn files) to
>
> ignore for building?
>
>
> Greets,
>
>
> Andreas
>

Re: Naming: cordova-2.8.0.js --> cordova.js

[Michael Brooks]

Jeff, thanks for the valuable recap!

That is exactly the difference I was talking about. I would propose that
> instead of native placing the file there, we just make it a final part of
> the build step. Just as we've done with other CLI tasks, make a micro
> cordova script to do it, and have it called right before build.


It would be fantastic to move the script injection logic out of the CLI and
into the project build step. It would be really nice if we could:

1) Add cordova.js to www/
2) Add the script reference to each HTML file.

Doing this at build-time helps remove the dynamic injection issues of
WebView API support and race-conditions.

Michael


On Wed, May 1, 2013 at 9:10 AM, Brian LeRoux  wrote:

> Or we put the version in the filename.
>
> On Wed, May 1, 2013 at 9:00 AM, Jesse MacFadyen 
> wrote:
> > Interesting journey, Jeffery.
> > What if instead of linking from www/index.html to www/cordova.js, we
> > put the js in the app root above www?
> >
> > Or: 

Re: Naming: cordova-2.8.0.js --> cordova.js

[Michael Brooks]

+1 cordova.js with version as a header comment


On Tue, Apr 30, 2013 at 11:31 AM, Filip Maj  wrote:

> If I recall correctly the original reason was because putting the version
> in after the lib name in the JS filename was what "other libraries did"
> aka jQuery.
>
> +1 from me.
>
> On 4/30/13 11:24 AM, "tommy-carlos Williams"  wrote:
>
> >+1
> >
> >Wouldn't this make mobile spec easier too?
> >
> >On 01/05/2013, at 4:20, Andrew Grieve  wrote:
> >
> >> This has been brought up a few times, but I'm not sure there's been a
> >> decisive answer here yet...
> >>
> >> iOS now uses "cordova.ios.js"
> >> Android uses "cordova.android.js", but renames it in a build step to
> >>add in
> >> the version number.
> >> CLI normalizes to "cordova.js"
> >>
> >> The version number is now stamped at the top of the file in a code
> >>comment,
> >> and I feel that having it in the file name just makes work for us and
> >>our
> >> users. I'd like to change all repos to just use "cordova.js".
> >>
> >> Any objections?
> >>
> >> Andrew
>
>

Re: Use git sub-modules for the copies of cordova-* within CLI?

[Michael Brooks]

Yea, I believe the plan is the lazy-load the platforms to a global
configuration directory. The lazy-load would only happen on the first
request for a given platform. Any future requests would use the cached
platform.

For example: ~/.cordova/platform/cordova-android-2.7.0/

Andrew, I think your advantages are accurate. I would also add:

4. Removes need to `sudo chown username /path/to/global/npm/cordova/`

I've got a lot on my plate right now, but I am hoping to get started on
this lazy-loading asap.

Michael


On Tue, Apr 30, 2013 at 8:56 AM, Filip Maj  wrote:

> Yeah, Michael Brooks was working towards lazy-loading the libraries as you
> need them.
>
> On 4/30/13 5:08 AM, "Andrew Grieve"  wrote:
>
> >Actually... Now I think I'm remembering that there was talk about not
> >including these at all... Was that right? We were going to package them up
> >as separate npm targets, or have CLI be able to download them on demand as
> >zip files?
> >
> >
> >On Mon, Apr 29, 2013 at 10:28 PM, Andrew Grieve
> >wrote:
> >
> >> Right now we have a copy / paste of the entire cordova-ios,
> >> cordova-android, cordova-blackberry directories within cordova-cli/lib.
> >>I'm
> >> wondering if we should change these to be submodules.
> >>
> >> Git submodules often don't work well because they don't automatically
> >> track branches. In this case though, I think they do exactly what we'd
> >>want
> >> them to - to point to a specific commit hash.
> >>
> >> Advantages:
> >> 1. cordova-cli currently takes a while to clone since its index is so
> >>big.
> >> Using submodules would mean the index would stop growing so much (not
> >>sure
> >> if we can purge the currently copies from index).
> >> 2. It would be clear that the copies within CLI do not have any
> >> modifications
> >> 3. Would be easier to update them for each release
> >>
>
>

Re: config.xml - phonegap properties

[Michael Brooks]

Hi Andreas,

Good catch and we've already logged this issue as CB-3279 [1].

I haven't had a chance to investigate it, but I imagine it was either a
copy & paste mistake when the config.xml support was first added the CLI.
Since the version is 1.9.0, I imagine it was copied from a PhoneGap/Build
project that was set to PhoneGap 1.9.0. In short, you can ignore it and it
should be removed.

Thanks for the heads up!
Michael

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


On Tue, Apr 30, 2013 at 8:49 AM, Andreas Sander
wrote:

> Hi,
>
> I've a short question concerning the www/config.xml property file.
>
> I compiled my cordova project with Cordova v1.6.0 via npm and command
> line. After creating a project with cordova create command, there are two
> config.xml properties concerning phonegap.
>
>  
> http://api.phonegap.com/1.0/device"; />
>
> Is this a left-over of phonegap code before cordova existed?
>
> Nevertheless:
>
> Why does the phonegap-version is set to 1.9.0 when I'm building it with
> cordova 2.6.0? Is there a meaning for this value, which I don't get? Or can
> I change it to the same version number, hence 2.6.0?
>
> Any help is appreciated!
>
> With best regards,
>
> Andreas Sander
>

Re: [cordova-cli] npm Version Update

[Michael Brooks]

The first step will be to lazy load the locked in version. This ensures
that the npm install isn't huge and downloading platforms that the
developer is not interested it. It also allows us to lazy load patched
releases almost instantaneously - no npm update required.

The much longer goal would be to discuss and architect the grunt inspired
approach. However, with how the CLI is structured, it would be a big leap
to take between now and 3.0 (imo).


On Sat, Apr 20, 2013 at 11:32 AM, Brian LeRoux  wrote:

> So wait, I had thought thats what you were doing w/ the CLI right now?
> Or is lazy loading just lazy loading version lock then?
>
> On Fri, Apr 19, 2013 at 3:06 PM, Michael Brooks
>  wrote:
> > Totally down with this Brian. However, it doesn't exist today and
> > realistically it wouldn't exist before 3.0.0.
> >
> > My proposed versioning allows us have both today and allows us to
> > transition to an independent CLI version in the future.
> >
> > Today, we can reliably track both the Cordova framework version and begin
> > tracking a proper CLI version.
> >
> > Tomorrow, when the grunt-approach exists, we will already have a proper
> CLI
> > version to base off.
> >
> > This does bring up the question of ordering though. If the goal is to
> > decouple the Cordova framework version from the CLI version, then perhaps
> > the CLI version should come first and Cordova framework should come
> second:
> > major.minor.patch+major.minor.patch
> >
> > Example:
> >
> >   1.0.12+2.7.0 === npm module 1.0.12 and Cordova framework 2.7.0
> >
> >
> > On Fri, Apr 19, 2013 at 3:47 PM, Brian LeRoux  wrote:
> >
> >> Cordova CLI has a version that is independent of the Cordova releases.
> >> (Once we decouple the creating of projects from version locking.)
> >>
> >> So I create a project today with Cordova CLI it would use the most
> >> recent release. Lets pretend that's 2.7. Cool. A month later I create
> >> a project with the CLI and its 2.8.
> >>
> >> If I run `cordova -v` it will return the version of the CLI tool and
> >> maybe a notice about the most recent release if I'm not in a project
> >> and the version that project is if I am.
> >>
> >> I'm not sure how Grunt is handling that part but it would be worth
> >> looking into. Basically the CLI is dumb, independently versioned, and
> >> the version of Cordova is a project level concern.
> >>
> >>
> >>
> >> On Fri, Apr 19, 2013 at 2:33 PM, Michael Brooks
> >>  wrote:
> >> >>
> >> >> Why not independently version?
> >> >
> >> >
> >> > Can you elaborate? I don't understand how that work under both the
> >> Cordova
> >> > project and as a consumable npm module.
> >> >
> >> >
> >> > On Fri, Apr 19, 2013 at 3:28 PM, Brian LeRoux  wrote:
> >> >
> >> >> I don't get it. Why not independently version?
> >> >>
> >> >> (I recognize we version lock currently.)
> >> >>
> >> >>
> >> >> On Fri, Apr 19, 2013 at 2:19 PM, Filip Maj  wrote:
> >> >> > Rockin, love it
> >> >> >
> >> >> > On 4/19/13 2:17 PM, "Michael Brooks" 
> >> wrote:
> >> >> >
> >> >> >>Hey all,
> >> >> >>
> >> >> >>I'm planning to change the way we version the Cordova CLI.
> >> >> >>
> >> >> >>TL;DR
> >> >> >>---
> >> >> >>
> >> >> >>  2.7.0+1.0.5  === Cordova 2.7.0 and npm module version 1.0.5
> >> >> >>  2.7.1+1.0.12 === Cordova 2.7.1 and npm module version 1.0.12
> >> >> >>
> >> >> >>Current State
> >> >> >>---
> >> >> >>
> >> >> >>Today, the Cordova CLI uses a major.minor.patch version
> identifiers to
> >> >> >>publish to npm. The major and minor identifiers track the Cordova
> >> >> >>framework
> >> >> >>version, while the patch identifier is reserved for tracking
> Cordova
> >> >> CLI's
> >> >> >>updates.
> >> >> >>
> >> >> >>For example, the current release is 2.6.2. This means it supports
> >> Cordova
> >> >> >>2.6.x and has released two npm version upd

Re: [cordova-cli] npm Version Update

[Michael Brooks]

Totally down with this Brian. However, it doesn't exist today and
realistically it wouldn't exist before 3.0.0.

My proposed versioning allows us have both today and allows us to
transition to an independent CLI version in the future.

Today, we can reliably track both the Cordova framework version and begin
tracking a proper CLI version.

Tomorrow, when the grunt-approach exists, we will already have a proper CLI
version to base off.

This does bring up the question of ordering though. If the goal is to
decouple the Cordova framework version from the CLI version, then perhaps
the CLI version should come first and Cordova framework should come second:
major.minor.patch+major.minor.patch

Example:

  1.0.12+2.7.0 === npm module 1.0.12 and Cordova framework 2.7.0


On Fri, Apr 19, 2013 at 3:47 PM, Brian LeRoux  wrote:

> Cordova CLI has a version that is independent of the Cordova releases.
> (Once we decouple the creating of projects from version locking.)
>
> So I create a project today with Cordova CLI it would use the most
> recent release. Lets pretend that's 2.7. Cool. A month later I create
> a project with the CLI and its 2.8.
>
> If I run `cordova -v` it will return the version of the CLI tool and
> maybe a notice about the most recent release if I'm not in a project
> and the version that project is if I am.
>
> I'm not sure how Grunt is handling that part but it would be worth
> looking into. Basically the CLI is dumb, independently versioned, and
> the version of Cordova is a project level concern.
>
>
>
> On Fri, Apr 19, 2013 at 2:33 PM, Michael Brooks
>  wrote:
> >>
> >> Why not independently version?
> >
> >
> > Can you elaborate? I don't understand how that work under both the
> Cordova
> > project and as a consumable npm module.
> >
> >
> > On Fri, Apr 19, 2013 at 3:28 PM, Brian LeRoux  wrote:
> >
> >> I don't get it. Why not independently version?
> >>
> >> (I recognize we version lock currently.)
> >>
> >>
> >> On Fri, Apr 19, 2013 at 2:19 PM, Filip Maj  wrote:
> >> > Rockin, love it
> >> >
> >> > On 4/19/13 2:17 PM, "Michael Brooks" 
> wrote:
> >> >
> >> >>Hey all,
> >> >>
> >> >>I'm planning to change the way we version the Cordova CLI.
> >> >>
> >> >>TL;DR
> >> >>---
> >> >>
> >> >>  2.7.0+1.0.5  === Cordova 2.7.0 and npm module version 1.0.5
> >> >>  2.7.1+1.0.12 === Cordova 2.7.1 and npm module version 1.0.12
> >> >>
> >> >>Current State
> >> >>---
> >> >>
> >> >>Today, the Cordova CLI uses a major.minor.patch version identifiers to
> >> >>publish to npm. The major and minor identifiers track the Cordova
> >> >>framework
> >> >>version, while the patch identifier is reserved for tracking Cordova
> >> CLI's
> >> >>updates.
> >> >>
> >> >>For example, the current release is 2.6.2. This means it supports
> Cordova
> >> >>2.6.x and has released two npm version updates since Cordova 2.6.0.
> >> >>
> >> >>The Problem
> >> >>---
> >> >>
> >> >>The problem is that this approach to versioning does not accurately
> >> >>represent the Cordova framework or the npm module.
> >> >>
> >> >>When the Cordova framework releases a minor patch, such as Cordova
> 2.6.1,
> >> >>then the npm module cannot represent that update.
> >> >>
> >> >>When the Cordova CLI changes the public module's API, it cannot
> represent
> >> >>it. This would typically be reserved for a major or minor identifier.
> >> >>
> >> >>The Solution
> >> >>---
> >> >>
> >> >>In semantic versioning, the version precedance is as follows [1]:
> >> >>
> >> >>1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-beta.2 < 1.0.0-beta.11 <
> 1.0.0-rc.1 <
> >> >>1.0.0-rc.1+build.1 < 1.0.0 < 1.0.0+0.3.7 < 1.3.7+build <
> >> >>1.3.7+build.2.b8f12d7 < 1.3.7+build.11.e0f985a
> >> >>
> >> >>We can adopt the following scheme to accurately track both the Cordova
> >> >>framework version and the npm version:
> >> >>
> >> >>major.minor.patch+major.minor.patch
> >> >>
> >> >>The first three m.m.p are to track the Cordova framework.
> >> >>The second three m.m.p track the npm module.
> >> >>
> >> >>I would prefer to flip these, but to keep tagging consistent and
> >> backwards
> >> >>compatible, we must keep the Cordova framework as the first three
> >> >>identifies.
> >> >>
> >> >>Examples:
> >> >>
> >> >>  2.7.0-rc.1+1.0.0
> >> >>  2.7.0+1.0.5
> >> >>  2.7.1+1.0.12
> >> >>
> >> >>The Benefits
> >> >>---
> >> >>
> >> >>Now Cordova users know exactly what Cordova version is used by the
> CLI:
> >> >>
> >> >>  2.7.0+1.0.5  === Cordova 2.7.0
> >> >>  2.7.1+1.0.12 === Cordova 2.7.1
> >> >>
> >> >>Now npm module users can rely on semantic versioning (normal node
> >> >>practice):
> >> >>
> >> >>  2.7.0+1.0.5  === Cordova CLI is 1.0.5
> >> >>  2.7.1+1.0.12 === Cordova CLI is 1.0.12
> >> >>  2.7.1+1.1.0 === Cordova CLI is 1.1.0 - sweet, a nice API was added!
> >> >>  2.7.1+2.0.0 === Cordova CLI is 2.0.0 - oh no! my old APIs are
> removed!
> >> >>
> >> >>[1] http://semver.org/ @see 12)
> >> >
> >>
>

Re: [cordova-cli] npm Version Update

[Michael Brooks]

>
> Why not independently version?


Can you elaborate? I don't understand how that work under both the Cordova
project and as a consumable npm module.


On Fri, Apr 19, 2013 at 3:28 PM, Brian LeRoux  wrote:

> I don't get it. Why not independently version?
>
> (I recognize we version lock currently.)
>
>
> On Fri, Apr 19, 2013 at 2:19 PM, Filip Maj  wrote:
> > Rockin, love it
> >
> > On 4/19/13 2:17 PM, "Michael Brooks"  wrote:
> >
> >>Hey all,
> >>
> >>I'm planning to change the way we version the Cordova CLI.
> >>
> >>TL;DR
> >>---
> >>
> >>  2.7.0+1.0.5  === Cordova 2.7.0 and npm module version 1.0.5
> >>  2.7.1+1.0.12 === Cordova 2.7.1 and npm module version 1.0.12
> >>
> >>Current State
> >>---
> >>
> >>Today, the Cordova CLI uses a major.minor.patch version identifiers to
> >>publish to npm. The major and minor identifiers track the Cordova
> >>framework
> >>version, while the patch identifier is reserved for tracking Cordova
> CLI's
> >>updates.
> >>
> >>For example, the current release is 2.6.2. This means it supports Cordova
> >>2.6.x and has released two npm version updates since Cordova 2.6.0.
> >>
> >>The Problem
> >>---
> >>
> >>The problem is that this approach to versioning does not accurately
> >>represent the Cordova framework or the npm module.
> >>
> >>When the Cordova framework releases a minor patch, such as Cordova 2.6.1,
> >>then the npm module cannot represent that update.
> >>
> >>When the Cordova CLI changes the public module's API, it cannot represent
> >>it. This would typically be reserved for a major or minor identifier.
> >>
> >>The Solution
> >>---
> >>
> >>In semantic versioning, the version precedance is as follows [1]:
> >>
> >>1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 <
> >>1.0.0-rc.1+build.1 < 1.0.0 < 1.0.0+0.3.7 < 1.3.7+build <
> >>1.3.7+build.2.b8f12d7 < 1.3.7+build.11.e0f985a
> >>
> >>We can adopt the following scheme to accurately track both the Cordova
> >>framework version and the npm version:
> >>
> >>major.minor.patch+major.minor.patch
> >>
> >>The first three m.m.p are to track the Cordova framework.
> >>The second three m.m.p track the npm module.
> >>
> >>I would prefer to flip these, but to keep tagging consistent and
> backwards
> >>compatible, we must keep the Cordova framework as the first three
> >>identifies.
> >>
> >>Examples:
> >>
> >>  2.7.0-rc.1+1.0.0
> >>  2.7.0+1.0.5
> >>  2.7.1+1.0.12
> >>
> >>The Benefits
> >>---
> >>
> >>Now Cordova users know exactly what Cordova version is used by the CLI:
> >>
> >>  2.7.0+1.0.5  === Cordova 2.7.0
> >>  2.7.1+1.0.12 === Cordova 2.7.1
> >>
> >>Now npm module users can rely on semantic versioning (normal node
> >>practice):
> >>
> >>  2.7.0+1.0.5  === Cordova CLI is 1.0.5
> >>  2.7.1+1.0.12 === Cordova CLI is 1.0.12
> >>  2.7.1+1.1.0 === Cordova CLI is 1.1.0 - sweet, a nice API was added!
> >>  2.7.1+2.0.0 === Cordova CLI is 2.0.0 - oh no! my old APIs are removed!
> >>
> >>[1] http://semver.org/ @see 12)
> >
>

[cordova-cli] npm Version Update

[Michael Brooks]

Hey all,

I'm planning to change the way we version the Cordova CLI.

TL;DR
---

  2.7.0+1.0.5  === Cordova 2.7.0 and npm module version 1.0.5
  2.7.1+1.0.12 === Cordova 2.7.1 and npm module version 1.0.12

Current State
---

Today, the Cordova CLI uses a major.minor.patch version identifiers to
publish to npm. The major and minor identifiers track the Cordova framework
version, while the patch identifier is reserved for tracking Cordova CLI's
updates.

For example, the current release is 2.6.2. This means it supports Cordova
2.6.x and has released two npm version updates since Cordova 2.6.0.

The Problem
---

The problem is that this approach to versioning does not accurately
represent the Cordova framework or the npm module.

When the Cordova framework releases a minor patch, such as Cordova 2.6.1,
then the npm module cannot represent that update.

When the Cordova CLI changes the public module's API, it cannot represent
it. This would typically be reserved for a major or minor identifier.

The Solution
---

In semantic versioning, the version precedance is as follows [1]:

1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 <
1.0.0-rc.1+build.1 < 1.0.0 < 1.0.0+0.3.7 < 1.3.7+build <
1.3.7+build.2.b8f12d7 < 1.3.7+build.11.e0f985a

We can adopt the following scheme to accurately track both the Cordova
framework version and the npm version:

major.minor.patch+major.minor.patch

The first three m.m.p are to track the Cordova framework.
The second three m.m.p track the npm module.

I would prefer to flip these, but to keep tagging consistent and backwards
compatible, we must keep the Cordova framework as the first three
identifies.

Examples:

  2.7.0-rc.1+1.0.0
  2.7.0+1.0.5
  2.7.1+1.0.12

The Benefits
---

Now Cordova users know exactly what Cordova version is used by the CLI:

  2.7.0+1.0.5  === Cordova 2.7.0
  2.7.1+1.0.12 === Cordova 2.7.1

Now npm module users can rely on semantic versioning (normal node practice):

  2.7.0+1.0.5  === Cordova CLI is 1.0.5
  2.7.1+1.0.12 === Cordova CLI is 1.0.12
  2.7.1+1.1.0 === Cordova CLI is 1.1.0 - sweet, a nice API was added!
  2.7.1+2.0.0 === Cordova CLI is 2.0.0 - oh no! my old APIs are removed!

[1] http://semver.org/ @see 12)

[cordova-docs] Referencing Latest Version in Edge

[Michael Brooks]

Hey all,

We've been having conflicts with referencing the next version in the edge
documentation.

>From now on, the edge documentation should reference the next version as
"x.x.x".

On each release, the release script will find & replace "x.x.x" with the
released version.

For example:

  - "cordova-x.x.x.js" becomes "cordova-2.7.0.js"
  - "Cordova x.x.x" becomes "Cordova 2.7.0"
  - "Getting Started with x.x.x" becomes "Getting Started with 2.7.0"

The JIRA issue around this is: CB-3192 [1]

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

Re: 2.7 for Adobe Max?

[Michael Brooks]

Sure Andrew. Alternatively, you can update the WIki to references the
README.md section.

Personally, I like keeping the release instructions with the project source
code. I know others have different opinions on that.

Michael


On Thu, Apr 18, 2013 at 3:04 PM, Andrew Grieve  wrote:

> Michael also pointed out that there are also release time instructions in
> cordova-app-hello-world's README.md file.
>
> I'd like to move these to the wiki as well.
>
>
> On Thu, Apr 18, 2013 at 4:16 PM, Andrew Grieve 
> wrote:
>
> > Good catch. I did update the version for cordova-js.
> >
> > Incrementing the version is in the Android release checklist on the wiki,
> > but it's not in the list of JIRA sub-tasks. I also failed to update
> release
> > notes.
> >
> > I think I actually like it better on the wiki, and maybe we can just
> point
> > to the wiki from the generate JIRA task?
> > I would put "updating JS" and "copying hello world app" under the same
> > category. They should be on the wiki and not as JIRA issues.
> >
> > Sound alright? If so, I'll make the changes.
> >
> >
> > On Thu, Apr 18, 2013 at 4:08 PM, Joe Bowser  wrote:
> >
> >> Remember to increment the versions.  I had to re-tag on Android
> >> because the version wasn't incremented.  Did it get incremented on
> >> cordova-js?  If not, we'll have to re-tag again.
> >>
> >> On Thu, Apr 18, 2013 at 12:49 PM, Andrew Grieve 
> >> wrote:
> >> > Also wanted to remind that we can still re-tag, but should not be
> doing
> >> any
> >> > merges between branches. Cherry-picks only.
> >> >
> >> >
> >> > On Thu, Apr 18, 2013 at 3:45 PM, Andrew Grieve 
> >> wrote:
> >> >
> >> >> Alrighty!
> >> >>
> >> >> Thanks Joe for creating the JIRA issues!
> >> >>
> >> >> What I just did:
> >> >> - branched & tagged cordova-js.
> >> >> - closed all of the sample-app issues after merging it into iOS
> showed
> >> >> there to be no changes.
> >> >> - for Android & iOS: updated the JS, branched & tagged
> >> >> - updated the CuttingReleases wiki page (still had the old
> master/next
> >> >> system on it)
> >> >>
> >> >> I haven't run mobile spec at all yet (did run the iOS unit tests
> >> though).
> >> >>
> >> >> I'm going to spend some time looking at CB-2698 before doing any
> mobile
> >> >> spec testing. Feel free to follow the master bug to see what else
> needs
> >> >> doing:
> >> >>
> >> >> https://issues.apache.org/jira/browse/CB-3072
> >> >>
> >> >> Andrew
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> On Thu, Apr 18, 2013 at 11:20 AM, Andrew Grieve <
> agri...@chromium.org
> >> >wrote:
> >> >>
> >> >>> New goal - let's aim for today!
> >> >>>
> >> >>>
> >> >>> I'd like to take a look and at CB-2698, but since this is
> iOS-specific
> >> >>> (and native-code only), I'll go ahead with creating issues &
> >> branching the
> >> >>> JS. If CB-2698 gets fixed, we can cherry-pick it.
> >> >>>
> >> >>>
> >> >>> On Tue, Apr 16, 2013 at 2:45 PM, Giorgio Natili <
> >> g.nat...@gnstudio.com>wrote:
> >> >>>
> >>  +1
> >> 
> >>  On 4/16/13 7:52 PM, "Filip Maj"  wrote:
> >> 
> >>  >+1.
> >>  >
> >>  >So, how do we feel about starting an RC soon?
> >>  >
> >>  >On 4/16/13 10:19 AM, "Brian LeRoux"  wrote:
> >>  >
> >>  >>It would be ideal to see 2.7 ship before the month is out for
> sure.
> >>  >>
> >>  >>
> >>  >>On Tue, Apr 16, 2013 at 7:41 AM, Joe Bowser 
> >> wrote:
> >>  >>
> >>  >>> I think that this would be a good thing.  It'd be nice to get a
> >>  >>> released lined up for Conf-Month! (Adobe Max, Google IO,
> JSConf,
> >>  etc).
> >>  >>>
> >>  >>> On Tue, Apr 16, 2013 at 7:35 AM, Andrew Grieve <
> >> agri...@chromium.org
> >>  >
> >>  >>> wrote:
> >>  >>> > Wanted to see what people thought of trying to get 2.7 out
> the
> >> door
> >>  >>>in
> >>  >>> time
> >>  >>> > for Adobe Max. The main motivation I see is to have a version
> >> that
> >>  >>>will
> >>  >>> > work the "future" branch of CLI. 2.6 is missing the
> >>  plugin_loader.js
> >>  >>>code
> >>  >>> > required to load a plugin's JS.
> >>  >>>
> >>  >
> >> 
> >> 
> >> 
> >> >>>
> >> >>
> >>
> >
> >
>

Re: Making WebView's WebSQL work on Android 3.0+

[Michael Brooks]

Thanks for the details Ian.

In our experience, by-passing CORS policies is a HUGE bonus for most
developers. It would be rad if you can find a nice hackity-hack to get
around this so that we can also take advantage of WebSQL :)

Michael


On Wed, Apr 17, 2013 at 12:50 PM, Joe Bowser  wrote:

> So, there isn't a CORS issue with Android?
>
> On Wed, Apr 17, 2013 at 11:41 AM, Ian Clelland 
> wrote:
> > Specifically with iOS, setting the start page to a chrome-extension://
> url
> > causes the underlying UIWebView to apply CORS policies to all XHR
> requests.
> >
> > UIWebView seems to use the same restrictions as desktop Safari:
> >- Requests coming from file:/// urls do not use the Origin header
> >- Requests coming from other schemes (such as chrome-extension://)
> have
> > an Origin header applied, and the UIWebView validates the
> Access-Control-*
> > headers in the response.
> >
> > In practice, this means that when we make an XHR to an origin server
> which
> > doesn't support CORS, the response is rejected by the UIWebView, and the
> > XHR completes with an error.
> >
> > (I'm looking at a couple of ways to work around this; hopefully we don't
> > have to go as far as replacing the HTTP stack on iOS now, too)
> >
> > Ian
> >
> >
> > On Wed, Apr 17, 2013 at 1:34 PM, Michal Mocny 
> wrote:
> >
> >> Ian has been running into some issues with CORS while working on
> porting an
> >> app, I'll let him comment on specifics.
> >>
> >>
> >> On Wed, Apr 17, 2013 at 12:27 PM, Michael Brooks
> >> wrote:
> >>
> >> > Very cool Andrew. Does this affect the cross-origin policy? Many users
> >> > exploit the ability to make requests across multiple domains.
> >> >
> >> > Michael
> >> >
> >> >
> >> > On Wed, Apr 17, 2013 at 8:35 AM, Andrew Grieve 
> >> > wrote:
> >> >
> >> > > Just tried it with:
> >> > >
> >> > > chrome-extension://asdf/chromeapp.html?foo:1?#asdf?ds#af:s
> >> > >
> >> > > Had to make a slight tweak to IceCreamCordovaWebViewClient, but it
> >> worked
> >> > > fine.
> >> > >
> >> > >
> >> > > On Wed, Apr 17, 2013 at 12:39 AM, Joe Bowser 
> >> wrote:
> >> > >
> >> > > > How does this affect URI handling?  We've had far bigger issues
> with
> >> > > > file:///android-asset failing on ICS+.  Did you test with URIs
> that
> >> > > contain
> >> > > > a question mark, pound or a colon?
> >> > > >
> >> > > > On Apr 16, 2013 7:23 PM, "Andrew Grieve" 
> >> wrote:
> >> > > >
> >> > > >> Found a juicy hack that works around the webview disabling WebSQL
> >> for
> >> > > >> file: URLs.
> >> > > >>
> >> > > >> For our Chrome Apps plugins, we serve apps from
> chrome-extension://
> >> > URLs
> >> > > >> instead of file:// URLs. This is possible via
> >> > shouldInterceptRequest(),
> >> > > >> where we just map the requests to the files.
> >> > > >>
> >> > > >> So... I had the idea to test the WebSQL mobile-spec tests under
> this
> >> > > >> scheme (while disabling Android's custom WebSQL work-around),
> and it
> >> > > seemed
> >> > > >> to work fine.
> >> > > >>
> >> > > >> I think that this means that we could change Cordova app urls to
> be
> >> > > >> cordova:// (for ICS+), and could then delete the storage plugin.
> >> > > >>
> >> > > >> What do you think?
> >> > > >>
> >> > > >
> >> > >
> >> >
> >>
>

Re: Making WebView's WebSQL work on Android 3.0+

[Michael Brooks]

Very cool Andrew. Does this affect the cross-origin policy? Many users
exploit the ability to make requests across multiple domains.

Michael


On Wed, Apr 17, 2013 at 8:35 AM, Andrew Grieve  wrote:

> Just tried it with:
>
> chrome-extension://asdf/chromeapp.html?foo:1?#asdf?ds#af:s
>
> Had to make a slight tweak to IceCreamCordovaWebViewClient, but it worked
> fine.
>
>
> On Wed, Apr 17, 2013 at 12:39 AM, Joe Bowser  wrote:
>
> > How does this affect URI handling?  We've had far bigger issues with
> > file:///android-asset failing on ICS+.  Did you test with URIs that
> contain
> > a question mark, pound or a colon?
> >
> > On Apr 16, 2013 7:23 PM, "Andrew Grieve"  wrote:
> >
> >> Found a juicy hack that works around the webview disabling WebSQL for
> >> file: URLs.
> >>
> >> For our Chrome Apps plugins, we serve apps from chrome-extension:// URLs
> >> instead of file:// URLs. This is possible via shouldInterceptRequest(),
> >> where we just map the requests to the files.
> >>
> >> So... I had the idea to test the WebSQL mobile-spec tests under this
> >> scheme (while disabling Android's custom WebSQL work-around), and it
> seemed
> >> to work fine.
> >>
> >> I think that this means that we could change Cordova app urls to be
> >> cordova:// (for ICS+), and could then delete the storage plugin.
> >>
> >> What do you think?
> >>
> >
>

Re: Spam control in the Wiki

[Michael Brooks]

Yep I can edit, thanks Shaz!


On Tue, Apr 16, 2013 at 3:14 PM, Brian LeRoux  wrote:

> ya no kidding
>
>
> On Tue, Apr 16, 2013 at 2:46 PM, Anis KADRI  wrote:
>
> > That's cool! I was getting tired of googling every apache conference
> since
> > 1970.
> >
> >
> > On Tue, Apr 16, 2013 at 2:42 PM, Filip Maj  wrote:
> >
> > > Yep works! Thanks shaz
> > >
> > > also: no more super annoying "what city was apache con 2004 held in?"
> > > questions. Double-win.
> > >
> > > On 4/16/13 2:39 PM, "Shazron"  wrote:
> > >
> > > >Ok, I've added
> > > >- FilMaj
> > > >- AndrewGrieve
> > > >- MichaelBrooks
> > > >
> > > >to the AdminGroup, please test whether you can edit.
> > > >
> > > >For the others, please reply with your wiki usernames so I can add
> > you...
> > > >
> > > >
> > > >
> > > >On Tue, Apr 16, 2013 at 10:14 AM, Shazron  wrote:
> > > >
> > > >> Nope, still no access :(
> > > >> I re-opened https://issues.apache.org/jira/browse/INFRA-6131
> > > >>
> > > >>
> > > >> On Tue, Apr 16, 2013 at 12:07 AM, Jukka Zitting
> > > >>wrote:
> > > >>
> > > >>> Hi,
> > > >>>
> > > >>> On Mon, Apr 15, 2013 at 9:51 PM, Shazron 
> wrote:
> > > >>> > But there is still a problem - I don't have access to these pages
> > to
> > > >>>add
> > > >>> > people:
> > > >>> > - http://wiki.apache.org/cordova/ContributorsGroup
> > > >>> > - http://wiki.apache.org/cordova/AdminGroup
> > > >>> >
> > > >>> > Thus, I think no one can edit/add any pages to the wiki at the
> > > >>>moment.
> > > >>> >
> > > >>> > I assume Jukka will have to add at least one of us to get the
> ball
> > > >>> rolling?
> > > >>>
> > > >>> I don't have access either.
> > > >>>
> > > >>> Perhaps there was a typo when infra added your account to the
> > > >>> AdminGroup? Recheck to verify that you're logged in when accessing
> > > >>> http://wiki.apache.org/cordova/AdminGroup (you should see
> > > >>> ShazronAbdullah at the top of the page), and reopen INFRA-6131 if
> it
> > > >>> still doesn't work.
> > > >>>
> > > >>> BR,
> > > >>>
> > > >>> Jukka Zitting
> > > >>>
> > > >>
> > > >>
> > >
> > >
> >
>

Re: New directory structure in cordova-cli's future branch

[Michael Brooks]

I'm still not sold on the new directory structure, but I would need to
review the previous thread on why we are interested in adopting it.

A minor concern on my part is the placement of `config.xml`.

The path to `index.html` must be referenced relative to `config.xml` [1].
Since `config.xml` is outside of www/ the the default  path [2]
must become "www/index.html", which is breaking the default start path
defined by the Widget spec.

I'm not sure which platform's support the  element, but BlackBerry
does and I imagine we will have full coverage in the future.

However, this also brings up the question of whether we are continuing with
the Widget spec or supporting the SysApps work. Fil will have more insight
into this when we gets back from the SysApps F2F.

[1] http://www.w3.org/TR/widgets/#start-files
[2] http://www.w3.org/TR/widgets/#the-content-element-and-its-attributes

Michael



On Tue, Apr 9, 2013 at 11:51 AM, Braden Shepherdson wrote:

> That's now how I recalled the discussion. It certainly wasn't clear-cut,
> but I thought the conclusion was that this was fine.
>
> Well, then this is now a discussion thread. What are the counterarguments?
>
> Braden
>
>
> On Tue, Apr 9, 2013 at 2:49 PM, Brian LeRoux  wrote:
>
> > :(
> >
> > We never had full consensus to do this Braden.
> >
> > On Tuesday, April 9, 2013, Filip Maj wrote:
> >
> > > For a couple months now the npm package has had about 1000 downloads
> per
> > > month [1].
> > >
> > > We do have upgrade guides in our docs for each version for each
> platform.
> > > Maybe we could add a CLI section? Then we can reference those guides in
> > > the CLI's readme? Just thinking out loud.
> > >
> > > [1] http://npmjs.org/package/cordova
> > >
> > > On 4/9/13 5:40 PM, "Braden Shepherdson"  > >
> > > wrote:
> > >
> > > >This mailing list post is, or will shortly be, indexed by Google and
> > > >others. Any newcomers will see the new docs and create new projects.
> > > >
> > > >As I mentioned on IRC, existing users are either accepting or ignoring
> > the
> > > >"alpha" warnings that this software is new and under heavy
> development,
> > > >and
> > > > if they want to jump on it early they're going to have to expect some
> > > >pain.
> > > >
> > > >That said, I don't really know of any better way to socialize it. Is
> > there
> > > >anywhere where a brief blog post on this would make sense?
> > > >
> > > >I don't know how many people are using these tools and not on the
> > mailing
> > > >list, though certainly some turn up on IRC occasionally.
> > > >
> > > >Braden
> > > >
> > > >
> > > >On Tue, Apr 9, 2013 at 11:24 AM, Filip Maj  >
> > > wrote:
> > > >
> > > >> How will we communicate this change to our existing users?
> > > >>
> > > >> On 4/9/13 5:22 PM, "Braden Shepherdson"  > >
> > > wrote:
> > > >>
> > > >> >I've just pushed a change to the future branch that changes the
> > > >>directory
> > > >> >structure to:
> > > >> >
> > > >> >app/
> > > >> >merges/
> > > >> >android/
> > > >> >ios/
> > > >> >www/
> > > >> >config.xml
> > > >> >
> > > >> >As was discussed at our video conference meeting a couple of weeks
> > ago,
> > > >> >this has a number of advantages:
> > > >> >- config.xml is no longer in the www/ directory
> > > >> >- One can easily version control the whole app/ directory, and get
> > > >>their
> > > >> >web assets, merges and so on into the repo.
> > > >> >- That repo can contain additional information: a README.md,
> > > >>supplementary
> > > >> >documentation, tests, whatever. The CLI will ignore anything
> outside
> > of
> > > >> >the
> > > >> >merges and www directories.
> > > >> >
> > > >> >
> > > >> >The downside is that this is a breaking change: running the new
> > > >>version of
> > > >> >the tools on an old project will fail (but I think in a harmless
> way)
> > > >> >until
> > > >> >you rearrange the directories. You can do that with the following
> > > >> >commands:
> > > >> >
> > > >> >$ mkdir app
> > > >> >$ mv www/config.xml app
> > > >> >$ mv www app
> > > >> >$ mv merges app
> > > >> >
> > > >> >All docs and tests are updated as well. Any problems should be
> > > >>reported on
> > > >> >JIRA and assigned to me.
> > > >> >
> > > >> >Braden
> > > >>
> > > >>
> > >
> > >
> >
>

Re: Platform-level command line scripts ;)

[Michael Brooks]

>
> Augh! This actually made it past the mailing list. :(

 ...

> +1 for the dislike :P but users will tell us if they like having 12 scripts
> laying around.


They are only assigned issues. If you guys have concerns, bring them up.
There is little point in committing to work if it isn't valuable to our
users.

On that note, Benn and I noticed a recent issue with the `run` command.
Since `run` will implicitly build an application, it must accept the build
mode flag `--debug` or `--release`. In other words, it should accept all
parameters that `build` accepts and forward the valid ones to the `build`
command. This should be true for any high-level command.

Anyone have input on the `run` command? Once settled, we'll update the Wiki
and issue details.

Michael


On Tue, Apr 9, 2013 at 11:47 AM, Anis KADRI  wrote:

> +1 for the dislike :P but users will tell us if they like having 12 scripts
> laying around.
>
>
> On Tue, Apr 9, 2013 at 11:38 AM, Joe Bowser  wrote:
>
> > Augh! This actually made it past the mailing list. :(
> >
> > I hate this idea for the emulators and devices, because this is a set
> > of extremely complex script that has next to zero payoff for our
> > users.  I really wish I paid more attention to this thread earlier on,
> > because I really don't like these scripts.  I guess it's too late to
> > vote a -1 against these, and I guess it's my fault for ignoring things
> > I really dislike.
> >
> > Joe
> >
> > On Tue, Apr 9, 2013 at 7:46 AM, Filip Maj  wrote:
> > > FYI issues for all of these scripts have been filed.
> > >
> > > On 3/28/13 1:31 PM, "Michael Brooks"  wrote:
> > >
> > >>Fil, great work on the wiki document. Below are some feedback points.
> > >>
> > >>
> > >>> `build`
> > >>
> > >>...
> > >>
> > >>What happens when a user specifies both --debug and --release?
> > >>
> > >>
> > >>I'm happy as long as we decide on what happens. For the sake of ease, I
> > >>think it would be better to just fail.
> > >>
> > >>This brings up the question of exit codes. I don't want to over
> engineer,
> > >>but should we distinguish between an exit code for an "unsupported
> > >>command"
> > >>and "runtime command error" (e.g. unsupported argument combination)? As
> > >>long as there is a message with the exit code, it's not necessary but
> > >>could
> > >>provide a good hint to higher-level tools.
> > >>
> > >>`run [--target=]`
> > >>
> > >>
> > >>I like the term `run` and how it will implicitly invokes `build` when
> > >>necessary. This will be the go-to command for most developers.
> > >>
> > >>`list-emulator-images`
> > >>> ...
> > >>> `list-started-emulators`
> > >>> ...
> > >>> `list-devices`
> > >>
> > >>
> > >>The listing format is: "ID: DESCRIPTION". What will it look like when
> no
> > >>description is provided? "ID" or "ID:"?
> > >>
> > >>Is it possible to remove the colon entirely and delimit on a space? "ID
> > >>DESCRIPTION" and "ID"
> > >>
> > >>`deploy-emulator`
> > >>> ...
> > >>> `deploy-device`
> > >>
> > >>
> > >>Deploy is a confusing term because it's too similar to "run." Even both
> > >>command definitions use the term "deploy."
> > >>
> > >>I'd like to propose renaming the deploy commands to: `install-emulator`
> > >>and
> > >>`install-device`.
> > >>
> > >>Install more clearly describes the action and implies that it does not
> > >>implicitly build first.
> > >>
> > >>Again, awesome work Fil!
> > >>Michael
> > >>
> > >>On Tue, Mar 26, 2013 at 4:16 PM, Filip Maj  wrote:
> > >>
> > >>> Thanks Shaz, updated the wiki article.
> > >>>
> > >>> On 3/26/13 4:07 PM, "Shazron"  wrote:
> > >>>
> > >>> >* log is only the Simulator
> > >>> >* build release/debug -- last one clobbers? depending on how the
> > >>>parsing
> > >>> >is
> > >>> >implemented
> > >>> >
> > >>> >

Re: Use of Google Docs for Planning / Specifications / etc

[Michael Brooks]

>
> My main problem is starting a proposal or draft on a website to begin
> with. The initial discussion, in my mind, should be done on the list in
> email form, so the apache archives have a clear record of how a discussion
> about a new proposal or feature has evolved.


This summaries that main concern. It's not being too lazy to click a link
or communication of revisions. It's that in 5 years from now, the Cordova
project will have lost and gained contributors, but the evolution of each
proposal will still be accessible because it has been captured
and archived by Apache's Infrastructure.




On Fri, Apr 5, 2013 at 11:59 AM, Filip Maj  wrote:

> My main problem is starting a proposal or draft on a website to begin
> with. The initial discussion, in my mind, should be done on the list in
> email form, so the apache archives have a clear record of how a discussion
> about a new proposal or feature has evolved.
>
> So instead of "here's my proposal: link", it would be "here's my proposal:
> text dump from the link"
>
> In terms of documenting the proposal as it evolves from the list, I don't
> care whether it's in Gdocs or in the wiki.
>
> On 4/5/13 11:56 AM, "Michal Mocny"  wrote:
>
> >-1, but hey, what can you do..
> >
> >I guess that if we don't like opening links, then we will be consuming
> >wiki
> >doc proposals via the wiki-update emails that go out?  Also, since it
> >emails for each patch, perhaps update the wiki with as few commits as
> >possible, including when making comments, and ideally without causing edit
> >conflicts with others editing.  Shish, good luck.
> >
> >-Michal
> >
> >On Fri, Apr 5, 2013 at 2:36 PM, tommy-carlos Williams
> >wrote:
> >
> >> +1
> >>
> >> Guiltily admitting to being in the not-opening boat with Fil :/
> >>
> >> On 06/04/2013, at 4:22, Filip Maj  wrote:
> >>
> >> > +1, it's a bad excuse on my side but the extra step in opening the
> >>link
> >> is
> >> > sometimes enough to discourage me from even looking at proposals :P
> >> >
> >> > On 4/5/13 10:18 AM, "Michael Brooks" 
> wrote:
> >> >
> >> >> Hey guys,
> >> >>
> >> >> I know this has been on the minds of a number of contributors and I
> >>want
> >> >> to
> >> >> bring it up on the list.
> >> >>
> >> >> I think we need to stop using Google Docs for drafting our plans,
> >> >> specifications, and such.
> >> >>
> >> >> For myself, this is a little disappointing because I like Google Docs
> >> and
> >> >> I
> >> >> think it's easy to comment and amend the document. However, the data
> >>is
> >> >> not
> >> >> hosted by Apache Infrastructure and the changes are not captured on
> >>the
> >> >> source control, mailing list, issue tracker, or wiki. In other words,
> >> it's
> >> >> side stepping the regular channels that contributors would monitor.
> >> >>
> >> >> For future documents, we should be using the wiki. The wiki does
> >>support
> >> >> rendering comments [1], so we can achieve the same effect as Google
> >> >> Docs...
> >> >> just in a more awkward way.
> >> >>
> >> >> Thoughts? If someone can make a compelling case to keep using Google
> >> Docs,
> >> >> I'm all ears.
> >> >>
> >> >> Michael
> >> >>
> >> >> [1] http://wiki.apache.org/cordova/HelpOnComments
> >> >
> >>
>
>

Use of Google Docs for Planning / Specifications / etc

[Michael Brooks]

Hey guys,

I know this has been on the minds of a number of contributors and I want to
bring it up on the list.

I think we need to stop using Google Docs for drafting our plans,
specifications, and such.

For myself, this is a little disappointing because I like Google Docs and I
think it's easy to comment and amend the document. However, the data is not
hosted by Apache Infrastructure and the changes are not captured on the
source control, mailing list, issue tracker, or wiki. In other words, it's
side stepping the regular channels that contributors would monitor.

For future documents, we should be using the wiki. The wiki does support
rendering comments [1], so we can achieve the same effect as Google Docs...
just in a more awkward way.

Thoughts? If someone can make a compelling case to keep using Google Docs,
I'm all ears.

Michael

[1] http://wiki.apache.org/cordova/HelpOnComments

Re: App-Harness Description

[Michael Brooks]

Thanks Andrew!


On Tue, Apr 2, 2013 at 5:57 PM, Andrew Grieve  wrote:

> Fastest Yet! Repo is created:
> https://git-wip-us.apache.org/repos/asf/cordova-app-harness.git
>
>
> On Tue, Apr 2, 2013 at 8:39 PM, Andrew Grieve 
> wrote:
>
> > INFRA ticket filed!
> >
> > https://issues.apache.org/jira/browse/INFRA-6103
> >
> >
> >
> >
> > On Tue, Apr 2, 2013 at 1:30 PM, Filip Maj  wrote:
> >
> >> Fineee. +1 harness.
> >>
> >> I'll save WebKeg for another day!
> >>
> >> On 4/1/13 4:40 PM, "Lorin Beer"  wrote:
> >>
> >> >while some truly excellent names have been suggested, I'll +1 harness.
> >> Fil
> >> >will just have to wait for a project named "WebKeg".
> >> >
> >> >
> >> >On Mon, Apr 1, 2013 at 9:05 AM, Michael Brooks
> >> >wrote:
> >> >
> >> >> You also get a Google app based on Cordova's Harness app. Open
> source!
> >> >>:)
> >> >>
> >> >> The general consensus seems to be the name "Harness."
> >> >>
> >> >> Any complaints with...?
> >> >>
> >> >> - repository name: cordova-app-harness
> >> >> - discuss name: Cordova App Harness
> >> >>
> >> >> Michael
> >> >>
> >> >>
> >> >> On Mon, Apr 1, 2013 at 3:11 AM, Giorgio Natili <
> g.nat...@gnstudio.com
> >> >> >wrote:
> >> >>
> >> >> > Makes sense, it means we will get an Adobe app based upon the
> harness
> >> >> > one... Cool!
> >> >> >
> >> >> > On 4/1/13 7:40 AM, "Brian LeRoux"  wrote:
> >> >> >
> >> >> > >There should be no PhoneGap in the name.
> >> >> > >
> >> >> > >There will be a PhoneGap app based on the Cordova code (as there
> is
> >> >>with
> >> >> > >the distribution).
> >> >> > >
> >> >> > >Make sense?
> >> >> > >
> >> >> > >On Sunday, March 31, 2013, Giorgio Natili wrote:
> >> >> > >
> >> >> > >> I prefer cordova-harness too but right now cordova is less known
> >> >>that
> >> >> > >> PhoneGap. Do you think that a name like cordova-phonegap-harness
> >> >> should
> >> >> > >>be
> >> >> > >> too long?
> >> >> > >>
> >> >> > >> Giorgio
> >> >> > >>
> >> >> > >> On 3/29/13 1:40 AM, "Simon MacDonald" <
> simon.macdon...@gmail.com>
> >> >> > wrote:
> >> >> > >>
> >> >> > >> >I prefer cordova-harness to cordova-app myself.
> >> >> > >> >Simon Mac Donald
> >> >> > >> >http://hi.im/simonmacdonald
> >> >> > >> >
> >> >> > >> >
> >> >> > >> >On Thu, Mar 28, 2013 at 8:37 PM, Michal Mocny
> >> >>
> >> >> > >> wrote:
> >> >> > >> >> FWIW, I dont think thats a good idea.  Will likely lead to
> >> >> ambiguity
> >> >> > >> >> between "a cordova app" and "the cordova-app", not to mention
> >> >> > >> >>googleability.
> >> >> > >> >>
> >> >> > >> >> Sorry, but I don't have any awesome suggestions, but I
> thought
> >> >> > >> >> cordova-harness was fine.
> >> >> > >> >>
> >> >> > >> >> -Michal
> >> >> > >> >>
> >> >> > >> >>
> >> >> > >> >> On Thu, Mar 28, 2013 at 5:56 PM, Brian LeRoux 
> >> >>wrote:
> >> >> > >> >>
> >> >> > >> >>> cordova-app sounds good to me
> >> >> > >> >>>
> >> >> > >> >>> On Thu, Mar 28, 2013 at 2:45 PM, Andrew Grieve
> >> >> > >>
> >> >> > >> >>> wrote:
> >> >> > >> >>> > I don't think we need to decide on an App Store name yet.
> >>

Re: Work on the VHS api

[Michael Brooks]

Apache Cordova can only be considered a success when we have "complete
support for uploading cat videos to online video services."


On Mon, Apr 1, 2013 at 11:38 AM, Shazron  wrote:

> I think it's appropriate for HTML6
>
>
> On Mon, Apr 1, 2013 at 11:32 AM, Joe Bowser  wrote:
>
> > Hey
> >
> > I really think that we should add this to Cordova ASAP.  Think we can
> > get it into the 2.6 release?
> >
> > http://darktears.fr/vcr-api/Overview.html
> >
>

Re: App-Harness Description

[Michael Brooks]

You also get a Google app based on Cordova's Harness app. Open source! :)

The general consensus seems to be the name "Harness."

Any complaints with...?

- repository name: cordova-app-harness
- discuss name: Cordova App Harness

Michael


On Mon, Apr 1, 2013 at 3:11 AM, Giorgio Natili wrote:

> Makes sense, it means we will get an Adobe app based upon the harness
> one... Cool!
>
> On 4/1/13 7:40 AM, "Brian LeRoux"  wrote:
>
> >There should be no PhoneGap in the name.
> >
> >There will be a PhoneGap app based on the Cordova code (as there is with
> >the distribution).
> >
> >Make sense?
> >
> >On Sunday, March 31, 2013, Giorgio Natili wrote:
> >
> >> I prefer cordova-harness too but right now cordova is less known that
> >> PhoneGap. Do you think that a name like cordova-phonegap-harness should
> >>be
> >> too long?
> >>
> >> Giorgio
> >>
> >> On 3/29/13 1:40 AM, "Simon MacDonald" 
> wrote:
> >>
> >> >I prefer cordova-harness to cordova-app myself.
> >> >Simon Mac Donald
> >> >http://hi.im/simonmacdonald
> >> >
> >> >
> >> >On Thu, Mar 28, 2013 at 8:37 PM, Michal Mocny 
> >> wrote:
> >> >> FWIW, I dont think thats a good idea.  Will likely lead to ambiguity
> >> >> between "a cordova app" and "the cordova-app", not to mention
> >> >>googleability.
> >> >>
> >> >> Sorry, but I don't have any awesome suggestions, but I thought
> >> >> cordova-harness was fine.
> >> >>
> >> >> -Michal
> >> >>
> >> >>
> >> >> On Thu, Mar 28, 2013 at 5:56 PM, Brian LeRoux  wrote:
> >> >>
> >> >>> cordova-app sounds good to me
> >> >>>
> >> >>> On Thu, Mar 28, 2013 at 2:45 PM, Andrew Grieve
> >>
> >> >>> wrote:
> >> >>> > I don't think we need to decide on an App Store name yet. Repo
> >>name
> >> >>> sounds
> >> >>> > good though.
> >> >>> >
> >> >>> > On Thu, Mar 28, 2013 at 4:40 PM, Michael Brooks <
> >> >>> mich...@michaelbrooks.ca>wrote:
> >> >>> >
> >> >>> >> Alright, I want to get this project started and we need to settle
> >> >>>on a
> >> >>> >> name.
> >> >>> >>
> >> >>> >> No one has made a compelling argument against calling the app
> >> >>>"Cordova."
> >> >>> >>
> >> >>> >> Proposed name:
> >> >>> >>
> >> >>> >> - App Store name: "Cordova"
> >> >>> >> - Repository name: "cordova-app"
> >> >>> >>
> >> >>> >> Here are my reasons:
> >> >>> >>
> >> >>> >> 1. We naturally refer to it as "The Cordova App" in casual
> >> >>>discussion
> >> >>> >>
> >> >>> > We haven't though. Sounds quite ambiguous to me since Cordova is a
> >> >>> > framework for building apps. "The Cordova App" --> which Cordova
> >>app?
> >> >>> >
> >> >>> >
> >> >>> >> 2. There are no plans for any other app, making this "The Cordova
> >> >>>App."
> >> >>> >>
> >> >>> > There already exist a bunch of similar apps by other people the.
> >>E.g.
> >> >>> > "Cordova Browser"
> >> >>> >
> >> >>> >
> >> >>> >> 3. Most OS's limit the name length, so "Cordova XXX" will likely
> >>be
> >> >>>too
> >> >>> >>
> >> >>> > Good point here. This is easy to test on iOS by creating
> >>home-screen
> >> >>> > bookmarks from safari. Couldn't get any of the names I liked :(.
> >> >>> >
> >> >>> >
> >> >>> >> 4. All Cordova app examples (e.g. Hello World) are prefixed as
> >> >>> >> "cordova-app-xxx"
> >> >>> >>
> >> >>> > I think the name's fine, but wouldn't this be an argument for
> >> >>>calling it
> >> >>> > "cordova-app-cordova" :P
> >> >>> >
> >> >>> >
> >> >>> >>
> >> >>> >> Michael
> >> >>> >>
> >> >>> >> On Tue, Mar 26, 2013 at 1:27 PM, Benn Mapes
> >>
> >> >>> wrote:
> >> >>> >>
> >> >>> >> > +1 for WebKeg
> >> >>> >> >
> >> >>> >> >
> >> >>> >> > On Tue, Mar 26, 2013 at 12:52 PM, Brian LeRoux 
> >> wrote:
> >> >>> >> >
> >> >>> >> > > omg. yes!
> >> >>> >> > >
> >> >>> >> > > cordova-webkeg
> >> >>> >> > >
> >> >>> >> > > I can see the Yohei style app icon already..
> >> >>> >> > >
> >> >>> >> > > On Tue, Mar 26, 2013 at 12:14 PM, Douglas Campos 
>
>

Re: App-Harness Description

[Michael Brooks]

Alright, I want to get this project started and we need to settle on a name.

No one has made a compelling argument against calling the app "Cordova."

Proposed name:

- App Store name: "Cordova"
- Repository name: "cordova-app"

Here are my reasons:

1. We naturally refer to it as "The Cordova App" in casual discussion
2. There are no plans for any other app, making this "The Cordova App."
3. Most OS's limit the name length, so "Cordova XXX" will likely be too
long.
4. All Cordova app examples (e.g. Hello World) are prefixed as
"cordova-app-xxx"

Michael

On Tue, Mar 26, 2013 at 1:27 PM, Benn Mapes  wrote:

> +1 for WebKeg
>
>
> On Tue, Mar 26, 2013 at 12:52 PM, Brian LeRoux  wrote:
>
> > omg. yes!
> >
> > cordova-webkeg
> >
> > I can see the Yohei style app icon already..
> >
> > On Tue, Mar 26, 2013 at 12:14 PM, Douglas Campos  wrote:
> > >
> > > On 26/03/2013, at 16:13, Filip Maj  wrote:
> > >
> > >> My vote is for WebKeg
> > >
> > > THIS
> > > --
> > > qmx
> > >
> >
>

Re: Platform-level command line scripts ;)

[Michael Brooks]

Fil, great work on the wiki document. Below are some feedback points.


> `build`

...

What happens when a user specifies both --debug and --release?


I'm happy as long as we decide on what happens. For the sake of ease, I
think it would be better to just fail.

This brings up the question of exit codes. I don't want to over engineer,
but should we distinguish between an exit code for an "unsupported command"
and "runtime command error" (e.g. unsupported argument combination)? As
long as there is a message with the exit code, it's not necessary but could
provide a good hint to higher-level tools.

`run [--target=]`


I like the term `run` and how it will implicitly invokes `build` when
necessary. This will be the go-to command for most developers.

`list-emulator-images`
> ...
> `list-started-emulators`
> ...
> `list-devices`


The listing format is: "ID: DESCRIPTION". What will it look like when no
description is provided? "ID" or "ID:"?

Is it possible to remove the colon entirely and delimit on a space? "ID
DESCRIPTION" and "ID"

`deploy-emulator`
> ...
> `deploy-device`


Deploy is a confusing term because it's too similar to "run." Even both
command definitions use the term "deploy."

I'd like to propose renaming the deploy commands to: `install-emulator` and
`install-device`.

Install more clearly describes the action and implies that it does not
implicitly build first.

Again, awesome work Fil!
Michael

On Tue, Mar 26, 2013 at 4:16 PM, Filip Maj  wrote:

> Thanks Shaz, updated the wiki article.
>
> On 3/26/13 4:07 PM, "Shazron"  wrote:
>
> >* log is only the Simulator
> >* build release/debug -- last one clobbers? depending on how the parsing
> >is
> >implemented
> >
> >
> >On Tue, Mar 26, 2013 at 3:56 PM, Filip Maj  wrote:
> >
> >> OK, I've done some rehash of the proposal and put it up on the wiki:
> >> http://wiki.apache.org/cordova/CommandLineToolingDesign
> >>
> >> Please take a look and post back if you have questions, disagreement,
> >>want
> >> to +1 it, etc.
> >>
> >> At the top there is a generic multi-device flow that can solve a lot of
> >> the consistency issues we've seen before.
> >>
> >> Assuming this proposal is on track, there are three outstanding
> >>questions.
> >>
> >> Two for the `log` command:
> >>
> >> * Does the current iOS implementation only work for simulator, or
> >>device,
> >> or either, or neither?
> >> * Does the multi-device flow apply correctly to the log case? It seems
> >> identifying whether the user's Cordova application is running on an
> >> emulator or device target would need to be figured out.
> >>
> >> One about the build command:
> >>
> >> * What happens when a user specifies both --release and --debug, I.e.
> >> `build --release --debug`?
> >>
> >>
> >>
> >> On 3/25/13 1:54 PM, "Michael Brooks"  wrote:
> >>
> >> >>
> >> >> To be absolutely clear, the above is NOT the motivation for changing
> >> >>this
> >> >> stuff around. Cordova-cli needs consistency across platforms. This is
> >> >>the
> >> >> motivation.
> >> >
> >> >
> >> >Yep, as long as we can guarantee that each script follows a predictable
> >> >input and output, I don't care how we implement it.
> >> >
> >> >If you guys really want a single entry-point with flags, then go nuts,
> >>but
> >> >we will need to clearly define what happens when:
> >> >
> >> >  - no flag is provided e.g. `build`
> >> >  - multiple flags are provided e.g. `build --release --debug`
> >> >
> >> >---
> >> >
> >> >+1 to adding a script that validates a platform's SDK requirements.
> >> >
> >> >This script should not need to modify project files to assert the SDK
> >> >requirements. I mention this because the current `cordova-cli` Android
> >> >`check_requirements` must successfully update the Android project
> >>target
> >> >before returning true. However, consider the scenario where you
> >>validate
> >> >the SDK before adding the platform - in this case, the Android
> >> >`check_requirements` will always fail.
> >> >
> >> >Michael
> >> >
> >> >On Mon, Mar 25, 2013 at 11:14 AM, Filip Maj  wrote:
> >> >
> >> >>
> >> >> >Hopefully, next time we will change/update these things it will be
> >>for
> >> >>a
> >> >> >real reason (such as SDK tools updates etc...) and not because we
> >>think
> >> >> >that there might be a better implementation in C#.
> >> >>
> >> >> To be absolutely clear, the above is NOT the motivation for changing
> >> >>this
> >> >> stuff around. Cordova-cli needs consistency across platforms. This is
> >> >>the
> >> >> motivation.
> >> >>
> >> >>
> >>
> >>
>

Re: Farewell

[Michael Brooks]

Thanks Markus for all your work, help, and advice! Best of luck in the
future and feel free to chime-in whenever you can!

Michael

On Thu, Mar 28, 2013 at 9:20 AM, Brian LeRoux  wrote:

> Thanks so much and don't be stranger Markus! Let us know if ever you
> need our help.
>
> On Thu, Mar 28, 2013 at 8:38 AM, Lorin Beer 
> wrote:
> > thanks for your hard work, and good luck in your future endeavours!
> >
> >
> >
> > On Thu, Mar 28, 2013 at 7:30 AM, Anis KADRI 
> wrote:
> >
> >> Thanks for your contributions and good luck to you Markus!
> >>
> >>
> >> On Thu, Mar 28, 2013 at 7:21 AM, Leutwyler, Markus
> >> wrote:
> >>
> >> > Today is my last day of work at HP as my Role in Developer Relations
> here
> >> > in Europe is ending this month.
> >> > I'm in the process of moving stewardship of Phonegap/Cordova for
> (Open)
> >> > webOS to someone at  LG.
> >> >
> >> > Glad to have been part and to have the chance to contribute to such an
> >> > important Open Source Project!
> >> >
> >> > Markus
> >> >
> >>
>

Re: [cordova-cli] versioning

[Michael Brooks]

>
>  ~/.cordova///


I originally wrote this but expected some backlash on breaking our
- convention. I agree, it makes the tool parsing easier.

One thing, though: cordova-cli currently runs up the file tree searching
> for '.cordova' to identify a cordova-cli-generated project root (like
> git). Can we rename the cache folder to something other than .cordova?
> .cordovalibs or something?


I think we can solve this without renaming:

if .cordova path is HOME_DIR
   then path is not a project

Thoughts?
Michael

On Tue, Mar 26, 2013 at 10:24 AM, Filip Maj  wrote:

> Yep, on it, and agree.
>
> One thing, though: cordova-cli currently runs up the file tree searching
> for '.cordova' to identify a cordova-cli-generated project root (like
> git). Can we rename the cache folder to something other than .cordova?
> .cordovalibs or something?
>
> On 3/26/13 10:22 AM, "Brian LeRoux"  wrote:
>
> >Ok. I really like Mike's proposal. Think we should do this. Its solves
> >most of our woe. Slight caveat that I would like the cache to be in
> >the format of:
> >
> > ~/.cordova///
> >
> >(To prevent weird string splitting logic/bugs emerging.)
> >
> >Fil: can you backlog this? I think it should come AFTER we finish
> >fixing up plugman/jsinstall and at least one plugin xplatform done.
> >
> >
> >On Mon, Mar 25, 2013 at 3:26 PM, Michael Brooks
> > wrote:
> >> With respect to the lazy-loading suggestion, I know Brian has raised the
> >> offline scenario on a previous thread.
> >>
> >> At install time of the CLI (`npm install -g cordova`), we can lazy-load
> >>all
> >> platforms and sample app(s) for a given version.
> >>
> >> At install time of the CLI as a library (`npm install cordova`), we can
> >>not
> >> lazy-load the platforms. This allows other distributions (e.g.
> >> `phonegap-cli`) to not be forced to download a large number of
> >> unnecessary files.
> >>
> >> Michael
> >>
> >> On Mon, Mar 25, 2013 at 3:18 PM, Filip Maj  wrote:
> >>
> >>> Really like this. It a) slims down the cli tools by lazy loading the
> >>> libraries as they are needed and b) solves the upgrade/downgrade story,
> >>> since eventually you'll be able to simply change the version of the
> >>> cordova npm dependency at a project-level.
> >>>
> >>> The only "downside" (not really) is that every generated cordova-cli
> >>> project now is implicitly an npm project as it needs a package.json at
> >>>the
> >>> top-level.
> >>>
> >>> On 3/25/13 11:06 AM, "Michael Brooks" 
> wrote:
> >>>
> >>> >+1 to locking the CLI to a version
> >>> >+1 to the Grunt vision
> >>> >
> >>> >However, I'd like to propose a different approach to the CLI
> >>>versioning
> >>> >and
> >>> >it can also solve the `create` command issue to help move towards a
> >>>dumb
> >>> >global `cordova`.
> >>> >
> >>> >## Cordova-CLI
> >>> >
> >>> >- npm version is still associated with a Cordova distribution
> >>> >- Cordova-CLI does not vendor the Cordova distribution
> >>> >- Adding a platform will lazy load the platform distribution into
> >>> >~/.cordova/platform/-/
> >>> >- We can lazy load by downloading a gzip from the Apache Git web
> >>> >server
> >>> >- Next time the platform is needed, it is copied from
> >>> >~/.cordova/platform/- >>> >
> >>> >## Cordova Create
> >>> >
> >>> >- Creating an app should be a lazy load of the Hello World app
> >>> >   - Cached in ~/.cordova/app/-/
> >>> >- We can update the Hello World app to match a standard Cordova CLI
> >>> >project
> >>> >- Now the global Cordova CLI is a dumb tool
> >>> >   - On create: lazy loading or copying the hello world app
> >>> >   - On project command: shelling to ./node_modules/bin/cordova
> >>>
> >>> >
> >>> >On Fri, Mar 22, 2013 at 1:08 PM, Filip Maj  wrote:
> >>> >
> >>> >> As Tommay pointed out, you need to create the cordova project
> >>>structure
> >>> >>in
> >>> >> the first place with some manner of tool..
> >>> >>
> &g

Re: App-Harness Description

[Michael Brooks]

haha, so Harness it is? ;)

On Tue, Mar 26, 2013 at 10:17 AM, Brian LeRoux  wrote:

> cordova-kink
>
> PROS:
> would probably get lots of downloads in the app store
>
> CONS:
> would probably not get accepted into the app store
>
> On Tue, Mar 26, 2013 at 10:03 AM, Michal Mocny 
> wrote:
> > I like the kinky version.
> >
> >
> > On Tue, Mar 26, 2013 at 12:52 PM, Brian LeRoux  wrote:
> >
> >> Heh, DX sounds *very* Adobe. (Remember Flash MX?) Meanwhile Devtool
> >> sounds very Google.
> >>
> >> Either way I like both more than calling it a harness. ;)
> >>
> >> On Tue, Mar 26, 2013 at 9:39 AM, Andrew Grieve 
> >> wrote:
> >> > Awesome!
> >> >
> >> > Yep - it's editable so that you can edit it :)
> >> >
> >> > I like Cordova DX, or maybe "Cordova DevTool"
> >> >
> >> >
> >> >
> >> > On Tue, Mar 26, 2013 at 12:10 PM, Michael Brooks <
> >> mich...@michaelbrooks.ca>
> >> > wrote:
> >> >>
> >> >> Hey Andrew,
> >> >>
> >> >> This is exactly what I had planned as well. It's as if we read each
> >> >> other's
> >> >> minds.
> >> >>
> >> >> I'll go through the document a second time and add some comments. Do
> you
> >> >> mind if I edit the document?
> >> >>
> >> >> What is this thing going to be called? cordova-app-harness sounds
> kinky.
> >> >>
> >> >>
> >> >> For naming, my stance has been the Cordova App. There is no reason to
> >> make
> >> >> it complicated. If the app stores, users would install Cordova. If
> you
> >> >> think this is confusing users with downloading the Cordova framework
> >> >> (which
> >> >> they sort of are), then call it "Cordova DX" (DX is developer
> >> experience).
> >> >>
> >> >> Michael
> >> >>
> >> >> On Tue, Mar 26, 2013 at 9:06 AM, Brian LeRoux  wrote:
> >> >>
> >> >> > Looks great Andrew. I'd add Ripple and device mirroring as part of
> >> >> > this. (More than one device navigates in concert.)
> >> >> >
> >> >> > What is this thing going to be called? cordova-app-harness sounds
> >> kinky.
> >> >> >
> >> >> >
> >> >> > On Mon, Mar 25, 2013 at 5:59 PM, Andrew Grieve <
> agri...@chromium.org>
> >> >> > wrote:
> >> >> > > Hey Michael (and anyone else interested),
> >> >> > >
> >> >> > > I've written up a requirements doc for this:
> >> >> > >
> >> >> > >
> >> >> >
> >> >> >
> >>
> https://docs.google.com/document/d/14LG1IiEiQ9npc2RmPo5_UEKQTfsg-3ivJu7R2iPBmsw/edit?usp=sharing
> >> >> > >
> >> >> > > It's a bit biased towards hosting Chrome Apps, but I think the
> >> >> > > majority
> >> >> > of
> >> >> > > the app will be generic. The chrome bits will be implemented as a
> >> >> > > combination of extra plugins that are installed in, and some UI
> >> >> > > tweaks.
> >> >> > >
> >> >> > > Would definitely love feedback to know if this describes the same
> >> type
> >> >> > > of
> >> >> > > thing you were thinking of. Shravan will likely be starting on
> this
> >> >> > > this
> >> >> > > week.
> >> >> >
> >> >
> >> >
> >>
>

Re: Welcome to our new committers!

[Michael Brooks]

Welcome to the team!

On Tue, Mar 26, 2013 at 9:41 AM, Andrew Grieve  wrote:

> Yes! Awesome to have you all on the team!
>
> http://www.youtube.com/watch?v=KMU0tzLwhbE
>
>
> On Tue, Mar 26, 2013 at 12:31 PM, Braden Shepherdson  >wrote:
>
> > Congratulations!
> >
> >
> > On Tue, Mar 26, 2013 at 12:27 PM, Brian LeRoux  wrote:
> >
> > > \o/
> > >
> > > On Tue, Mar 26, 2013 at 9:08 AM, Filip Maj  wrote:
> > > > Just wanted to send out a quick congratulatory note to the public dev
> > > > list. We've voted in four new committers in the past week or two, I'm
> > > very
> > > > excited about this!
> > > >
> > > > Don Coleman, Max Woghiren, James Jong, and Tommy Carlos-Williams:
> > > welcome,
> > > > stoked to have you folks join, and congratulations!
> > > >
> > >
> >
>

Re: App-Harness Description

[Michael Brooks]

Hey Andrew,

This is exactly what I had planned as well. It's as if we read each other's
minds.

I'll go through the document a second time and add some comments. Do you
mind if I edit the document?

What is this thing going to be called? cordova-app-harness sounds kinky.


For naming, my stance has been the Cordova App. There is no reason to make
it complicated. If the app stores, users would install Cordova. If you
think this is confusing users with downloading the Cordova framework (which
they sort of are), then call it "Cordova DX" (DX is developer experience).

Michael

On Tue, Mar 26, 2013 at 9:06 AM, Brian LeRoux  wrote:

> Looks great Andrew. I'd add Ripple and device mirroring as part of
> this. (More than one device navigates in concert.)
>
> What is this thing going to be called? cordova-app-harness sounds kinky.
>
>
> On Mon, Mar 25, 2013 at 5:59 PM, Andrew Grieve 
> wrote:
> > Hey Michael (and anyone else interested),
> >
> > I've written up a requirements doc for this:
> >
> >
> https://docs.google.com/document/d/14LG1IiEiQ9npc2RmPo5_UEKQTfsg-3ivJu7R2iPBmsw/edit?usp=sharing
> >
> > It's a bit biased towards hosting Chrome Apps, but I think the majority
> of
> > the app will be generic. The chrome bits will be implemented as a
> > combination of extra plugins that are installed in, and some UI tweaks.
> >
> > Would definitely love feedback to know if this describes the same type of
> > thing you were thinking of. Shravan will likely be starting on this this
> > week.
>

Re: [cordova-cli] Merges Directory

[Michael Brooks]

As a heads up, I'm not trying to sell the naming convention approach.
Simply, I've used both approaches for multiple projects between 2009-2012.
I've found the merges/ to become confusing, error prone, and encouraging a
platform-specific coding mindset.

I can see the benefits, but they seem somewhat minor, so I'd prefer the

compartmentalization of platform files.  If I'm working on a specific
> platform, I can work in that platform's directory.  Having the files spread
> out in a monolithic directory—especially once an app supports more than a
> couple of platforms—might get a little cumbersome.


Arguments for or against either approach can usually be countered, because
they solve the exact same problem. The main difference is organization and
being able to quickly eyeball whether a given file/folder will be replaced
by a platform-specific one. This important when you a generic www/ file
that is overwritten by only one platform. Too many times, I've edited the
 generic file only to realize that there was also a platform-specific
implementation of it.

The other consideration for ./merges are other assets: icons, and
> splashscreens. (Which would then require 2x or something for
> retina/hdpi situations.)


The platform resource problem should not be solved with the merges
directory. The config.xml parser should move the platform's resources and
delete the other platforms' resources.

Michael

On Tue, Mar 26, 2013 at 8:36 AM, Max Woghiren  wrote:

> I can see the benefits, but they seem somewhat minor, so I'd prefer the
> compartmentalization of platform files.  If I'm working on a specific
> platform, I can work in that platform's directory.  Having the files spread
> out in a monolithic directory—especially once an app supports more than a
> couple of platforms—might get a little cumbersome.
>
>
> On Mon, Mar 25, 2013 at 5:34 PM, Michael Brooks  >wrote:
>
> > Just like to provide an alternative suggestion to the merges/ directory
> and
> > here everyone's thoughts.
> >
> > While doing client work at Nitobi, each of our build scripts had similar
> > functionality to merging platform-specific web assets. Below, I'll
> describe
> > what I've experienced and make a suggestion on an improvement.
> >
> > 1. Separate Merges Directory
> >
> >   app
> >   |__ merges/
> >   ||__ android/
> >   |__ www/
> >
> > In the above structure, the android/ directory is a mirror of the www/
> > directory. When a file exists in the android/ directory, it will replace
> > the file in the www/.
> >
> > I believe this is how the merges/ directory in `cordova-cli` works.
> >
> > I've experienced two main problems with this approach:
> >
> > - difficult to keep track of what files are replaced, since you need to
> > cross-reference between directories
> > - too easy to start developing in the merges/android/ directory instead
> of
> > www/
> >
> > 2. Unified Merges Approach
> >
> > app
> > |__ www/
> >  |__ index.html
> >  |__ myfile.js
> >  |__ myfile.android.js
> >  |__ myfolder/
> >  |__ myfolder.android/
> >
> > I've had much greater success with this approach.
> >
> > When a file ends with a dot platform (optional extension) name (e.g.
> > myfile.android.js), it will be renamed to remove the platform name (e.g.
> > myfile.js). This will work on both files and directories.
> >
> > This makes it extremely easy to keep track of what files and directories
> > are generic or platform specific. I haven't actually noticed any downside
> > to this approach and I used it for 2 years.
> >
> > Thoughts?
> > Michael
> >
>

Re: Plugin Repos Created!

[Michael Brooks]

>
> Would it make sense to add these new repos to the list on
> http://cordova.apache.org? The intent is to encourage contributions. I'd
> be fine to do that, but wanted to get a sanity check on that first.


I think that makes sense.

Originally, we tried to keep platforms on the left column and supporting
projects on the right column. It makes sense to have the plugins on the
right - hopefully that wouldn't make the site look unbalanced. I know the
site is configured to support 3 columns, so we ask our designer to tweak
the template if it looks weird.

 Thanks for volunteering Marcel!

On Mon, Mar 25, 2013 at 7:04 PM, Marcel Kinard  wrote:

> Would it make sense to add these new repos to the list on
> http://cordova.apache.org? The intent is to encourage contributions. I'd
> be fine to do that, but wanted to get a sanity check on that first.
>
> -- Marcel
>
> On Mar 22, 2013, at 8:54 PM, Andrew Grieve  wrote:
>
> > https://issues.apache.org/jira/browse/INFRA-5839
>
>

Re: [cordova-cli] versioning

[Michael Brooks]

With respect to the lazy-loading suggestion, I know Brian has raised the
offline scenario on a previous thread.

At install time of the CLI (`npm install -g cordova`), we can lazy-load all
platforms and sample app(s) for a given version.

At install time of the CLI as a library (`npm install cordova`), we can not
lazy-load the platforms. This allows other distributions (e.g.
`phonegap-cli`) to not be forced to download a large number of
unnecessary files.

Michael

On Mon, Mar 25, 2013 at 3:18 PM, Filip Maj  wrote:

> Really like this. It a) slims down the cli tools by lazy loading the
> libraries as they are needed and b) solves the upgrade/downgrade story,
> since eventually you'll be able to simply change the version of the
> cordova npm dependency at a project-level.
>
> The only "downside" (not really) is that every generated cordova-cli
> project now is implicitly an npm project as it needs a package.json at the
> top-level.
>
> On 3/25/13 11:06 AM, "Michael Brooks"  wrote:
>
> >+1 to locking the CLI to a version
> >+1 to the Grunt vision
> >
> >However, I'd like to propose a different approach to the CLI versioning
> >and
> >it can also solve the `create` command issue to help move towards a dumb
> >global `cordova`.
> >
> >## Cordova-CLI
> >
> >- npm version is still associated with a Cordova distribution
> >- Cordova-CLI does not vendor the Cordova distribution
> >- Adding a platform will lazy load the platform distribution into
> >~/.cordova/platform/-/
> >- We can lazy load by downloading a gzip from the Apache Git web
> >server
> >- Next time the platform is needed, it is copied from
> >~/.cordova/platform/- >
> >## Cordova Create
> >
> >- Creating an app should be a lazy load of the Hello World app
> >   - Cached in ~/.cordova/app/-/
> >- We can update the Hello World app to match a standard Cordova CLI
> >project
> >- Now the global Cordova CLI is a dumb tool
> >   - On create: lazy loading or copying the hello world app
> >   - On project command: shelling to ./node_modules/bin/cordova 
> >
> >On Fri, Mar 22, 2013 at 1:08 PM, Filip Maj  wrote:
> >
> >> As Tommay pointed out, you need to create the cordova project structure
> >>in
> >> the first place with some manner of tool..
> >>
> >> On 3/22/13 11:58 AM, "tommy-carlos Williams" 
> wrote:
> >>
> >> >I don't have much to add except that I really like this about Grunt.
> >> >
> >> >However, it would get "interesting" with Cordova since the global is
> >>what
> >> >creates a project in the first place. I still think it could work and
> >> >have the global only responsible for creating dirs and setting up
> >> >package.json stuff etc...
> >> >
> >> >+1 for looking into this.
> >> >
> >> >On 23/03/2013, at 4:53, Brian LeRoux  wrote:
> >> >
> >> >> Right now the global executable is version locked to a Cordova
> >> >> release. If you have a project running 2.5 you are required to have
> >> >> Cordova/CLI 2.5. If you need to then work in Cordova 2.4 you need to
> >> >> downgrade (not really but you would to be safe).
> >> >>
> >> >> In Grunt .4 the global executable is dumb. It just shells to locally
> >> >> installed ./node_module version of Grunt. This enables project level
> >> >> versioning of Grunt. Nice feature. We can do the same thing: with the
> >> >> caveat that you would then require a package.json and ./node_modules
> >> >> folder in our Cordova projects.
> >> >>
> >> >> Discuss.
> >>
> >>
>
>

[cordova-cli] Merges Directory

[Michael Brooks]

Just like to provide an alternative suggestion to the merges/ directory and
here everyone's thoughts.

While doing client work at Nitobi, each of our build scripts had similar
functionality to merging platform-specific web assets. Below, I'll describe
what I've experienced and make a suggestion on an improvement.

1. Separate Merges Directory

  app
  |__ merges/
  ||__ android/
  |__ www/

In the above structure, the android/ directory is a mirror of the www/
directory. When a file exists in the android/ directory, it will replace
the file in the www/.

I believe this is how the merges/ directory in `cordova-cli` works.

I've experienced two main problems with this approach:

- difficult to keep track of what files are replaced, since you need to
cross-reference between directories
- too easy to start developing in the merges/android/ directory instead of
www/

2. Unified Merges Approach

app
|__ www/
 |__ index.html
 |__ myfile.js
 |__ myfile.android.js
 |__ myfolder/
 |__ myfolder.android/

I've had much greater success with this approach.

When a file ends with a dot platform (optional extension) name (e.g.
myfile.android.js), it will be renamed to remove the platform name (e.g.
myfile.js). This will work on both files and directories.

This makes it extremely easy to keep track of what files and directories
are generic or platform specific. I haven't actually noticed any downside
to this approach and I used it for 2 years.

Thoughts?
Michael

Re: docs commit: [CB-2305] Add documntation for InAppBrowser.executeScript and InAppBrowser.insertCSS APIs

[Michael Brooks]

Yea, the docs 2.6.x branch will happen before the above commit.

Docs are typically tagged last, in case other platforms want to get in some
last minutes updates. I've been waiting on Windows, but I can go ahead and
create the branch now to avoid confusion.

On Mon, Mar 25, 2013 at 1:10 PM, Filip Maj  wrote:

> Yes that makes sense. We can simply branch for 2.6.x before this commit,
> that would work in our process ya?
>
> On 3/25/13 11:28 AM, "Shazron"  wrote:
>
> >This is for 2.7.0 right? The feature is not in 2.6.0 so it shouldn't be in
> >2.6.0 docs. (the 2.6.x docs should branch off master before this commit
> >since it hasn't been created yet)
> >
> >
> >On Mon, Mar 25, 2013 at 8:37 AM,  wrote:
> >
> >> Updated Branches:
> >>   refs/heads/master a897edd1f -> 40eb8dedd
> >>
> >>
> >> [CB-2305] Add documntation for InAppBrowser.executeScript and
> >> InAppBrowser.insertCSS APIs
> >>
> >>
> >> Project: http://git-wip-us.apache.org/repos/asf/cordova-docs/repo
> >> Commit:
> >> http://git-wip-us.apache.org/repos/asf/cordova-docs/commit/40eb8ded
> >> Tree: http://git-wip-us.apache.org/repos/asf/cordova-docs/tree/40eb8ded
> >> Diff: http://git-wip-us.apache.org/repos/asf/cordova-docs/diff/40eb8ded
> >>
> >> Branch: refs/heads/master
> >> Commit: 40eb8dedd117cc91b692944a5f933b086d770a4f
> >> Parents: a897edd
> >> Author: Ian Clelland 
> >> Authored: Mon Mar 18 12:06:41 2013 -0400
> >> Committer: Michael Brooks 
> >> Committed: Mon Mar 25 08:36:23 2013 -0700
> >>
> >> --
> >>  docs/en/edge/cordova/inappbrowser/inappbrowser.md |  154
> >>
> >>  1 files changed, 154 insertions(+), 0 deletions(-)
> >> --
> >>
> >>
> >>
> >>
> >>
> http://git-wip-us.apache.org/repos/asf/cordova-docs/blob/40eb8ded/docs/en
> >>/edge/cordova/inappbrowser/inappbrowser.md
> >> --
> >> diff --git
> >>a/docs/en/edge/cordova/inappbrowser/inappbrowser.mdb/docs/en/edge/cordova
> >>/inappbrowser/
> >> inappbrowser.md
> >> index bbf5cf6..5cd267b 100644
> >> --- a/docs/en/edge/cordova/inappbrowser/inappbrowser.md
> >> +++ b/docs/en/edge/cordova/inappbrowser/inappbrowser.md
> >> @@ -262,6 +262,160 @@ Full Example
> >>
> >>  
> >>
> >> +executeScript
> >> +=
> >> +
> >> +> Injects JavaScript code into the InAppBrowser window
> >> +
> >> +ref.executeScript(details, callback);
> >> +
> >> +- __ref:__ reference to the InAppBrowser window (`InAppBrowser`)
> >> +- __injectDetails:__ details of the script ot run (`Object`)
> >> +- Supported keys:  (exactly one of "file" or "code" should be
> >>present)
> >> +
> >> +"file" - URL of the script to inject
> >> +"code" - Text of the script to inject
> >> +
> >> +- __callback:__ the function that is to be called in the Cordova
> >> application after the JavaScript code is injected.
> >> +
> >> +Supported Platforms
> >> +---
> >> +
> >> +- Android
> >> +- iOS
> >> +
> >> +Quick Example
> >> +-
> >> +
> >> +var ref = window.open('http://apache.org', '_blank',
> >>'location=yes');
> >> +ref.addEventListener('loadstop', function() {
> >> +ref.executeSript({file: "myscript.js"});
> >> +});
> >> +
> >> +Full Example
> >> +
> >> +
> >> +
> >> +
> >> +  
> >> +InAppBrowser.executeScript Example
> >> +
> >> + >> src="cordova-2.5.0.js">
> >> +
> >> +
> >> +// Wait for Cordova to load
> >> +//
> >> +document.addEventListener("deviceready", onDeviceReady, false);
> >> +
> >> +// Global InAppBrowser reference
> >> +var iabRef = null;
> >> +
> >> +// Inject our custom JavaScr

Re: [cordova-cli] - what does the plugins folder do?

[Michael Brooks]

>
> One of the other goals here is to make the tools magically convenient
> without becoming voodoo. That's the fundamental goal behind turning
> platforms/ into a build artifact: then the answer to "what files in here
> can I edit, and which ones get updated when I run ?" is an
> easy, blanket answer: "Everything in those directories is a build artifact.
> You can edit things quickly for testing, but expect them to get
> overwritten."


Good point Braden! Okay, scrap the .cordova/platform suggestion.

On Mon, Mar 25, 2013 at 11:47 AM, Filip Maj  wrote:

> Braden's got this, +1
>
> On 3/25/13 11:20 AM, "Braden Shepherdson"  wrote:
>
> >I'm not sure about moving the platforms folder, build artifact or no,
> >because one may be loading it in Eclipse/Xcode/etc. and burying it in a
> >hidden folder makes the tools more magical.
> >
> >One of the other goals here is to make the tools magically convenient
> >without becoming voodoo. That's the fundamental goal behind turning
> >platforms/ into a build artifact: then the answer to "what files in here
> >can I edit, and which ones get updated when I run ?" is an
> >easy, blanket answer: "Everything in those directories is a build
> >artifact.
> >You can edit things quickly for testing, but expect them to get
> >overwritten."
> >
> >Braden
>
>

Re: Platform-level command line scripts ;)

[Michael Brooks]

>
> To be absolutely clear, the above is NOT the motivation for changing this
> stuff around. Cordova-cli needs consistency across platforms. This is the
> motivation.


Yep, as long as we can guarantee that each script follows a predictable
input and output, I don't care how we implement it.

If you guys really want a single entry-point with flags, then go nuts, but
we will need to clearly define what happens when:

  - no flag is provided e.g. `build`
  - multiple flags are provided e.g. `build --release --debug`

---

+1 to adding a script that validates a platform's SDK requirements.

This script should not need to modify project files to assert the SDK
requirements. I mention this because the current `cordova-cli` Android
`check_requirements` must successfully update the Android project target
before returning true. However, consider the scenario where you validate
the SDK before adding the platform - in this case, the Android
`check_requirements` will always fail.

Michael

On Mon, Mar 25, 2013 at 11:14 AM, Filip Maj  wrote:

>
> >Hopefully, next time we will change/update these things it will be for a
> >real reason (such as SDK tools updates etc...) and not because we think
> >that there might be a better implementation in C#.
>
> To be absolutely clear, the above is NOT the motivation for changing this
> stuff around. Cordova-cli needs consistency across platforms. This is the
> motivation.
>
>

Re: [cordova-cli] - what does the plugins folder do?

[Michael Brooks]

>
> +1 for ./platforms becoming a build artifact.


I totally support this goal Braden.

When we make the platforms/ a build artifact, I'd like to move the
platforms directory to:
  /my-app/.cordova/platform/

Michael

On Fri, Mar 22, 2013 at 3:07 PM, Michael Wolf wrote:

> Agreed +1
>
> On 3/22/13 4:23 PM, "Brian LeRoux"  wrote:
>
> >Ya love it. =)
> >
> >On Fri, Mar 22, 2013 at 1:02 PM, Filip Maj  wrote:
> >> Agree with everything Braden said
> >>
> >> On 3/22/13 12:05 PM, "tommy-carlos Williams" 
> wrote:
> >>
> >>>+1 for ./platforms becoming a build artifact.
> >>>
> >>>That is already how we are attempting to roll in our project using the
> >>>cli, though its not quite right yet.
> >>>
> >>>On 23/03/2013, at 5:26, Braden Shepherdson  wrote:
> >>>
>  We want this to stick around. One of my goals for the CLI is to make
> the
>  platforms/foo subdirectories completely build artifacts. Native code,
> web
>  assets, JS code, all get copied on every prepare. That's not currently
> true
>  for native code, but it is for the rest.
> 
>  Since we're doing that, we need the full content of the plugins to
> stick
>  around. Is there a problem with keeping this around?
> 
>  Braden
> 
> 
>  On Fri, Mar 22, 2013 at 2:12 PM, Brian LeRoux  wrote:
> 
> > Cool. So, is this interim or necessary to exist for all of time?
> > (Would assume you need some sort of staging area but not sure you
> >need
> > to keep em around if we can cache the manifest info or something.)
> >
> > On Fri, Mar 22, 2013 at 11:01 AM, Braden Shepherdson
> >  wrote:
> >> I assume you mean the top-level plugins/ folder in the CLI?
> >>
> >> That is where plugins are cached when you cordova plugin add them.
> > Whether
> >> they're coming from local directories or git or wherever, they get
> >>copied
> >> here. Then on a prepare this is where the plugin's assets are copied
> > from.
> >>
> >> Braden
> >>
> >>
> >> On Fri, Mar 22, 2013 at 1:56 PM, Brian LeRoux  wrote:
> >>
> >>> ...
> >
> >>
>
>

Re: [cordova-cli] versioning

[Michael Brooks]

+1 to locking the CLI to a version
+1 to the Grunt vision

However, I'd like to propose a different approach to the CLI versioning and
it can also solve the `create` command issue to help move towards a dumb
global `cordova`.

## Cordova-CLI

- npm version is still associated with a Cordova distribution
- Cordova-CLI does not vendor the Cordova distribution
- Adding a platform will lazy load the platform distribution into
~/.cordova/platform/-/
- We can lazy load by downloading a gzip from the Apache Git web server
- Next time the platform is needed, it is copied from
~/.cordova/platform/--/
- We can update the Hello World app to match a standard Cordova CLI project
- Now the global Cordova CLI is a dumb tool
   - On create: lazy loading or copying the hello world app
   - On project command: shelling to ./node_modules/bin/cordova 

On Fri, Mar 22, 2013 at 1:08 PM, Filip Maj  wrote:

> As Tommay pointed out, you need to create the cordova project structure in
> the first place with some manner of tool..
>
> On 3/22/13 11:58 AM, "tommy-carlos Williams"  wrote:
>
> >I don't have much to add except that I really like this about Grunt.
> >
> >However, it would get "interesting" with Cordova since the global is what
> >creates a project in the first place. I still think it could work and
> >have the global only responsible for creating dirs and setting up
> >package.json stuff etc...
> >
> >+1 for looking into this.
> >
> >On 23/03/2013, at 4:53, Brian LeRoux  wrote:
> >
> >> Right now the global executable is version locked to a Cordova
> >> release. If you have a project running 2.5 you are required to have
> >> Cordova/CLI 2.5. If you need to then work in Cordova 2.4 you need to
> >> downgrade (not really but you would to be safe).
> >>
> >> In Grunt .4 the global executable is dumb. It just shells to locally
> >> installed ./node_module version of Grunt. This enables project level
> >> versioning of Grunt. Nice feature. We can do the same thing: with the
> >> caveat that you would then require a package.json and ./node_modules
> >> folder in our Cordova projects.
> >>
> >> Discuss.
>
>

Re: archiving older platforms

[Michael Brooks]

+1

On Thu, Mar 21, 2013 at 2:12 PM, Shazron  wrote:

> +1
>
>
> On Thu, Mar 21, 2013 at 1:46 PM, Michal Mocny  wrote:
>
> > +1
> >
> >
> > On Thu, Mar 21, 2013 at 4:38 PM, Brian LeRoux  wrote:
> >
> > > Ok, I think we have agreement that we'll put these guys on hold until
> > > they find a steward. This means:
> > >
> > > - we won't be taggin them further
> > > - we won't be including them in a release
> > >
> > > This does not mean:
> > >
> > > - deletion or archiving or attic for the src
> > >
> > > (Think of it as a pause button!)
> > >
> > > Agree/disagree?
> > >
> > > On Wed, Mar 20, 2013 at 7:47 AM, Andrew Grieve 
> > > wrote:
> > > > If there are no fixes going into these platforms, then there is no
> > > benefit
> > > > in their users updating them to newer versions of Cordova.
> > > >
> > > > There's going to be more refactoring required when moving plugins to
> > > their
> > > > own repos. We'll really need owners for all platforms that will make
> > the
> > > > transition, or else we won't have any way to test that the
> refactoring
> > > > hasn't broken a platform. On specific example is that blackberry's JS
> > > repo
> > > > is really 4-in-1 currently, and our plugin spec doesn't have support
> > for
> > > > this. They will need to be split out into 4 separate platforms, at
> > least
> > > as
> > > > far as the JS is concerned.
> > > >
> > > > So... I guess my +1 is just for any platform that doesn't have a
> > someone
> > > > willing to focus on it. E.g. I'm fine with keeping WebOS around if
> > Markus
> > > > wants to do the work to support it through this transition.
> > > >
> > > >
> > > > On Tue, Mar 19, 2013 at 10:52 PM, Ken Wallis  >
> > > wrote:
> > > >
> > > >>
> > > >> We will try to provide relevant stats on platform adoption as we are
> > > able.
> > > >> I am anxiously awaiting that information myself. ;)
> > > >>
> > > >> While lacking this information, I still feel that BBOS will be with
> us
> > > for
> > > >> a deal of time, particularly in the enterprise where we are seeing a
> > > >> significant trend towards Cordova/PhoneGap/WebWorks as the primary
> > > platform
> > > >> of choice for apps. This is, frustratingly, a difficult market to
> get
> > > >> adequate metrics out of, as they will typically not use PhoneGap
> Build
> > > IMO,
> > > >> and they don't deploy to commercial application stores. A bit of a
> > black
> > > >> box, but our enterprise support teams continually support the notion
> > > that
> > > >> enterprise looks at HTML5 apps first.
> > > >>
> > > >> In this regard, we would like to see support for BBOS be maintained
> in
> > > the
> > > >> short term. Our team is focused on bringing up BlackBerry 10 built
> on
> > > >> Cordova, and once that has gotten to a stable point we will then be
> > > able to
> > > >> look at resources and determine if BBOS is still a valuable platform
> > to
> > > >> support and if we can port BBOS to the new structures.
> > > >>
> > > >> Hope that makes sense.
> > > >>
> > > >> Sent from my BlackBerry Z10 smartphone.
> > > >> From: Anis KADRI
> > > >> Sent: Monday, March 18, 2013 1:00 PM
> > > >> To: dev@cordova.apache.org
> > > >> Reply To: dev@cordova.apache.org
> > > >> Subject: Re: archiving older platforms
> > > >>
> > > >>
> > > >> s/QR/Qt
> > > >>
> > > >>
> > > >> On Mon, Mar 18, 2013 at 8:58 AM, Lorin Beer <
> lorin.beer@gmail.com
> > > >> >wrote:
> > > >>
> > > >> > +1 Bada/webOS/QR
> > > >> >
> > > >> > echoing Michael's point, I'd like to see usage stats on the older
> BB
> > > >> > platforms. BB10 should absolutely be the focus, but If they are
> > > currently
> > > >> > being used, mothballing may be premature. Revisiting the issues
> > > &

Re: Platform-level command line scripts

[Michael Brooks]

+1 Fil's outlined design.

I'm still not convinced of what Anis and Andrew are in favour of. Having
each script do more will make it more difficult for common results across
all platforms.

I really like Anis's suggestion of just four scripts. What's the motivation
> for having many scripts? Having fewer will dramatically reduce copy & paste
> bugs. It will also aid discoverability (since you'll get --help instead of
> just "ls" and infer from the name what they do).


The motivation for having many scripts is that there is a single entry
point for a single action. Each action is discrete. Either a platform
supports `deploy-emulator` or doesn't. If we have a single `run`
entry-point, it becomes confusing whether a platform supports all
requirements of the `run` action.

I feel the code repetition is also a weak argument. We are defining
entry-point scripts. You can refactor out the common routines (e.g. build)
into a helper script that can be invoked by multiple scripts. As far as I
know, this is possible in bash, batch, and Windows Script Hosting.

ripple should be a separate option and not a separate command in my
> opinion. To simplify things and if everyone agrees we can ignore the `run`
> command flow above and launch ripple by default and ask users to specify
> options if they want to deploy and run to a particular device/emulator.


I feel Ripple has no place in the platform-specific scripts. I love Ripple,
but Ripple belongs is a higher-level tool such as Cordova CLI. The
platform-specific scripts are meant to deal with platform-specific
functions.

Michael

On Wed, Mar 20, 2013 at 8:22 PM, Benn Mapes  wrote:

> I liked the idea you mentioned earlier with having one wrapper script,
> that way there is one entry point for the given commands for the needed
> functionality. Then it doesn't matter what underlying scripts actually do
> the work.
>
> Then our only focus would be on the commands and not so much the name of
> the scripts.
>
>
> On Wed, Mar 20, 2013 at 7:36 PM, Andrew Grieve 
> wrote:
>
> > I really like Anis's suggestion of just four scripts. What's the
> motivation
> > for having many scripts? Having fewer will dramatically reduce copy &
> paste
> > bugs. It will also aid discoverability (since you'll get --help instead
> of
> > just "ls" and infer from the name what they do).
> >
> >
> > On Wed, Mar 20, 2013 at 7:06 PM, Filip Maj  wrote:
> >
> > > Ya ya ya we're all on agreement on this specific issue. The underlying
> > > platform scripts can be used regardless of whether you're using
> > > cordova-cli or not.
> > >
> > > On 3/20/13 3:51 PM, "Anis KADRI"  wrote:
> > >
> > > >On Wed, Mar 20, 2013 at 3:43 PM, Benn Mapes 
> > wrote:
> > > >
> > > >> I know that sounds
> > > >> like a lot
> > > >> of scripts but we're building them for the cordova-cli to use,  so i
> > > >>like
> > > >> the idea of breaking
> > > >>  them out so each script does a *very specific* task with as
> > > >>little-to-no
> > > >>
> > > >
> > > >No we're not. cordova-cli is a cool tool that people can use but it
> > should
> > > >not be the only way of building Cordova apps in my opinion.
> > >
> > >
> >
>

Re: Platform-level command line scripts

[Michael Brooks]

I think this thread is starting to diverge from its purpose and step into
the responsibilities of the Cordova CLI.

Easy Wins
> -


Fil, I agree with your easy wins. Thanks for summarizing the current state
of the platform-specific scripts.

It would also be good to have a stubbed implemented of each script on each
platform. For example, if a platform does not yet support "log" then it
should still have a log script that echo's "logging is unuspported." This
allows the Cordova CLI is "shell out" to the scripts without having to
check whether the platform has indeed implemented something.

Harder Wins
> ---


This deserves it's own thread. There seems to be a lot of confusion around
the difference between and role of Cordova CLI commands and
Platform-specific scripts. Some of the above replies are mixing or
interchanging those terms.

For platform-specific scripts, I believe a simple and explicit nature is
critical. A script must do one thing and only one thing. If we deviate from
this, then platform-specific scripts will likely act different for each
platform.

Michael

On Wed, Mar 20, 2013 at 8:59 AM, Ken Wallis  wrote:

> Deploy vs. Emulate:  Deploy could be used to deploy to anything, emulator,
> ripple, simulator, or actual device.  I think perhaps deploy is the right
> terminology in this regard than emulate?
>
> I agree with Jeff that it would be valuable to standardize arguments as
> well, in so far as those those that are common across platforms.
> --
>
> Ken Wallis
>
> Product Manager – WebWorks
>
> BlackBerry
>
> 289-261-4369
>
> 
> From: agri...@google.com [agri...@google.com] on behalf of Andrew Grieve [
> agri...@chromium.org]
> Sent: Wednesday, March 20, 2013 11:09 AM
> To: dev
> Subject: Re: Platform-level command line scripts
>
> I like the suggestions of having fewer commands. Actually, why not have
> just one command? It would make for less copy/paste, and you'd only have to
> use a single --help to see what you can do.
>
> E.g.:
>
> ./cordova/cli.js build --profile=release
> ./cordova/cli.js build --profile=debug
> ./cordova/cli.js clean
> ./cordova/cli.js package  // For app store
> ./cordova/cli.js log
> ./cordova/cli.js run --target=DEVICE_ID
> ./cordova/cli.js run --target=EMULATOR_ID
> ./cordova/cli.js run --target=ripple
> ./cordova/cli.js run --target=emulator
> ./cordova/cli.js run --target=emulator
>
>
>
>
>
> On Wed, Mar 20, 2013 at 6:19 AM, Brian LeRoux  wrote:
>
> > Fil: yes I like the easy wins you describe.
> >
> > Anis: agree on harder wins. The `emulate` cmd should require a
> > parameter and only launch platform emulators.  The `run` cmd should
> > default to Ripple, and while we're in there we should kill the serve
> > command. Also agree, we should do a download to Fruitstrap from one of
> > our forks (to be safe).
> >
> > Tommy: would be awesome to get your help on the `release` cmd for iOS.
> >
> > Jesse: agree about cordova-deploy tool should just deploy. (Only I
> > think we should rename it to `emulate` and have it require a
> > parameter.)
> >
> > Mapes: we hate the Bruins ok buddy? Get over it. Also: `build` cmd is
> > for debug builds and `release` cmd is for doing release builds as you
> > intuited. I think you got `run` and `emulate` mixed up but the spirit
> > was correct.
> >
> > Tim/Bryan: can we kick up a fresh thread on the BB10 business? It
> > would be nice to get that in but I think those queries got lost in
> > this deluge.
> >
> > Axe! (Parashuram's online crime fighting persona is axemclion): thanks
> > for saying hi, we'd love the help yo!
> >
> >
> > On Wed, Mar 20, 2013 at 1:14 AM, Jesse MacFadyen
> >  wrote:
> > > Welcome Parashuram!
> > > Happy to have some help. Benn has been working on most of this, and I
> > > have created the deploy tools for wp7 and wp8, so reach out if you
> > > need guidance or anything.
> > >
> > > Cheers,
> > >   Jesse
> > >
> > > Sent from my iPhone5
> > >
> > > On 2013-03-19, at 10:24 PM, "Parashuram Narasimhan (MS OPEN TECH)"
> > >  wrote:
> > >
> > > Hi,
> > >
> > > I could offer to start helping on the Windows Phone side of things.
> > >
> > > P.S: This is my first email to the group, and I think I should
> > > introduce myself - I am Parashuram, working for Microsoft Open
> > > Technologies Inc.
> > >
> > > -Original Message-
> > > From: Filip Maj [mailto:f...@adobe.com]
> > > Sent: Tuesday, March 19, 2013 3:42 PM
> > > To: dev@cordova.apache.org
> > > Subject: Platform-level command line scripts
> > >
> > > Bringing this up once more, hopefully the last time :)
> > >
> > > TL;DR: the behavior and naming of the platform-level scripts are still
> > > not 100% lined up. I'd like to fix this and agree with you all on some
> > > of the finer points surrounding this issue.
> > >
> > > Benn Mapes, an intern at Adobe, has been working on adding Windows
> > > Phone support to cordova-cli. It's been a bit of work, but the first
> > > step is to land command 

Re: [DISCUSS] Add Ripple support to cordova-cli

[Michael Brooks]

>
> We have a discussion going on the Cordova list running about this
> right now. The idea will be that `cordova run` will launch the app in
> Ripple. (And we're going to kill off the `cordova serve` cmd.) We'll
> keep `cordova emulate [platform]` around but I doubt ppl will use it
> much once `run` is there.


I'd like to avoid the sprawl of commands and keep it more organized and
intuitive.

Ripple is an emulator and belongs under the "emulate" command.

The command signature should be:
$ cordova emulate [options] 

$ cordova emulate 
Launches the platform's SDK emulator

$ cordova emulate  --ripple [--port ]
Launches the platform in the Ripple emulator

Michael

On Wed, Mar 20, 2013 at 3:30 AM, Brian LeRoux  wrote:

> We have a discussion going on the Cordova list running about this
> right now. The idea will be that `cordova run` will launch the app in
> Ripple. (And we're going to kill off the `cordova serve` cmd.) We'll
> keep `cordova emulate [platform]` around but I doubt ppl will use it
> much once `run` is there.
>
> Good times! =)
>
>
>
> On Wed, Mar 20, 2013 at 1:12 AM, Alessandro Aprile
>  wrote:
> > +1 ripple is so simple and useful...
> >
> > 2013/3/20 Tommy-Carlos Williams 
> >
> >> +1
> >>
> >> Ripple is all I use `cordova serve` for anyway :)
> >>
> >>
> >> On 20/03/2013, at 10:14 AM, Filip Maj  wrote:
> >>
> >> > I would like to see Ripple support completely replace the "cordova
> >> server"
> >> > command - they both do the same thing but Ripple is better tailored at
> >> > doing the server+emulation job.
> >> >
> >> > On 3/9/13 12:08 PM, "Brian LeRoux"  wrote:
> >> >
> >> >> Yes, this is awesome, think a Ripple command is good while we suss it
> >> >> out: `cordova emulate ripple` or even just `cordova ripple`.
> >> >>
> >> >> Eventually I'd think we'd want `cordova emulate` to just default to
> >> >> Ripple once it feels baked enough.
> >> >>
> >> >> On Thu, Mar 7, 2013 at 11:12 AM, Gord Tanner 
> wrote:
> >> >>> Hello everyone,
> >> >>>
> >> >>> I made a quick prototype to add support for using ripple from the
> >> >>> cordova-cli [1].
> >> >>>
> >> >>> Currently I just added a new command called ripple that calls the
> >> >>> cordova
> >> >>> emulate command and then starts the ripple server to point to it.
>  It
> >> >>> will
> >> >>> then launch the default browser (cross platform) which will launch
> your
> >> >>> App
> >> >>> in ripple.  This does not require the plugin to be installed as
> Ripple
> >> >>> is
> >> >>> functioning as a proxy / web app.
> >> >>>
> >> >>> I have a question on how to handle this command:
> >> >>>
> >> >>> - Should this be a flag on the "cordova emulate" command?
> >> >>>
> >> >>> The Command could ether be:
> >> >>>
> >> >>> cordova serve  [port] --ripple
> >> >>>
> >> >>> or
> >> >>>
> >> >>> cordova ripple  [port]
> >> >>>
> >> >>> There are also a couple of todos:
> >> >>>
> >> >>> - Ripple needs to be published to npm and we should install it via
> >> that,
> >> >>> currently I am just cloning via git.  This will happen soon and is
> just
> >> >>> a
> >> >>> temp hack.
> >> >>> - Ripple is currently starting its own server, we should allow the
> >> >>> "cordova
> >> >>> emulate" middleware to be usable by ripple
> >> >>> - Ripple should allow us to pick the device we want to launch on.
>  If I
> >> >>> launch using blackberry I shouldn't have ripple emulate an iPhone.
> >> >>>
> >> >>>
> >> >>> [1]
> >> >>>
> >> >>>
> >>
> https://github.com/gtanner/cordova-cli/commit/cf499d53b3e6f6631513fd5
> >> >>> 110c0861f8f01
> >> >
> >>
> >>
>

Re: [Plugins] Plugin versioning

[Michael Brooks]

>
> However, It's expensive to clone down the
> repository just to check if the plugin works or not.


Good point Anis, it would be expensive to clone down a plugin simply to disc


> I believe we should store some sort of mapping on our discovery server.
> Such as:
> {
>   cordova_version: plugin_versions
> }


It would be nice to avoid duplicating information (plugin source and
discovery server).

Could we consider something similar to `npm info `, which returns
the JSON of the module's package.json. If we did the same for the plugin
configuration, then plugman can locally assess whether the plugin is
compatible, without having the download the entire plugin.

Micael

On Tue, Mar 19, 2013 at 11:34 AM, Tim Kim  wrote:

> +1
>
> However, I think we may need a better property/value pair name than
> just cordova_version:
> plugin_versions. This is because I feel like there is a implicit idea that
> this particular plugin will work on a specific version of Cordova, but for
> all platforms. Whereas in reality, most of the plugins out there are just
> for iOS and Android. So maybe if the mapping was more like:
>
> {
>   cordova_version: {
>   android: android_plugin_version,
>   blackberry: blackberry_plugin_version,
>   ios: ios_plugin_version
> }
> }
>
> I think this also takes care of if a plugin adds in another platform but in
> a later version.
>
>
> On 19 March 2013 07:59, Anis KADRI  wrote:
>
> > Hey all,
> >
> > Plugins need to be versioned to be backward compatible with previous
> > versions of Cordova. I had a discussion with the PhoneGap:Build team
> > yesterday and they need to be backward compatible. Ally Ogilvie also
> > mentioned in separate thread that game developers would also need
> something
> > like this.
> >
> > We have already broken the plugin interface a number of times and we know
> > that a plugin implementation won't work across all versions of Cordova.
> > The plugin spec already supports an  tag to specify which
> versions
> > of cordova it supports. However, It's expensive to clone down the
> > repository just to check if the plugin works or not.
> >
> > I believe we should store some sort of mapping on our discovery server.
> > Such as:
> >
> > {
> >   cordova_version: plugin_versions
> > }
> >
> > That way when plugman tries to install a plugin it knows ahead of time
> > (before cloning the repository) if there is a version of the plugin that
> > works with the user's version of cordova.
> >
> > This will probably be less needed after 3.0 when the plugin interface is
> > stable enough.
> >
> > Thoughts ?
> >
> > -a
> >
>
>
>
> --
> Timothy Kim
>

Re: PhoneGap Plugins - Provide Versioning Advice

[Michael Brooks]

Hey Ally, good to hear from you and awesome feedback!

Your thread came at a good time because Anis and Braden are starting to
tackle these issues in a sane way.

As Anis mentioned, a discussion thread should be jumping up today. You can
also track the plugin progress through the plugman code (no GitHub mirror
yet) [1], JIRA issue component [2], or hop onto IRC [3] for some real-time
chatter (all important discussions happen on [1] and [2] though).

[1] https://git-wip-us.apache.org/repos/asf?p=cordova-plugman.git;a=summary
[2] https://issues.apache.org/jira/browse/CB/component/12320402
[3] Freenode #cordova

Michael

On Tue, Mar 19, 2013 at 7:44 AM, Anis KADRI  wrote:

> Yes, the plan is to have plugins versionned and backwards compatible with
> previous versions of Cordova. Depending on what cordova version you have
> installed there will/should be a specific version of that plugin that works
> with it. I will kick off a thread about this.
>
>
> On Tue, Mar 19, 2013 at 7:10 AM, Michal Mocny  wrote:
>
> > Excellent Suggestion.  Plugin management is a huge focus for the next few
> > months and likely the major change for cordova 3.0.  Expect improvements.
> >  I'll let others speak to the specifics of the current plugin versioning
> > plan, but its great to have outside feedback on what we should focus on.
> >
> > -Michal
> >
> >
> > On Tue, Mar 19, 2013 at 2:56 AM, Ally Ogilvie 
> wrote:
> >
> > > Hi all,
> > >
> > > I am a great fan of rolling releases and pushing much needed features
> out
> > > as soon as possible, something which the Cordova Team is awesome at
> > doing!
> > >
> > > (Here comes the however) However, I hope that as a platform we want not
> > > only indie developers but medium to large development studios to use
> the
> > > platform too.
> > >
> > > Unfortunately something that always plagues software projects is
> updates
> > > and stability etc.
> > > In a commercial project lasting 6-12 months for game development stuck
> to
> > > the same version of Cordova, its pretty common to see (from my
> > experience)
> > > that the kick ass plugin you wanted to use just jumped 10 versions of
> > > Cordova rendering it backwards incompatible for you to use...
> > >
> > > Assuming you cannot assassinate your project manager or find the extra
> > man
> > > hours to upgrade your Cordova platform (plus all your other plugins), I
> > > personally would love to see more advice given to plugin developers to
> > > version their shit. The platform does it, why not the plugins...
> > >
> > > Branches at best, tags at the very least.
> > >
> > > the Plugin Development Guide seems to be a logic place for this
> > >
> > >
> >
> http://docs.phonegap.com/en/2.5.0/guide_plugin-development_index.md.html#Plugin%20Development%20Guide
> > >
> > > I guess this would help developers use plugman too?
> > >
> > > (Rant over) :)
> > >
> > > Thanks all!
> > >
> > > --
> > > Ally Ogilvie
> > > Lead Developer - MobDev. | Wizcorp Inc. 
> > > --
> > > TECH . GAMING . OPEN-SOURCE WIZARDS+ 81 (0)3-4550-1448 |
> > > Website
> > >  | Twitter  |
> > > Facebook
> > >  | LinkedIn 
> > >
> >
>

Re: plugman apache repository

[Michael Brooks]

Awesome!

To avoid confusion (and extra work on your part), I'd recommend retiring
github.com/imhotep/plugman/.

Simply delete everything but the README.md. Then update the README.md to
redirect developers to the Apache repository. You can then fork the Apache
repository (when it's mirrored) and carry on.

If you don't do this, then GitHub will show you are the canonical
repository and contributors will send you pull requests instead of the
Apache repository.

Michael

On Mon, Mar 18, 2013 at 3:25 PM, Anis KADRI  wrote:

> Just a heads up
>
> plugman has now its own Apache repository (cordova-plugman.git) [1]. Issues
> should be filed using Jira. It is not mirrored to github.com/apache yet
> and
> I reopened the INFRA issue and hopefully they will get to it or they will
> request a separate issue. I will keep my github [2] fork up-to-date as much
> as possible but it should not be the canonical source.
>
> [1]
> https://git-wip-us.apache.org/repos/asf?p=cordova-plugman.git;a=summary
> [2] http://github.com/imhotep/plugman
>

Re: archiving older platforms

[Michael Brooks]

>
> As far as bb 6 and 7, I am sure the majority of devices out there are BB 6
> and 7. BB10 just came out so there can't be that many yet. Developers don't
> seem to be interested in those platform though and I think the focus should
> be on BB10.


It would probably be more accurate to say "BlackBerry Java" which includes
BB 4.6/5/6/7 - yep, we "support" all the way back 4.6 although no one tests
that far back anymore.

I've heard BlackBerry voice the opinion that they would like to see Apache
Cordova focus solely on BlackBerry 10. However, PhoneGap/Build has seen a
large demand for BlackBerry 5 and 6.

+1 Bada

+1 webOS - we may want to bring this out of the Attic in the future

+1 QR - we may want to bring it this out of the Attic when gearing up for
Ubuntu Phone

+0 BB - I want to talk with the our PhoneGap/Build team to better
understand their stance. I'd also like Ken or Jeff from BlackBerry to chime
in with their opinion.

On Sun, Mar 17, 2013 at 10:11 AM, Anis KADRI  wrote:

> +1 to kill those platforms and archive them in the attic :-D
>
> If WebOS, Qt become relevant again we can revive them from the attic.
>
>
> On Sun, Mar 17, 2013 at 10:09 AM, Anis KADRI  wrote:
>
> > According to [1]:
> >
> > "Projects whose PMC are unable to muster 3 votes for a release, who have
> > no active committers or are unable to fulfill their reporting duties to
> the
> > board are all good candidates for the Attic."
> >
> > I believe those projects satisfy the "no active committers" argument.
> >
> > I don't see any active committers for Bada, Qt or WebOS.
> >
> > Markus Leutwyler is the only WebOS committer and is no longer employed by
> > the company that is in charge of it and I am not sure if he's still
> > interested in maintaining it. There are still devices out there I am sure
> > but no new devices are getting shipped.
> >
> > Bada is officially dead [2] but they still released an SDK a couple of
> > weeks ago [3] O_O! They still owned #4 spot in Q3 2012 ahead of Windows
> > Phone [4]
> >
> > As far as bb 6 and 7, I am sure the majority of devices out there are BB
> 6
> > and 7. BB10 just came out so there can't be that many yet. Developers
> don't
> > seem to be interested in those platform though and I think the focus
> should
> > be on BB10.
> >
> > [1] http://attic.apache.org/
> > [2]
> >
> http://www.fiercemobilecontent.com/story/samsung-scraps-bada-os-folds-it-tizen/2013-02-25
> > [3] http://static.bada.com/releasenotes/2.0.6.html
> > [4] http://www.gartner.com/newsroom/id/2237315
> >
> >
> > On Sat, Mar 16, 2013 at 10:15 PM, Brian LeRoux  wrote:
> >
> >> The question has come up about our continued support for:
> >>
> >> - bada
> >> - webos
> >> - qt
> >> - bb6 & bb7
> >>
> >> Nobody is currently actively maintaining Bada, and Qt. However, I
> >> could see us wanting to keep Qt around given Ubuntu Phone. There are
> >> no new webOS devices, though rumours persist they could happen, it
> >> seems like its more of a ceremony than real support. The older BB
> >> platforms are maintained but the real focus is BB10.
> >>
> >> Thoughts?
> >>
> >
> >
>

Re: New doc with new git workflows

[Michael Brooks]

Reads very well, nice work Braden!

I was going to mention adding the creation of a topic branch for
completeness, but Ian, Max, and you have already hashed that out.

I would vote to create a "Contributor" section under "Guides." If Marcel
feels there's importance in defining roles, then that's where that
documentation can go as well. Another useful article would be GitHub Pull
Requests (sending and managing), since Apache is a read-only mirror.

Not sure how useful it is, but my PhoneGap Day 2012 presentation
"Contributing to Apache Cordova" [1] added some definitions about
Contributor and Committer.

[1]
http://michaelbrooks.ca/deck/contributing-to-cordova/2012-08-21-adobe-web-summit/index.html

Michael

On Tue, Mar 12, 2013 at 1:52 PM, Marcel Kinard  wrote:

> From a conceptual perspective, one of the things that seems a bit
> convulted across the project is that there aren't clear documentation
> buckets for the different roles: Cordova committer, Cordova contributor,
> Cordova user. There is some really good content, but it's a bit fractured
> across the cordova-docs.git, README.md in other repos, wiki, etc. Maybe I
> just look at things through role-colored glasses.
>
> Your googledrive doc looks like great content for the Cordova committer.
> This suggestion may be growing the scope from what you intended, but would
> it make sense to build a "Cordova committer" bucket and start to
> consolidate docs for that role in that place starting with this one, such
> as moving similar content out of the wiki, etc?
>
> What you've written here I would categorize as process or governance.
> Another question I'd ask is if the process/governance docs should go in the
> source code repo or someplace else? Assuming they will be branched and
> version-tagged similar to the code, that puts them the same timeline as the
> code. But I don't typically think of branching and snapshotting
> process/governance docs and keeping around old copies, because
> process/governance is constantly evolving and generally new
> process/governance can be mixed with old code because it is
> infrastructure-related, instead of function-in-code related. So perhaps the
> question here is (assuming this md goes into git) should that git not get
> branched/snapshot'd, and instead publish only HEAD, because you always use
> the process/governance described in HEAD? In which case, a wiki is not a
> bad versioning model, assuming you can render what you want.
>
> -- Marcel Kinard
>
> On Mar 11, 2013, at 7:35 PM, Braden Shepherdson 
> wrote:
>
> > I wrote up the new git workflows into a doc intended for inclusion in the
> > Cordova Documentation (it provides much nicer formatting than the wiki).
> > You can check it out here:
> >
> >
> https://googledrive.com/host/0B8sLcyOAEX-XUHAxNXhISE5rTTg/guide_contributing_index.md.html
> >
> > Please let me know if you spot any problems or have any questions. If
> > people like the idea of a contributor entry in the Guide, I'll commit
> this
> > into edge.
> >
> > Braden
>
>

Re: Decreasing the Deprecation Time

[Michael Brooks]

+1 for switching the deprecation window from time to release. Michal summed
it up perfectly.

It's worth reflecting on Tommy and Simon's input. The deprecation window is
there to give users adequate warning that breakage is impending. However,
it's just make-work for us, if our user's don't care or take action.

On Wed, Mar 13, 2013 at 7:09 PM, Simon MacDonald
wrote:

> On Tue, Mar 12, 2013 at 8:06 PM, Tommy-Carlos Williams
>  wrote:
> >
> > No one sees a deprecation warning and thinks "ooh… better not use
> that…", they say "a warning is not an error" and move on with their project.
>
> What I find incredibly weird is no one cares about our deprecation
> method but god forbid your Android Java code is using a deprecated
> method or constant. I've been contacted by users days after a new
> Android version drops asking to get rid of the deprecated methods.
>
> Simon Mac Donald
> http://hi.im/simonmacdonald
>

Re: Shravan - Intro + InAppBrowser Feature addition

[Michael Brooks]

Welcome Shravan. That's a pretty rad intern role. We have a similar intern,
Benn Mapes, at Adobe Vancouver who we unleash on whatever peaks his
interest.

On Wed, Mar 13, 2013 at 3:04 PM, Brian LeRoux  wrote:

> /me highfives all around
>
> On Wed, Mar 13, 2013 at 2:33 PM, James Jong  wrote:
> > Welcome Sharavan!  Glad you're joining the party with me!
> >
> > -James Jong
> >
> > On Mar 13, 2013, at 5:29 PM, Anis KADRI  wrote:
> >
> >> Welcome Shravan!
> >>
> >>
> >> On Wed, Mar 13, 2013 at 2:06 PM, Shazron  wrote:
> >>
> >>> Ignored :) Welcome Sharavan!
> >>>
> >>>
> >>> On Wed, Mar 13, 2013 at 1:42 PM, Shravan Narayan   wrote:
> >>>
>  *small correction - the subject of my previous email says "Intro +
>  InAppBrowser Feature addition" Please ignore the "InAppBrowser
> >>> Feature
>  addition" part.
> 
> 
>  On Wed, Mar 13, 2013 at 4:20 PM, Shravan Narayan <
> shrava...@google.com
> > wrote:
> 
> > Hi,
> > My name is Shravan Narayan. I am a new intern at Google in the
> Cordova
> > team since mid February. I'm working on implementing the ChromeApps
> api
>  in
> > Cordova for Android and iOS .
> >
> > The list of api's are available here if you're curious
> > http://developer.chrome.com/apps/api_index.html
> > http://developer.chrome.com/apps/experimental.html
> >
> > While most of my work is in the ChromeApps side, I would probably
> > occasionally be submitting a couple of small fixes/changes to
> Cordova.
> >
> > This is the first time I've used Cordova, and I'm very glad Google is
> > giving me the opportunity to work on projects related closely with an
>  open
> > source project such as this.
> >
> > Shravan
> >
> >
> 
> >>>
> >
>

Re: who is James

[Michael Brooks]

Welcome James and thanks for the intro! I was wondering who you were :)

On Tue, Mar 12, 2013 at 2:36 PM, Gord Tanner  wrote:

> Welcome!
>
> Sent from my iPhone
>
> On 2013-03-12, at 5:26 PM, Lorin Beer  wrote:
>
> > Hi James, thanks for the intro!
> >
> >
> > On Tue, Mar 12, 2013 at 2:18 PM, Anis KADRI 
> wrote:
> >
> >> Welcome James!
> >>
> >>
> >> On Tue, Mar 12, 2013 at 12:41 PM, Brian LeRoux  wrote:
> >>
> >>> Welcome to the fray James!
> >>>
> >>> On Tue, Mar 12, 2013 at 12:32 PM, Michal Mocny 
> >>> wrote:
>  Hi James!  Thanks for the intro.
> 
>  I think its worthwhile to make a page with reverse intros from all of
> >> us
> >>> to
>  you, I'll get on that.
> 
> 
>  On Tue, Mar 12, 2013 at 3:29 PM, Filip Maj  wrote:
> 
> > Welcome! Looking forward to collaborating with you :)
> >
> > On 3/12/13 2:27 PM, "James Jong"  wrote:
> >
> >> Hey everyone,
> >>
> >> I just wanted to introduce myself to the group since I'm sure some
> of
> >>> you
> >> are wondering who this 'James Jong' guy is.  Probably not, but let's
> >> pretend you doŠ ;-)
> >>
> >> I work in the mobile software group in IBM and my current job role
> is
> >>> to
> >> help build and foster the Cordova community as best as I can.  I
> work
> >>> on
> >> a small team and that's our (very cool) mission.  You may already
> >> know
> >> some of the folks I'm working with (Simon, Becky, Bryce, Pat,
> >> Marcel).
> >> We actively use Cordova and want to contribute to the long-term
> >> success
> >> of Cordova.  I will likely be focusing more on iOS and mobile-spec
> >> initially, but also have an interest in the CLI work and debugging.
> >> Personally, I think it's awesome that I get to work with Cordova as
> >> my
> >> full-time job and that is the main reason I jumped at this
> >> opportunity.
> >> My previous roles have all been with internal development within
> IBM,
> >> mostly on the server-side.  I've worked on linux, network security,
> >>> user
> >> interfaces, C/C++ and Java in those roles.  I am really looking
> >> forward
> >> to getting to know you and working with the community.
> >>
> >> Thanks to Andrew for suggesting that I do this.  Hopefully it gives
> >>> you a
> >> better background on me.  Feel free to contact me if you want more
> >> details or just to chat.
> >>
> >> -James Jong
> >>
>

Re: cordova.io domain name

[Michael Brooks]

Hello everyone,

I've hit a dead-end in my efforts to donate the cordova.io domain to
Apache, so it looks like I'll remain the owner.

I've renewed the domain for 2 years and it will expire next on March 27
2015.

Adobe sponsored the renewal cost of approx €60, so thank you Adobe!

Cheers,
Michael

On Thu, Feb 14, 2013 at 6:44 PM, Michael Brooks wrote:

> Update from my IRC #asfinfra chat:
>
> Apache has a strong stance that the domain must be project.apache.org[1]. 
> Custom domains can be used but must redirect to the original domain
> and cannot mask the original domain. Also, custom domains cannot contain
> the word "apache".
>
> There are precedents where domains have been donated to Apache.
> Unfortunately, they were not able to provide any specifics. I did find an
> example where Oracle donated OpenOffice.org to Apache [2]. However, the
> infrastructure guys emphasized that OpenOffice is a special case and has
> been an example to a number of rules.
>
> So, as it stands, I'm where I was before.
>
> My main outstanding question is: Can I donate cordova.io to Apache. If
> so, how?
>
> [1] https://blogs.apache.org/OOo/entry/what_is_a_podling
> [2] https://blogs.apache.org/foundation/entry/if_it_s_not_at
>
> On Thu, Feb 14, 2013 at 10:30 AM, Michael Brooks  > wrote:
>
>> Yea, I'll jump into the IRC channel today. I thought I'd check here in
>> case anyone has some magical wiki links about it.
>>
>>
>> On Thu, Feb 14, 2013 at 9:39 AM, Filip Maj  wrote:
>>
>>> Ask infra? I'm afraid of what they'll say but probably have to do it.
>>>
>>> On 2/13/13 10:32 PM, "Michael Brooks"  wrote:
>>>
>>> >Hi all,
>>> >
>>> >The domain renewal for cordova.io is due in March 2013.
>>> >
>>> >How do other Apache projects manage custom domains? I've searched around
>>> >apache.org without much luck.
>>> >
>>> >During our incubation period, there was a brief discussion about the
>>> >domain
>>> >name, but little progress was made. For myself, there are two questions:
>>> >
>>> >1. Does the Apache foundation accept domain transfers?
>>> >  - It seems wrong to have a single person in charge of the domain
>>> >ownership.
>>> >  - Regardless, I wil continue to renew the domain if Apache does not
>>> want
>>> >the responsibility.
>>> >
>>> >2. Does Apache infrastructure support custom domains?
>>> >  - So that we do not need to do the domain redirect.
>>> >  - Since CouchDB uses redirects as well, I am guessing the answer is
>>> "no"
>>> >
>>> >The only resource that I can find is on website management [1]. However,
>>> >it
>>> >does not address domain names.
>>> >
>>> >Thanks,
>>> >Michael
>>> >
>>> >[1] http://apache.org/dev/#web
>>>
>>>
>>
>

Re: [ALL PLATFORMS] element support in config.xml

[Michael Brooks]

>
> In general, I believe the cordova-cli should ONLY rely on each platforms
> scripts. It should not try to do anything fancy or anything that users who
> don't use it can't do otherwise.


I whole heartily support this. I probably worded my original response in
the wrong way.

The point is that the Cordova CLI should not deal with platform-specifics.
We know from past experiences that decoupling the platform responsibility
will result in a large, difficult to maintain tool.

On Tue, Mar 5, 2013 at 3:44 PM, Anis KADRI  wrote:

> I also disagree with getting rid of the config.xml part. It doesn't solve
> the current problem (or any problem I can think of). I also disagree with
> having multiple scrips that do one single thing. All platforms have common
> tasks (build, clean, log, run). They're just executed differently.
>
> I believe that we should update ./cordova/build to support copying icons
> over. It's simple, easy and straight-forward. cordova-cli already uses that
> script so it shouldn't do anything extra.
>
> *In general, I believe the cordova-cli should ONLY rely on each platforms
> scripts. It should not try to do anything fancy or anything that users who
> don't use it can't do otherwise.*
> *
> *
> my 0.02
>
>
> On Tue, Mar 5, 2013 at 3:30 PM, Joe Bowser  wrote:
>
> > I disagree! We've already put too much work into making Cordova
> > support config.xml.  I think that we're at the point where we can:
> >
> > 1. Have multiple tools read the same XML file
> > 2. Have certain tags ignored by cordova, but read by cordova-cli
> > 3. Have certain tags ignored by cordova-cli but read by cordova
> > 4. Document this so that it makes sense for each platform.
> >
> > I'm not looking forward to going back and re-deprecating config.xml
> > support just because it's impossible to specify an icon at runtime
> > without the help of half-baked shell/bash scripts.  The fact is that
> > the widget spec is a really poor spec, and was never intended to be
> > used for apps that have both runtime and compile-time elements.  If
> > we're going to keep cramming this square peg into the round hole,
> > we're going to have to make the hole bigger, and fill in the parts
> > after the fact.
> >
> >
> > On Tue, Mar 5, 2013 at 3:14 PM, Michael Brooks  >
> > wrote:
> > > It's worth pointing out that the same problems will apply to the splash
> > > screens.
> > >
> > >
> > >> Since this is a compile-time property, how would we go about
> supporting
> > it
> > >> across all platforms? I'm thinking either a) need to add logic into
> each
> > >> platform's CLI scripts to parse the contents of config.xml,
> grab/verify
> > >> icon assets, copy them over into appropriate place or b) move that
> > >> responsibility into the CLI tool, but then we'd need extra
> documentation
> > >> on how to update the icon on a per-platform basis in case users are
> not
> > >> using the cli tools.
> > >
> > >
> > > I want to lean on b) having the CLI take on the responsibility.
> > >
> > > However, since each platform currently supports config.xml parsing
> > > (e.g. whitelist), then for consistency it should also support .
> > >
> > > This leads into a bigger topic. I'm starting to feel like each native
> > > project should
> > > be just that - a native project. No config.xml support or conformance
> to
> > the
> > > generic Cordova app specification.
> > >
> > > The Cordova CLI is the tool that unionizes all of the platforms under a
> > > common
> > > app specification. It would translate config.xml properties to the
> native
> > > manifests.
> > > Now... if we look back at our previous CLI efforts, we know that this
> is
> > a
> > > path
> > > full of maintenance hell (decoupling native logic from the native
> > project).
> > > One way
> > > to ensure native project compatibility with the Cordova CLI is to
> create
> > > small
> > > bin/ scripts for each CLI task. For example, a bin/ script to "install"
> > an
> > > icon or a
> > > bin/ script to "update" the app name. The CLI can then shell out to
> these
> > > native
> > > bin/ scripts in the same way that it does to create or build a project.
> > >
> > > This is an ugly topic... thoughts?
> > >
> > > One more question that came up on th

Re: [plugins] Static or Dynamic Libraries

[Michael Brooks]

>
> For Android plugin developers if they want to keep their source hidden they
> could provide only the class that extends from CordovaPlugin in source form
> and have it call their code in a provided jar file. Just trying to think of
> a simple way for folks to provide "for pay" plugins.


Good to know!

On Tue, Mar 5, 2013 at 11:40 AM, Simon MacDonald
wrote:

> For Android plugin developers if they want to keep their source hidden they
> could provide only the class that extends from CordovaPlugin in source form
> and have it call their code in a provided jar file. Just trying to think of
> a simple way for folks to provide "for pay" plugins.
>
> Simon Mac Donald
> http://hi.im/simonmacdonald
>
>
> On Mon, Mar 4, 2013 at 5:41 PM, Michael Brooks  >wrote:
>
> > Again, thanks for the feedback guys!
> >
> >
> > > The original proposal said that pre-compiled "Can be an alternative
> (not
> > > replacement) to distributing plugins as source-code." so I don't think
> > the
> > > original intent was for selling plugins.
> >
> >
> > Please, don't read too much into what I wrote. I just wanted to get this
> > suggestion out of my head before it was, once again, forgotten.
> >
> > I think distributing a plugin without the source code is a compelling
> > option to some plugin developers. Commercial businesses may want to
> > interface with internal libraries that are not open sourced or even
> > distributed as a library. For example, maybe an Augmented Reality plugin
> > taps into algorithms that are the foundation of the AR company's
> business.
> >
> > I'm more than happy to shelve this library suggestion and revisit it
> after
> > plugins have been exercised by Cordova users.
> >
> > Michael
> >
> > On Mon, Feb 25, 2013 at 10:01 AM, Michal Mocny 
> > wrote:
> >
> > > The original proposal said that pre-compiled "Can be an alternative
> (not
> > > replacement) to distributing plugins as source-code." so I don't think
> > the
> > > original intent was for selling plugins.  Thats not to say that that
> > isn't
> > > useful, but my understanding is that end goal of this particular thread
> > is
> > > attaining app developer simplicity.
> > >
> > >
> > > On Mon, Feb 25, 2013 at 12:49 PM, Andrew Grieve  > > >wrote:
> > >
> > > > On Mon, Feb 25, 2013 at 9:11 AM, Braden Shepherdson <
> > bra...@chromium.org
> > > > >wrote:
> > > >
> > > > > I'm working on our prototype for automatic installation of
> Javascript
> > > > from
> > > > > plugins in cordova-cli. We already have installation for native
> code
> > > and
> > > > > non-JS www assets. I don't see anything to be gained from
> precompiled
> > > > > libraries, since a user of Cordova already has the device SDK in
> > place
> > > > and
> > > > > is using either our scripts (cordova build, bin/emulate, etc.) or
> > > > > Eclipse/Xcode/etc. to build the deployable application.
> > > > >
> > > > > Switching to libraries loses us transparency for bugfixes ("make
> this
> > > > > change in some/plugin/File.java and see if that fixes your bug")
> and
> > > > error
> > > > > messages, and it's not like we've got closed-source products we
> want
> > to
> > > > > make sure people can't read.
> > > > >
> > > >
> > > > Yep, this is certainly a trade-off with this approach. I don't think
> > > we're
> > > > suggesting moving any of the core plugins to be pre-compiled, but
> just
> > > that
> > > > this will enable people to sell plugins without giving away their
> > source
> > > > code.
> > > >
> > > >
> > > > >
> > > > > Braden
> > > > >
> > > > >
> > > > > On Sat, Feb 23, 2013 at 10:07 PM, Simon MacDonald <
> > > > > simon.macdon...@gmail.com
> > > > > > wrote:
> > > > >
> > > > > > The other issue with jars on Android is they will be unable to
> > refer
> > > to
> > > > > > anything in the res folder. That's basically why Android library
> > > > projects
> > > > > > exist as conventional jars just don't cut it. L

Re: [ALL PLATFORMS] element support in config.xml

[Michael Brooks]

It's worth pointing out that the same problems will apply to the splash
screens.


> Since this is a compile-time property, how would we go about supporting it
> across all platforms? I'm thinking either a) need to add logic into each
> platform's CLI scripts to parse the contents of config.xml, grab/verify
> icon assets, copy them over into appropriate place or b) move that
> responsibility into the CLI tool, but then we'd need extra documentation
> on how to update the icon on a per-platform basis in case users are not
> using the cli tools.


I want to lean on b) having the CLI take on the responsibility.

However, since each platform currently supports config.xml parsing
(e.g. whitelist), then for consistency it should also support .

This leads into a bigger topic. I'm starting to feel like each native
project should
be just that - a native project. No config.xml support or conformance to the
generic Cordova app specification.

The Cordova CLI is the tool that unionizes all of the platforms under a
common
app specification. It would translate config.xml properties to the native
manifests.
Now... if we look back at our previous CLI efforts, we know that this is a
path
full of maintenance hell (decoupling native logic from the native project).
One way
to ensure native project compatibility with the Cordova CLI is to create
small
bin/ scripts for each CLI task. For example, a bin/ script to "install" an
icon or a
bin/ script to "update" the app name. The CLI can then shell out to these
native
bin/ scripts in the same way that it does to create or build a project.

This is an ugly topic... thoughts?

One more question that came up on the issue thread is, does the src attrib
> need to be relative to the www? The concern here being that you will have
> several megabytes of icon images in your application package that gets
> used only for specific platforms, and only at compile time. I'm not sure
> if there is some sort of convention we can come up with here to alleviate
> this problem (perhaps in the context of using the CLI tools?).


I think the icon paths should be defined relative to the config.xml, so
relative
to the www/.

Now, for those users using cordova-cli, I am trying to see if we can come
> up with a reasonable convention that solves the problem of packaging icon
> assets that are not relevant for specific platforms.


Why not simply delete (or not copy) icons referenced by the config.xml when
we generate the native project (the artifacts as Brian calls them)? The
config.xml
tells us exactly what we don't want to include, so we can leverage that and
ensure
the www/ folder built by the native project does not include large, unused
resources.

On Tue, Mar 5, 2013 at 11:11 AM, Brian LeRoux  wrote:

> Smells a little weird to me but we could introduce an /icons folder
> within the /merges/ folders as appropriate. Otherwise I see
> /icons just mirroring /merges except slightly differently.
>
> On Tue, Mar 5, 2013 at 10:50 AM, Filip Maj  wrote:
> > I'm never into creating make-work.
> >
> > Solving this problem using the CLI tools allows for defining application
> > metadata, including icons, without having to know ANYTHING about the
> > native platform structures. However, I brought this discussion up
> > (actually Daniel Pogue did on the JIRA issue), that it would be good to
> > define these icons without toiling around "extra" assets on a
> per-platform
> > basis.
> >
> > We already enable this kind of customization of application name, package
> > id, whitelist access, and application entry point (html page) all via
> > config.xml. Now I want to push the support a bit further to allow users
> to
> > do the same thing with icons. The way icons differ from previous
> > properties is that they are tied to specific assets. Just like the other
> > properties, they need to be "set up" before the app gets compiled.
> Leaving
> > them in the www/ folder, in a way, is wasteful, since each platform only
> > needs to consume a few icon assets at most, but the requirements for each
> > icon asset differ vastly across platforms, and as such you end up with a
> > lot of different assets [1].
> >
> > First thing's first, we definitely need to document which icon assets
> > people need to change in the native project structures for each platform.
> > I'll set up issues for those.
> >
> > Now, for those users using cordova-cli, I am trying to see if we can come
> > up with a reasonable convention that solves the problem of packaging icon
> > assets that are not relevant for specific platforms. I have a few ideas:
> >
> > - have an icons folder under the .cordova folder, containing icon assets,
> > that the config.xml's  elements inside the platform-agnostic www/
> > folder reference.
> > - have an icons folder under the platform-agnostic www/ folder that gets
> > removed before compilation. This one is a little more clear to users but
> > starts imposing restrictions on what can and can't be in the
> > platform-a

Re: Cordova Documentation version based urls make for poor web search targets

[Michael Brooks]

Created the issue here: https://issues.apache.org/jira/browse/CB-2619

On Mon, Mar 4, 2013 at 3:40 PM, Michael Brooks wrote:

>  When I google for cordova documentation, I'm usually taken to an old version
>> (say, 2.1.0).
>
>
> This has also been a problem with the PhoneGap documentation.
>
> Eventually, the doc generator will be rewritten and we should definitely
> keep this issue in mind.
>
> It would be nice to have a short-term solution though. I like the idea of
> adding some JavaScript inspection and rendering a small flash message at
> the top. I'll create a JIRA issue for this.
>
> Also, I took a look at how some other projects do it (like python) and they
>> just use a single url for "latest" and only create custom version-based
>> urls for previous releases.  (And since they link to latest more often
>> than
>> to specific releases, I guess it naturally ranks higher)
>
>
> Yup, I think the "latest" directory or storing the latest release in the
> root directory should be a long-term solution for the rewritten generator.
>
> The documentation URL in the MIDDLE of cordova.apache.org still points to
>> the 2.4.0 docs.  The one on the bottom correctly points to 2.5.0. Couldn't
>> all links just point to the LATEST version of the docs and have the server
>> just handle the redirection via symlink?
>
>
> I noticed this as well and updated the generator. That documentation link
> is now generated from the latest release version, so there is no need to
> manually update it.
>
> On Fri, Mar 1, 2013 at 10:26 AM, Marc Fielding <
> marc.field...@dataclysm.com> wrote:
>
>> To follow on to this point:
>>
>> The documentation URL in the MIDDLE of cordova.apache.org still points
>> to the 2.4.0 docs.  The one on the bottom correctly points to 2.5.0.
>> Couldn't all links just point to the LATEST version of the docs and have
>> the server just handle the redirection via symlink?
>>
>> Thanks,
>>
>> Marc
>
>
>

Re: Cordova Documentation version based urls make for poor web search targets

[Michael Brooks]

>
>  When I google for cordova documentation, I'm usually taken to an old version
> (say, 2.1.0).


This has also been a problem with the PhoneGap documentation.

Eventually, the doc generator will be rewritten and we should definitely
keep this issue in mind.

It would be nice to have a short-term solution though. I like the idea of
adding some JavaScript inspection and rendering a small flash message at
the top. I'll create a JIRA issue for this.

Also, I took a look at how some other projects do it (like python) and they
> just use a single url for "latest" and only create custom version-based
> urls for previous releases.  (And since they link to latest more often than
> to specific releases, I guess it naturally ranks higher)


Yup, I think the "latest" directory or storing the latest release in the
root directory should be a long-term solution for the rewritten generator.

The documentation URL in the MIDDLE of cordova.apache.org still points to
> the 2.4.0 docs.  The one on the bottom correctly points to 2.5.0. Couldn't
> all links just point to the LATEST version of the docs and have the server
> just handle the redirection via symlink?


I noticed this as well and updated the generator. That documentation link
is now generated from the latest release version, so there is no need to
manually update it.

On Fri, Mar 1, 2013 at 10:26 AM, Marc Fielding
wrote:

> To follow on to this point:
>
> The documentation URL in the MIDDLE of cordova.apache.org still points to
> the 2.4.0 docs.  The one on the bottom correctly points to 2.5.0. Couldn't
> all links just point to the LATEST version of the docs and have the server
> just handle the redirection via symlink?
>
> Thanks,
>
> Marc

Re: [website] Documentation Linkage

[Michael Brooks]

Hi Marcel,

As far as I know, we don't have any UX contributors, but the Adobe
contributors have access to a couple great UX minds.

Q1: Would you like me to perform the changes you've described below?


It looks like this has already been moved back under Developer and
reworded. Thanks!

 Q2: I did add a step to http://wiki.apache.org/cordova/CuttingReleases ,
> was that the wrong place?


Hmmm... the cutting a release article includes updating the docs and
website, but doesn't explain how. The "how" is documented in the website's
README.md [1]. I'll update the Wiki to reference the README.md for the
complete update steps.

Q3: In the future if I have ideas of similar magnitude for the website,
> those should be floated in a Jira item first?


I think the same mentality to code can be applied to the website. Trivial
changes (grammer, spelling, etc) can just be updated. Larger tasks like new
content, refactors (shifting content around, terminology changes), and
changes to process (steps involved to update) should be tracked on JIRA or
the mailing list.

I felt like a total ass nitpicking these details. I'm glad to hear it's
actually worked out a few areas of confusion.

Michael

[1] https://svn.apache.org/repos/asf/cordova/site/README.md

On Mon, Feb 25, 2013 at 10:19 AM, Marcel Kinard  wrote:

> Those are all from me.
>
> I am all for high-quality user-facing resources, and that was the
> intention. I wasn't aware that there was access to UX skills, and didn't
> intend to do anything outside of protocol.
>
> Q1: Would you like me to perform the changes you've described below?
>
> Q2: I did add a step to http://wiki.apache.org/cordova/CuttingReleases ,
> was that the wrong place?
>
> Q3: In the future if I have ideas of similar magnitude for the website,
> those should be floated in a Jira item first?
>
> For full disclosure, I made other changes to the website over time,
> including a reference to the issues mailing list, added a paragraph
> regarding the docs, added links to the completed CLAs, added link to the
> download archive, etc. So please sanity check the whole page to see if
> there is anything additional outside of expectations.
>
> I'm cool with nitpicking, I want the user experience to be really good.
>
> -- Marcel Kinard
>
> On Feb 22, 2013, at 6:50 PM, Michael Brooks 
> wrote:
>
> > Hi all,
> >
> > TLDR; Please avoid drive-by updates without documentation and/or
> discussion.
> >
> > I feel like a nitpicker, but this is what leads to broken links and
> > low-quality user-facing resources.
> >
> > 1. Recently, there was a commit that reworded "Documentation" to "Cordova
> > Documentation"
> >- I feel that mentioning "Cordova" is unnecessary.
> >- I spoke with our UX team member and he agrees, summarizing the
> > reasoning as:
> >- "Always remove redundancy."
> >- I would like to change the wording back to "Documentation."
> >
> > 2. Recently, there was a commit that moved "Documentation" from the
> > "Development" category to "General"
> >- Again, I think this is incorrect.
> >- The Documentation is targeted at Cordova developers.
> >- The "General" is a catch all bucket.
> >- Our UX team member summarized this as:
> >- "Always lean towards specificity or generality."
> >- I would like to move Documentation back under "Development"
> >
> > 3. Recently, there was a commit that updated the Documentation link from
> "
> > http://docs.cordova.io"; to "http://cordova.apache.org/docs/en/2.4.0/";
> >- I understand why we may want to use the official URL.
> >- However, the documentation is linked in multiple places meaning each
> > release we need to remember to update every mention of the documentation.
> >- Additionally, the commit did not update the README.md's "How to
> > updating the docs" section with the new steps.
> >- I'm fine keeping the URL as the official one, but please update
> > the README.md.
> >
> > Let me know if you in agreement or against each of the points.
> >
> > Thanks,
> > Michael
>
>

Re: [plugins] Static or Dynamic Libraries

[Michael Brooks]

Again, thanks for the feedback guys!


> The original proposal said that pre-compiled "Can be an alternative (not
> replacement) to distributing plugins as source-code." so I don't think the
> original intent was for selling plugins.


Please, don't read too much into what I wrote. I just wanted to get this
suggestion out of my head before it was, once again, forgotten.

I think distributing a plugin without the source code is a compelling
option to some plugin developers. Commercial businesses may want to
interface with internal libraries that are not open sourced or even
distributed as a library. For example, maybe an Augmented Reality plugin
taps into algorithms that are the foundation of the AR company's business.

I'm more than happy to shelve this library suggestion and revisit it after
plugins have been exercised by Cordova users.

Michael

On Mon, Feb 25, 2013 at 10:01 AM, Michal Mocny  wrote:

> The original proposal said that pre-compiled "Can be an alternative (not
> replacement) to distributing plugins as source-code." so I don't think the
> original intent was for selling plugins.  Thats not to say that that isn't
> useful, but my understanding is that end goal of this particular thread is
> attaining app developer simplicity.
>
>
> On Mon, Feb 25, 2013 at 12:49 PM, Andrew Grieve  >wrote:
>
> > On Mon, Feb 25, 2013 at 9:11 AM, Braden Shepherdson  > >wrote:
> >
> > > I'm working on our prototype for automatic installation of Javascript
> > from
> > > plugins in cordova-cli. We already have installation for native code
> and
> > > non-JS www assets. I don't see anything to be gained from precompiled
> > > libraries, since a user of Cordova already has the device SDK in place
> > and
> > > is using either our scripts (cordova build, bin/emulate, etc.) or
> > > Eclipse/Xcode/etc. to build the deployable application.
> > >
> > > Switching to libraries loses us transparency for bugfixes ("make this
> > > change in some/plugin/File.java and see if that fixes your bug") and
> > error
> > > messages, and it's not like we've got closed-source products we want to
> > > make sure people can't read.
> > >
> >
> > Yep, this is certainly a trade-off with this approach. I don't think
> we're
> > suggesting moving any of the core plugins to be pre-compiled, but just
> that
> > this will enable people to sell plugins without giving away their source
> > code.
> >
> >
> > >
> > > Braden
> > >
> > >
> > > On Sat, Feb 23, 2013 at 10:07 PM, Simon MacDonald <
> > > simon.macdon...@gmail.com
> > > > wrote:
> > >
> > > > The other issue with jars on Android is they will be unable to refer
> to
> > > > anything in the res folder. That's basically why Android library
> > projects
> > > > exist as conventional jars just don't cut it. Luckily since most
> > Cordova
> > > > plugins will do their UI in HTML the likelihood of the plugin needing
> > to
> > > > access the res folder is very low.
> > > >
> > > >
> > > > Simon Mac Donald
> > > > http://hi.im/simonmacdonald
> > > >
> > > >
> > > > On Fri, Feb 22, 2013 at 7:33 PM, Michael Brooks <
> > > mich...@michaelbrooks.ca
> > > > >wrote:
> > > >
> > > > > Sweet, thanks for the Android input Joe!
> > > > >
> > > > > It's awesome to see such detailed responses for Android,
> BlackBerry,
> > > iOS,
> > > > > and Windows!
> > > > >
> > > > > I suppose we can proceed as Marcel suggestion? Create JIRA issue,
> > link
> > > to
> > > > > this thread, but keep our vision forward by finishing source-code
> > > > > distributed plugins.
> > > > >
> > > > > Michael
> > > > >
> > > > > On Fri, Feb 22, 2013 at 4:23 PM, Joe Bowser 
> > wrote:
> > > > >
> > > > > > Hey
> > > > > >
> > > > > > I'm definitely a fan of pre-compiled libraries for plugins. The
> > main
> > > > > > reason I like JARs instead of Java files is because of the
> > following:
> > > > > >
> > > > > > * Cleaner projects
> > > > > > * Installation is extremely easy for non-Activity plugins (drop
> in
> > > the
> > > > 

Re: Testing MobileSpecTest

[Michael Brooks]

Cool, since I see a conditional for Android and iOS, it would be nice to
have WP7 or BB test this and ensure it works there as well.

On Tue, Feb 26, 2013 at 11:53 AM, Michal Mocny  wrote:

> Thanks for heads up.
>
> -Michal
>
>
> On Tue, Feb 26, 2013 at 2:40 PM, Michael Brooks  >wrote:
>
> > Perhaps wait for someone to verify that this works on their system.
> >
> > A good number of us are at ApacheCon today and running at half speed.
> >
> > Michael
> >
> > On Tue, Feb 26, 2013 at 11:26 AM, Michal Mocny 
> > wrote:
> >
> > > Bump.
> > >
> > > Is there any opposition to me landing this?  It should simplify
> > > testing&making changes to mobile-spec tests on dev work in a way that
> > > doesn't hurt normal git workflow.
> > >
> > > -Michal
> > >
> > >
> > > On Mon, Feb 25, 2013 at 4:00 PM, Michal Mocny 
> > wrote:
> > >
> > > > Actually, got this working, pushed a remote branch for feedback:
> > > >
> > > > Commit:
> > > >
> > >
> >
> http://git-wip-us.apache.org/repos/asf/cordova-mobile-spec/commit/9ec39e93
> > > >
> > > > We can add the other platforms, of course, and on windows you can
> hard
> > > > link the file, I think?
> > > >
> > > > -Michal
> > > >
> > > >
> > > > On Mon, Feb 25, 2013 at 2:59 PM, Michal Mocny 
> > > wrote:
> > > >
> > > >> Yeah I'm trying to prototype what I proposed and I cannot find a way
> > to
> > > >> test for file existence in a sync way, and the mobile spec tests
> don't
> > > deal
> > > >> well with having cordova.js injected after page load.  This is
> > solvable
> > > but
> > > >> I'll shelve it until I get more feedback/interest expressed.
> > > >>
> > > >> -Michal
> > > >>
> > > >>
> > > >> On Mon, Feb 25, 2013 at 2:43 PM, Jesse MacFadyen <
> > > purplecabb...@gmail.com
> > > >> > wrote:
> > > >>
> > > >>> For every version, I do the following for WP7 and WP8 :
> > > >>>
> > > >>> - create a new project from the latest template
> > > >>> - remove the dll and link to the repo project directly
> > > >>> - copy over mobile-spec
> > > >>> - modify cordova.js to include cordova.windowsphone.js
> > > >>> - add visual studio link to cordova-js output pkg version
> > > >>>
> > > >>> Run tests, debug, fix, rebuild, retest...
> > > >>>
> > > >>> With this setup, I can modify cordova-js, rebuild and retest, as
> well
> > > >>> as do the same on the native side.
> > > >>>
> > > >>> Fwiw, I don't think there is a generic solution. Any sim link idea
> > you
> > > >>> have is likely gonna fail in windows, and this will ultimately make
> > > >>> things more difficult for someone. I could be wrong.
> > > >>>
> > > >>> Cheers,
> > > >>>   Jesse
> > > >>>
> > > >>> Sent from my iPhone5
> > > >>>
> > > >>> On 2013-02-25, at 11:15 AM, Michal Mocny 
> wrote:
> > > >>>
> > > >>> How do other devs test mobile spec locally?
> > > >>>
> > > >>> Specifically, how do you set up your repo to test with your working
> > > >>> cordova.js version, in a way that you can make changes to
> mobile-spec
> > > >>> tests, push local changes merge changes coming from remote.
> > > >>>
> > > >>> I'm always overriding/clearing/overriding the default cordova.js
> file
> > > in
> > > >>> order to test/merge/push etc.
> > > >>>
> > > >>> Proposal:
> > > >>> I change the current cordova.js file to: If a local
> > cordova.PLATFORM.js
> > > >>> file exists, load that.  Otherwise, load cordova-VERSION.js the way
> > we
> > > do
> > > >>> now.
> > > >>>
> > > >>> Then, all you have to do is create a local symlink to your
> cordova.js
> > > and
> > > >>> never add that file to your git commits.
> > > >>>
> > > >>> Or, do others already have a good solution?
> > > >>>
> > > >>> -Michal
> > > >>>
> > > >>
> > > >>
> > > >
> > >
> >
>

Re: Testing MobileSpecTest

[Michael Brooks]

Perhaps wait for someone to verify that this works on their system.

A good number of us are at ApacheCon today and running at half speed.

Michael

On Tue, Feb 26, 2013 at 11:26 AM, Michal Mocny  wrote:

> Bump.
>
> Is there any opposition to me landing this?  It should simplify
> testing&making changes to mobile-spec tests on dev work in a way that
> doesn't hurt normal git workflow.
>
> -Michal
>
>
> On Mon, Feb 25, 2013 at 4:00 PM, Michal Mocny  wrote:
>
> > Actually, got this working, pushed a remote branch for feedback:
> >
> > Commit:
> >
> http://git-wip-us.apache.org/repos/asf/cordova-mobile-spec/commit/9ec39e93
> >
> > We can add the other platforms, of course, and on windows you can hard
> > link the file, I think?
> >
> > -Michal
> >
> >
> > On Mon, Feb 25, 2013 at 2:59 PM, Michal Mocny 
> wrote:
> >
> >> Yeah I'm trying to prototype what I proposed and I cannot find a way to
> >> test for file existence in a sync way, and the mobile spec tests don't
> deal
> >> well with having cordova.js injected after page load.  This is solvable
> but
> >> I'll shelve it until I get more feedback/interest expressed.
> >>
> >> -Michal
> >>
> >>
> >> On Mon, Feb 25, 2013 at 2:43 PM, Jesse MacFadyen <
> purplecabb...@gmail.com
> >> > wrote:
> >>
> >>> For every version, I do the following for WP7 and WP8 :
> >>>
> >>> - create a new project from the latest template
> >>> - remove the dll and link to the repo project directly
> >>> - copy over mobile-spec
> >>> - modify cordova.js to include cordova.windowsphone.js
> >>> - add visual studio link to cordova-js output pkg version
> >>>
> >>> Run tests, debug, fix, rebuild, retest...
> >>>
> >>> With this setup, I can modify cordova-js, rebuild and retest, as well
> >>> as do the same on the native side.
> >>>
> >>> Fwiw, I don't think there is a generic solution. Any sim link idea you
> >>> have is likely gonna fail in windows, and this will ultimately make
> >>> things more difficult for someone. I could be wrong.
> >>>
> >>> Cheers,
> >>>   Jesse
> >>>
> >>> Sent from my iPhone5
> >>>
> >>> On 2013-02-25, at 11:15 AM, Michal Mocny  wrote:
> >>>
> >>> How do other devs test mobile spec locally?
> >>>
> >>> Specifically, how do you set up your repo to test with your working
> >>> cordova.js version, in a way that you can make changes to mobile-spec
> >>> tests, push local changes merge changes coming from remote.
> >>>
> >>> I'm always overriding/clearing/overriding the default cordova.js file
> in
> >>> order to test/merge/push etc.
> >>>
> >>> Proposal:
> >>> I change the current cordova.js file to: If a local cordova.PLATFORM.js
> >>> file exists, load that.  Otherwise, load cordova-VERSION.js the way we
> do
> >>> now.
> >>>
> >>> Then, all you have to do is create a local symlink to your cordova.js
> and
> >>> never add that file to your git commits.
> >>>
> >>> Or, do others already have a good solution?
> >>>
> >>> -Michal
> >>>
> >>
> >>
> >
>

Re: tag 2.5.0 soon?

[Michael Brooks]

+1 I'm in favour of moving along unless someone points out a reason to hold
back.

On Mon, Feb 25, 2013 at 4:25 PM, Brian LeRoux  wrote:

> +1. lets get this over with so we can put some serious goodness into 2.6
>
> On Mon, Feb 25, 2013 at 1:44 PM, Filip Maj  wrote:
> > How's everyone feeling with the last rc release? The issue tracker has
> > been kind of quiet, good sign? I'd like to set up the tagging issues
> > tomorrow-ish so we can get the thing tagged-n-bagged by end-of-week.
> >
>

Re: Jasmine Tests failing with the most recent multipart changes

[Michael Brooks]

Yep, I agree with you Andrew. Lets ride out the current next/master Git
workflow for the 2.5.0 release. Afterwards, we can kick up a
retrospective thread
to discuss the pros / cons / improvements.

On Monday, February 25, 2013, Andrew Grieve wrote:

> Do the changes you'd like to see cherry-picked fix regressions? If not,
> then I'd say just leave them broken in 2.5.
>
> I think what'd you'd do then is cherry-pick into next, and then immediately
> merge next into master. The merge in this case should have a conflict
> because of the two identical changes, but it should be able to auto-resolve
> them.
>
> So far, I've been finding this workflow much better for having forward
> progress. Since we created the next branch, we've have 17
> non-regression-fixing commits to cordova-ios. In our old flow, this number
> would be 0.
>
> I am also finding that having to figure out if I want to commit to next vs
> master *before* I make a change to be taxing though. The reason we're doing
> it this way around is so that we can use the same release branch "next" for
> the next release as well. If we used named branched (e.g. "next2.5.0") then
> we could commit to master and cherry-pick after-the-fact the changes we
> want in the release branch.
>
> Let's maybe discuss our options here after this release is over with.
>
>
>
> On Mon, Feb 25, 2013 at 3:10 PM, Joe Bowser >
> wrote:
>
> > I haven't cherry-picked anything into next yet.  I've kept working on
> > master and I've been ignoring next.  However, there's some things in
> > master that I would like to see in the next release.  How do we do
> > that without cherry-picking? Or do we just keep things broken in 2.5
> > and just shrug our shoulders and say whoops?
> >
> > Again, I think this work-flow is terrible, and I would like to go back
> > to what we used to do if cherry-picking really breaks things this bad.
> >
> > On Mon, Feb 25, 2013 at 12:01 PM, Andrew Grieve 
> > 
> >
> > wrote:
> > > Joe - do you mean you're committing to master and cherry-picking into
> > next?
> > >
> > > I think this would result in two identical-but-different changes
> > appearing
> > > in the two branches, whereas checking into next and merging into master
> > > ends up with the same change appearing in both branches. The result of
> > this
> > > (I think) is that cherry-picking will make history a bit more
> confusing,
> > > and increase the risk of future merges having conflicts.
> > >
> > >
> > > On Mon, Feb 25, 2013 at 1:52 PM, Joe Bowser 
> > > >
> wrote:
> > >
> > >> That's assuming that we're fixing for release.  I've been doing all
> > >> work in master at this point. I think we're fine doing both
> > >> cherrypicks and merging, but I think that's what makes this process
> > >> complicated.
> > >>
> > >> On Mon, Feb 25, 2013 at 10:42 AM, Filip Maj 
> > >> >
> wrote:
> > >> >
> > >> >>Also, on a side note, for the release, if there's commits in master
> > >> >>that we want in this release, do we do a cherry pick into next?
> > >> >
> > >> > Yes. I see it the opposite way (I commit into next and merge into
> > >> master).
> > >> >
> > >>
> >
>

Re: [plugins] Static or Dynamic Libraries

[Michael Brooks]

Sweet, thanks for the Android input Joe!

It's awesome to see such detailed responses for Android, BlackBerry, iOS,
and Windows!

I suppose we can proceed as Marcel suggestion? Create JIRA issue, link to
this thread, but keep our vision forward by finishing source-code
distributed plugins.

Michael

On Fri, Feb 22, 2013 at 4:23 PM, Joe Bowser  wrote:

> Hey
>
> I'm definitely a fan of pre-compiled libraries for plugins. The main
> reason I like JARs instead of Java files is because of the following:
>
> * Cleaner projects
> * Installation is extremely easy for non-Activity plugins (drop in the
> libs directory)
>
> The downsides on Android:
>
> * You can't verify a JAR - Have to trust that the JAR isn't sketchy,
> signatures can mitigate this, but not eliminate it
> * JARs can't transport assets, assets would have to be transported
> separately
>
> Overall, if you sign the JARs and allow for a mechanism for our users
> to check the signature of the JAR, I'm cool with this approach.  We
> should remember that our users aren't the type of people who will
> check a Java file to make sure the plugin does what it says it does,
> and it would be nice to be able to have a tool to give them some
> assurance that the plugin does only what they think it does.
>
> Joe
>
>
> On Fri, Feb 22, 2013 at 1:30 PM, Michael Brooks
>  wrote:
> > Great responses everyone. We've now got a decent overall of the iOS and
> WP
> > landscape, not to mention use-cases of other projects such Google Maps.
> >
> > tl;dr: IMHO, those three things listed above is where we should put our
> >> effort to make plugins easier, then see where that gets us. I think it
> will
> >> drive us the furthest forward. Then go back an reevaluate whether or
> not to
> >> provide precompiled libs to see if it truly makes life easier for the
> user,
> >> or if it complicates life for the user.
> >
> >
> > Marcel, this is the feedback that I was hoping to see! Thanks a bunch for
> > the analysis.
> >
> > The project is always driven by what gives ours users the most value. So,
> > it makes sense to not lose sight of our goal - offering plugins to users.
> > If the first phase is source-code only, then so be it.
> >
> > The intention of packaging plugins as libraries is entirely around making
> > the users' life less painful. I was reminded of this problem last night,
> > when I had to compile a 2 year old OS X library because the developer did
> > not publish the .framework. Unsurprisingly, it failed to build because
> > Xcode no longer bundles the necessary libraries. Similarly, if I needed
> to
> > a use a JPG or MP3 library, I would not want to include the source code
> in
> > my project simply because it takes too long to compile (assume it does
> > compile).
> >
> > Michael
> >
> > On Fri, Feb 22, 2013 at 12:38 PM, Marcel Kinard 
> wrote:
> >
> >> So if I back up for a moment and look at the bigger picture, it looks
> like
> >> what you are going for is to make it easier for Cordova users to pick up
> >> plugins, either base ones or third-party ones. There are many ways to do
> >> that, providing precompiled code is one way.
> >>
> >> If I were to step into the shoes of a relatively new Cordova user who
> >> wanted to pick up a plugin for my app, I don't think the compilation is
> >> difficult enough to warrant some workaround such as providing
> libraries. My
> >> [admitedly, limited] understanding is that as a Cordova user I always
> need
> >> to use the device SDK to build my app. Therefore the compiler is right
> >> there and it's not difficult to invoke (i.e., iOS always needs
> compilation).
> >>
> >> While still in the shoes of that Cordova user, what appears to be more
> >> challenging in that role is figuring out what files are needed, where to
> >> put them, and what to edit (i.e., config.xml). Basically, getting the
> >> environment and content setup for the SDK to run against. After that,
> >> running the SDK/compiler is easy. So for this difficulty, the kinds of
> >> helps could include:
> >> - docs: overall on how to install/remove plugins, and plugin-specific
> docs
> >> on their specific requirements/quirks
> >> - tooling: a CLI (i.e., plugman) that could make it as easy as npm
> >> - verification: help me as a user understand if the plugin is in there
> >> correctly, (i.e., smoke test or something like 'rpm -V')
> >>
> >> tl;dr: IMHO, those three things listed above is where we should put our
> >> effort to make plugins easier, then see where that gets us. I think it
> will
> >> drive us the furthest forward. Then go back an reevaluate whether or
> not to
> >> provide precompiled libs to see if it truly makes life easier for the
> user,
> >> or if it complicates life for the user.
> >>
> >> The library idea is neat, it ought be captured in Jira while these other
> >> things are worked on first.
> >>
> >> -- Marcel Kinard
>

Re: Tag 2.5.0rc1?

[Michael Brooks]

Docs are up: http://cordova.apache.org/docs/en/2.5.0rc1/

Great work on the release and have a good weekend everyone!

On Fri, Feb 22, 2013 at 1:14 PM, Michael Brooks wrote:

> I'll deploy the latest docs the the website shortly. SVN isn't the
> quickest.
>
>
> On Fri, Feb 22, 2013 at 1:05 PM, Filip Maj  wrote:
>
>> Thanks Steve!
>>
>> On 2/22/13 12:59 PM, "Steven Gill"  wrote:
>>
>> >Hey all,
>> >
>> >2.5.0RC1 can be downloaded at
>> >https://dist.apache.org/repos/dist/release/cordova/.
>> >
>> >Cheers,
>> >-Steve
>> >
>> >On Thu, Feb 21, 2013 at 12:47 PM, Steven Gill
>> >wrote:
>> >
>> >> Cool. Will do!
>> >>
>> >> -Steve
>> >>
>> >>
>> >> On Thu, Feb 21, 2013 at 11:46 AM, Filip Maj  wrote:
>> >>
>> >>> Cordova-cli tagged and pushed to npm as 2.5.0.
>> >>>
>> >>> Steve, all subtasks done. You can generate a release now!
>> >>>
>> >>> Great job team!
>> >>>
>> >>> On 2/20/13 3:26 PM, "Tim Kim"  wrote:
>> >>>
>> >>> >I've tagged BlackBerry but the media tests still crash the mobile
>> spec
>> >>> >auto
>> >>> >test. Not much we can do about this right now since we're still
>> >>>waiting
>> >>> on
>> >>> >BlackBerry to get back to us on this issue:
>> >>> >https://github.com/blackberry/BB10-WebWorks-Framework/issues/606
>> >>> >
>> >>> >It also might be the case that this issue is only on the dev alpha
>> >>> devices
>> >>> >- I think they have a slightly different OS build if compared to the
>> >>> >actual
>> >>> >BB10 device (ie, Z10/Q10).
>> >>> >
>> >>> >However, if you comment out the last three media tests (ie, "should
>> >>> return
>> >>> >MediaError for bad filename", "position should be set properly",
>> >>> >and "duration should be set properly") it should work properly.
>> >>> >
>> >>> >
>> >>> >On 20 February 2013 14:22, Jesse  wrote:
>> >>> >
>> >>> >> CurrentStatus: Resolved my cordova-js issues for WP7, (pulled too
>> >>>many
>> >>> >> changes in)
>> >>> >> WP7 it has been tagged.
>> >>> >> Moving on to WP8.
>> >>> >>
>> >>> >> On Wed, Feb 20, 2013 at 1:46 PM, Shazron 
>> wrote:
>> >>> >>
>> >>> >> > Alright, the two iOS errors (compass error, FileTransfer body
>> >>>error)
>> >>> >>are
>> >>> >> > deemed harmless, so I will check in the cordova-js for iOS for
>> >>> >>2.5.0rc1,
>> >>> >> > and tag iOS 2.5.0rc1.
>> >>> >> >
>> >>> >> >
>> >>> >> > On Wed, Feb 20, 2013 at 1:27 PM, Jesse 
>> >>> >>wrote:
>> >>> >> >
>> >>> >> > > CompassHeading is not an exposed API, and I had planned to
>> >>>remove
>> >>> >>the
>> >>> >> > tests
>> >>> >> > > for it.
>> >>> >> > > However, there are numerous places where it is used (
>> throughout
>> >>> >> > > cordova-js, I don't believe any native code depends on it's
>> >>> >>existence )
>> >>> >> > >
>> >>> >> > > https://issues.apache.org/jira/browse/CB-1583
>> >>> >> > > ideally duck typing of the value received from compass results
>> >>>is
>> >>> >>all
>> >>> >> we
>> >>> >> > > need, but numerous implementations are dependent on the
>> >>>parameters
>> >>> >>in
>> >>> >> the
>> >>> >> > > constructor, so I left it.
>> >>> >> > >
>> >>> >> > >
>> >>> >> > > On Wed, Feb 20, 2013 at 1:22 PM, Filip Maj 
>> >>>wrote:
>> >>> >> > >
>> >>> >> > > > The compass error

[website] Documentation Linkage

[Michael Brooks]

Hi all,

TLDR; Please avoid drive-by updates without documentation and/or discussion.

I feel like a nitpicker, but this is what leads to broken links and
low-quality user-facing resources.

1. Recently, there was a commit that reworded "Documentation" to "Cordova
Documentation"
- I feel that mentioning "Cordova" is unnecessary.
- I spoke with our UX team member and he agrees, summarizing the
reasoning as:
- "Always remove redundancy."
- I would like to change the wording back to "Documentation."

2. Recently, there was a commit that moved "Documentation" from the
"Development" category to "General"
- Again, I think this is incorrect.
- The Documentation is targeted at Cordova developers.
- The "General" is a catch all bucket.
- Our UX team member summarized this as:
- "Always lean towards specificity or generality."
- I would like to move Documentation back under "Development"

3. Recently, there was a commit that updated the Documentation link from "
http://docs.cordova.io"; to "http://cordova.apache.org/docs/en/2.4.0/";
- I understand why we may want to use the official URL.
- However, the documentation is linked in multiple places meaning each
release we need to remember to update every mention of the documentation.
- Additionally, the commit did not update the README.md's "How to
updating the docs" section with the new steps.
- I'm fine keeping the URL as the official one, but please update
the README.md.

Let me know if you in agreement or against each of the points.

Thanks,
Michael

Re: [plugins] Static or Dynamic Libraries

[Michael Brooks]

Great responses everyone. We've now got a decent overall of the iOS and WP
landscape, not to mention use-cases of other projects such Google Maps.

tl;dr: IMHO, those three things listed above is where we should put our
> effort to make plugins easier, then see where that gets us. I think it will
> drive us the furthest forward. Then go back an reevaluate whether or not to
> provide precompiled libs to see if it truly makes life easier for the user,
> or if it complicates life for the user.


Marcel, this is the feedback that I was hoping to see! Thanks a bunch for
the analysis.

The project is always driven by what gives ours users the most value. So,
it makes sense to not lose sight of our goal - offering plugins to users.
If the first phase is source-code only, then so be it.

The intention of packaging plugins as libraries is entirely around making
the users' life less painful. I was reminded of this problem last night,
when I had to compile a 2 year old OS X library because the developer did
not publish the .framework. Unsurprisingly, it failed to build because
Xcode no longer bundles the necessary libraries. Similarly, if I needed to
a use a JPG or MP3 library, I would not want to include the source code in
my project simply because it takes too long to compile (assume it does
compile).

Michael

On Fri, Feb 22, 2013 at 12:38 PM, Marcel Kinard  wrote:

> So if I back up for a moment and look at the bigger picture, it looks like
> what you are going for is to make it easier for Cordova users to pick up
> plugins, either base ones or third-party ones. There are many ways to do
> that, providing precompiled code is one way.
>
> If I were to step into the shoes of a relatively new Cordova user who
> wanted to pick up a plugin for my app, I don't think the compilation is
> difficult enough to warrant some workaround such as providing libraries. My
> [admitedly, limited] understanding is that as a Cordova user I always need
> to use the device SDK to build my app. Therefore the compiler is right
> there and it's not difficult to invoke (i.e., iOS always needs compilation).
>
> While still in the shoes of that Cordova user, what appears to be more
> challenging in that role is figuring out what files are needed, where to
> put them, and what to edit (i.e., config.xml). Basically, getting the
> environment and content setup for the SDK to run against. After that,
> running the SDK/compiler is easy. So for this difficulty, the kinds of
> helps could include:
> - docs: overall on how to install/remove plugins, and plugin-specific docs
> on their specific requirements/quirks
> - tooling: a CLI (i.e., plugman) that could make it as easy as npm
> - verification: help me as a user understand if the plugin is in there
> correctly, (i.e., smoke test or something like 'rpm -V')
>
> tl;dr: IMHO, those three things listed above is where we should put our
> effort to make plugins easier, then see where that gets us. I think it will
> drive us the furthest forward. Then go back an reevaluate whether or not to
> provide precompiled libs to see if it truly makes life easier for the user,
> or if it complicates life for the user.
>
> The library idea is neat, it ought be captured in Jira while these other
> things are worked on first.
>
> -- Marcel Kinard

Re: Tag 2.5.0rc1?

[Michael Brooks]

I'll deploy the latest docs the the website shortly. SVN isn't the quickest.

On Fri, Feb 22, 2013 at 1:05 PM, Filip Maj  wrote:

> Thanks Steve!
>
> On 2/22/13 12:59 PM, "Steven Gill"  wrote:
>
> >Hey all,
> >
> >2.5.0RC1 can be downloaded at
> >https://dist.apache.org/repos/dist/release/cordova/.
> >
> >Cheers,
> >-Steve
> >
> >On Thu, Feb 21, 2013 at 12:47 PM, Steven Gill
> >wrote:
> >
> >> Cool. Will do!
> >>
> >> -Steve
> >>
> >>
> >> On Thu, Feb 21, 2013 at 11:46 AM, Filip Maj  wrote:
> >>
> >>> Cordova-cli tagged and pushed to npm as 2.5.0.
> >>>
> >>> Steve, all subtasks done. You can generate a release now!
> >>>
> >>> Great job team!
> >>>
> >>> On 2/20/13 3:26 PM, "Tim Kim"  wrote:
> >>>
> >>> >I've tagged BlackBerry but the media tests still crash the mobile spec
> >>> >auto
> >>> >test. Not much we can do about this right now since we're still
> >>>waiting
> >>> on
> >>> >BlackBerry to get back to us on this issue:
> >>> >https://github.com/blackberry/BB10-WebWorks-Framework/issues/606
> >>> >
> >>> >It also might be the case that this issue is only on the dev alpha
> >>> devices
> >>> >- I think they have a slightly different OS build if compared to the
> >>> >actual
> >>> >BB10 device (ie, Z10/Q10).
> >>> >
> >>> >However, if you comment out the last three media tests (ie, "should
> >>> return
> >>> >MediaError for bad filename", "position should be set properly",
> >>> >and "duration should be set properly") it should work properly.
> >>> >
> >>> >
> >>> >On 20 February 2013 14:22, Jesse  wrote:
> >>> >
> >>> >> CurrentStatus: Resolved my cordova-js issues for WP7, (pulled too
> >>>many
> >>> >> changes in)
> >>> >> WP7 it has been tagged.
> >>> >> Moving on to WP8.
> >>> >>
> >>> >> On Wed, Feb 20, 2013 at 1:46 PM, Shazron  wrote:
> >>> >>
> >>> >> > Alright, the two iOS errors (compass error, FileTransfer body
> >>>error)
> >>> >>are
> >>> >> > deemed harmless, so I will check in the cordova-js for iOS for
> >>> >>2.5.0rc1,
> >>> >> > and tag iOS 2.5.0rc1.
> >>> >> >
> >>> >> >
> >>> >> > On Wed, Feb 20, 2013 at 1:27 PM, Jesse 
> >>> >>wrote:
> >>> >> >
> >>> >> > > CompassHeading is not an exposed API, and I had planned to
> >>>remove
> >>> >>the
> >>> >> > tests
> >>> >> > > for it.
> >>> >> > > However, there are numerous places where it is used ( throughout
> >>> >> > > cordova-js, I don't believe any native code depends on it's
> >>> >>existence )
> >>> >> > >
> >>> >> > > https://issues.apache.org/jira/browse/CB-1583
> >>> >> > > ideally duck typing of the value received from compass results
> >>>is
> >>> >>all
> >>> >> we
> >>> >> > > need, but numerous implementations are dependent on the
> >>>parameters
> >>> >>in
> >>> >> the
> >>> >> > > constructor, so I left it.
> >>> >> > >
> >>> >> > >
> >>> >> > > On Wed, Feb 20, 2013 at 1:22 PM, Filip Maj 
> >>>wrote:
> >>> >> > >
> >>> >> > > > The compass error is introduced from Gord's latest change.
> >>> >> > > >
> >>> >> > > > The test that is failing is:
> >>> >> > > >
> >>> >> > > >  if you create a new CompassHeading object with no
> >>>parameters, it
> >>> >> > should
> >>> >> > > > have defined properties.
> >>> >> > > >
> >>> >> > > > This commit:
> >>> >> > > >
> >>> >> > > >
> >>> >> > >
> >>> >> >
> >>> >>
> >>> >>
> >>>
> >>>
> https://github.com/apache/cordova-js/commit/6133a7e05bcd2ddc4a15591cf79c
> >>>d
> >>> >>a9
> >>> >> > > > 65cbaf1ab
> >>> >> > > >
> >>> >> > > >
> >>> >> > > > Breaks that (no parameters are defined leads to properties ==
> >>> >> > undefined)
> >>> >> > > >
> >>> >> > > > Not a big deal as in practice this won't break anything. We
> >>> should
> >>> >> > either
> >>> >> > > > remove the test or add more fine-grained checking into
> >>> >> compassHeading.
> >>> >> > > >
> >>> >> > > > On 2/20/13 12:44 PM, "Shazron"  wrote:
> >>> >> > > >
> >>> >> > > > >The FileTransfer errors should go away once I check in the
> >>> >>updated
> >>> >> js,
> >>> >> > > > >which leaves the compass stuff. I'll investigate the compass
> >>> >>stuff
> >>> >> > > before
> >>> >> > > > >committing the updated js.
> >>> >> > > > >
> >>> >> > > > >
> >>> >> > > > >On Wed, Feb 20, 2013 at 12:40 PM, Filip Maj 
> >>> >>wrote:
> >>> >> > > > >
> >>> >> > > > >> The FileTransferError body property is not implemented yet
> >>>so
> >>> >>that
> >>> >> > > error
> >>> >> > > > >> is fine.
> >>> >> > > > >>
> >>> >> > > > >> The bugs blocking RC are:
> >>> >> > > > >> - The compass ones are new, we should investigate
> >>> >> > > > >> - The FileTransfer is not defined, which was a symbol
> >>>mapping
> >>> >> issue
> >>> >> > in
> >>> >> > > > >>the
> >>> >> > > > >> JS (which is why all platforms need to grab the new JS
> >>>test).
> >>> >> > > > >>
> >>> >> > > > >> On 2/20/13 12:37 PM, "Shazron"  wrote:
> >>> >> > > > >>
> >>> >> > > > >> >Don't think these failures should block rc1, but on iOS,
> >>>I'm
> >>> >> > getting
> >>> >> > > > >>that
> >>> >> > > > >> >plus:
> >>> >> > > > >> >
> >>> >> > > > >> >Compass (navigator.co

Re: Proposition to split cordova-blackberry into two separate plugins

[Michael Brooks]

Agree with Brian and Jesse.

Windows currently has three repositories: Windows, WP7, and WP8.

>From a user's perspective, it would make more sense to have only two
repositories: Windows and WP. This is how the Apple environment works: iOS
and Mac.

As Jesse mentioned, it is conceivable to merge WP7 and WP8 into a single
repository. Maybe we should. Someday, maybe we will.

Regardless, we can learn from the past. In this case, keeping BlackBerry
under a single repository.

Years ago, we chose to keep all BlackBerry platforms under a single
repository. PlayBook challenged this approach by introducing itself as a
new Air/Qnx platform. However, after talking more with the BlackBerry team
(Jeff was part of that discussion at the ol'Nitobi office) we learned that
the goal was to generalize the PlayBook platform for future BlackBerry
devices. So, it made sense to keep PlayBook under the BlackBerry repository.

Michael

On Fri, Feb 22, 2013 at 12:39 PM, Jesse MacFadyen
wrote:

> I agree with Brian, single repo, multiple sub-projects.
> The windows repo contains win7 and win8 and there is absolutely no
> code shared between them. Conceivably wp7+8 could be merged in the
> same way.
>
> Cheers,
>   Jesse
>
> Sent from my iPhone5
>
> On 2013-02-22, at 12:02 PM, Brian LeRoux  wrote:
>
> Perhaps code on Github can clear this up, but given the discussion so
> far, I am unconvinced. Creating a new Git repo isn't solving any of
> the problems described below. This should be sub folder of
> ./cordova-blackberry.
>
> We currently have 20+ repos. Once we push everything to plugins that
> will be 40+ repos. We need to keep things clear for our developer
> community and especially so for new committers. Best way to do this is
> to continue to putting BlackBerry code under the BlackBerry repo.
>
> We can evolve that repo to include the enhancements you describe below
> without a new repository to do it. Rather a clean room I would ask you
> guys pull request the existing repo w/ a new folder and lets move the
> conversation to JIRA on how to best clean up.
>
>
>
> On Fri, Feb 22, 2013 at 7:34 AM, Jeffrey Heifetz  wrote:
> > Hey Brian,
> >
> > BB10 is not just  a specific version number of an SDK like BBOS v 10,
> its a brand new OS. Like Mac OSX vs Classical Mac OS. But independent of
> the technology differences I believe this approach will improve things for
> cordova developers targeting blackberry by making it more consistent with
> the approach taken with other platforms.
> >
> > Firstly the developer experience for developers targeting both BB10 and
> one of BBOS and PBOS. The current implementation based on 3 slightly
> different versions of webworks means that there are similar things that end
> up acting quite differently. One example is the config.xml. Currently the
> solution is that Cordova populates one massive config.xml that attempts to
> satisfy all 3 sub-platforms and cordova at large as well. Unfortunately the
> SDKS are quite different offering very different functionalities through
> the config, and there is currently no way to handle these differences in
> the sub-platforms.
> > By splitting we can handle these in the same way all other cordova
> platforms do (unsure what this is) and once the core plugins are split
> accurately let the individual plugins add these values accordingly
> (something that may not be possible when BBOS and PBOS share a config entry
> but BB10 does not).
> >
> > Even developer experience for developers making cross platform plugins
> thinking to add support for blackberry. Currently blackberry has a unique
> structure requiring plugins to have their code in a specific way for 3
> different platforms. While adding support for just one is not difficult,
> its different from any other platform (to my knowledge).
> >
> > Another example will be simple performance. The way the repo is
> architected right now, javascript is loaded that runs for all 3 platforms
> and it runtime detects which one to use. Its not even clear how this will
> work once all of the plugins are split into their own repos, but having
> this adds unnecessary complications that can be removed.
> >
> > We're in the midst of getting our code up on github, maybe it'll be
> clearer what we want to do when there's code to see.
> >
> > On 2013-02-20, at 12:47 PM, Brian LeRoux wrote:
> >
> >> Hey Jeffrey, I'm sorry but I'm not convinced by 'its cleaner' as an
> >> argument. Its not. Its a specific version number to a specific SDK. I
> >> understand that you have more than one SDK: this is common in mobile
> >> platforms, and addressed by the current repo.
> >>
> >> Can you be more precise and explain exactly what you envision this new
> >> repo to contain, and specifically why it can't come as a pull request
> >> to the existing repo/codebase?
> >>
> >>
> >> On Tue, Feb 19, 2013 at 5:47 PM, Jeffrey Heifetz 
> wrote:
> >>> Sharzon, sorry I have no clue when BB10 will be making its way to
> playbook.
> >>>
> >>> Bryan, wh

[plugins] Static or Dynamic Libraries

[Michael Brooks]

Hi all,

I'd like to pick your brain around the feasibility of plugins existing as
static or dynamic libraries.

I had this idea a few years ago, when we first started discussing plugins.
At the time, it was
possible on BlackBerry and, with some work, possible on Android and iOS.
However, a lot
has changed in the last few years, so I'd like to revisit the topic.

Overview:

- A plugin developer would compile their plugin as a static or dynamic
library.
- A plugin developer would publish their plugin as the library.
- An app developer would install the static or dynamic library.

Benefits:

- The plugin is only compiled by the author who distributes it.
- For complex plugins, this may help avoid compile-time errors around
dependencies.
- The plugin may be able to bundle some of its assets, simplifying the
installation process.
- Can be an alternative (not replacement) to distributing plugins as
source-code.

Questions:

- For each platform, how feasible is this?
- What problems (or other benefits) would exist with plugins as libraries?

Thanks!
Michael

Re: docs question: master/next

[Michael Brooks]

Yea, ideally fast-forward merged to preserve the SHA. If that's not
possible, then cherry-picked.

On Thu, Feb 21, 2013 at 4:54 PM, Shazron  wrote:

> Cool - then those two commits should be cherry-picked into next since they
> are part of the next release
>
>
> On Thu, Feb 21, 2013 at 4:53 PM, Michael Brooks  >wrote:
>
> > TLDR; Yes
> >
> > My understanding is that any commits that you want to appear in the
> "next"
> > release, then put them into next.
> >
> > All commits into "next" will eventually be merged into "master" as well
> for
> > the future releases.
> >
> > Michael
> >
> > On Thu, Feb 21, 2013 at 4:27 PM, Shazron  wrote:
> >
> > > Should these two commits be in next as well since they are to be
> released
> > > with 2.5.0?
> > >
> > >
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=commit;h=d2cce8fdc5d3343702d89868c04805bfc662b1c8
> > >
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=commit;h=b58149ed332ecc14ed46cf73b60734a0e15d1816
> > >
> >
>

Re: docs question: master/next

[Michael Brooks]

TLDR; Yes

My understanding is that any commits that you want to appear in the "next"
release, then put them into next.

All commits into "next" will eventually be merged into "master" as well for
the future releases.

Michael

On Thu, Feb 21, 2013 at 4:27 PM, Shazron  wrote:

> Should these two commits be in next as well since they are to be released
> with 2.5.0?
>
>
> https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=commit;h=d2cce8fdc5d3343702d89868c04805bfc662b1c8
>
> https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=commit;h=b58149ed332ecc14ed46cf73b60734a0e15d1816
>

Re: git question

[Michael Brooks]

>
> Could/Should we write a pre-push-hook, s.t. when pushing 'next' to check
> that it has been merged into master, at least locally?


I think we should avoid adding more architecture management code for now.
I've got a few opinions and suggestions on the current git workflow, but I
want to hold my tongue until we see the current proposal used in practice
for releasing 2.5.0rc1, 2.5.0rc2, and 2.5.0.

Michael

On Thu, Feb 21, 2013 at 2:03 PM, Michal Mocny  wrote:

> One might even imagine automating merges from next into master somehow?
>
> Could/Should we write a pre-push-hook, s.t. when pushing 'next' to check
> that it has been merged into master, at least locally?
>
>
> On Thu, Feb 21, 2013 at 4:55 PM, Andrew Grieve 
> wrote:
>
> > If I do the same thing with a clean client (merge next into master),
> then I
> > get the same thing.
> >
> > I think what happened is that we generated a new version of docs
> > at: docs/en/2.5.0rc1 on the next branch, but haven't yet merged that into
> > master.
> >
> > So... I think you're fine. :)
> >
> >
> > On Thu, Feb 21, 2013 at 4:01 PM, Marcel Kinard 
> wrote:
> >
> > > I was following the ContributorWorklow to fix these docs in both next
> and
> > > master. The commit and push to next (see attached) looks good. However,
> > > when I did "git merge next" after "git checkout master", I saw way more
> > > changes than I expected:
> > >  289 files changed, 19759 insertions(+), 132 deletions(-)
> > > All rhe 2.5.0rc1 files were added, and most if not all of the edge
> files
> > > had 2 or more line changes each. That doesn't look right to me, so I
> did
> > > not do the "git push apache master". I wanted to stop and ask for
> advice
> > > before I did any damage. Suggestions?
> > >
> > > -- Marcel Kinard
> > >
> > > Begin forwarded message:
> > >
> > > > From: marc...@apache.org
> > > > Subject: docs commit: CB-2515: add lessons learned to the list of
> > > pre-reqs
> > > > Date: February 21, 2013 3:46:08 PM EST
> > > > To: comm...@cordova.apache.org
> > > > Reply-To: callback-...@cordova.apache.org
> > > >
> > > > Updated Branches:
> > > >  refs/heads/next 10e89b559 -> 4c5e503e7
> > > >
> > > >
> > > > CB-2515: add lessons learned to the list of pre-reqs
> > > >
> > > >
> > > > Project: http://git-wip-us.apache.org/repos/asf/cordova-docs/repo
> > > > Commit:
> > > http://git-wip-us.apache.org/repos/asf/cordova-docs/commit/4c5e503e
> > > > Tree:
> > http://git-wip-us.apache.org/repos/asf/cordova-docs/tree/4c5e503e
> > > > Diff:
> > http://git-wip-us.apache.org/repos/asf/cordova-docs/diff/4c5e503e
> > > >
> > > > Branch: refs/heads/next
> > > > Commit: 4c5e503e7fdd9b407beb5ffc2a997ecc4e093151
> > > > Parents: 10e89b5
> > > > Author: Marcel Kinard 
> > > > Authored: Wed Feb 20 19:22:16 2013 -0500
> > > > Committer: Marcel Kinard 
> > > > Committed: Thu Feb 21 15:39:56 2013 -0500
> > > >
> > > >
> --
> > > > .../guide/getting-started/windows-phone-8/index.md |   39
> > > ---
> > > > 1 files changed, 20 insertions(+), 19 deletions(-)
> > > >
> --
> > > >
> > > >
> > > >
> > >
> >
> http://git-wip-us.apache.org/repos/asf/cordova-docs/blob/4c5e503e/docs/en/edge/guide/getting-started/windows-phone-8/index.md
> > > >
> --
> > > > diff --git
> >
> a/docs/en/edge/guide/getting-started/windows-phone-8/index.mdb/docs/en/edge/guide/getting-started/windows-phone-8/
> > > index.md
> > > > index 9d09ce6..4f6aa5d 100644
> > > > --- a/docs/en/edge/guide/getting-started/windows-phone-8/index.md
> > > > +++ b/docs/en/edge/guide/getting-started/windows-phone-8/index.md
> > > > @@ -28,42 +28,42 @@ Note: Applications built with Apache Cordova for
> > > Windows Phone 8 will only run o
> > > > ---
> > > >
> > > > - Operating System:
> > > > - - Windows 8, Windows 8 Pro
> > > > +- Windows 8 or Windows 8 Pro
> > > > +- The 64-bit version (x64) of Windows is required for the
> SDK.
> > > > +- The Pro version is recommended so you can run a device
> > > emulator.
> > > >
> > > > - Hardware:
> > > > - - 6.5 GB of free hard disk space
> > > > - - 4 GB RAM
> > > > - - 64-bit (x64) CPU
> > > > +- 6.5 GB of free hard disk space
> > > > +- 4 GB RAM
> > > > +- 64-bit (x64) CPU
> > > >
> > > > -- Windows Phone 8 Emulator:
> > > > - - Windows 8 Pro edition or greater
> > > > - - Requires a processor that supports Second Level Address
> Translation
> > > (SLAT)
> > > > +- Windows Phone 8 Emulator
> > > > +- The phone emulator uses Hyper-V, so this list includes those
> > > pre-reqs.
> > > > +- Windows 8 Pro 64-bit edition or greater
> > > > +- Requires a processor that supports virtualization and [Second
> > > Level Address Translation (SLAT)](
> > > http://en.wikipedia.org/wiki/Second_Level_Address_Translation)
> > > > +- See the [l

Re: git question

[Michael Brooks]

>
> 289 files changed, 19759 insertions(+), 132 deletions(-)
> All rhe 2.5.0rc1 files were added, and most if not all of the edge files
> had 2 or more line changes each. That doesn't look right to me, so I did
> not do the "git push apache master". I wanted to stop and ask for advice
> before I did any damage. Suggestions?


This is totally normal.

When a new version is released (e.g. 2.5.0rc1), then all references to the
previous version (e.g. 2.4.0) are updated in the `edge` directory and a new
directory is created for the released version (2.5.0rc1).


On Thu, Feb 21, 2013 at 1:55 PM, Andrew Grieve  wrote:

> If I do the same thing with a clean client (merge next into master), then I
> get the same thing.
>
> I think what happened is that we generated a new version of docs
> at: docs/en/2.5.0rc1 on the next branch, but haven't yet merged that into
> master.
>
> So... I think you're fine. :)
>
>
> On Thu, Feb 21, 2013 at 4:01 PM, Marcel Kinard  wrote:
>
> > I was following the ContributorWorklow to fix these docs in both next and
> > master. The commit and push to next (see attached) looks good. However,
> > when I did "git merge next" after "git checkout master", I saw way more
> > changes than I expected:
> >  289 files changed, 19759 insertions(+), 132 deletions(-)
> > All rhe 2.5.0rc1 files were added, and most if not all of the edge files
> > had 2 or more line changes each. That doesn't look right to me, so I did
> > not do the "git push apache master". I wanted to stop and ask for advice
> > before I did any damage. Suggestions?
> >
> > -- Marcel Kinard
> >
> > Begin forwarded message:
> >
> > > From: marc...@apache.org
> > > Subject: docs commit: CB-2515: add lessons learned to the list of
> > pre-reqs
> > > Date: February 21, 2013 3:46:08 PM EST
> > > To: comm...@cordova.apache.org
> > > Reply-To: callback-...@cordova.apache.org
> > >
> > > Updated Branches:
> > >  refs/heads/next 10e89b559 -> 4c5e503e7
> > >
> > >
> > > CB-2515: add lessons learned to the list of pre-reqs
> > >
> > >
> > > Project: http://git-wip-us.apache.org/repos/asf/cordova-docs/repo
> > > Commit:
> > http://git-wip-us.apache.org/repos/asf/cordova-docs/commit/4c5e503e
> > > Tree:
> http://git-wip-us.apache.org/repos/asf/cordova-docs/tree/4c5e503e
> > > Diff:
> http://git-wip-us.apache.org/repos/asf/cordova-docs/diff/4c5e503e
> > >
> > > Branch: refs/heads/next
> > > Commit: 4c5e503e7fdd9b407beb5ffc2a997ecc4e093151
> > > Parents: 10e89b5
> > > Author: Marcel Kinard 
> > > Authored: Wed Feb 20 19:22:16 2013 -0500
> > > Committer: Marcel Kinard 
> > > Committed: Thu Feb 21 15:39:56 2013 -0500
> > >
> > > --
> > > .../guide/getting-started/windows-phone-8/index.md |   39
> > ---
> > > 1 files changed, 20 insertions(+), 19 deletions(-)
> > > --
> > >
> > >
> > >
> >
> http://git-wip-us.apache.org/repos/asf/cordova-docs/blob/4c5e503e/docs/en/edge/guide/getting-started/windows-phone-8/index.md
> > > --
> > > diff --git
> a/docs/en/edge/guide/getting-started/windows-phone-8/index.mdb/docs/en/edge/guide/getting-started/windows-phone-8/
> > index.md
> > > index 9d09ce6..4f6aa5d 100644
> > > --- a/docs/en/edge/guide/getting-started/windows-phone-8/index.md
> > > +++ b/docs/en/edge/guide/getting-started/windows-phone-8/index.md
> > > @@ -28,42 +28,42 @@ Note: Applications built with Apache Cordova for
> > Windows Phone 8 will only run o
> > > ---
> > >
> > > - Operating System:
> > > - - Windows 8, Windows 8 Pro
> > > +- Windows 8 or Windows 8 Pro
> > > +- The 64-bit version (x64) of Windows is required for the SDK.
> > > +- The Pro version is recommended so you can run a device
> > emulator.
> > >
> > > - Hardware:
> > > - - 6.5 GB of free hard disk space
> > > - - 4 GB RAM
> > > - - 64-bit (x64) CPU
> > > +- 6.5 GB of free hard disk space
> > > +- 4 GB RAM
> > > +- 64-bit (x64) CPU
> > >
> > > -- Windows Phone 8 Emulator:
> > > - - Windows 8 Pro edition or greater
> > > - - Requires a processor that supports Second Level Address Translation
> > (SLAT)
> > > +- Windows Phone 8 Emulator
> > > +- The phone emulator uses Hyper-V, so this list includes those
> > pre-reqs.
> > > +- Windows 8 Pro 64-bit edition or greater
> > > +- Requires a processor that supports virtualization and [Second
> > Level Address Translation (SLAT)](
> > http://en.wikipedia.org/wiki/Second_Level_Address_Translation)
> > > +- See the [list of Intel processors that support VT-x
> > (virtualization) and EPT (SLAT)](
> > http://ark.intel.com/Products/VirtualizationTechnology)
> > > +- Enable the virtualization capability (i.e., VT-x on Intel) in
> > your BIOS settings, as usually this is disabled by default.
> > >
> > > - SDK + IDE ( Visual Studio )
> > > - - VS Express for Windows Ph

Re: Symbol Mapping in Cordova

[Michael Brooks]

Sounds awesome Andrew, thanks for the concise recap.

I agree, JIRA isn't the ideal solution when considering today's options
around code conversation, but it's what we have as an Apache project. C'est
le vie.

Regardless, if you need a platform to do a task, then JIRA is the answer.
If you need to discuss something before deciding on the tasks to do, then
the mailing-list is the answer.

Michael

On Wed, Feb 20, 2013 at 1:58 PM, Andrew Grieve  wrote:

> Recap:
> I tested the common changes against iOS & Android and checked them in. I
> also checked in the blackberry ones, since they contain better test
> coverage in cordova-js than other platforms.
>
> I then emailed out asking if anyone could test the remaining changes on the
> branch against WP and webos. After 8 days of silence, I merged them in
> hopes that sometime between now and the 2.6 release someone will run the
> tests and discover if the changes broke anything.
>
>
> Outcome:
> -Instead of the mailing-list, we'll use JIRA issues to assign specific
> owners to the job of testing out these changes when they come up.
>
>
> What to do now:
> I'll create two sub-tasks of CB-2227. One for WP, one for webos.
>
>
> Sound right / good?
>
>
>
>
>
> On Wed, Feb 20, 2013 at 4:32 PM, Michal Mocny  wrote:
>
> > Agree with where this conversation is going.  I do think a "call to
> action"
> > for review is important (esp given the number of platforms) and perhaps
> > JIRA isn't the absolute worst way to do it ;)
> >
> > Another question: Are there plans to expand CI to other platforms?
>  Support
> > requesting tests for a remote feature branch?  This may remove some
> strain
> > on testers for the less popular platforms.
> >
> >
> > On Wed, Feb 20, 2013 at 4:29 PM, Filip Maj  wrote:
> >
> > > Good call Mike. Moving this sort of stuff to JIRA (and bringing back to
> > > list when necessary) makes a lot of sense.
> > >
> > > On 2/20/13 1:27 PM, "Michael Brooks"  wrote:
> > >
> > > >>
> > > >> If the "can you guys test my changes" answer is "no", then it'd be
> > > >>great to
> > > >> hear a "no" instead of 8 days of silence. That said, I think we'd be
> > > >>able
> > > >> to move faster if we just took some time to review/test each others'
> > > >> changes when necessary. We do this when processing pull requests
> from
> > > >> external devs, so why not do this for each other?
> > > >
> > > >
> > > >Totally valid and I support the suggestion of code reviews (as long as
> > its
> > > >not a hinderance to commit ease).
> > > >
> > > >It would be nice if we can bring conversations closer to the code (via
> > > >GitHub pull requests and code comments) instead of blasting emails at
> > each
> > > >other. I assume using GitHub more is against the Apache Way? We could
> > > >bring
> > > >conversations more into to JIRA. For this particular example, Andrew
> > could
> > > >create a JIRA issue and assign subtasks for the major platforms to
> test
> > to
> > > >branch and report back any issues.
> > > >
> > > >Michael
> > > >
> > > >On Wed, Feb 20, 2013 at 1:07 PM, Andrew Grieve 
> > > >wrote:
> > > >
> > > >> I agree with your sentiments, but I think it's impractical in
> > practice.
> > > >>We
> > > >> have ~11 platforms, and any change to common js affects them all.
> > > >>
> > > >> In this case, I would need to learn how to build & run on webos,
> > tizen,
> > > >>wp7
> > > >> and windowphone, as well as buying the required hardware to do so. A
> > > >>tall
> > > >> order for some refactoring changes.
> > > >>
> > > >> If the "can you guys test my changes" answer is "no", then it'd be
> > > >>great to
> > > >> hear a "no" instead of 8 days of silence. That said, I think we'd be
> > > >>able
> > > >> to move faster if we just took some time to review/test each others'
> > > >> changes when necessary. We do this when processing pull requests
> from
> > > >> external devs, so why not do this for each other?
> > > >>
> > > >>
> > > >>
>

Re: Symbol Mapping in Cordova

[Michael Brooks]

>
> If the "can you guys test my changes" answer is "no", then it'd be great to
> hear a "no" instead of 8 days of silence. That said, I think we'd be able
> to move faster if we just took some time to review/test each others'
> changes when necessary. We do this when processing pull requests from
> external devs, so why not do this for each other?


Totally valid and I support the suggestion of code reviews (as long as its
not a hinderance to commit ease).

It would be nice if we can bring conversations closer to the code (via
GitHub pull requests and code comments) instead of blasting emails at each
other. I assume using GitHub more is against the Apache Way? We could bring
conversations more into to JIRA. For this particular example, Andrew could
create a JIRA issue and assign subtasks for the major platforms to test to
branch and report back any issues.

Michael

On Wed, Feb 20, 2013 at 1:07 PM, Andrew Grieve  wrote:

> I agree with your sentiments, but I think it's impractical in practice. We
> have ~11 platforms, and any change to common js affects them all.
>
> In this case, I would need to learn how to build & run on webos, tizen, wp7
> and windowphone, as well as buying the required hardware to do so. A tall
> order for some refactoring changes.
>
> If the "can you guys test my changes" answer is "no", then it'd be great to
> hear a "no" instead of 8 days of silence. That said, I think we'd be able
> to move faster if we just took some time to review/test each others'
> changes when necessary. We do this when processing pull requests from
> external devs, so why not do this for each other?
>
>
>
>
>
>
> On Wed, Feb 20, 2013 at 3:47 PM, Michael Brooks  >wrote:
>
> > Agreed. Please take responsibility and test your code on devices (ideally
> > not simulators).
> >
> > If your change impacts multiple platforms, have it tested on those before
> > pushing to master.
> >
> > On Wed, Feb 20, 2013 at 12:42 PM, Filip Maj  wrote:
> >
> > > Andrew did you test it on a device? Don't think "hey guys can you test
> my
> > > changes" is a sustainable approach
> > >
> > > On 2/20/13 12:19 PM, "Andrew Grieve"  wrote:
> > >
> > > >Okay, I've interpreted the silence as a "just go ahead and merge it
> and
> > > >people will complain if it's broken".
> > > >
> > > >Seeing as we've now cut the next branch, I figured it was a good time
> to
> > > >merge these remaining changes in. So, I did. Please let me know if
> > symbols
> > > >aren't working.
> > > >
> > > >
> > > >On Tue, Feb 12, 2013 at 2:39 PM, Andrew Grieve 
> > > >wrote:
> > > >
> > > >> I've just merged in most of the changes for this (CB-2227). Again,
> the
> > > >> goal here was to move all plugin-specific logic out of common files.
> > > >>It's
> > > >> not the end-game solution, but a step in the right direction.
> > > >>
> > > >> There are still some changes left on the symbolmapping branch that
> > > >>affect
> > > >> windows & webos. If there's someone who knows how, it would be great
> > if
> > > >>you
> > > >> could try merging in the branch and ensure mobile-spec is still
> > working
> > > >> with the changes. If so, these changes can also be merged into
> master.
> > > >>
> > > >>
> > > >>
> > > >> On Tue, Jan 29, 2013 at 3:38 PM, Andrew Grieve
> > > >>wrote:
> > > >>
> > > >>> This is now finished in the branch. There is now *no* plugin logic
> > left
> > > >>> in common.js, nor in any platform.js files.
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > >
> https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=shortlog;h=re
> > > >>>fs/heads/symbolmapping
> > > >>>
> > > >>> There is one exception, and that's things like the "app" plugin,
> > where
> > > >>> it's not really a plugin that a platform can live without.
> > > >>>
> > > >>> Changes of interest:
> > > >>> 1. In tests, I've added helpers for stubbing out modules & for
> > stubbing
> > > >>> out properties. I used this to be abl

Re: Symbol Mapping in Cordova

[Michael Brooks]

Agreed. Please take responsibility and test your code on devices (ideally
not simulators).

If your change impacts multiple platforms, have it tested on those before
pushing to master.

On Wed, Feb 20, 2013 at 12:42 PM, Filip Maj  wrote:

> Andrew did you test it on a device? Don't think "hey guys can you test my
> changes" is a sustainable approach
>
> On 2/20/13 12:19 PM, "Andrew Grieve"  wrote:
>
> >Okay, I've interpreted the silence as a "just go ahead and merge it and
> >people will complain if it's broken".
> >
> >Seeing as we've now cut the next branch, I figured it was a good time to
> >merge these remaining changes in. So, I did. Please let me know if symbols
> >aren't working.
> >
> >
> >On Tue, Feb 12, 2013 at 2:39 PM, Andrew Grieve 
> >wrote:
> >
> >> I've just merged in most of the changes for this (CB-2227). Again, the
> >> goal here was to move all plugin-specific logic out of common files.
> >>It's
> >> not the end-game solution, but a step in the right direction.
> >>
> >> There are still some changes left on the symbolmapping branch that
> >>affect
> >> windows & webos. If there's someone who knows how, it would be great if
> >>you
> >> could try merging in the branch and ensure mobile-spec is still working
> >> with the changes. If so, these changes can also be merged into master.
> >>
> >>
> >>
> >> On Tue, Jan 29, 2013 at 3:38 PM, Andrew Grieve
> >>wrote:
> >>
> >>> This is now finished in the branch. There is now *no* plugin logic left
> >>> in common.js, nor in any platform.js files.
> >>>
> >>>
> >>>
> >>>
> https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=shortlog;h=re
> >>>fs/heads/symbolmapping
> >>>
> >>> There is one exception, and that's things like the "app" plugin, where
> >>> it's not really a plugin that a platform can live without.
> >>>
> >>> Changes of interest:
> >>> 1. In tests, I've added helpers for stubbing out modules & for stubbing
> >>> out properties. I used this to be able to undo symbol mapping within
> >>>tests.
> >>>
> >>> var propertyreplacer = require('cordova/propertyreplacer');
> >>> propertyreplacer.stub(platform, 'id', 'test');
> >>>
> >>> var modulereplacer = require('cordova/modulereplacer');
> >>> modulereplacer.replace('cordova/platform', {id:'test',
> >>> initialize:createSpy()});
> >>>
> >>> 2. Loading plugins by name (aka, looping through all defined modules
> >>>and
> >>> loading the ones that have names that match a pattern).
> >>> A) "symbols" Modules that have the name "symbols" are loaded to define
> >>> their plugin's module->JS symbol mappings (merges/clobbers/defaults).
> >>>On
> >>> Blackberry, sub-platform symbol files are called "bbsymbols".
> >>> B) "plugininit" Modules that have the name "plugininit" are loaded to
> >>> perform any custom start-up logic.
> >>> C) "*Proxy" On Windows8, modules that end with "Proxy" are loaded on
> >>> start-up.
> >>>
> >>> I don't love the looping-through-module-names approach, but thought it
> >>> was a good initial solution while we talk about better ideas. To do
> >>>this, I
> >>> had to make the moduleMap exported, which it wasn't before. Certainly
> >>> interested to hear if this is a really bad idea, and what alternatives
> >>>we
> >>> could use going forward.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Thu, Jan 17, 2013 at 12:45 PM, Andrew Grieve
> >>>wrote:
> >>>
>  Pushed up the change with the File plugin being registered in this new
>  way. Please let me know if you have concerns about it, since the next
> step
>  is moving over other plugin APIs, which is boring work :P.
> 
>  Also, let's move any discussion into the JIRA issue:
>  https://issues.apache.org/jira/browse/CB-2227
> 
> 
> 
>  On Wed, Jan 16, 2013 at 4:35 PM, Andrew Grieve
> wrote:
> 
> > Branch started!
> >
> > I've completed steps 1 & 2.
> >
> >
> >
> >
> https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=shortlog;h=
> >refs/heads/symbolmapping
> >
> >
> > On Wed, Jan 16, 2013 at 1:39 PM, Filip Maj  wrote:
> >
> >> This all seems reasonable. Shall we start a branch?
> >>
> >> On 1/15/13 2:47 PM, "Andrew Grieve"  wrote:
> >>
> >> >Sorry to dump another large email on the list, but I'm hoping this
> >> one is
> >> >at least less controversial :). I wrote up a plan for moving
> >> >module->symbol
> >> >mapping out of common.js & platform.js and into individual plugins.
> >> >
> >> >If you have feedback/comments, let me know.
> >> >
> >> >* Goals:
> >> >
> >> >   - Change from listing module->symbol mapping within common.js &
> >> >   platform.js, to listing this within the plugins themselves.
> >> >   - Support apps that don't want us to clobber global symbols.
> >> >  - aka, allow module->symbol mapping to be turned off
> >> >   - Allow retrieval of clobbered globals
> >> >  - Currently modules save it themselves when they

Re: docs on cordova.apache.org

[Michael Brooks]

Attention: Expect a one hour outage on docs.cordova.io.

I'll be updating the DNS for docs.cordova.io to use A-records instead of
HTTP Redirects because it's faster.

You can still access the docs using the full path:
http://cordova.apache.org/docs/en/2.4.0

You can also access the PhoneGap Documentation (nearly identical) at
http://docs.phonegap.com/

Michael

On Tue, Feb 19, 2013 at 4:57 PM, Michael Brooks wrote:

> Yay! Board Report another objective complete!
>
>
> Or better said: Yay! Another board report objective complete!
>
> On Tue, Feb 19, 2013 at 4:56 PM, Michael Brooks 
> wrote:
>
>> Yay! Board Report another objective complete!
>>
>>
>> On Tue, Feb 19, 2013 at 4:54 PM, Brian LeRoux  wrote:
>>
>>> Sweet. I'll update the board report. =)
>>>
>>> On Tue, Feb 19, 2013 at 4:38 PM, Michael Brooks <
>>> mich...@michaelbrooks.ca>wrote:
>>>
>>> > Update: Short-term goal [1] is now complete.
>>> >
>>> > The documentation is hosted on Apache infrastructure under the Apache
>>> > Cordova website. Additionally, http://docs.cordova.io/ redirects to
>>> the
>>> > Apache Cordova documentation.
>>> >
>>> > [1]: https://issues.apache.org/jira/browse/CB-1880
>>> >
>>> > On Thu, Feb 7, 2013 at 4:00 PM, Michael Brooks <
>>> mich...@michaelbrooks.ca
>>> > >wrote:
>>> >
>>> > > Steve Gill and myself sat down on Friday and reviewed the state of
>>> the
>>> > > documentation and where we need it to go.
>>> > >
>>> > > The short-term goal is to host the documentation on
>>> > > http://cordova.apache.org/docs and redirect with
>>> http://docs.cordova.io
>>> > >
>>> > > The long-term goal is everything else - theming, organization,
>>> document
>>> > > structure, etc. I don't want this discussion to happen on this
>>> thread.
>>> > >
>>> > > The short-term goal is small and focused. No automation for updating
>>> or
>>> > > anything like that. It's meant to achieve our objective on the Apache
>>> > board
>>> > > report and set a new objective. After hosting the documentation, we
>>> will
>>> > > need to cull the versions down to only those that are part of Apache
>>> > > Cordova (removing the old PhoneGap versions). We can look into an
>>> > > auto-update mechanism, although the generator will be replaced in the
>>> > > long-term goal.
>>> > >
>>> > > A downside to hosting the documentation on the website's SVN is that
>>> it
>>> > > will shoot up to roughly 600MB (300MB in public/ and 300MB in www/).
>>> We
>>> > can
>>> > > reduce this by removing the irrelevant versions.
>>> > >
>>> > > As Fil mentioned, this week has been busy. Before starting work, I'll
>>> > > create and update the relevant JIRA issues, then open a discussion on
>>> > where
>>> > > we want the docs to go.
>>> > >
>>> > > Michael
>>> > >
>>> > > On Thu, Feb 7, 2013 at 12:47 PM, Filip Maj  wrote:
>>> > >
>>> > >> Not sure.. Michael's had a busy week and he's had ideas on this one
>>> for
>>> > a
>>> > >> while. Mike?
>>> > >>
>>> > >> On 2/7/13 10:31 AM, "Marcel Kinard"  wrote:
>>> > >>
>>> > >> >Poking this thread with the release of 2.4.
>>> > >> >
>>> > >> >Where are we at?
>>> > >> >
>>> > >> >Is there anything I can do to help?
>>> > >> >
>>> > >> >-- Marcel Kinard
>>> > >> >
>>> > >> >On Jan 17, 2013, at 12:19 PM, Michael Brooks <
>>> mich...@michaelbrooks.ca
>>> > >
>>> > >> >wrote:
>>> > >> >
>>> > >> >>>
>>> > >> >>> I've got Jenkins running locally, pulling from cordova-docs,
>>> polling
>>> > >> >>>daily,
>>> > >> >>> and generating the docs. But the SVN Publisher doesn't seem to
>>> work:
>>> > >> >>> https://wiki.jenkins-ci.org/display/JENKINS/SVN+Publisher (I
>>>

Re: docs on cordova.apache.org

[Michael Brooks]

>
> Yay! Board Report another objective complete!


Or better said: Yay! Another board report objective complete!

On Tue, Feb 19, 2013 at 4:56 PM, Michael Brooks wrote:

> Yay! Board Report another objective complete!
>
>
> On Tue, Feb 19, 2013 at 4:54 PM, Brian LeRoux  wrote:
>
>> Sweet. I'll update the board report. =)
>>
>> On Tue, Feb 19, 2013 at 4:38 PM, Michael Brooks > >wrote:
>>
>> > Update: Short-term goal [1] is now complete.
>> >
>> > The documentation is hosted on Apache infrastructure under the Apache
>> > Cordova website. Additionally, http://docs.cordova.io/ redirects to the
>> > Apache Cordova documentation.
>> >
>> > [1]: https://issues.apache.org/jira/browse/CB-1880
>> >
>> > On Thu, Feb 7, 2013 at 4:00 PM, Michael Brooks <
>> mich...@michaelbrooks.ca
>> > >wrote:
>> >
>> > > Steve Gill and myself sat down on Friday and reviewed the state of the
>> > > documentation and where we need it to go.
>> > >
>> > > The short-term goal is to host the documentation on
>> > > http://cordova.apache.org/docs and redirect with
>> http://docs.cordova.io
>> > >
>> > > The long-term goal is everything else - theming, organization,
>> document
>> > > structure, etc. I don't want this discussion to happen on this thread.
>> > >
>> > > The short-term goal is small and focused. No automation for updating
>> or
>> > > anything like that. It's meant to achieve our objective on the Apache
>> > board
>> > > report and set a new objective. After hosting the documentation, we
>> will
>> > > need to cull the versions down to only those that are part of Apache
>> > > Cordova (removing the old PhoneGap versions). We can look into an
>> > > auto-update mechanism, although the generator will be replaced in the
>> > > long-term goal.
>> > >
>> > > A downside to hosting the documentation on the website's SVN is that
>> it
>> > > will shoot up to roughly 600MB (300MB in public/ and 300MB in www/).
>> We
>> > can
>> > > reduce this by removing the irrelevant versions.
>> > >
>> > > As Fil mentioned, this week has been busy. Before starting work, I'll
>> > > create and update the relevant JIRA issues, then open a discussion on
>> > where
>> > > we want the docs to go.
>> > >
>> > > Michael
>> > >
>> > > On Thu, Feb 7, 2013 at 12:47 PM, Filip Maj  wrote:
>> > >
>> > >> Not sure.. Michael's had a busy week and he's had ideas on this one
>> for
>> > a
>> > >> while. Mike?
>> > >>
>> > >> On 2/7/13 10:31 AM, "Marcel Kinard"  wrote:
>> > >>
>> > >> >Poking this thread with the release of 2.4.
>> > >> >
>> > >> >Where are we at?
>> > >> >
>> > >> >Is there anything I can do to help?
>> > >> >
>> > >> >-- Marcel Kinard
>> > >> >
>> > >> >On Jan 17, 2013, at 12:19 PM, Michael Brooks <
>> mich...@michaelbrooks.ca
>> > >
>> > >> >wrote:
>> > >> >
>> > >> >>>
>> > >> >>> I've got Jenkins running locally, pulling from cordova-docs,
>> polling
>> > >> >>>daily,
>> > >> >>> and generating the docs. But the SVN Publisher doesn't seem to
>> work:
>> > >> >>> https://wiki.jenkins-ci.org/display/JENKINS/SVN+Publisher (I
>> tested
>> > >> it
>> > >> >>>on
>> > >> >>> another SVN repo, not Apache's) -- reports success but nothing is
>> > >> >>>uploaded.
>> > >> >>> This could be a solution in the interim if I could get the
>> publisher
>> > >> to
>> > >> >>
>> > >> >>
>> > >> >> Well, it's an interesting experiment. I don't have the time to
>> look
>> > >> >>into it
>> > >> >> now, but
>> > >> >> as I said I'm working to free up February for the documentation
>> > update.
>> > >> >> I'll pick
>> > >> >> your brain about the Jenkins stuff then. Thanks for

Re: docs on cordova.apache.org

[Michael Brooks]

Yay! Board Report another objective complete!

On Tue, Feb 19, 2013 at 4:54 PM, Brian LeRoux  wrote:

> Sweet. I'll update the board report. =)
>
> On Tue, Feb 19, 2013 at 4:38 PM, Michael Brooks  >wrote:
>
> > Update: Short-term goal [1] is now complete.
> >
> > The documentation is hosted on Apache infrastructure under the Apache
> > Cordova website. Additionally, http://docs.cordova.io/ redirects to the
> > Apache Cordova documentation.
> >
> > [1]: https://issues.apache.org/jira/browse/CB-1880
> >
> > On Thu, Feb 7, 2013 at 4:00 PM, Michael Brooks  > >wrote:
> >
> > > Steve Gill and myself sat down on Friday and reviewed the state of the
> > > documentation and where we need it to go.
> > >
> > > The short-term goal is to host the documentation on
> > > http://cordova.apache.org/docs and redirect with
> http://docs.cordova.io
> > >
> > > The long-term goal is everything else - theming, organization, document
> > > structure, etc. I don't want this discussion to happen on this thread.
> > >
> > > The short-term goal is small and focused. No automation for updating or
> > > anything like that. It's meant to achieve our objective on the Apache
> > board
> > > report and set a new objective. After hosting the documentation, we
> will
> > > need to cull the versions down to only those that are part of Apache
> > > Cordova (removing the old PhoneGap versions). We can look into an
> > > auto-update mechanism, although the generator will be replaced in the
> > > long-term goal.
> > >
> > > A downside to hosting the documentation on the website's SVN is that it
> > > will shoot up to roughly 600MB (300MB in public/ and 300MB in www/). We
> > can
> > > reduce this by removing the irrelevant versions.
> > >
> > > As Fil mentioned, this week has been busy. Before starting work, I'll
> > > create and update the relevant JIRA issues, then open a discussion on
> > where
> > > we want the docs to go.
> > >
> > > Michael
> > >
> > > On Thu, Feb 7, 2013 at 12:47 PM, Filip Maj  wrote:
> > >
> > >> Not sure.. Michael's had a busy week and he's had ideas on this one
> for
> > a
> > >> while. Mike?
> > >>
> > >> On 2/7/13 10:31 AM, "Marcel Kinard"  wrote:
> > >>
> > >> >Poking this thread with the release of 2.4.
> > >> >
> > >> >Where are we at?
> > >> >
> > >> >Is there anything I can do to help?
> > >> >
> > >> >-- Marcel Kinard
> > >> >
> > >> >On Jan 17, 2013, at 12:19 PM, Michael Brooks <
> mich...@michaelbrooks.ca
> > >
> > >> >wrote:
> > >> >
> > >> >>>
> > >> >>> I've got Jenkins running locally, pulling from cordova-docs,
> polling
> > >> >>>daily,
> > >> >>> and generating the docs. But the SVN Publisher doesn't seem to
> work:
> > >> >>> https://wiki.jenkins-ci.org/display/JENKINS/SVN+Publisher (I
> tested
> > >> it
> > >> >>>on
> > >> >>> another SVN repo, not Apache's) -- reports success but nothing is
> > >> >>>uploaded.
> > >> >>> This could be a solution in the interim if I could get the
> publisher
> > >> to
> > >> >>
> > >> >>
> > >> >> Well, it's an interesting experiment. I don't have the time to look
> > >> >>into it
> > >> >> now, but
> > >> >> as I said I'm working to free up February for the documentation
> > update.
> > >> >> I'll pick
> > >> >> your brain about the Jenkins stuff then. Thanks for looking into
> it.
> > >> >>
> > >> >> which by the way, the whole tree right now is over
> > >> >>> 300MB. en/edge right now is only 7MB
> > >> >>
> > >> >>
> > >> >> That's not a big concern. The rewrite of the documentation will
> only
> > >> >> version the
> > >> >> latest. This will make internationalization contributions more
> > >> >>confusing,
> > >> >> since
> > >> >> most update older version of Apache Cordova, but we can solve tha

Re: docs on cordova.apache.org

[Michael Brooks]

Update: Short-term goal [1] is now complete.

The documentation is hosted on Apache infrastructure under the Apache
Cordova website. Additionally, http://docs.cordova.io/ redirects to the
Apache Cordova documentation.

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

On Thu, Feb 7, 2013 at 4:00 PM, Michael Brooks wrote:

> Steve Gill and myself sat down on Friday and reviewed the state of the
> documentation and where we need it to go.
>
> The short-term goal is to host the documentation on
> http://cordova.apache.org/docs and redirect with http://docs.cordova.io
>
> The long-term goal is everything else - theming, organization, document
> structure, etc. I don't want this discussion to happen on this thread.
>
> The short-term goal is small and focused. No automation for updating or
> anything like that. It's meant to achieve our objective on the Apache board
> report and set a new objective. After hosting the documentation, we will
> need to cull the versions down to only those that are part of Apache
> Cordova (removing the old PhoneGap versions). We can look into an
> auto-update mechanism, although the generator will be replaced in the
> long-term goal.
>
> A downside to hosting the documentation on the website's SVN is that it
> will shoot up to roughly 600MB (300MB in public/ and 300MB in www/). We can
> reduce this by removing the irrelevant versions.
>
> As Fil mentioned, this week has been busy. Before starting work, I'll
> create and update the relevant JIRA issues, then open a discussion on where
> we want the docs to go.
>
> Michael
>
> On Thu, Feb 7, 2013 at 12:47 PM, Filip Maj  wrote:
>
>> Not sure.. Michael's had a busy week and he's had ideas on this one for a
>> while. Mike?
>>
>> On 2/7/13 10:31 AM, "Marcel Kinard"  wrote:
>>
>> >Poking this thread with the release of 2.4.
>> >
>> >Where are we at?
>> >
>> >Is there anything I can do to help?
>> >
>> >-- Marcel Kinard
>> >
>> >On Jan 17, 2013, at 12:19 PM, Michael Brooks 
>> >wrote:
>> >
>> >>>
>> >>> I've got Jenkins running locally, pulling from cordova-docs, polling
>> >>>daily,
>> >>> and generating the docs. But the SVN Publisher doesn't seem to work:
>> >>> https://wiki.jenkins-ci.org/display/JENKINS/SVN+Publisher (I tested
>> it
>> >>>on
>> >>> another SVN repo, not Apache's) -- reports success but nothing is
>> >>>uploaded.
>> >>> This could be a solution in the interim if I could get the publisher
>> to
>> >>
>> >>
>> >> Well, it's an interesting experiment. I don't have the time to look
>> >>into it
>> >> now, but
>> >> as I said I'm working to free up February for the documentation update.
>> >> I'll pick
>> >> your brain about the Jenkins stuff then. Thanks for looking into it.
>> >>
>> >> which by the way, the whole tree right now is over
>> >>> 300MB. en/edge right now is only 7MB
>> >>
>> >>
>> >> That's not a big concern. The rewrite of the documentation will only
>> >> version the
>> >> latest. This will make internationalization contributions more
>> >>confusing,
>> >> since
>> >> most update older version of Apache Cordova, but we can solve that
>> >>with...
>> >> documentation.
>> >>
>> >> On Wed, Jan 16, 2013 at 10:04 AM, Shazron  wrote:
>> >>
>> >>> I've got Jenkins running locally, pulling from cordova-docs, polling
>> >>>daily,
>> >>> and generating the docs. But the SVN Publisher doesn't seem to work:
>> >>> https://wiki.jenkins-ci.org/display/JENKINS/SVN+Publisher (I tested
>> it
>> >>>on
>> >>> another SVN repo, not Apache's) -- reports success but nothing is
>> >>>uploaded.
>> >>> This could be a solution in the interim if I could get the publisher
>> to
>> >>> actually publish -- which by the way, the whole tree right now is over
>> >>> 300MB. en/edge right now is only 7MB.
>> >>>
>> >>>
>> >>> On Mon, Jan 14, 2013 at 9:32 AM, Shazron  wrote:
>> >>>
>> >>>> I agree with Ross that it should be on Apache's servers and not
>> >>>>somewhere
>> >>>> else (like Amazon S3). At most some dev could l

Re: cordova.io domain name

[Michael Brooks]

Update from my IRC #asfinfra chat:

Apache has a strong stance that the domain must be project.apache.org [1].
Custom domains can be used but must redirect to the original domain and
cannot mask the original domain. Also, custom domains cannot contain the
word "apache".

There are precedents where domains have been donated to Apache.
Unfortunately, they were not able to provide any specifics. I did find an
example where Oracle donated OpenOffice.org to Apache [2]. However, the
infrastructure guys emphasized that OpenOffice is a special case and has
been an example to a number of rules.

So, as it stands, I'm where I was before.

My main outstanding question is: Can I donate cordova.io to Apache. If so,
how?

[1] https://blogs.apache.org/OOo/entry/what_is_a_podling
[2] https://blogs.apache.org/foundation/entry/if_it_s_not_at

On Thu, Feb 14, 2013 at 10:30 AM, Michael Brooks
wrote:

> Yea, I'll jump into the IRC channel today. I thought I'd check here in
> case anyone has some magical wiki links about it.
>
>
> On Thu, Feb 14, 2013 at 9:39 AM, Filip Maj  wrote:
>
>> Ask infra? I'm afraid of what they'll say but probably have to do it.
>>
>> On 2/13/13 10:32 PM, "Michael Brooks"  wrote:
>>
>> >Hi all,
>> >
>> >The domain renewal for cordova.io is due in March 2013.
>> >
>> >How do other Apache projects manage custom domains? I've searched around
>> >apache.org without much luck.
>> >
>> >During our incubation period, there was a brief discussion about the
>> >domain
>> >name, but little progress was made. For myself, there are two questions:
>> >
>> >1. Does the Apache foundation accept domain transfers?
>> >  - It seems wrong to have a single person in charge of the domain
>> >ownership.
>> >  - Regardless, I wil continue to renew the domain if Apache does not
>> want
>> >the responsibility.
>> >
>> >2. Does Apache infrastructure support custom domains?
>> >  - So that we do not need to do the domain redirect.
>> >  - Since CouchDB uses redirects as well, I am guessing the answer is
>> "no"
>> >
>> >The only resource that I can find is on website management [1]. However,
>> >it
>> >does not address domain names.
>> >
>> >Thanks,
>> >Michael
>> >
>> >[1] http://apache.org/dev/#web
>>
>>
>

Re: cordova.io domain name

[Michael Brooks]

Yea, I'll jump into the IRC channel today. I thought I'd check here in case
anyone has some magical wiki links about it.

On Thu, Feb 14, 2013 at 9:39 AM, Filip Maj  wrote:

> Ask infra? I'm afraid of what they'll say but probably have to do it.
>
> On 2/13/13 10:32 PM, "Michael Brooks"  wrote:
>
> >Hi all,
> >
> >The domain renewal for cordova.io is due in March 2013.
> >
> >How do other Apache projects manage custom domains? I've searched around
> >apache.org without much luck.
> >
> >During our incubation period, there was a brief discussion about the
> >domain
> >name, but little progress was made. For myself, there are two questions:
> >
> >1. Does the Apache foundation accept domain transfers?
> >  - It seems wrong to have a single person in charge of the domain
> >ownership.
> >  - Regardless, I wil continue to renew the domain if Apache does not want
> >the responsibility.
> >
> >2. Does Apache infrastructure support custom domains?
> >  - So that we do not need to do the domain redirect.
> >  - Since CouchDB uses redirects as well, I am guessing the answer is "no"
> >
> >The only resource that I can find is on website management [1]. However,
> >it
> >does not address domain names.
> >
> >Thanks,
> >Michael
> >
> >[1] http://apache.org/dev/#web
>
>

cordova.io domain name

[Michael Brooks]

Hi all,

The domain renewal for cordova.io is due in March 2013.

How do other Apache projects manage custom domains? I've searched around
apache.org without much luck.

During our incubation period, there was a brief discussion about the domain
name, but little progress was made. For myself, there are two questions:

1. Does the Apache foundation accept domain transfers?
  - It seems wrong to have a single person in charge of the domain
ownership.
  - Regardless, I wil continue to renew the domain if Apache does not want
the responsibility.

2. Does Apache infrastructure support custom domains?
  - So that we do not need to do the domain redirect.
  - Since CouchDB uses redirects as well, I am guessing the answer is "no"

The only resource that I can find is on website management [1]. However, it
does not address domain names.

Thanks,
Michael

[1] http://apache.org/dev/#web

Re: cordova-cli documentation in cordova-docs

[Michael Brooks]

I would vote for it to be included in the Cordova documentation (
docs.cordova.io).

Michael

On Thu, Feb 7, 2013 at 3:10 PM, Anis KADRI  wrote:

> I don't know about getting started but I vote for it being part of
> docs.cordova.io
>
>
> On Thu, Feb 7, 2013 at 3:04 PM, Filip Maj  wrote:
>
> > We have none at the moment :)
> >
> > Any thoughts/recommendations on where it should go, what it should look
> > like? Part of the getting started guide or no?
> >
> >
>

Re: refactoring mobile spec (was: Creating repos for core plugins)

[Michael Brooks]

Yes, each plugin should be responsible for its own tests. This is something
that we should practice with the core plugins and encourage with
third-party plugins.

I'm still playing catch up, but this is something that must be added to the
plugin spec IMO.

Michael

On Thu, Feb 7, 2013 at 12:48 PM, Filip Maj  wrote:

> This is definitely what I had envisioned as well..
>
> On 2/7/13 11:13 AM, "Andrew Grieve"  wrote:
>
> >If someone wants to lead the charge on this angle of the plugin
> >splitting-out, that would be awesome. On the priority list though, I think
> >it's pretty low.  Right now you have to set up the project file, add the
> >JS, and then run the tests. This model will still work when plugins are
> >separated out.
> >
> >
> >On Thu, Feb 7, 2013 at 1:21 PM, Marcel Kinard  wrote:
> >
> >> I don't want to jump forward too far, but would it make sense to breakup
> >> mobile-spec in a similar way so that the tests for a plugin are actually
> >> located in the plugin's repo? Then the test and the function under test
> >> would be synchronized. And it could potentially open the way for
> >> third-parties to supply tests for their own plugins.
> >>
> >> -- Marcel Kinard
> >>
> >> On Feb 7, 2013, at 10:44 AM, Andrew Grieve 
> wrote:
> >>
> >> > https://issues.apache.org/jira/browse/INFRA-5839
> >>
> >>
>
>

Re: docs on cordova.apache.org

[Michael Brooks]

Steve Gill and myself sat down on Friday and reviewed the state of the
documentation and where we need it to go.

The short-term goal is to host the documentation on
http://cordova.apache.org/docs and redirect with http://docs.cordova.io

The long-term goal is everything else - theming, organization, document
structure, etc. I don't want this discussion to happen on this thread.

The short-term goal is small and focused. No automation for updating or
anything like that. It's meant to achieve our objective on the Apache board
report and set a new objective. After hosting the documentation, we will
need to cull the versions down to only those that are part of Apache
Cordova (removing the old PhoneGap versions). We can look into an
auto-update mechanism, although the generator will be replaced in the
long-term goal.

A downside to hosting the documentation on the website's SVN is that it
will shoot up to roughly 600MB (300MB in public/ and 300MB in www/). We can
reduce this by removing the irrelevant versions.

As Fil mentioned, this week has been busy. Before starting work, I'll
create and update the relevant JIRA issues, then open a discussion on where
we want the docs to go.

Michael

On Thu, Feb 7, 2013 at 12:47 PM, Filip Maj  wrote:

> Not sure.. Michael's had a busy week and he's had ideas on this one for a
> while. Mike?
>
> On 2/7/13 10:31 AM, "Marcel Kinard"  wrote:
>
> >Poking this thread with the release of 2.4.
> >
> >Where are we at?
> >
> >Is there anything I can do to help?
> >
> >-- Marcel Kinard
> >
> >On Jan 17, 2013, at 12:19 PM, Michael Brooks 
> >wrote:
> >
> >>>
> >>> I've got Jenkins running locally, pulling from cordova-docs, polling
> >>>daily,
> >>> and generating the docs. But the SVN Publisher doesn't seem to work:
> >>> https://wiki.jenkins-ci.org/display/JENKINS/SVN+Publisher (I tested it
> >>>on
> >>> another SVN repo, not Apache's) -- reports success but nothing is
> >>>uploaded.
> >>> This could be a solution in the interim if I could get the publisher to
> >>
> >>
> >> Well, it's an interesting experiment. I don't have the time to look
> >>into it
> >> now, but
> >> as I said I'm working to free up February for the documentation update.
> >> I'll pick
> >> your brain about the Jenkins stuff then. Thanks for looking into it.
> >>
> >> which by the way, the whole tree right now is over
> >>> 300MB. en/edge right now is only 7MB
> >>
> >>
> >> That's not a big concern. The rewrite of the documentation will only
> >> version the
> >> latest. This will make internationalization contributions more
> >>confusing,
> >> since
> >> most update older version of Apache Cordova, but we can solve that
> >>with...
> >> documentation.
> >>
> >> On Wed, Jan 16, 2013 at 10:04 AM, Shazron  wrote:
> >>
> >>> I've got Jenkins running locally, pulling from cordova-docs, polling
> >>>daily,
> >>> and generating the docs. But the SVN Publisher doesn't seem to work:
> >>> https://wiki.jenkins-ci.org/display/JENKINS/SVN+Publisher (I tested it
> >>>on
> >>> another SVN repo, not Apache's) -- reports success but nothing is
> >>>uploaded.
> >>> This could be a solution in the interim if I could get the publisher to
> >>> actually publish -- which by the way, the whole tree right now is over
> >>> 300MB. en/edge right now is only 7MB.
> >>>
> >>>
> >>> On Mon, Jan 14, 2013 at 9:32 AM, Shazron  wrote:
> >>>
> >>>> I agree with Ross that it should be on Apache's servers and not
> >>>>somewhere
> >>>> else (like Amazon S3). At most some dev could locally install Jenkins
> >>>>and
> >>>> run a CI server with a script that can auto update the SVN repo (using
> >>>> their creds), or something - until we can get a permanent solution
> >>>>
> >>>>
> >>>> On Mon, Jan 14, 2013 at 9:22 AM, Michael Brooks <
> >>> mich...@michaelbrooks.ca>wrote:
> >>>>
> >>>>> @Andrew I was thinking S3 so that a service can auto-update on each
> >>>>> commit.
> >>>>> From Yohei's experience with the cordova.apache.org SVN setup, it
> >>>>>looks
> >>>>> like automating that is a headache.
> >>>>>

[jira] [Resolved] (CB-2374) Tag Docs

[Michael Brooks (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CB-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Brooks resolved CB-2374.


Resolution: Fixed

> Tag Docs
> 
>
> Key: CB-2374
> URL: https://issues.apache.org/jira/browse/CB-2374
> Project: Apache Cordova
>  Issue Type: Sub-task
>  Components: Docs
>Reporter: Filip Maj
>    Assignee: Michael Brooks
> Fix For: 2.4.0
>
>
> After all platforms have been tagged, the docs can be tagged.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CB-2374) Tag Docs

[Michael Brooks (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13571450#comment-13571450
 ] 

Michael Brooks commented on CB-2374:


Tag 2.4.0 as commit 
[8778e5|https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=commit;h=8778e583a9e9febfe4c1672a0243628a44d564dc]

> Tag Docs
> 
>
> Key: CB-2374
> URL: https://issues.apache.org/jira/browse/CB-2374
> Project: Apache Cordova
>  Issue Type: Sub-task
>  Components: Docs
>Reporter: Filip Maj
>    Assignee: Michael Brooks
> Fix For: 2.4.0
>
>
> After all platforms have been tagged, the docs can be tagged.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CB-2351) Tag Hello World App

[Michael Brooks (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-2351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13570658#comment-13570658
 ] 

Michael Brooks commented on CB-2351:


Tag 2.4.0 as commit 
[355cb8|https://git-wip-us.apache.org/repos/asf?p=cordova-app-hello-world.git;a=commit;h=355cb8b8eac8b910fcb6c848f64b128f99024158]

> Tag Hello World App
> ---
>
> Key: CB-2351
> URL: https://issues.apache.org/jira/browse/CB-2351
> Project: Apache Cordova
>  Issue Type: Sub-task
>  Components: App Hello World
>Reporter: Filip Maj
>    Assignee: Michael Brooks
> Fix For: 2.4.0
>
>
> Tag sample application so that each platform can cut a copy of the 
> application.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (CB-2351) Tag Hello World App

[Michael Brooks (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CB-2351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Brooks resolved CB-2351.


Resolution: Fixed

> Tag Hello World App
> ---
>
> Key: CB-2351
> URL: https://issues.apache.org/jira/browse/CB-2351
> Project: Apache Cordova
>  Issue Type: Sub-task
>  Components: App Hello World
>Reporter: Filip Maj
>    Assignee: Michael Brooks
> Fix For: 2.4.0
>
>
> Tag sample application so that each platform can cut a copy of the 
> application.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CB-1365) Need to document config.xml

[Michael Brooks (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13568448#comment-13568448
 ] 

Michael Brooks commented on CB-1365:


Yup, I'll look into it.

> Need to document config.xml
> ---
>
> Key: CB-1365
> URL: https://issues.apache.org/jira/browse/CB-1365
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Docs
>Affects Versions: 2.2.0
>Reporter: Simon MacDonald
>Assignee: Filip Maj
> Fix For: 2.4.0
>
>
> Is there documentation somewhere regarding options in the config.xml file for 
> phonegap/cordova 2.0, specifically preferences. I see bits and pieces here 
> and there, but nothing all in one spot.
> Further edits necessary:
> - We should provide examples, like the iOS specific content doc
> - it might confuse people since our config.xml root element is actually 
> 'cordova', not 'widget' (yet) (+ file issue for 2.5)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: All platforms: config.xml documentation

[Michael Brooks]

Sounds good Fil!

On Tue, Jan 29, 2013 at 12:42 PM, Andrew Grieve wrote:

> Sounds great!
>
>
> On Tue, Jan 29, 2013 at 3:18 PM, Filip Maj  wrote:
>
> > Reference issue: https://issues.apache.org/jira/browse/CB-1365
> >
> > More and more work is going into support for various features of
> > config.xml. It is becoming _the_ spot to configure your application.
> >
> > Sadly, we have no documentation. It's not mentioned in the Getting
> Started
> > guides, either.
> >
> > Proposal:
> >
> > - the current "project settings" guide to be expanded to describe all of
> > the platform-agnostic elements in config.xml that help configure your app
> > - the current contents of "project settings" becomes a sub-section that
> is
> > platform-specific, as it only describes (currently) one of the elements
> of
> > config.xml
> > - explicitly mention + link to config.xml guide from the getting started
> > guides
> >
> >
>

Re: Cordova CLI (and by proxy, platform) requirements

[Michael Brooks]

About a year and a half ago, I started to refactor the BlackBerry bin/
(ANT) script. My goal was the following:

1. Use SDK path if explicitly stated in the config file (project.properties)
2. Otherwise search the PATH and use the SDK found
3. Otherwise fail noisily

Back during our client work days, our apps were often built for a specific
SDK (4.6, 5.0, or 6.0). The config file was an explicit way of telling
collaborators that the target SDK. However, as WebWorks and the Playbook
SDK emerged, explicitly stating the SDK became less a repetitive hassle.
This is why the PATH option would have been nice. In general, I think every
platform should strive to support PATHs. If you find that users need to
switch between multiple SDKs, then consider allowing the user to explicitly
override the default SDK PATH.

As for the prompting discussion: I don't mind prompting, but it MUST be
overridable for automation purposes. You should be able to provide an
option that overrides that particular prompt (`--bbwp`,
`--signing-password`, `--device-ip`, etc).

Michael

On Mon, Jan 28, 2013 at 4:25 PM, Filip Maj  wrote:

> Totally agree Jesse. My first pass at BB support includes interactive
> prompting. I would love to get rid of it, or provide another way to
> specify that stuff. Like you say, perhaps command line options is the way
> to go (if someone wants to automate the use of the script, for example).
>
> The easy fix is to spew out a big warning after you add BlackBerry to your
> project's platforms instructing the user to customize  file>. People who use Cordova BlackBerry already (like Don) do something
> like this as it is.
>
> On 1/28/13 3:53 PM, "Jesse"  wrote:
>
> >Fil, It will most likely not just be BB, so your solution may not be
> >future
> >proof.
> >I would draw a line in the sand stating that there must be a bb-config
> >file
> >which instructs the cli build command of which sdk version to use (via an
> >explicit path ). OR it could be a command line argument at build time.
> >I assume that we should be able to target any specific sdk version, and
> >this is not restricted to being a once only issue that can be resolved at
> >the time of 'adding a new platform target' and must be dealt with every
> >time we build.
> >
> >I think making this script interactive is extremely limiting if we want it
> >to be used by other tools. If this is not an issue, then go for it ...
> >
> >
> >
> >
> >
> >
> >On Mon, Jan 28, 2013 at 3:47 PM, Filip Maj  wrote:
> >
> >> So that's what I'm trying to see if we can fix.
> >>
> >> The multiple SDKs that use the same executable script name throws a
> >>wrench
> >> into this whole thing.. Lame.
> >>
> >> What if we drew a line in the sand and said for BlackBerry we only
> >>support
> >> BB10? Then we can get rid of prompts and tell people to put their BB10
> >>SDK
> >> (not their playbook SDK) bbwp path on their system PATH?
> >>
> >> On 1/28/13 3:37 PM, "Brian LeRoux"  wrote:
> >>
> >> >uh oh. so, does this mean we do both and put prompting behind a
> >> >configuration option?
> >> >
> >> >RECURSIVE ERROR
> >> >
> >> >On Mon, Jan 28, 2013 at 5:25 PM, Gord Tanner 
> wrote:
> >> >> I think the reason blackberry doesn't put the sdk on the path is
> >> >>because they need to have multiple sdk versions (all with the same
> >> >>command names) on the same machine.
> >> >>
> >> >> -1 for path
> >> >> +1 for prompting
> >> >>
> >> >> Sent from my iPhone
> >> >>
> >> >> On 2013-01-28, at 6:22 PM, Jesse MacFadyen 
> >> >>wrote:
> >> >>
> >> >>> +1 path and configuration for credentials.
> >> >>>
> >> >>> -1 prompting for values, or confirming previous values.
> >> >>>
> >> >>> I think the tool should be non-interactive, or at least that is my
> >> >>>expectation.
> >> >>>
> >> >>> On fail simply provide advice on how to remedy the situation.
> >> >>> Prompting for a path is out of scope IMO. Its much better to
> >>document
> >> >>> expectations and fail noisily when they are not met. I thinks.
> >> >>>
> >> >>> Cheers,
> >> >>>  Jesse
> >> >>>
> >> >>> Sent from my iPhone5
> >> >>>
> >> >>> On 2013-01-28, at 2:23 PM, Don Coleman 
> >>wrote:
> >> >>>
> >> >>> I have the Android tools in my path but not BlackBerry.
> >> >>>
> >> >>> Prompting for the BlackBerry file locations and passwords etc works
> >> >>>OK. It
> >> >>> would be nice to search the default location, or at least store all
> >> >>>this
> >> >>> info in ~/.cordova-cli so the next time I run the tool I can just
> >> >>>confirm
> >> >>> the previous entries.
> >> >>>
> >> >>> I like the way the yeoman.io audit script (
> >> >>> https://github.com/yeoman/yeoman/wiki/Manual-Install) checks for
> >> what's
> >> >>> required and offers solutions for what's missing.
> >> >>>
> >> >>>
> >> >>> On Mon, Jan 28, 2013 at 5:14 PM, Filip Maj  wrote:
> >> >>>
> >>  Hey all,
> >> 
> >>  Working out some bootstrap-type stuff for cordova-cli. Here's a
> >> situation
> >>  I am dealing with now in the cli code that I would

Re: ship 2.4 monday

[Michael Brooks]

I haven't heard any major blockers, so Monday Feb 4th seems good.

Michael

On Mon, Jan 28, 2013 at 11:31 AM, Filip Maj  wrote:

> Monday Feb 4th or w/e! Next week!
>
> On 1/28/13 11:25 AM, "Becky Gibson"  wrote:
>
> >-1 if you mean Monday as in today?
> >
> >I'd like to see the mobile-spec issues resolved.  I can't figure out why
> >my
> >mobile-spec file transfer fails and others do not.  I suspect it has to do
> >with the whitelist but am not certain.
> >
> >
> >On Mon, Jan 28, 2013 at 2:16 PM, Filip Maj  wrote:
> >
> >> +1 silence
> >>
> >> On 1/28/13 11:11 AM, "Brian LeRoux"  wrote:
> >>
> >> >remember: silence is assent!
> >>
> >>
>
>

Re: Cordova for Firefox OS

[Michael Brooks]

>
> I'm in favor of just using Cordova-FirefoxOS since it is an explicitly
> clear name that makes it easy to find.


I agree with Herm on using Cordova-FirefoxOS (cordova-firefoxos) for the
same reasons. Matching the official name is important for ease of use.

While we wait for Infra to create the repository, Dan and Gord can push to
a branch in the labs repo. That way the code can easily be pushed to the
official repo whenever it's created.

Michael

On Mon, Jan 28, 2013 at 11:23 AM, Dan Silivestru
wrote:

> I like the sound of FxOS, it's short :-)
>
> Also the CLI for deploying directly to device would be very helpful, Gord
> and I couldn't find a way to do it with the currently published docs.
> Looking forward to that addition.
>
> Dan.
>
>
> On Mon, Jan 28, 2013 at 1:29 PM, Herm Wong  >wrote:
>
> > The B2G name has been deprecated in favor of Firefox OS; internally (at
> > Mozilla) they seem to be using the acronym FxOS. I'm in favor of just
> using
> > Cordova-FirefoxOS since it is an explicitly clear name that makes it easy
> > to find.
> > I'm also in favor of Gord & Dan pushing up their Cordova-JS changes for
> > Firefox OS, I'll merge my changes after their initial commit.
> > I've been working directly with Mozilla to finalize some of CL interfaces
> > so that we will be able to using build scripts to package and deploy apps
> > directly to the devices.
> >
> > > Date: Mon, 28 Jan 2013 07:05:20 +0100
> > > Subject: Re: Cordova for Firefox OS
> > > From: g.nat...@gnstudio.com
> > > To: dev@cordova.apache.org
> > >
> > > Hi Gord,
> > >
> > > I'm trying to get a device too, as soon as I get I would volunteer to
> > test
> > > each new feature you will port on the device.
> > > Hope it can help...
> > >
> > > Giorgio
> > >
> > > On 1/28/13 2:51 AM, "Gord Tanner"  wrote:
> > >
> > > >Hello,
> > > >
> > > >Dan Silivestru and I were at a hackathon on the weekend at Mozilla and
> > we
> > > >took the day to port Cordova over to the Firefox OS phone.
> > > >
> > > >We got it running successfully on the simulator and device that day.
> > > > Currently it just supports firing of deviceready and the
> accelerometer
> > > >(not really tested).
> > > >
> > > >The code can be found here:
> > > >https://github.com/gtanner/cordova-b2g
> > > >
> > > >and the javascript code here:
> > > >https://github.com/gtanner/cordova-js
> > > >
> > > >We won a phone for our efforts (so did Fil and Steve) so we will have
> a
> > > >real device or two to test and work on for the platform.
> > > >
> > > >What is the next steps for getting this into the apache repo's and
> > merged
> > > >in?
> > >
> > >
> >
> >
>
>
>
> --
> Dan Silivestru
> +1 (519) 589-3624
>

Re: Cordova for Firefox OS

[Michael Brooks]

Nice work Gord!

I believe Herm Wong has been working on a Cordova Firefox OS implementation
as well. He's spent a number of days at Mozilla and has helped guide some
of their CLI work. Hopefully Herm can chime in on this thread and add some
more detail.

Before we rush a create a repo, we should decide on a name. Otherwise we'll
have another cordova-webworks / cordova-iphone mistakes. I thought the name
Boot2Gecko was deprecated in favour of FireFox OS.

Michael

On Sun, Jan 27, 2013 at 6:10 PM, Gord Tanner  wrote:

> Yes,
>
> The JavaScript is all very localized and new / unstable code is only
> included in the newly built cordova.b2g.js file.
>
> I would say it is zero risk commiting now.
>
> Would be awesome to get infra to create the cordova-b2g repo and to merge
> this in.
>
>
> On Sun, Jan 27, 2013 at 8:59 PM, Simon MacDonald
> wrote:
>
> > Don't quote me on this but I think we need to file an infrastructure
> ticket
> > to get a firefox OS repo opened. I don't see any reason why you couldn't
> > commit the JS now. Although on the JS maybe you want to create your own
> FF
> > OS branch until it becomes more stable.
> >
> > Simon Mac Donald
> > http://hi.im/simonmacdonald
> >
> >
> > On Sun, Jan 27, 2013 at 8:51 PM, Gord Tanner  wrote:
> >
> > > Hello,
> > >
> > > Dan Silivestru and I were at a hackathon on the weekend at Mozilla and
> we
> > > took the day to port Cordova over to the Firefox OS phone.
> > >
> > > We got it running successfully on the simulator and device that day.
> > >  Currently it just supports firing of deviceready and the accelerometer
> > > (not really tested).
> > >
> > > The code can be found here:
> > > https://github.com/gtanner/cordova-b2g
> > >
> > > and the javascript code here:
> > > https://github.com/gtanner/cordova-js
> > >
> > > We won a phone for our efforts (so did Fil and Steve) so we will have a
> > > real device or two to test and work on for the platform.
> > >
> > > What is the next steps for getting this into the apache repo's and
> merged
> > > in?
> > >
> >
>