Re: cordova-js commits on master but not on 3.2.x branch

And the js commits for blackberry did not change the js for other platforms! Win win. Sent from my iPhone > On Nov 7, 2013, at 6:56 PM, Carlos Santana wrote: > > Thank you Steve ! > > >> On Thu, Nov 7, 2013 at 8:06 PM, Steven Gill wrote: >> >> Sweet. None of these require re-tagging cordo

Re: cordova-js commits on master but not on 3.2.x branch

Thank you Steve ! On Thu, Nov 7, 2013 at 8:06 PM, Steven Gill wrote: > Sweet. None of these require re-tagging cordova-js. > > > On Thu, Nov 7, 2013 at 3:50 PM, Josh Soref wrote: > > > Carlos wrote: > > > Should the following commits should be included for 3.2 specially > > BB10 changes? > > >

MSDN subscriptions for contributors

I can't find the original email in my archives, but here is an email mentioning the availability of MSDN to apache commiters.[1] You'll need to go to [2] with your svn credentials and fill out the form. And I think you need to do it every year. [1] http://apache-database.10148.n7.nabble.com/Mic

Re: cordova-js commits on master but not on 3.2.x branch

Sweet. None of these require re-tagging cordova-js. On Thu, Nov 7, 2013 at 3:50 PM, Josh Soref wrote: > Carlos wrote: > > Should the following commits should be included for 3.2 specially > BB10 changes? > > On the subject of changes designed for 3.2, this set (for CCB-5258) is the > only thing

Re: CI failures - CLI & WP8

+1 We need to focus more on making sure tests pass on windows and mac as we make changes. On Thu, Nov 7, 2013 at 4:22 PM, Jesse wrote: > tests should be passing now. This is related to the fact that wp7/8 and > windows8 don't consider repo root to be platform root. > > It may make sense to to

Re: CI failures - CLI & WP8

tests should be passing now. This is related to the fact that wp7/8 and windows8 don't consider repo root to be platform root. It may make sense to to add another field to the platform objects to specify this, but I simply modified the tests to allow for it. Incidentally, these tests would be mu

Re: cordova-js commits on master but not on 3.2.x branch

Carlos wrote: > Should the following commits should be included for 3.2 specially BB10  > changes? On the subject of changes designed for 3.2, this set (for CCB-5258) is the only thing I have that I really want to get it in: ‎https://github.com/apache/cordova-cli/pull/70 https://github.com/apache

Re: cordova-js commits on master but not on 3.2.x branch

cordova-js has been retagged On Thu, Nov 7, 2013 at 3:01 PM, Steven Gill wrote: > Alright I got this. > > > On Thu, Nov 7, 2013 at 2:58 PM, Carlos Santana wrote: > >> Steve can you go ahead merge amd retag I'm out right now on a cfa meeting. >> >> --Carlos >> >> On Thursday, November 7, 2013, S

Re: cordova-js commits on master but not on 3.2.x branch

Alright I got this. On Thu, Nov 7, 2013 at 2:58 PM, Carlos Santana wrote: > Steve can you go ahead merge amd retag I'm out right now on a cfa meeting. > > --Carlos > > On Thursday, November 7, 2013, Steven Gill wrote: > > > Alright, lets do it. Carlos, you want to retag the JS? > > > > > > On T

Re: cordova-js commits on master but not on 3.2.x branch

Steve can you go ahead merge amd retag I'm out right now on a cfa meeting. --Carlos On Thursday, November 7, 2013, Steven Gill wrote: > Alright, lets do it. Carlos, you want to retag the JS? > > > On Thu, Nov 7, 2013 at 2:49 PM, Jesse > > wrote: > > > I am a plus one, if these items are intended

Re: cordova-js commits on master but not on 3.2.x branch

Alright, lets do it. Carlos, you want to retag the JS? On Thu, Nov 7, 2013 at 2:49 PM, Jesse wrote: > I am a plus one, if these items are intended to be in 3.2.0. > > Technically, all platforms should be updated so they are all built from the > same git commit. > > @purplecabbage > risingj.com

Re: cordova-js commits on master but not on 3.2.x branch

I am a plus one, if these items are intended to be in 3.2.0. Technically, all platforms should be updated so they are all built from the same git commit. @purplecabbage risingj.com On Thu, Nov 7, 2013 at 2:41 PM, Shazron wrote: > +1 > > > On Thu, Nov 7, 2013 at 2:17 PM, Steven Gill > wrote:

Re: cordova-js commits on master but not on 3.2.x branch

+1 On Thu, Nov 7, 2013 at 2:17 PM, Steven Gill wrote: > Blackberry and Android would need to get retagged. I have no issue with > retagging the JS in-regards to firefoxos. Other platform maintainers can > chime in. > > > On Thu, Nov 7, 2013 at 2:08 PM, Carlos Santana > wrote: > > > Should the

Re: Question about a commit in 3.1.x

Funny that would be causing you issues. The motivation for making it was to make the bridge work on the KitKat chromium-based WebView. Without it, no event would fire when an even number of messages were sent from native->js (since the online state would be the same as when it started, Chromium is

Re: cordova-js commits on master but not on 3.2.x branch

Blackberry and Android would need to get retagged. I have no issue with retagging the JS in-regards to firefoxos. Other platform maintainers can chime in. On Thu, Nov 7, 2013 at 2:08 PM, Carlos Santana wrote: > Should the following commits should be included for 3.2 specially BB10 > changes? >

cordova-js commits on master but not on 3.2.x branch

Should the following commits should be included for 3.2 specially BB10 changes? * d5e4e9e CB-5307 Remove references to Callback and Incubator * 9740276 CB-5253 remove webworksready event * 6568e94 CB-5253 remove webworks.exec * 9bbf2b7 CB-5247 [BlackBerry10] Map blackberry.event to document * 4e2e

Re: Review Request 15328: CB-5063: Keep cordova.js in platform_www to avoid copying it from lib. CB-5063: Keep cordova.js in platform_www to avoid copying it from lib.

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15328/#review28455 --- Ship it! Ship It! - Braden Shepherdson On Nov. 7, 2013, 9:59 p.m

Review Request 15328: CB-5063: Keep cordova.js in platform_www to avoid copying it from lib. CB-5063: Keep cordova.js in platform_www to avoid copying it from lib.

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15328/ --- Review request for cordova. Bugs: CB-5063 https://issues.apache.org/jira/br

Re: Review Request 15253: CB-4400: cd to project root in most cordova commands.

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15253/#review28451 --- Ship it! Ship It! - Braden Shepherdson On Nov. 6, 2013, 1:11 a.m

Re: Review Request 15046: "Prepare" should not depend on the ~/.cordova/libs directory

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15046/ --- (Updated Nov. 7, 2013, 9:29 p.m.) Review request for cordova. Changes ---

Re: Review Request 15046: "Prepare" should not depend on the ~/.cordova/libs directory

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15046/ --- (Updated Nov. 7, 2013, 9:09 p.m.) Review request for cordova. Changes ---

RE: Medic/CI

Great Thanks David and Sergey! Sent from my Windows Phone From: Lorin Beer Sent: ‎11/‎7/‎2013 21:00 To: dev Subject: Re: Medic/CI great work, thanks David! On Thu, Nov 7, 2013 at 11:04 AM, Sergey Gr

Re: Refactoring the CLI tests

What we're aiming for here is that we mock as little as is practical, and ideally only mock things at the boundaries of CLI: calls to the platform scripts, some calls to Plugman (generally we want to let these end-to-end tests call the real Plugman, but there are exceptions). We'll do it first, an

Re: Refactoring the CLI tests

This reiterates some of the conclusions Braden and Mark have already reached, but generally testing should be split into two categories: unit tests and integration tests. There's debate about whether things like the file system should be mocked or not, but I think it's wrong to call our current te

Re: Medic/CI

great work, thanks David! On Thu, Nov 7, 2013 at 11:04 AM, Sergey Grebnov (Akvelon) < v-seg...@microsoft.com> wrote: > Great news David, thank you! > > -Sergey > -Original Message- > From: drk...@google.com [mailto:drk...@google.com] On Behalf Of David Kemp > Sent: Thursday, November 7,

Re: Refactoring the CLI tests

The reason why every FS call is mocked is speed but speed is subjective in my opinion. Given the features of CLI, my opinion is that anything < 1 minute is acceptable. When I run tests, I am not actively watching them execute. I think the only calls that should be mocked are network calls because y

RE: Medic/CI

Great news David, thank you! -Sergey -Original Message- From: drk...@google.com [mailto:drk...@google.com] On Behalf Of David Kemp Sent: Thursday, November 7, 2013 10:55 PM To: dev@cordova.apache.org Subject: Medic/CI After a little turmoil, the medic repo is now up to date with the Windo

Medic/CI

After a little turmoil, the medic repo is now up to date with the Windows support added, and still working on mac/ios/android. Thanks for the additions Sergey! ** and everything except CLI is green **

Re: Refactoring the CLI tests

Alright, Mark and I have discussed this further, and we will be beginning the effort with some end-to-end tests that will supplement the existing tests. To some extent this is duplicating things that go on in the CI, since it checks out various plugins using the tools. But we think it's still a wo

Re: Refactoring the CLI tests

I don't think we should scrap the current tests. I am totally in favor of having new end to end tests. We need to catch regressions better. Braden, let me know how I can help. > On Nov 7, 2013, at 9:02 AM, Michal Mocny wrote: > > Discussing locally with Braden.. these tests seem to be test

Re: Refactoring the CLI tests

Discussing locally with Braden.. these tests seem to be testing internal details instead of expected functionality. Its quite common for valid patches to break the tests and invalid patches to leave the tests passing. There have been several occurrences recently where things landed even though "c

Re: Refactoring the CLI tests

+1 to testing end-to-end, but I thought thats what BuildBot/Medic does? Likely we want to ship those end-to-end test scripts so users can test changes locally, but I think the tests are are inside CLI now are meant to be unit tests, which yes, have very limited usefulness in isolation, but perhaps

cordova remote proxy

Hi there, Ive submitted the idea a while ago on the cordova ML and now that the cordova codebase is much more sane and promises-based API are on their way we can put the subject back the discussion table ;) Basically, it would be very handy and timesa

Re: Review Request 15046: "Prepare" should not depend on the ~/.cordova/libs directory

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15046/ --- (Updated Nov. 7, 2013, 4:48 p.m.) Review request for cordova. Changes ---

Refactoring the CLI tests

The CLI tests are bad. I propose making them better. The tests are bad for two reasons: 1. They're fragile because the tests depend on exactly the right functions being called, sometimes in the right order. 2. They don't test what we really want, which is that projects get created and all the file

Re: jira permissions

Done. On Thu, Nov 7, 2013 at 10:43 AM, Marcel Kinard wrote: > Could one of the Jira admins grant Jira karma to Josh? Thanks! > > Begin forwarded message: > > > From: "Josh Soref (JIRA)" > > Subject: [jira] [Commented] (CB-5307) Remove references to Callback and > Incubator > > Date: November 7

Re: cordova serve broken

Ah, I'm getting the picture. I've only ever thought of using serve for (a) app harness and (b) livereload on a device. For both those I wouldn't want any mocking of cordova stuff at all. So what Ripple brings to the table is (c) the ability to run on unsupported platforms via browser. I agree w

Re: android target level

I think some people are confused about this number and backward compatibility. There are *two* version constraints on Android. The one we're discussing here is which API we're compiling against, which should generally be set at the latest stable version (+1 to 3.2 targeting API 18 (Android 4.3)).

Wiki updates - Running Tests

I've taken another stab at the Wiki. I'd actually like to remove a bunch of links from the main page. IMO, it's close to TL;DR. * I'd like https://wiki.apache.org/cordova/FrontPage?action=LocalSiteMap to actually have some hierarchy... Something like ‎https://wiki.apache.org/cordova/IssueWorkf

CI failures - CLI & WP8

last error output from npm test of CLI: Failures: 1) platform command success `add` should shell out to specified platform's bin/create, using the version that is specified in platforms manifest Message: Expected '"lib/wp/cordova/3.1.0/wp8/wp8/bin/create" "some/path/platforms/wp8"

jira permissions

Could one of the Jira admins grant Jira karma to Josh? Thanks! Begin forwarded message: > From: "Josh Soref (JIRA)" > Subject: [jira] [Commented] (CB-5307) Remove references to Callback and > Incubator > Date: November 7, 2013 10:03:24 AM EST > To: iss...@cordova.apache.org > Reply-To: dev@cord

Re: File API tests

Nice =) On Tue, Nov 5, 2013 at 8:51 PM, Ian Clelland wrote: > On Mon, Nov 4, 2013 at 1:47 PM, Michal Mocny wrote: > > > Easier to read and catching errors that had gone undetected for a long > > time? > > > > Sounds like a ringing endorsement to me ;) > > > > Oh -- and smaller, too :) > > The

Re: Medic. Windows support for review

Hi Medic users, I reviewed these and did some testing (not enough) and pushed the commits. Unfortunately, now that its live, I have found a serious problem. working on it... David Kemp On Thu, Nov 7, 2013 at 9:29 AM, Carlos Santana wrote: > Thanks Sergey ! > > Testing and CI contributions I

Re: android target level

We are also in the works on getting a Nexus 5, probably on Friday we want to get unlocked On Thu, Nov 7, 2013 at 9:38 AM, Joe Bowser wrote: > That's correct. I only have an old Nexus 7 with an AOSP build I made > yesterday to test things on 4.4 while I wait for the Nexus 5 or the > official upd

res folder

I'm in the process of adding some additional resolutions to the BB10 splash screens and noticed that the res folder has been moved out of www in hello world. Is the intention of this folder that all apps will get the same set of default assets regardless of www template? Has there been logic intr

Re: New filesystem roots API?

On 11/6/13, 1:30 PM, "Michal Mocny" wrote: >I think perhaps the motivation here is being lost in the sea of details. > Let me attempt to decompose the motivation into very few words (please >correct me Ian): > >* We desire a way for apps to access to "the idiosyncrasies of the various >platform

Re: cordova serve broken

During the lull in Ripple's development it definitely felt risky but the project has become rather active again of late. The big advantage is the mocking for all the Cordova specific stuff (like deviceready). We do need a lightweight option for App Harness. I believe we can treat Ripple as a middl

Re: cordova serve broken

Yes, Ripple can run chromeless On Thu, Nov 7, 2013 at 8:54 AM, Bryan Higgins wrote: > Is there a JIRA for the serve issue? Josh recently added some content to > make the landing page functional. > > Ripple integration sounds great. Gord - is there a way to make ripple run > chromeless for the ap

Re: cordova serve broken

Ripple already does a livereload (sort of, upon refresh currently). It should be easy to add in support for a file watcher. On Thu, Nov 7, 2013 at 9:33 AM, Carlos Santana wrote: > Gord Can you make shareable branch I want to contribute to effort also. > > In addition of serving with ripple I w

Re: cordova serve broken

Forgive the ignorance, but, why should we be depending on ripple for implementing cordova serve? One advantage I see, is that we already do want to support Ripple as a client, and I'm deducing that Ripple has a server component which serves files, so why reinvent the wheel, lets share code, great.

Re: android target level

That's correct. I only have an old Nexus 7 with an AOSP build I made yesterday to test things on 4.4 while I wait for the Nexus 5 or the official updates, and since I have no camera drivers working. BTW: We still have a gallery, but I think the Camera plugin may be broken in 4.4. On Nov 7, 2013 6

Re: cordova serve broken

Gord Can you make shareable branch I want to contribute to effort also. In addition of serving with ripple I would like to implement "watch and livereload" for "serve" as user changes files in Project/www/ it calls "prepare" and sends a livereload event to browser. On Thu, Nov 7, 2013 at 8:54 A

Re: Medic. Windows support for review

Thanks Sergey ! Testing and CI contributions I consider big improvements! On Thu, Nov 7, 2013 at 8:40 AM, Sergey Grebnov (Akvelon) < v-seg...@microsoft.com> wrote: > I've added wp8 and windows8 support for Medic. Could someone review and > merge? David? > > CB-5152 Medic. Add Windows Phone8 sup

Re: New filesystem roots API?

On Thu, Nov 7, 2013 at 4:47 AM, Brian LeRoux wrote: > I tend to agree. Keeping this as a standalone extension will give us a > clear 'thing' to allow devs to shim out if they want to be browser > compatible. Also, in favor in async. > > Brings up a deeper philosphical discussion: should we be pro

Re: android target level

To be clear the goal for Cordova 3.2 is to set target 18 (Android 4.3) and for Cordova 3.3 target 19 (Android 4.4) ? We are about to release 3.2 so I want to be sure. I vote to set target 19/4.4 (KitKat) for Cordova 3.3 (Allows time to investigate, test, integrate, and document) On Thu, Nov 7,

Re: cordova serve broken

Is there a JIRA for the serve issue? Josh recently added some content to make the landing page functional. Ripple integration sounds great. Gord - is there a way to make ripple run chromeless for the app harness? On Thu, Nov 7, 2013 at 7:54 AM, Gord Tanner wrote: > I can code up a quick sample

Medic. Windows support for review

I've added wp8 and windows8 support for Medic. Could someone review and merge? David? CB-5152 Medic. Add Windows Phone8 support CB-5153 Medic. Add Windows related info to home page https://github.com/apache/cordova-medic/pull/1 CB-5289 Medic. Can't be installed on Windows due to ios-deploy depen

Re: android target level

Joe is right on the money. If the target is older than 13 it will fail to compile which was detected elsewhere [1]. Also as detected on the other thread CLI is not actually [2] [3] delegating the requirement checks to platform scripts for Android and iOS. After this issue is resolved it will depen

Re: cordova serve broken

I can code up a quick sample integration to see what cordova serve (powered by ripple) would look like. On Thu, Nov 7, 2013 at 7:16 AM, Josh Soref wrote: > Brian wrote: > > Feels like we're starting to regress rather often on the CLI these past > two releases. > > This is due to not running t

Re: android target level

Axel: you are correct that we want as many devices as possible. This is why we've always set to the highest level. If you set to the highest level it is inclusive to all platforms before it (that we decide to support). On Thu, Nov 7, 2013 at 12:00 PM, Axel Nennker wrote: > I think the highest l

Re: android target level

The whole point is to have one APK across all official Android versions. This requirement is going to confuse pur users even more and make maintaining the platform next to impossible. Web developers shouldn't have to know about API level. The fact is that we've been fairly successful in maintaini

Re: cordova serve broken

Brian wrote: > Feels like we're starting to regress rather often on the CLI these past two > releases. > This is due to not running tests (or indeed writing them). > Thats fine. Stuff happens. A gentle reminder: > - If there is a bug: write a test > - If you are adding or refactoring code: run t

Re: cordova serve broken

Also: wonder if it is time to revisit this as just Ripple. The new version of Ripple is pretty awesome. On Thu, Nov 7, 2013 at 11:54 AM, Brian LeRoux wrote: > Feels like we're starting to regress rather often on the CLI these past > two releases. This is due to not running tests (or indeed wr

Re: android target level

I think the highest level is not what developers need. When you create a product/app you want your app to run on as many devices as possible and not only the latest. Am 07.11.2013 11:36 schrieb "Brian LeRoux" : > Apologies I think there is another thread about this but I'd like to > understand mor

cordova serve broken

Feels like we're starting to regress rather often on the CLI these past two releases. This is due to not running tests (or indeed writing them). Thats fine. Stuff happens. A gentle reminder: - If there is a bug: write a test - If you are adding or refactoring code: run the tests That is all.

Re: android target level

+1 On 7 Nov 2013, at 9:35 pm, Brian LeRoux wrote: > Apologies I think there is another thread about this but I'd like to > understand more about what we're thinking here. There's been discussion > that we should make this configurable. I disagree. I think we need to > target highest available l

android target level

Apologies I think there is another thread about this but I'd like to understand more about what we're thinking here. There's been discussion that we should make this configurable. I disagree. I think we need to target highest available level possible, as we always have in the past, and take backwar

Re: New filesystem roots API?

I tend to agree. Keeping this as a standalone extension will give us a clear 'thing' to allow devs to shim out if they want to be browser compatible. Also, in favor in async. Brings up a deeper philosphical discussion: should we be providing shims for functionality so that our community user land

Re: New filesystem roots API?

-1 to using requestLocalFileSystem. RLFS is a standard, and what we're adding here is not a part of it. I think there is value in keeping Cordova-specific logic separate so that it's easy for devs to know when they are using an API that is Cordova-specific (as opposed to a polyfill). That said, I t