Re: 2.9.1 Backport release

2013-10-30 Thread Jesse 
tagged

@purplecabbage
risingj.com


On Wed, Oct 30, 2013 at 5:41 PM, Shazron  wrote:

> iOS is ready for js, then retest.
>
> On Wednesday, October 30, 2013, Jesse wrote:
>
> > Okay, I am ready to tag the js, and get to releasing ...
> > Where is everyone else at?
> >
> > @purplecabbage
> > risingj.com
> >
> >
> > On Thu, Oct 24, 2013 at 2:43 PM, Shazron  wrote:
> >
> > > https://issues.apache.org/jira/browse/CB-5189
> > >
> > > Integrated everything for iOS, and tested on iOS 7 and 6 (I have no
> iOS 5
> > > device).
> > >
> > > Results below.
> > >
> > > AutoTests:
> > > ===
> > > iOS 7.0.3 (all pass)
> > > iOS 6.1.4 (all pass)
> > >
> > > Manual Tests (iOS 6.1.4)
> > > ===
> > > Media Record (pass)
> > > Splashscreen (pass)
> > > InAppBrowser (pass - but got a "multiple loadstart events (2)" popup
> > error
> > > each time a page was loaded - I think this the test is causing this)
> > > Accelerometer (pass)
> > > Camera (pass)
> > > Media Capture Audio (pass)
> > >
> > > Manual Tests (iOS 7.0.3)
> > > ===
> > > Media Record (pass)
> > > Splashscreen (pass)
> > > InAppBrowser (pass)
> > > Accelerometer (pass)
> > > Camera (pass)
> > > Media Capture Audio (pass, but UI is "shifted up" a bit, instead of
> > > sticking to the bottom, un-related to recording)
> > >
> > >
> > >
> > > On Wed, Oct 23, 2013 at 5:16 PM, Shazron  wrote:
> > >
> > > > iOS tracked as subtask under
> > > https://issues.apache.org/jira/browse/CB-5189
> > > >
> > > >
> > > > On Wed, Oct 23, 2013 at 2:55 PM, Shazron  wrote:
> > > >
> > > >> Will integrate:
> > > >>
> > > >> 1. https://issues.apache.org/jira/browse/CB-4958 (Camera - iOS 7)
> > > >> 2. https://issues.apache.org/jira/browse/CB-4930 (InAppBrowser -
> iOS
> > 7)
> > > >> 3. https://issues.apache.org/jira/browse/CB-4847 (Media/Media
> > Capture -
> > > >> iOS 7)
> > > >> 4. https://issues.apache.org/jira/browse/CB-4825 (Device Motion)
> > > >> 5. https://issues.apache.org/jira/browse/CB-5035 (Device Motion)
> > > >>
> > > >> These should be relatively straightforward copy paste jobs, then
> test
> > on
> > > >> mobile spec.
> > > >>
> > > >> This one is more of a cordova-js thing where it affects all
> platforms:
> > > >> https://issues.apache.org/jira/browse/CB-4771
> > > >>
> > > >>
> > > >> On Tue, Oct 22, 2013 at 4:25 PM, Shazron  wrote:
> > > >>
> > > >>> Gonna look over all the iOS issues tomorrow. Most of them are just
> > > >>> straight copy and paste jobs (yay for them all being plugins!).
> When
> > > is the
> > > >>> schedule for release? (since we have 3.2 on the plate as well)
> > > >>>
> > > >>>
> > > >>> On Tue, Oct 22, 2013 at 8:26 AM, Andrew Grieve <
> agri...@chromium.org
> > > >wrote:
> > > >>>
> > >  Thanks Joe!
> > > 
> > >  Will work on the IAB & UriResolvers issues right now.
> > > 
> > > 
> > >  On Tue, Oct 22, 2013 at 11:17 AM, Joe Bowser 
> > > wrote:
> > > 
> > >  > There are some 3.0.0 bugs that don't exist in 2.9.0.
> > >  >
> > >  > On Mon, Oct 21, 2013 at 4:57 PM, Josh Soref <
> > jso...@blackberry.com>
> > >  wrote:
> > >  > > On 10/21/13 7:38 PM, "Jesse"  wrote:
> > >  > >>Having a tonne of fun
>

Re: 2.9.1 Backport release

2013-10-30 Thread Shazron 
iOS is ready for js, then retest.

On Wednesday, October 30, 2013, Jesse wrote:

> Okay, I am ready to tag the js, and get to releasing ...
> Where is everyone else at?
>
> @purplecabbage
> risingj.com
>
>
> On Thu, Oct 24, 2013 at 2:43 PM, Shazron  wrote:
>
> > https://issues.apache.org/jira/browse/CB-5189
> >
> > Integrated everything for iOS, and tested on iOS 7 and 6 (I have no iOS 5
> > device).
> >
> > Results below.
> >
> > AutoTests:
> > ===
> > iOS 7.0.3 (all pass)
> > iOS 6.1.4 (all pass)
> >
> > Manual Tests (iOS 6.1.4)
> > ===
> > Media Record (pass)
> > Splashscreen (pass)
> > InAppBrowser (pass - but got a "multiple loadstart events (2)" popup
> error
> > each time a page was loaded - I think this the test is causing this)
> > Accelerometer (pass)
> > Camera (pass)
> > Media Capture Audio (pass)
> >
> > Manual Tests (iOS 7.0.3)
> > ===
> > Media Record (pass)
> > Splashscreen (pass)
> > InAppBrowser (pass)
> > Accelerometer (pass)
> > Camera (pass)
> > Media Capture Audio (pass, but UI is "shifted up" a bit, instead of
> > sticking to the bottom, un-related to recording)
> >
> >
> >
> > On Wed, Oct 23, 2013 at 5:16 PM, Shazron  wrote:
> >
> > > iOS tracked as subtask under
> > https://issues.apache.org/jira/browse/CB-5189
> > >
> > >
> > > On Wed, Oct 23, 2013 at 2:55 PM, Shazron  wrote:
> > >
> > >> Will integrate:
> > >>
> > >> 1. https://issues.apache.org/jira/browse/CB-4958 (Camera - iOS 7)
> > >> 2. https://issues.apache.org/jira/browse/CB-4930 (InAppBrowser - iOS
> 7)
> > >> 3. https://issues.apache.org/jira/browse/CB-4847 (Media/Media
> Capture -
> > >> iOS 7)
> > >> 4. https://issues.apache.org/jira/browse/CB-4825 (Device Motion)
> > >> 5. https://issues.apache.org/jira/browse/CB-5035 (Device Motion)
> > >>
> > >> These should be relatively straightforward copy paste jobs, then test
> on
> > >> mobile spec.
> > >>
> > >> This one is more of a cordova-js thing where it affects all platforms:
> > >> https://issues.apache.org/jira/browse/CB-4771
> > >>
> > >>
> > >> On Tue, Oct 22, 2013 at 4:25 PM, Shazron  wrote:
> > >>
> > >>> Gonna look over all the iOS issues tomorrow. Most of them are just
> > >>> straight copy and paste jobs (yay for them all being plugins!). When
> > is the
> > >>> schedule for release? (since we have 3.2 on the plate as well)
> > >>>
> > >>>
> > >>> On Tue, Oct 22, 2013 at 8:26 AM, Andrew Grieve  > >wrote:
> > >>>
> >  Thanks Joe!
> > 
> >  Will work on the IAB & UriResolvers issues right now.
> > 
> > 
> >  On Tue, Oct 22, 2013 at 11:17 AM, Joe Bowser 
> > wrote:
> > 
> >  > There are some 3.0.0 bugs that don't exist in 2.9.0.
> >  >
> >  > On Mon, Oct 21, 2013 at 4:57 PM, Josh Soref <
> jso...@blackberry.com>
> >  wrote:
> >  > > On 10/21/13 7:38 PM, "Jesse"  wrote:
> >  > >>Having a tonne of fun

Re: 2.9.1 Backport release

2013-10-30 Thread Jesse 
Okay, I am ready to tag the js, and get to releasing ...
Where is everyone else at?

@purplecabbage
risingj.com


On Thu, Oct 24, 2013 at 2:43 PM, Shazron  wrote:

> https://issues.apache.org/jira/browse/CB-5189
>
> Integrated everything for iOS, and tested on iOS 7 and 6 (I have no iOS 5
> device).
>
> Results below.
>
> AutoTests:
> ===
> iOS 7.0.3 (all pass)
> iOS 6.1.4 (all pass)
>
> Manual Tests (iOS 6.1.4)
> ===
> Media Record (pass)
> Splashscreen (pass)
> InAppBrowser (pass - but got a "multiple loadstart events (2)" popup error
> each time a page was loaded - I think this the test is causing this)
> Accelerometer (pass)
> Camera (pass)
> Media Capture Audio (pass)
>
> Manual Tests (iOS 7.0.3)
> ===
> Media Record (pass)
> Splashscreen (pass)
> InAppBrowser (pass)
> Accelerometer (pass)
> Camera (pass)
> Media Capture Audio (pass, but UI is "shifted up" a bit, instead of
> sticking to the bottom, un-related to recording)
>
>
>
> On Wed, Oct 23, 2013 at 5:16 PM, Shazron  wrote:
>
> > iOS tracked as subtask under
> https://issues.apache.org/jira/browse/CB-5189
> >
> >
> > On Wed, Oct 23, 2013 at 2:55 PM, Shazron  wrote:
> >
> >> Will integrate:
> >>
> >> 1. https://issues.apache.org/jira/browse/CB-4958 (Camera - iOS 7)
> >> 2. https://issues.apache.org/jira/browse/CB-4930 (InAppBrowser - iOS 7)
> >> 3. https://issues.apache.org/jira/browse/CB-4847 (Media/Media Capture -
> >> iOS 7)
> >> 4. https://issues.apache.org/jira/browse/CB-4825 (Device Motion)
> >> 5. https://issues.apache.org/jira/browse/CB-5035 (Device Motion)
> >>
> >> These should be relatively straightforward copy paste jobs, then test on
> >> mobile spec.
> >>
> >> This one is more of a cordova-js thing where it affects all platforms:
> >> https://issues.apache.org/jira/browse/CB-4771
> >>
> >>
> >> On Tue, Oct 22, 2013 at 4:25 PM, Shazron  wrote:
> >>
> >>> Gonna look over all the iOS issues tomorrow. Most of them are just
> >>> straight copy and paste jobs (yay for them all being plugins!). When
> is the
> >>> schedule for release? (since we have 3.2 on the plate as well)
> >>>
> >>>
> >>> On Tue, Oct 22, 2013 at 8:26 AM, Andrew Grieve  >wrote:
> >>>
>  Thanks Joe!
> 
>  Will work on the IAB & UriResolvers issues right now.
> 
> 
>  On Tue, Oct 22, 2013 at 11:17 AM, Joe Bowser 
> wrote:
> 
>  > There are some 3.0.0 bugs that don't exist in 2.9.0.
>  >
>  > On Mon, Oct 21, 2013 at 4:57 PM, Josh Soref 
>  wrote:
>  > > On 10/21/13 7:38 PM, "Jesse"  wrote:
>  > >>Having a tonne of fun putting the bunny back in the box.
>  > >>Here is a list of plugin defects [1]  that have been closed
> between
>  2.9.0
>  > >>and 3.1.0
>  > >>Please have a look and decide if you think each is worth the
> effort
>  of
>  > >>backporting.
>  > >>
>  > >>[1] https://issues.apache.org/jira/browse/CB-5136
>  > >
>  > > While I don't intend to ever use old versions, here's a short
>  opinion on
>  > > each:
>  > >
>  > > + CB-4656  (
>  android )
>  > (Not applicable to 2.9.x, caused by UriResource Bug)
>  >
>  > > + CB-4471  (
>  android )
>  > (Sadly, this isn't a fix, it's just suppressing the NPE.  This is in
>  > the 2.9.x branch)
>  >
>  > > - CB-3569  (
>  android )
>  > This still needs to be done.  If someone who is familiar with URI
>  > resolvers want to take a crack at it, that'd be good.
>  >
>  > > + CB-4514  (
>  android )
>  > This is in 2.9.x
>  >
>  > > + CB-4521  (
>  android )
>  > This is in 2.9.x
>  >
>  > > - CB-4864  (
>  android )
>  > This doesn't need to be in 2.9.x
>  >
>  > > + CB-3747  (
>  android )
>  > > + CB-4858  (
>  android )
>  > > + CB-4087  (
>  android )
>  > > + CB-4586  (
>  android )
>  > InAppBrowser bugs that need to go in.  We should backport
> InAppBrowser
>  > entirely, but I would like the resolutions fleshed out a bit, since
> I
>  > have no idea how these were fixed other than the commit.  I couldn't
>  > reproduce the stupid video bug on any of the devices that I tested
>  > this on.
>  >
>  > Also, there's JS changes that were made.  Andrew, since you own this
>  > one, can you backport this?
>  >
>  > > + CB-3628  (
>  android )
>  > > -- good luck, the bug has no indication of what work was done

Re: Cordova for Ubuntu

2013-10-30 Thread Maxim Ermilov 
> First step is to get a CLA signed w/ Apache.
CLA&ICLA is finally signed.

> In the meantime, you can create pull requests to Plugman, CLI and Plugin*
https://github.com/apache/cordova-plugman/pull/24
https://github.com/apache/cordova-cli/pull/47
https://github.com/apache/cordova-plugin-console/pull/3

_
Best regards,
Maxim Ermilov

Re: keyboard mobile-spec test

2013-10-30 Thread Shazron 
I'll add the check whenever someone goes to the Keyboard manual test page.
Will re-visit once the cordova-plugins repo is up.


On Wed, Oct 30, 2013 at 4:14 PM, Michal Mocny  wrote:

> After discussing with shaz, seems there is no good solution which does not
> involve action on the users' part, except to just be explicit about remote
> url.
>
> Instead, I think we are going to just remove the hard dependency, and have
> those mobile-spec tests fail unless you manually install the plugin.  Since
> there are no auto-tests for it, its fine.  Once we find the plugin a repo,
> we can add a local dependency for it.
>
> Side note: part of the problem stems from the fact that the mobile-spec
> dependency plugin sucks.  Its hard coded to look in the parent directory,
> instead of just running the tests for whichever plugin happens to be
> installed however/wherever it was installed from.
>
> -Michal
>
>
> On Wed, Oct 30, 2013 at 3:47 PM, Michal Mocny  wrote:
>
> > The way we define dependencies is the problem.  The plugin author is
> > currently responsible for defining explicitly the location of the plugin
> to
> > fetch, instead of just the id&version and letting the system do its job.
> >
> > Andrew had a proposal in the past for a simple form of "local plugin
> > repository" that just used the local fs in a clever way.  Then, you could
> > add its id as a dependency even when its not in the public plugin
> registry,
> > and expect that mobile-spec from-master-branch to add a local mapping.
> >
> > Not sure if that work has even started, though.
> >
> > -Michal
> >
> >
> > On Wed, Oct 30, 2013 at 1:58 PM, Brian LeRoux  wrote:
> >
> >> I'm not a very big fan of this sub directory business anyhow. Too many
> >> ways
> >> to fail. It would be better, in my mind, if we aimed to always have one
> >> repo equals one package.
> >>
> >>
> >> On Wed, Oct 30, 2013 at 10:40 AM, Shazron  wrote:
> >>
> >> > if we had the cordova-plugins repo created, this won't be a problem.
> The
> >> > issue is not resolved yet:
> >> > https://issues.apache.org/jira/browse/INFRA-6902
> >> >
> >> >
> >> > On Wed, Oct 30, 2013 at 1:38 PM, Shazron  wrote:
> >> >
> >> > > It's checked into master (not in 3.2.x branch yet until this issue
> >> below
> >> > > is resolved).
> >> > >
> >> > > Should I add it in the dependency plugin?
> >> > >
> >> > > The problem is I have to add it as a url, not from a local repo
> (thus
> >> > > install requires an internet connection).
> >> > >
> >> > > This is because we can't switch to a branch _and_ a subdir of a
> local
> >> > repo
> >> > > (this is not a feature of the dependency tag).
> >> > >
> >> >
> >>
> >
> >
>

Re: keyboard mobile-spec test

2013-10-30 Thread Michal Mocny 
After discussing with shaz, seems there is no good solution which does not
involve action on the users' part, except to just be explicit about remote
url.

Instead, I think we are going to just remove the hard dependency, and have
those mobile-spec tests fail unless you manually install the plugin.  Since
there are no auto-tests for it, its fine.  Once we find the plugin a repo,
we can add a local dependency for it.

Side note: part of the problem stems from the fact that the mobile-spec
dependency plugin sucks.  Its hard coded to look in the parent directory,
instead of just running the tests for whichever plugin happens to be
installed however/wherever it was installed from.

-Michal


On Wed, Oct 30, 2013 at 3:47 PM, Michal Mocny  wrote:

> The way we define dependencies is the problem.  The plugin author is
> currently responsible for defining explicitly the location of the plugin to
> fetch, instead of just the id&version and letting the system do its job.
>
> Andrew had a proposal in the past for a simple form of "local plugin
> repository" that just used the local fs in a clever way.  Then, you could
> add its id as a dependency even when its not in the public plugin registry,
> and expect that mobile-spec from-master-branch to add a local mapping.
>
> Not sure if that work has even started, though.
>
> -Michal
>
>
> On Wed, Oct 30, 2013 at 1:58 PM, Brian LeRoux  wrote:
>
>> I'm not a very big fan of this sub directory business anyhow. Too many
>> ways
>> to fail. It would be better, in my mind, if we aimed to always have one
>> repo equals one package.
>>
>>
>> On Wed, Oct 30, 2013 at 10:40 AM, Shazron  wrote:
>>
>> > if we had the cordova-plugins repo created, this won't be a problem. The
>> > issue is not resolved yet:
>> > https://issues.apache.org/jira/browse/INFRA-6902
>> >
>> >
>> > On Wed, Oct 30, 2013 at 1:38 PM, Shazron  wrote:
>> >
>> > > It's checked into master (not in 3.2.x branch yet until this issue
>> below
>> > > is resolved).
>> > >
>> > > Should I add it in the dependency plugin?
>> > >
>> > > The problem is I have to add it as a url, not from a local repo (thus
>> > > install requires an internet connection).
>> > >
>> > > This is because we can't switch to a branch _and_ a subdir of a local
>> > repo
>> > > (this is not a feature of the dependency tag).
>> > >
>> >
>>
>
>

Re: keyboard mobile-spec test

2013-10-30 Thread Michal Mocny 
The way we define dependencies is the problem.  The plugin author is
currently responsible for defining explicitly the location of the plugin to
fetch, instead of just the id&version and letting the system do its job.

Andrew had a proposal in the past for a simple form of "local plugin
repository" that just used the local fs in a clever way.  Then, you could
add its id as a dependency even when its not in the public plugin registry,
and expect that mobile-spec from-master-branch to add a local mapping.

Not sure if that work has even started, though.

-Michal


On Wed, Oct 30, 2013 at 1:58 PM, Brian LeRoux  wrote:

> I'm not a very big fan of this sub directory business anyhow. Too many ways
> to fail. It would be better, in my mind, if we aimed to always have one
> repo equals one package.
>
>
> On Wed, Oct 30, 2013 at 10:40 AM, Shazron  wrote:
>
> > if we had the cordova-plugins repo created, this won't be a problem. The
> > issue is not resolved yet:
> > https://issues.apache.org/jira/browse/INFRA-6902
> >
> >
> > On Wed, Oct 30, 2013 at 1:38 PM, Shazron  wrote:
> >
> > > It's checked into master (not in 3.2.x branch yet until this issue
> below
> > > is resolved).
> > >
> > > Should I add it in the dependency plugin?
> > >
> > > The problem is I have to add it as a url, not from a local repo (thus
> > > install requires an internet connection).
> > >
> > > This is because we can't switch to a branch _and_ a subdir of a local
> > repo
> > > (this is not a feature of the dependency tag).
> > >
> >
>

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

2013-10-30 Thread Michal Mocny 
Sadly, we are approaching an in-between time of moving the mobile-spec
tests out of the app and into plugins.  We are still investigating the best
way to do this without disruption.

For what its worth: several plugins now have a 'cdvtest' branch which
supplies new-style tests ripped out of mobile-spec.  If you are having
issues cleaning up the old style tests, take a look at the new ones (or try
porting yourself).

I'm going to write up a doc with the summary of the state of testing within
a day or so given the results of this week to make it easier for you (and
others) to pick up.

-Michal


On Wed, Oct 30, 2013 at 1:54 PM, Naik, Archana  wrote:

>  Thanks Michal. You answered my questions.
>
>  More to elaborate on my question: I am testing amazon-fireos
> port(platform) with all plug-ins using mobile-spec. I am seeing some
> failures in 3.1.0 version because of test cases timing out. I am pretty new
> to cordova and still in learning phase. :) I am trying to understand these
> failures. Interestingly they pass on 3.0.x version.
>
>  Archana
>
>
>   From: Michal Mocny 
> Date: Wednesday, October 30, 2013 10:27 AM
> To: "Naik, Archana" 
> Cc: "dev@cordova.apache.org" , Michal Mocny <
> mmo...@chromium.org>
>
> Subject: Re: mobile-spec and releases: How do we test?
>
>   May you clarify?
>
>  Right now, there is no formal way to test plugins, we are trying to
> invent that way now.  Check out cordova-labs repo's cdvtest branch for a
> sample app & plugin to track progress.
>
>  Jasmine is hosted in that sample app, but plugins will not directly
> know/care.  Any testing framework which is api-compatible should work.  In
> practice, I'm not sure how compatible they all are, so it may very well be
> limited to jasmine -- but it does mean you can make local modifications
> such as our CI is doing to create a custom test reporter.
>
>  -Michal
>
>
> On Wed, Oct 30, 2013 at 12:57 PM, Naik, Archana  wrote:
>
>> Hi, Guys
>>
>> While on this topic, I have a question: how do I test individual plug-in?
>> Where is the this jasmine version specified?
>>
>> Thanks
>> Archana
>>
>> On 10/30/13 7:26 AM, "Michal Mocny"  wrote:
>>
>> >Here are some links to jasmine-2 docs since its a hard time finding them:
>> >
>> >http://jasmine.github.io/2.0/introduction.html
>> >
>> >https://github.com/pivotal/jasmine/blob/master/release_notes/20rc5.md
>> >
>> >
>> >On Wed, Oct 30, 2013 at 10:16 AM, Michal Mocny 
>> >wrote:
>> >
>> >>
>> >>
>> >>
>> >> On Tue, Oct 29, 2013 at 5:29 PM, Bryan Higgins
>> >>wrote:
>> >>
>> >>> I just converted geolocation to the new test style [1]
>> >>>
>> >>> I'm happy with the process overall, and I find the jasmine 2 tests are
>> >>> more
>> >>> succinct.
>> >>>
>> >>> There are a few things worth noting:
>> >>> - I kept the eval code in. At google today, it was discussed that this
>> >>>may
>> >>> not be the best approach.
>> >>> - Jasmine 2: You must hit at least one expect statement or the test
>> >>>will
>> >>> timeout even though done was called.
>> >>>
>> >>
>> >> We could file a bug (I ran into it during setup once too), but really,
>> >> what is the worth of a test if there are no expect clauses?
>> >>
>> >>
>> >>> - I did not remove the manual test page [2]. It would be great if we
>> >>>had a
>> >>> convention for importing these. (ie test harness looks for a page at
>> >>> www/test/plugin-id.html and adds a link to it if it exists)
>> >>>
>> >>
>> >> I'm going to work on a solution for this today.  The thought is that
>> the
>> >> plugin has a single module that can define all auto/manual tests, and
>> >>the
>> >> test-harness choses which to display where.
>> >>
>> >>
>> >>>
>> >>> [1]
>> >>>
>> >>>
>> >>>
>> https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-geolocation.git
>> >>>;a=commit;h=075850a460d8171a04809cf6317fb4c4ef998603
>> >>> [2]
>> >>>
>> >>>
>> >>>
>> https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-geolocation.git
>>
>> >>>;a=blob;f=test/manual.html;h=6ec2eed03e18c2efaa8710094d60930bb32227ba;hb
>> >>>=459a01c01e8dfa2a688d25483bb48c46d8e2
>> >>>
>> >>>
>> >>> On Tue, Oct 15, 2013 at 12:50 PM, David Kemp 
>> >>>wrote:
>> >>>
>> >>> > In spite of that fact that it needs a tooling change, I like the
>> >>>added
>> >>> >  tag / prepare steps.
>> >>> > The tooling change should be small and it means no runtime impact on
>> >>> apps.
>> >>> >
>> >>> > I love the approach - a very positive step to cleaning up testing.
>> >>> >
>> >>> > David Kemp
>> >>> >
>> >>> >
>> >>> >
>> >>> > On Tue, Oct 15, 2013 at 12:18 PM, Michal Mocny > >
>> >>> > wrote:
>> >>> >
>> >>> > > Braden, you're right, good catch.
>> >>> > >
>> >>> > > Discussing locally how we could support "prepare --mode=..." in
>> the
>> >>> most
>> >>> > > generalized form, we remembered an old suggestion to just support
>> >>> 
>> >>> > > tags.
>> >>> > >
>> >>> > > The benefits seem to be:
>> >>> > > - No need to add custom tag-prefix/attributes for the combinations
>> >>>of
>> >>> > > js-module mode=,

Re: keyboard mobile-spec test

2013-10-30 Thread Brian LeRoux 
I'm not a very big fan of this sub directory business anyhow. Too many ways
to fail. It would be better, in my mind, if we aimed to always have one
repo equals one package.


On Wed, Oct 30, 2013 at 10:40 AM, Shazron  wrote:

> if we had the cordova-plugins repo created, this won't be a problem. The
> issue is not resolved yet:
> https://issues.apache.org/jira/browse/INFRA-6902
>
>
> On Wed, Oct 30, 2013 at 1:38 PM, Shazron  wrote:
>
> > It's checked into master (not in 3.2.x branch yet until this issue below
> > is resolved).
> >
> > Should I add it in the dependency plugin?
> >
> > The problem is I have to add it as a url, not from a local repo (thus
> > install requires an internet connection).
> >
> > This is because we can't switch to a branch _and_ a subdir of a local
> repo
> > (this is not a feature of the dependency tag).
> >
>

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

2013-10-30 Thread Naik, Archana 
Thanks Michal. You answered my questions.

More to elaborate on my question: I am testing amazon-fireos port(platform) 
with all plug-ins using mobile-spec. I am seeing some failures in 3.1.0 version 
because of test cases timing out. I am pretty new to cordova and still in 
learning phase. :) I am trying to understand these failures. Interestingly they 
pass on 3.0.x version.

Archana


From: Michal Mocny mailto:mmo...@chromium.org>>
Date: Wednesday, October 30, 2013 10:27 AM
To: "Naik, Archana" mailto:na...@lab126.com>>
Cc: "dev@cordova.apache.org" 
mailto:dev@cordova.apache.org>>, Michal Mocny 
mailto:mmo...@chromium.org>>
Subject: Re: mobile-spec and releases: How do we test?

May you clarify?

Right now, there is no formal way to test plugins, we are trying to invent that 
way now.  Check out cordova-labs repo's cdvtest branch for a sample app & 
plugin to track progress.

Jasmine is hosted in that sample app, but plugins will not directly know/care.  
Any testing framework which is api-compatible should work.  In practice, I'm 
not sure how compatible they all are, so it may very well be limited to jasmine 
-- but it does mean you can make local modifications such as our CI is doing to 
create a custom test reporter.

-Michal


On Wed, Oct 30, 2013 at 12:57 PM, Naik, Archana 
mailto:na...@lab126.com>> wrote:
Hi, Guys

While on this topic, I have a question: how do I test individual plug-in?
Where is the this jasmine version specified?

Thanks
Archana

On 10/30/13 7:26 AM, "Michal Mocny" 
mailto:mmo...@chromium.org>> wrote:

>Here are some links to jasmine-2 docs since its a hard time finding them:
>
>http://jasmine.github.io/2.0/introduction.html
>
>https://github.com/pivotal/jasmine/blob/master/release_notes/20rc5.md
>
>
>On Wed, Oct 30, 2013 at 10:16 AM, Michal Mocny 
>mailto:mmo...@chromium.org>>
>wrote:
>
>>
>>
>>
>> On Tue, Oct 29, 2013 at 5:29 PM, Bryan Higgins
>>mailto:br...@bryanhiggins.net>>wrote:
>>
>>> I just converted geolocation to the new test style [1]
>>>
>>> I'm happy with the process overall, and I find the jasmine 2 tests are
>>> more
>>> succinct.
>>>
>>> There are a few things worth noting:
>>> - I kept the eval code in. At google today, it was discussed that this
>>>may
>>> not be the best approach.
>>> - Jasmine 2: You must hit at least one expect statement or the test
>>>will
>>> timeout even though done was called.
>>>
>>
>> We could file a bug (I ran into it during setup once too), but really,
>> what is the worth of a test if there are no expect clauses?
>>
>>
>>> - I did not remove the manual test page [2]. It would be great if we
>>>had a
>>> convention for importing these. (ie test harness looks for a page at
>>> www/test/plugin-id.html and adds a link to it if it exists)
>>>
>>
>> I'm going to work on a solution for this today.  The thought is that the
>> plugin has a single module that can define all auto/manual tests, and
>>the
>> test-harness choses which to display where.
>>
>>
>>>
>>> [1]
>>>
>>>
>>>https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-geolocation.git
>>>;a=commit;h=075850a460d8171a04809cf6317fb4c4ef998603
>>> [2]
>>>
>>>
>>>https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-geolocation.git
>>>;a=blob;f=test/manual.html;h=6ec2eed03e18c2efaa8710094d60930bb32227ba;hb
>>>=459a01c01e8dfa2a688d25483bb48c46d8e2
>>>
>>>
>>> On Tue, Oct 15, 2013 at 12:50 PM, David Kemp 
>>> mailto:drk...@chromium.org>>
>>>wrote:
>>>
>>> > In spite of that fact that it needs a tooling change, I like the
>>>added
>>> >  tag / prepare steps.
>>> > The tooling change should be small and it means no runtime impact on
>>> apps.
>>> >
>>> > I love the approach - a very positive step to cleaning up testing.
>>> >
>>> > David Kemp
>>> >
>>> >
>>> >
>>> > On Tue, Oct 15, 2013 at 12:18 PM, Michal Mocny 
>>> > mailto:mmo...@chromium.org>>
>>> > wrote:
>>> >
>>> > > Braden, you're right, good catch.
>>> > >
>>> > > Discussing locally how we could support "prepare --mode=..." in the
>>> most
>>> > > generalized form, we remembered an old suggestion to just support
>>> 
>>> > > tags.
>>> > >
>>> > > The benefits seem to be:
>>> > > - No need to add custom tag-prefix/attributes for the combinations
>>>of
>>> > > js-module mode=, asset mode=, etc etc
>>> > > - More visually apparent when reading a plugin.xml file, akin to
>>> > >  tag
>>> > >
>>> > > The drawbacks seem to be:
>>> > > - Not all descendant tags are easy to support for a given mode (ie,
>>> > > )
>>> > >
>>> > >
>>> > > Summarizing the options currently discussed in this thread:
>>> > >
>>> > > - new  tag.  Not general enough solution to support
>>> tests
>>> > > bundling , so -1 from me for this reason.
>>> > > - mode="..." attribute for a set of whitelisted tags (,
>>> > ,
>>> > > ...)
>>> > > -  tag for a set of whitelisted descendant
>>> > > tags (, , ...)
>>> > >
>>> > > The last two options are really functionally equivalent, but given
>>> that
>>> > we
>>> > > opted for  tag

Re: keyboard mobile-spec test

2013-10-30 Thread Shazron 
if we had the cordova-plugins repo created, this won't be a problem. The
issue is not resolved yet: https://issues.apache.org/jira/browse/INFRA-6902


On Wed, Oct 30, 2013 at 1:38 PM, Shazron  wrote:

> It's checked into master (not in 3.2.x branch yet until this issue below
> is resolved).
>
> Should I add it in the dependency plugin?
>
> The problem is I have to add it as a url, not from a local repo (thus
> install requires an internet connection).
>
> This is because we can't switch to a branch _and_ a subdir of a local repo
> (this is not a feature of the dependency tag).
>

keyboard mobile-spec test

2013-10-30 Thread Shazron 
It's checked into master (not in 3.2.x branch yet until this issue below is
resolved).

Should I add it in the dependency plugin?

The problem is I have to add it as a url, not from a local repo (thus
install requires an internet connection).

This is because we can't switch to a branch _and_ a subdir of a local repo
(this is not a feature of the dependency tag).

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

2013-10-30 Thread Michal Mocny 
May you clarify?

Right now, there is no formal way to test plugins, we are trying to invent
that way now.  Check out cordova-labs repo's cdvtest branch for a sample
app & plugin to track progress.

Jasmine is hosted in that sample app, but plugins will not directly
know/care.  Any testing framework which is api-compatible should work.  In
practice, I'm not sure how compatible they all are, so it may very well be
limited to jasmine -- but it does mean you can make local modifications
such as our CI is doing to create a custom test reporter.

-Michal


On Wed, Oct 30, 2013 at 12:57 PM, Naik, Archana  wrote:

> Hi, Guys
>
> While on this topic, I have a question: how do I test individual plug-in?
> Where is the this jasmine version specified?
>
> Thanks
> Archana
>
> On 10/30/13 7:26 AM, "Michal Mocny"  wrote:
>
> >Here are some links to jasmine-2 docs since its a hard time finding them:
> >
> >http://jasmine.github.io/2.0/introduction.html
> >
> >https://github.com/pivotal/jasmine/blob/master/release_notes/20rc5.md
> >
> >
> >On Wed, Oct 30, 2013 at 10:16 AM, Michal Mocny 
> >wrote:
> >
> >>
> >>
> >>
> >> On Tue, Oct 29, 2013 at 5:29 PM, Bryan Higgins
> >>wrote:
> >>
> >>> I just converted geolocation to the new test style [1]
> >>>
> >>> I'm happy with the process overall, and I find the jasmine 2 tests are
> >>> more
> >>> succinct.
> >>>
> >>> There are a few things worth noting:
> >>> - I kept the eval code in. At google today, it was discussed that this
> >>>may
> >>> not be the best approach.
> >>> - Jasmine 2: You must hit at least one expect statement or the test
> >>>will
> >>> timeout even though done was called.
> >>>
> >>
> >> We could file a bug (I ran into it during setup once too), but really,
> >> what is the worth of a test if there are no expect clauses?
> >>
> >>
> >>> - I did not remove the manual test page [2]. It would be great if we
> >>>had a
> >>> convention for importing these. (ie test harness looks for a page at
> >>> www/test/plugin-id.html and adds a link to it if it exists)
> >>>
> >>
> >> I'm going to work on a solution for this today.  The thought is that the
> >> plugin has a single module that can define all auto/manual tests, and
> >>the
> >> test-harness choses which to display where.
> >>
> >>
> >>>
> >>> [1]
> >>>
> >>>
> >>>
> https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-geolocation.git
> >>>;a=commit;h=075850a460d8171a04809cf6317fb4c4ef998603
> >>> [2]
> >>>
> >>>
> >>>
> https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-geolocation.git
> >>>;a=blob;f=test/manual.html;h=6ec2eed03e18c2efaa8710094d60930bb32227ba;hb
> >>>=459a01c01e8dfa2a688d25483bb48c46d8e2
> >>>
> >>>
> >>> On Tue, Oct 15, 2013 at 12:50 PM, David Kemp 
> >>>wrote:
> >>>
> >>> > In spite of that fact that it needs a tooling change, I like the
> >>>added
> >>> >  tag / prepare steps.
> >>> > The tooling change should be small and it means no runtime impact on
> >>> apps.
> >>> >
> >>> > I love the approach - a very positive step to cleaning up testing.
> >>> >
> >>> > David Kemp
> >>> >
> >>> >
> >>> >
> >>> > On Tue, Oct 15, 2013 at 12:18 PM, Michal Mocny 
> >>> > wrote:
> >>> >
> >>> > > Braden, you're right, good catch.
> >>> > >
> >>> > > Discussing locally how we could support "prepare --mode=..." in the
> >>> most
> >>> > > generalized form, we remembered an old suggestion to just support
> >>> 
> >>> > > tags.
> >>> > >
> >>> > > The benefits seem to be:
> >>> > > - No need to add custom tag-prefix/attributes for the combinations
> >>>of
> >>> > > js-module mode=, asset mode=, etc etc
> >>> > > - More visually apparent when reading a plugin.xml file, akin to
> >>> > >  tag
> >>> > >
> >>> > > The drawbacks seem to be:
> >>> > > - Not all descendant tags are easy to support for a given mode (ie,
> >>> > > )
> >>> > >
> >>> > >
> >>> > > Summarizing the options currently discussed in this thread:
> >>> > >
> >>> > > - new  tag.  Not general enough solution to support
> >>> tests
> >>> > > bundling , so -1 from me for this reason.
> >>> > > - mode="..." attribute for a set of whitelisted tags (,
> >>> > ,
> >>> > > ...)
> >>> > > -  tag for a set of whitelisted descendant
> >>> > > tags (, , ...)
> >>> > >
> >>> > > The last two options are really functionally equivalent, but given
> >>> that
> >>> > we
> >>> > > opted for  tag instead of attribute, I'm also favoring a
> >>> 
> >>> > > tag.
> >>> > >
> >>> > > -Michal
> >>> > >
> >>> > >
> >>> > > On Tue, Oct 15, 2013 at 11:43 AM, Braden Shepherdson <
> >>> > bra...@chromium.org
> >>> > > >wrote:
> >>> > >
> >>> > > > It's not true that adding these tests only creates larger
> >>>binaries.
> >>> > They
> >>> > > > will be fetched and parsed by the plugin loader code at app
> >>>startup
> >>> > time.
> >>> > > > It goes through the list of all plugins in cordova_plugins.js and
> >>> loads
> >>> > > > them all. That parses them, and runs the outermost layer, which
> >>>is
> >>> the
> >>> > > > wrapping function function(require

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

2013-10-30 Thread Mark Koudritsky 

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

Review request for cordova.


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


Repository: cordova-cli


Description
---

Currently all platform parsers (src/metadata/*_parser.js) copy
cordova.js from util.libDirectory for each run of prepare. This results
in errors when changing machines since the ~/.cordova/lib directory is
not populated.

With this change all the parsers construct the project www dir by first
copying contents of a new dir named 
/platforms//platform_www
(which contains cordova.js) and then the www dir from the app.

Until individual platform create scripts will be updated to create the
platform_www dir, prepare.js checks if the platform_www exists and if
not, creates it using cordova.js from ~/.cordova/lib.

Even after the platform create scripts are updated the check will be
required for projects that were created using older version and don't
yet have a platform_www dir.


Diffs
-

  spec/metadata/android_parser.spec.js 4afb52d 
  spec/metadata/blackberry_parser.spec.js 3353eb1 
  spec/metadata/ios_parser.spec.js 17206c6 
  spec/metadata/windows8_parser.spec.js 5639317 
  spec/metadata/wp7_parser.spec.js 6b69d09 
  spec/metadata/wp8_parser.spec.js 02372cc 
  spec/prepare.spec.js 8012924 
  src/metadata/android_parser.js df446e1 
  src/metadata/blackberry10_parser.js d9f71f3 
  src/metadata/firefoxos_parser.js c3edd7b 
  src/metadata/ios_parser.js 20e985c 
  src/metadata/windows8_parser.js 68520fc 
  src/metadata/wp7_parser.js b19dc32 
  src/metadata/wp8_parser.js 3bdef16 
  src/prepare.js 4ea22c5 

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


Testing
---

npm test
corodva platform add android
corodva platform add ios
corodva platform add balckberry10
cordova prepare
verified platfrom_www dir exists and contains the right file.

Did not test for win platforms.


Thanks,

Mark Koudritsky

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

2013-10-30 Thread Michal Mocny 
Here are some links to jasmine-2 docs since its a hard time finding them:

http://jasmine.github.io/2.0/introduction.html

https://github.com/pivotal/jasmine/blob/master/release_notes/20rc5.md


On Wed, Oct 30, 2013 at 10:16 AM, Michal Mocny  wrote:

>
>
>
> On Tue, Oct 29, 2013 at 5:29 PM, Bryan Higgins wrote:
>
>> I just converted geolocation to the new test style [1]
>>
>> I'm happy with the process overall, and I find the jasmine 2 tests are
>> more
>> succinct.
>>
>> There are a few things worth noting:
>> - I kept the eval code in. At google today, it was discussed that this may
>> not be the best approach.
>> - Jasmine 2: You must hit at least one expect statement or the test will
>> timeout even though done was called.
>>
>
> We could file a bug (I ran into it during setup once too), but really,
> what is the worth of a test if there are no expect clauses?
>
>
>> - I did not remove the manual test page [2]. It would be great if we had a
>> convention for importing these. (ie test harness looks for a page at
>> www/test/plugin-id.html and adds a link to it if it exists)
>>
>
> I'm going to work on a solution for this today.  The thought is that the
> plugin has a single module that can define all auto/manual tests, and the
> test-harness choses which to display where.
>
>
>>
>> [1]
>>
>> https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-geolocation.git;a=commit;h=075850a460d8171a04809cf6317fb4c4ef998603
>> [2]
>>
>> https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-geolocation.git;a=blob;f=test/manual.html;h=6ec2eed03e18c2efaa8710094d60930bb32227ba;hb=459a01c01e8dfa2a688d25483bb48c46d8e2
>>
>>
>> On Tue, Oct 15, 2013 at 12:50 PM, David Kemp  wrote:
>>
>> > In spite of that fact that it needs a tooling change, I like the added
>> >  tag / prepare steps.
>> > The tooling change should be small and it means no runtime impact on
>> apps.
>> >
>> > I love the approach - a very positive step to cleaning up testing.
>> >
>> > David Kemp
>> >
>> >
>> >
>> > On Tue, Oct 15, 2013 at 12:18 PM, Michal Mocny 
>> > wrote:
>> >
>> > > Braden, you're right, good catch.
>> > >
>> > > Discussing locally how we could support "prepare --mode=..." in the
>> most
>> > > generalized form, we remembered an old suggestion to just support
>> 
>> > > tags.
>> > >
>> > > The benefits seem to be:
>> > > - No need to add custom tag-prefix/attributes for the combinations of
>> > > js-module mode=, asset mode=, etc etc
>> > > - More visually apparent when reading a plugin.xml file, akin to
>> > >  tag
>> > >
>> > > The drawbacks seem to be:
>> > > - Not all descendant tags are easy to support for a given mode (ie,
>> > > )
>> > >
>> > >
>> > > Summarizing the options currently discussed in this thread:
>> > >
>> > > - new  tag.  Not general enough solution to support
>> tests
>> > > bundling , so -1 from me for this reason.
>> > > - mode="..." attribute for a set of whitelisted tags (,
>> > ,
>> > > ...)
>> > > -  tag for a set of whitelisted descendant
>> > > tags (, , ...)
>> > >
>> > > The last two options are really functionally equivalent, but given
>> that
>> > we
>> > > opted for  tag instead of attribute, I'm also favoring a
>> 
>> > > tag.
>> > >
>> > > -Michal
>> > >
>> > >
>> > > On Tue, Oct 15, 2013 at 11:43 AM, Braden Shepherdson <
>> > bra...@chromium.org
>> > > >wrote:
>> > >
>> > > > It's not true that adding these tests only creates larger binaries.
>> > They
>> > > > will be fetched and parsed by the plugin loader code at app startup
>> > time.
>> > > > It goes through the list of all plugins in cordova_plugins.js and
>> loads
>> > > > them all. That parses them, and runs the outermost layer, which is
>> the
>> > > > wrapping function function(require, module, exports) { ... }. So
>> there
>> > is
>> > > > still runtime memory and CPU impact.
>> > > >
>> > > > I support  tags or  or whatever.
>> > > > Similarly, prepare for tests. I realize we want to avoid tooling
>> > support,
>> > > > but I think tooling support is a lesser evil than production
>> > performance
>> > > > impact.
>> > > >
>> > > > Overall approach makes me happy.
>> > > >
>> > > > Braden
>> > > >
>> > > >
>> > > > On Fri, Oct 11, 2013 at 9:43 PM, Michal Mocny 
>> > > wrote:
>> > > >
>> > > >> On Fri, Oct 11, 2013 at 9:08 PM, Andrew Grieve <
>> agri...@chromium.org>
>> > > >> wrote:
>> > > >>
>> > > >> > The eval of the jasmine interface deserves mention. Is the
>> > motivation
>> > > >> > there that tests can choose to use another testing framework?
>> That's
>> > > why
>> > > >> > you don't just make jasmine functions globals?
>> > > >> >
>> > > >>
>> > > >> I was hoping the plugins would need to depend on anything but
>> CDVTest,
>> > > and
>> > > >> not expect any globals.  I guess, though, that CDVTest still
>> expects
>> > the
>> > > >> app to provide to a test framework and some other stuff, so in the
>> end
>> > > its
>> > > >> no different.  I was hedging on being able to update CDVTest in the
>> > > future
>> > > >> fo

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

2013-10-30 Thread Michal Mocny 
On Tue, Oct 29, 2013 at 5:29 PM, Bryan Higgins wrote:

> I just converted geolocation to the new test style [1]
>
> I'm happy with the process overall, and I find the jasmine 2 tests are more
> succinct.
>
> There are a few things worth noting:
> - I kept the eval code in. At google today, it was discussed that this may
> not be the best approach.
> - Jasmine 2: You must hit at least one expect statement or the test will
> timeout even though done was called.
>

We could file a bug (I ran into it during setup once too), but really, what
is the worth of a test if there are no expect clauses?


> - I did not remove the manual test page [2]. It would be great if we had a
> convention for importing these. (ie test harness looks for a page at
> www/test/plugin-id.html and adds a link to it if it exists)
>

I'm going to work on a solution for this today.  The thought is that the
plugin has a single module that can define all auto/manual tests, and the
test-harness choses which to display where.


>
> [1]
>
> https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-geolocation.git;a=commit;h=075850a460d8171a04809cf6317fb4c4ef998603
> [2]
>
> https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-geolocation.git;a=blob;f=test/manual.html;h=6ec2eed03e18c2efaa8710094d60930bb32227ba;hb=459a01c01e8dfa2a688d25483bb48c46d8e2
>
>
> On Tue, Oct 15, 2013 at 12:50 PM, David Kemp  wrote:
>
> > In spite of that fact that it needs a tooling change, I like the added
> >  tag / prepare steps.
> > The tooling change should be small and it means no runtime impact on
> apps.
> >
> > I love the approach - a very positive step to cleaning up testing.
> >
> > David Kemp
> >
> >
> >
> > On Tue, Oct 15, 2013 at 12:18 PM, Michal Mocny 
> > wrote:
> >
> > > Braden, you're right, good catch.
> > >
> > > Discussing locally how we could support "prepare --mode=..." in the
> most
> > > generalized form, we remembered an old suggestion to just support
> 
> > > tags.
> > >
> > > The benefits seem to be:
> > > - No need to add custom tag-prefix/attributes for the combinations of
> > > js-module mode=, asset mode=, etc etc
> > > - More visually apparent when reading a plugin.xml file, akin to
> > >  tag
> > >
> > > The drawbacks seem to be:
> > > - Not all descendant tags are easy to support for a given mode (ie,
> > > )
> > >
> > >
> > > Summarizing the options currently discussed in this thread:
> > >
> > > - new  tag.  Not general enough solution to support
> tests
> > > bundling , so -1 from me for this reason.
> > > - mode="..." attribute for a set of whitelisted tags (,
> > ,
> > > ...)
> > > -  tag for a set of whitelisted descendant
> > > tags (, , ...)
> > >
> > > The last two options are really functionally equivalent, but given that
> > we
> > > opted for  tag instead of attribute, I'm also favoring a
> 
> > > tag.
> > >
> > > -Michal
> > >
> > >
> > > On Tue, Oct 15, 2013 at 11:43 AM, Braden Shepherdson <
> > bra...@chromium.org
> > > >wrote:
> > >
> > > > It's not true that adding these tests only creates larger binaries.
> > They
> > > > will be fetched and parsed by the plugin loader code at app startup
> > time.
> > > > It goes through the list of all plugins in cordova_plugins.js and
> loads
> > > > them all. That parses them, and runs the outermost layer, which is
> the
> > > > wrapping function function(require, module, exports) { ... }. So
> there
> > is
> > > > still runtime memory and CPU impact.
> > > >
> > > > I support  tags or  or whatever.
> > > > Similarly, prepare for tests. I realize we want to avoid tooling
> > support,
> > > > but I think tooling support is a lesser evil than production
> > performance
> > > > impact.
> > > >
> > > > Overall approach makes me happy.
> > > >
> > > > Braden
> > > >
> > > >
> > > > On Fri, Oct 11, 2013 at 9:43 PM, Michal Mocny 
> > > wrote:
> > > >
> > > >> On Fri, Oct 11, 2013 at 9:08 PM, Andrew Grieve <
> agri...@chromium.org>
> > > >> wrote:
> > > >>
> > > >> > The eval of the jasmine interface deserves mention. Is the
> > motivation
> > > >> > there that tests can choose to use another testing framework?
> That's
> > > why
> > > >> > you don't just make jasmine functions globals?
> > > >> >
> > > >>
> > > >> I was hoping the plugins would need to depend on anything but
> CDVTest,
> > > and
> > > >> not expect any globals.  I guess, though, that CDVTest still expects
> > the
> > > >> app to provide to a test framework and some other stuff, so in the
> end
> > > its
> > > >> no different.  I was hedging on being able to update CDVTest in the
> > > future
> > > >> for whatever we need, and all 3rdparty plugins would not need
> > updating.
> > > >>  eval() could be used to do all sorts of clever things if we
> needed..
> > > >>
> > > >>
> > > >> >
> > > >> > One nit pick just from reading your email is that this will cause
> > the
> > > >> test
> > > >> > js-modules to be injected into apps that use the plugins. I think
> > > >> probably
> > > >> > we will want to update the too

RE: So, what to do about storage issues?

2013-10-30 Thread Dick Van den Brink 
A follow up on the issue, I had some time to check it today! Because we are 
still on cordova 3.0.0 I made a custom build with the fix and it works like a 
charm! Thanks :)

To: dev@cordova.apache.org
From: d_vandenbr...@outlook.com
Subject: RE: So, what to do about storage issues?
Date: Fri, 25 Oct 2013 13:55:26 +0700







Wow, that would be awesome! Thanks! Hope I have time to check it next week! 
Thanks!



Sent from my Windows Phone



From:
Andrew Grieve

Sent:
‎10/‎24/‎2013 22:12

To:
dev

Subject:
Re: So, what to do about storage issues?





Made a discovery today that Cordova's Quota logic was wrong. Filed this as

https://issues.apache.org/jira/browse/CB-5193 and fixed it :). Multiple

databases should work fine starting in 3.2 / 2.9.1.