Re: Platforms Meet-up @ Waterloo

[Carlos Santana]

I sent a request to our management team for travel, I don't think it's
going to get approved in this short time notice.

We would like to participate if you guys do a 1 hour hangout at the end of
the day maybe to recap.
If not just recording some of the meetings for later viewing that might be
helpful for folks not present.

If not that's OK also, have fun guys

--Carlos


On Tue, Oct 15, 2013 at 11:24 AM, Andrew Grieve wrote:

> Awesome! Glad that you guys can come!
>
> From the Google side - I think everyone will be here except for Braden
> (he's going to MTV to give a talk on AngularJS!).
>
> Here's a slightly expanded list of work topics I've thought of. Feel free
> to add or to take ownership of topics:
>
> - API Audit of File API (plus talking about fixing CB-285)
> - Accessibility (both IBM and Adobe have mentioned this recently, not sure
> if there's anything to share / report yet)
> - Audit of Native API
>   - Plugin API look good?
>   - WebView / Embedding API look good?
>   - Settings API look good?
> - Using Gradle on Android (I've read a couple "intro to Gradle" articles,
> but haven't fiddled yet)
> - Android Splash Screen uses a hard-coded delay (iOS goes away when page is
> ready)
> - Platform Roadmaps (other platforms too depending on who's attending)
>
>
>
>
> On Mon, Oct 14, 2013 at 5:36 PM, Anis KADRI  wrote:
>
> > +1!
> >
> > On Fri, Oct 11, 2013 at 10:35 AM, Gorkem Ercan 
> > wrote:
> > > +1
> > > would like to come, Red Hat is interested to contribute on platforms as
> > > well.
> > > --
> > > Gorkem
> > >
> > >
> > > On Wed, Oct 9, 2013 at 10:10 AM, Andrew Grieve 
> > wrote:
> > >
> > >> Working via email is fun, but seeing each other in person is fun too!
> > >>
> > >> I'd like to invite committers / active contributors who are able to
> join
> > >> the Google team for a couple days of work and fun at the Google
> Waterloo
> > >> office!
> > >>
> > >> When: Oct 29th, 30th (Tuesday, Wednesday)
> > >> Where: Google Waterloo (http://goo.gl/jI99Fr)
> > >> Full Address: 151 Charles Street West, Kitchener, Ontario
> > >> What: Working together + dinner and a social activity evening of the
> > 29th
> > >>
> > >> More details:
> > >> A lot of focus recently has been on CLI/Plugman, so I wanted this
> > meet-up
> > >> to instead focus on *platforms*.
> > >>
> > >> Specifically:
> > >> - iOS & Android Roadmaps (other platforms too depending on who's
> > attending)
> > >> - Storage locations (CB-285) (oldie but a goldie!)
> > >> - Accessibility (both IBM and Adobe have mentioned this recently, not
> > sure
> > >> if there's anything to share / report yet)
> > >>
> > >> If you're able to come, please respond to this thread so I can get an
> > idea
> > >> of numbers. We'll provide food and a work space, but you'll have to
> > figure
> > >> out how to get here. As always, we'll be sure to not make any
> decisions
> > >> without going through the ML.
> > >>
> > >> Andrew
> > >>
> >
>



-- 
Carlos Santana

Re: reviewboard .reviewboardrc and TRACKING_BRANCH = 'origin/dev' ?

[Carlos Santana]

Wiki has being updated
https://wiki.apache.org/cordova/CommitterWorkflow

list which repos can be use with post-review, and using github as
alternative for code review.

Oh and I manage to get Jesse's cell number so its there also :-)

--Carlos


On Wed, Oct 16, 2013 at 1:56 AM, Carlos Santana wrote:

> 1. How do I use post-review on cordova-wp8 repo then? without
> .reviewboardrc it doesn't work
>
> cordova-wp8:(master)$ post-review
> Unable to find a Review Board server for this source code tree.
>
> 2. I agree 100% (lets kill dev branch)
> But today How do I use post-review to submit a review for a commit that I
> want to push to dev branch for plugin?
>
> 3. what's your phone number? :-)
>
> I'm serious here if this post-review piece of sh%$ doesn't work I don't
> want to use it then. Or maybe don't send any code review since I have write
> access to repo now.
>
> Maybe this makes my question more clear now.
>
>
>
> On Wed, Oct 16, 2013 at 1:42 AM, Jesse  wrote:
>
>> My thoughts:
>>
>> 1. No,
>> 2. master SHOULD be used for development, and considered unstable, but
>> probably should have passing tests.
>> - this is not currently the case, but we need to change this. plugman,
>> I believe is still pulling from master where it should be pulling from a
>> version tag
>> 3. use github, use this mailing list, use a phonecall, ...
>>
>>
>> @purplecabbage
>> risingj.com
>>
>>
>> On Tue, Oct 15, 2013 at 10:13 PM, Carlos Santana > >wrote:
>>
>> > 1. Should all repos contain a file ".reviewboardrc" ? Some repos are
>> > missing this file
>> >
>> > 2. Should the plugins repos contain the file ".reviewboardrc" and it
>> should
>> > have a variable TRACKING_BRANCH = 'origin/dev'? since 'master' is not
>> being
>> > use for development.
>> >
>> > 3. Is obligatory to only use reviewboard? or can committers use github
>> to
>> > review code?
>> > 3a. As a personal preference I like github better for reviews, search,
>> and
>> > share code reviews. Maybe because it's what I have used for some time
>> as a
>> > contributor and also on other open source projects I contribute I also
>> use
>> > github for reviews/pullrequests
>> >
>> >
>> > References:
>> >
>> >
>> >
>> https://github.com/reviewboard/rbtools/blob/master/docs/rbtools/post-review.txt
>> >
>> >
>> > --
>> > Carlos Santana
>> > 
>> >
>>
>
>
>
> --
> Carlos Santana
> 
>



-- 
Carlos Santana

Re: reviewboard .reviewboardrc and TRACKING_BRANCH = 'origin/dev' ?

[Carlos Santana]

1. How do I use post-review on cordova-wp8 repo then? without
.reviewboardrc it doesn't work

cordova-wp8:(master)$ post-review
Unable to find a Review Board server for this source code tree.

2. I agree 100% (lets kill dev branch)
But today How do I use post-review to submit a review for a commit that I
want to push to dev branch for plugin?

3. what's your phone number? :-)

I'm serious here if this post-review piece of sh%$ doesn't work I don't
want to use it then. Or maybe don't send any code review since I have write
access to repo now.

Maybe this makes my question more clear now.



On Wed, Oct 16, 2013 at 1:42 AM, Jesse  wrote:

> My thoughts:
>
> 1. No,
> 2. master SHOULD be used for development, and considered unstable, but
> probably should have passing tests.
> - this is not currently the case, but we need to change this. plugman,
> I believe is still pulling from master where it should be pulling from a
> version tag
> 3. use github, use this mailing list, use a phonecall, ...
>
>
> @purplecabbage
> risingj.com
>
>
> On Tue, Oct 15, 2013 at 10:13 PM, Carlos Santana  >wrote:
>
> > 1. Should all repos contain a file ".reviewboardrc" ? Some repos are
> > missing this file
> >
> > 2. Should the plugins repos contain the file ".reviewboardrc" and it
> should
> > have a variable TRACKING_BRANCH = 'origin/dev'? since 'master' is not
> being
> > use for development.
> >
> > 3. Is obligatory to only use reviewboard? or can committers use github to
> > review code?
> > 3a. As a personal preference I like github better for reviews, search,
> and
> > share code reviews. Maybe because it's what I have used for some time as
> a
> > contributor and also on other open source projects I contribute I also
> use
> > github for reviews/pullrequests
> >
> >
> > References:
> >
> >
> >
> https://github.com/reviewboard/rbtools/blob/master/docs/rbtools/post-review.txt
> >
> >
> > --
> > Carlos Santana
> > 
> >
>



-- 
Carlos Santana

Re: reviewboard .reviewboardrc and TRACKING_BRANCH = 'origin/dev' ?

[Jesse]

My thoughts:

1. No,
2. master SHOULD be used for development, and considered unstable, but
probably should have passing tests.
- this is not currently the case, but we need to change this. plugman,
I believe is still pulling from master where it should be pulling from a
version tag
3. use github, use this mailing list, use a phonecall, ...


@purplecabbage
risingj.com


On Tue, Oct 15, 2013 at 10:13 PM, Carlos Santana wrote:

> 1. Should all repos contain a file ".reviewboardrc" ? Some repos are
> missing this file
>
> 2. Should the plugins repos contain the file ".reviewboardrc" and it should
> have a variable TRACKING_BRANCH = 'origin/dev'? since 'master' is not being
> use for development.
>
> 3. Is obligatory to only use reviewboard? or can committers use github to
> review code?
> 3a. As a personal preference I like github better for reviews, search, and
> share code reviews. Maybe because it's what I have used for some time as a
> contributor and also on other open source projects I contribute I also use
> github for reviews/pullrequests
>
>
> References:
>
>
> https://github.com/reviewboard/rbtools/blob/master/docs/rbtools/post-review.txt
>
>
> --
> Carlos Santana
> 
>

Re: Jira admin

[Shazron]

No worries -- sorry about the upcoming spam :)


On Tue, Oct 15, 2013 at 9:16 PM, Anis KADRI  wrote:

> I did not. I wasn't aware of this "Release" function. Apologies.
>
> On Tue, Oct 15, 2013 at 9:07 PM, Shazron  wrote:
> > Did you move the 3.1.0 issues to 3.2.0 automatically? (this is a feature
> of
> > the Release function). Didn't receive the usual flurry of emails. If not,
> > everyone needs to check 3.1.0 issues in JIRA, and either remove the 3.1.0
> > version from each issue or move to 3.2.0
> >
> >
> > On Tue, Oct 15, 2013 at 2:15 PM, Anis KADRI 
> wrote:
> >
> >> done
> >>
> >> On Tue, Oct 15, 2013 at 2:09 PM, Marcel Kinard 
> wrote:
> >> > Could one of the folks with Jira karma add "3.1.0" to the list of
> >> released versions? Thanks!
> >>
>

reviewboard .reviewboardrc and TRACKING_BRANCH = 'origin/dev' ?

[Carlos Santana]

1. Should all repos contain a file ".reviewboardrc" ? Some repos are
missing this file

2. Should the plugins repos contain the file ".reviewboardrc" and it should
have a variable TRACKING_BRANCH = 'origin/dev'? since 'master' is not being
use for development.

3. Is obligatory to only use reviewboard? or can committers use github to
review code?
3a. As a personal preference I like github better for reviews, search, and
share code reviews. Maybe because it's what I have used for some time as a
contributor and also on other open source projects I contribute I also use
github for reviews/pullrequests


References:

https://github.com/reviewboard/rbtools/blob/master/docs/rbtools/post-review.txt


-- 
Carlos Santana

Re: Jira admin

[Anis KADRI]

I did not. I wasn't aware of this "Release" function. Apologies.

On Tue, Oct 15, 2013 at 9:07 PM, Shazron  wrote:
> Did you move the 3.1.0 issues to 3.2.0 automatically? (this is a feature of
> the Release function). Didn't receive the usual flurry of emails. If not,
> everyone needs to check 3.1.0 issues in JIRA, and either remove the 3.1.0
> version from each issue or move to 3.2.0
>
>
> On Tue, Oct 15, 2013 at 2:15 PM, Anis KADRI  wrote:
>
>> done
>>
>> On Tue, Oct 15, 2013 at 2:09 PM, Marcel Kinard  wrote:
>> > Could one of the folks with Jira karma add "3.1.0" to the list of
>> released versions? Thanks!
>>

Re: Jira admin

[Shazron]

Did you move the 3.1.0 issues to 3.2.0 automatically? (this is a feature of
the Release function). Didn't receive the usual flurry of emails. If not,
everyone needs to check 3.1.0 issues in JIRA, and either remove the 3.1.0
version from each issue or move to 3.2.0


On Tue, Oct 15, 2013 at 2:15 PM, Anis KADRI  wrote:

> done
>
> On Tue, Oct 15, 2013 at 2:09 PM, Marcel Kinard  wrote:
> > Could one of the folks with Jira karma add "3.1.0" to the list of
> released versions? Thanks!
>

Re: third-party cordova plugin registry

[Gorkem Ercan]

Hey Anis,
plugman command line is better than what I have been doing :)
I failed to find the multiple registry issue. Can you forward it if you
find it.

Of course it is up to the provider but does that mean there is no curation
and cordova.io registry may carry plugins that has never worked?
--
Gorkem


On Tue, Oct 15, 2013 at 9:56 PM, Anis KADRI  wrote:

> I agree that they should be encouraged.
>
> configuration is stored in plugman (even for cordova-cli) and one can
> easily set a registry with `plugman config set registry
> http://newregistry' (exactly like NPM).
>
> There were discussions about adding multiple registry support as well
> as a fallback to the filesystem and I believe there is an issue for
> it.
>
> As far as which plugins go where, I believe it's up to whomever provides
> it.
>
> On Tue, Oct 15, 2013 at 4:08 PM, Gorkem Ercan 
> wrote:
> > Should 3rd party plugin registries be encouraged or not? I personally
> would
> > like to see more of them but I do not think we are technically supporting
> > them enough. Introducing a new registry to plugman/cli is done through
> > config.js. I guess the first problem is that "it is done through
> config.js"
> > rather than a CLI parameter.
> >
> > And even through config.js it is basically replacing the registry rather
> > than introducing a new one. This is somewhat limiting if a plugin
> > dependency is done through plugin ids (registry based ). The current
> > implementation limits plugins to have registry based dependencies from
> the
> > same repo that they are pulled in from.
> >
> > And I think this is related to the officially supported plugins
> discussion
> > as well. I think the plugins that "cordova community" (take community in
> > its largest form here) provides with a reasonable quality and support
> > should be in cordova registry. The other experimental stuff should live
> > elsewhere but be easily consumable for the brave.
> > --
> > Gorkem
> >
> >
> > On Sat, Oct 12, 2013 at 9:02 PM, Joni Rustulka  wrote:
> >
> >> I started work on an updated UI for the cordova registry yesterday,
> >> coincidentally.
> >>
> >> -j
> >>
> >> On 13-10-11 5:04 PM, "Steven Gill"  wrote:
> >>
> >> >Maybe we should contact him to help out with our official registry! We
> >> >could use some UX
> >> >
> >> >
> >> >On Fri, Oct 11, 2013 at 4:55 PM, Shazron  wrote:
> >> >
> >> >> Yeah especially since I'm sure none of us submitted anything he's
> >> >>just
> >> >> seeding stuff more like
> >> >>
> >> >>
> >> >> On Fri, Oct 11, 2013 at 4:54 PM, Jesse 
> wrote:
> >> >>
> >> >> > and apparently I have 2 ... this is going to confuse people, since
> >> >>most
> >> >> of
> >> >> > them are just different forks of the same repos.
> >> >> >
> >> >> > @purplecabbage
> >> >> > risingj.com
> >> >> >
> >> >> >
> >> >> > On Fri, Oct 11, 2013 at 4:52 PM, Jesse 
> >> >>wrote:
> >> >> >
> >> >> > > herm wong has 3 plugins up there! wtf?
> >> >> > >
> >> >> > > @purplecabbage
> >> >> > > risingj.com
> >> >> > >
> >> >> > >
> >> >> > > On Fri, Oct 11, 2013 at 4:46 PM, Anis KADRI <
> anis.ka...@gmail.com>
> >> >> > wrote:
> >> >> > >
> >> >> > >> I welcome the initiative. However, If I am not mistaken it only
> >> >> > >> references git URLs. There is no notion of version so you'd
> have to
> >> >> > >> pull from master.
> >> >> > >> It definitely looks better than plugins.cordova.io though xD!
> >> >> > >>
> >> >> > >> On Fri, Oct 11, 2013 at 4:40 PM, Shazron 
> >> wrote:
> >> >> > >> > Saw this from a comment on one of my blog posts:
> >> >> > >> > http://www.plugreg.com/
> >> >> > >>
> >> >> > >
> >> >> > >
> >> >> >
> >> >>
> >>
> >>
>

Re: third-party cordova plugin registry

[Anis KADRI]

I agree that they should be encouraged.

configuration is stored in plugman (even for cordova-cli) and one can
easily set a registry with `plugman config set registry
http://newregistry' (exactly like NPM).

There were discussions about adding multiple registry support as well
as a fallback to the filesystem and I believe there is an issue for
it.

As far as which plugins go where, I believe it's up to whomever provides it.

On Tue, Oct 15, 2013 at 4:08 PM, Gorkem Ercan  wrote:
> Should 3rd party plugin registries be encouraged or not? I personally would
> like to see more of them but I do not think we are technically supporting
> them enough. Introducing a new registry to plugman/cli is done through
> config.js. I guess the first problem is that "it is done through config.js"
> rather than a CLI parameter.
>
> And even through config.js it is basically replacing the registry rather
> than introducing a new one. This is somewhat limiting if a plugin
> dependency is done through plugin ids (registry based ). The current
> implementation limits plugins to have registry based dependencies from the
> same repo that they are pulled in from.
>
> And I think this is related to the officially supported plugins discussion
> as well. I think the plugins that "cordova community" (take community in
> its largest form here) provides with a reasonable quality and support
> should be in cordova registry. The other experimental stuff should live
> elsewhere but be easily consumable for the brave.
> --
> Gorkem
>
>
> On Sat, Oct 12, 2013 at 9:02 PM, Joni Rustulka  wrote:
>
>> I started work on an updated UI for the cordova registry yesterday,
>> coincidentally.
>>
>> -j
>>
>> On 13-10-11 5:04 PM, "Steven Gill"  wrote:
>>
>> >Maybe we should contact him to help out with our official registry! We
>> >could use some UX
>> >
>> >
>> >On Fri, Oct 11, 2013 at 4:55 PM, Shazron  wrote:
>> >
>> >> Yeah especially since I'm sure none of us submitted anything he's
>> >>just
>> >> seeding stuff more like
>> >>
>> >>
>> >> On Fri, Oct 11, 2013 at 4:54 PM, Jesse  wrote:
>> >>
>> >> > and apparently I have 2 ... this is going to confuse people, since
>> >>most
>> >> of
>> >> > them are just different forks of the same repos.
>> >> >
>> >> > @purplecabbage
>> >> > risingj.com
>> >> >
>> >> >
>> >> > On Fri, Oct 11, 2013 at 4:52 PM, Jesse 
>> >>wrote:
>> >> >
>> >> > > herm wong has 3 plugins up there! wtf?
>> >> > >
>> >> > > @purplecabbage
>> >> > > risingj.com
>> >> > >
>> >> > >
>> >> > > On Fri, Oct 11, 2013 at 4:46 PM, Anis KADRI 
>> >> > wrote:
>> >> > >
>> >> > >> I welcome the initiative. However, If I am not mistaken it only
>> >> > >> references git URLs. There is no notion of version so you'd have to
>> >> > >> pull from master.
>> >> > >> It definitely looks better than plugins.cordova.io though xD!
>> >> > >>
>> >> > >> On Fri, Oct 11, 2013 at 4:40 PM, Shazron 
>> wrote:
>> >> > >> > Saw this from a comment on one of my blog posts:
>> >> > >> > http://www.plugreg.com/
>> >> > >>
>> >> > >
>> >> > >
>> >> >
>> >>
>>
>>

Re: Tag 2.9.1

[Brian LeRoux]

3.5

(Or six months.)

But ya, what Jesse said.

On Tuesday, October 15, 2013, Jesse wrote:

> I would not add iOS7 support.
> I would consider adding any plugin changes if it is not too difficult to do
> so.
>
> @purplecabbage
> risingj.com
>
>
> On Tue, Oct 15, 2013 at 4:56 PM, Shazron >
> wrote:
>
> > Nothing is "completely" broken in iOS 7, although with iOS 7 issues that
> is
> > debatable. If we keep patching 2.9.x no one will move on to 3.x... (at
> > least for iOS). There has to be an ending...
> >
> >
> > On Tue, Oct 15, 2013 at 4:53 PM, Jesse 
> > >
> wrote:
> >
> > > Decide what is completely broken in your platform, that is reasonable
> to
> > > fix, and fix it.
> > > No promises ... just fix what we can, and document that it is fixed. I
> > > think...
> > >
> > > @purplecabbage
> > > risingj.com
> > >
> > >
> > > On Tue, Oct 15, 2013 at 3:10 PM, Shazron >
> wrote:
> > >
> > > > One question about this that was not answered. When does back-porting
> > > end?
> > > > I'm not sure what we promised for 2.9.x support going forward...
> > > >
> > > >
> > > > On Tue, Oct 15, 2013 at 1:16 PM, Jesse 
> > > > 
> >
> > wrote:
> > > >
> > > > > Okay, I am actively working on back-porting plugin fixes into 2.9.1
> > for
> > > > > WP7, WP8, and Windows8
> > > > > What is the status of Android, BB, iOS, ... ?
> > > > >
> > > > >
> > > > >
> > > > > @purplecabbage
> > > > > risingj.com
> > > > >
> > > > >
> > > > > On Mon, Oct 7, 2013 at 12:58 PM, Jesse MacFadyen <
> > > > purplecabb...@gmail.com 
> > > > > >wrote:
> > > > >
> > > > > > Yes, now that 3.1.0 is out the door, we can do this.
> > > > > >
> > > > > > Sent from my iPad
> > > > > >
> > > > > > > On Oct 7, 2013, at 10:36 AM, Joe Bowser 
> > > > > > > 
> >
> > wrote:
> > > > > > >
> > > > > > > I think we need to just have everyone go through their work
> over
> > > the
> > > > > > > past month and see if they missed backports.  I didn't actually
> > > have
> > > > > > > very much missed, and I just backported the File plugin in the
> > > 2.9.1
> > > > > > > branch.  Of course, with backporting, we need more people to
> look
> > > at
> > > > > > > what was in 3.1.0 and the plugins and check to make sure we
> > > backport
> > > > > > > everything, since this is really tricky and spans all the
> plugin
> > > > > > > repos. :(
> > > > > > >
> > > > > > >> On Mon, Oct 7, 2013 at 10:00 AM, Marcel Kinard <
> > > cmarc...@gmail.com >
> > > > > > wrote:
> > > > > > >> This thread seems to have gone quiet without a consensus.
> Should
> > > > there
> > > > > > be additional 2.9.x releases going forward?
> > > > > > >>
> > > > > > >> If so, how often? What kind of fixes should be backported?
> > Include
> > > > > > updated docs?
> > > > > > >>
> > > > > > >>> On Oct 1, 2013, at 2:50 PM, Jesse 
> > > > > > >>> 
> >
> > > wrote:
> > > > > > >>>
> > > > > > >>> As soon as we are done with 3.1.0 it would be a good time to
> go
> > > > back
> > > > > > and
> > > > > > >>> back-fill for a 2,9,1 release.
> > > > > > >>>
> > > > > > >>> Who's with me?
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Tag 2.9.1

[Jesse]

I would not add iOS7 support.
I would consider adding any plugin changes if it is not too difficult to do
so.

@purplecabbage
risingj.com


On Tue, Oct 15, 2013 at 4:56 PM, Shazron  wrote:

> Nothing is "completely" broken in iOS 7, although with iOS 7 issues that is
> debatable. If we keep patching 2.9.x no one will move on to 3.x... (at
> least for iOS). There has to be an ending...
>
>
> On Tue, Oct 15, 2013 at 4:53 PM, Jesse  wrote:
>
> > Decide what is completely broken in your platform, that is reasonable to
> > fix, and fix it.
> > No promises ... just fix what we can, and document that it is fixed. I
> > think...
> >
> > @purplecabbage
> > risingj.com
> >
> >
> > On Tue, Oct 15, 2013 at 3:10 PM, Shazron  wrote:
> >
> > > One question about this that was not answered. When does back-porting
> > end?
> > > I'm not sure what we promised for 2.9.x support going forward...
> > >
> > >
> > > On Tue, Oct 15, 2013 at 1:16 PM, Jesse 
> wrote:
> > >
> > > > Okay, I am actively working on back-porting plugin fixes into 2.9.1
> for
> > > > WP7, WP8, and Windows8
> > > > What is the status of Android, BB, iOS, ... ?
> > > >
> > > >
> > > >
> > > > @purplecabbage
> > > > risingj.com
> > > >
> > > >
> > > > On Mon, Oct 7, 2013 at 12:58 PM, Jesse MacFadyen <
> > > purplecabb...@gmail.com
> > > > >wrote:
> > > >
> > > > > Yes, now that 3.1.0 is out the door, we can do this.
> > > > >
> > > > > Sent from my iPad
> > > > >
> > > > > > On Oct 7, 2013, at 10:36 AM, Joe Bowser 
> wrote:
> > > > > >
> > > > > > I think we need to just have everyone go through their work over
> > the
> > > > > > past month and see if they missed backports.  I didn't actually
> > have
> > > > > > very much missed, and I just backported the File plugin in the
> > 2.9.1
> > > > > > branch.  Of course, with backporting, we need more people to look
> > at
> > > > > > what was in 3.1.0 and the plugins and check to make sure we
> > backport
> > > > > > everything, since this is really tricky and spans all the plugin
> > > > > > repos. :(
> > > > > >
> > > > > >> On Mon, Oct 7, 2013 at 10:00 AM, Marcel Kinard <
> > cmarc...@gmail.com>
> > > > > wrote:
> > > > > >> This thread seems to have gone quiet without a consensus. Should
> > > there
> > > > > be additional 2.9.x releases going forward?
> > > > > >>
> > > > > >> If so, how often? What kind of fixes should be backported?
> Include
> > > > > updated docs?
> > > > > >>
> > > > > >>> On Oct 1, 2013, at 2:50 PM, Jesse 
> > wrote:
> > > > > >>>
> > > > > >>> As soon as we are done with 3.1.0 it would be a good time to go
> > > back
> > > > > and
> > > > > >>> back-fill for a 2,9,1 release.
> > > > > >>>
> > > > > >>> Who's with me?
> > > > >
> > > >
> > >
> >
>

Re: Tag 2.9.1

[Shazron]

Nothing is "completely" broken in iOS 7, although with iOS 7 issues that is
debatable. If we keep patching 2.9.x no one will move on to 3.x... (at
least for iOS). There has to be an ending...


On Tue, Oct 15, 2013 at 4:53 PM, Jesse  wrote:

> Decide what is completely broken in your platform, that is reasonable to
> fix, and fix it.
> No promises ... just fix what we can, and document that it is fixed. I
> think...
>
> @purplecabbage
> risingj.com
>
>
> On Tue, Oct 15, 2013 at 3:10 PM, Shazron  wrote:
>
> > One question about this that was not answered. When does back-porting
> end?
> > I'm not sure what we promised for 2.9.x support going forward...
> >
> >
> > On Tue, Oct 15, 2013 at 1:16 PM, Jesse  wrote:
> >
> > > Okay, I am actively working on back-porting plugin fixes into 2.9.1 for
> > > WP7, WP8, and Windows8
> > > What is the status of Android, BB, iOS, ... ?
> > >
> > >
> > >
> > > @purplecabbage
> > > risingj.com
> > >
> > >
> > > On Mon, Oct 7, 2013 at 12:58 PM, Jesse MacFadyen <
> > purplecabb...@gmail.com
> > > >wrote:
> > >
> > > > Yes, now that 3.1.0 is out the door, we can do this.
> > > >
> > > > Sent from my iPad
> > > >
> > > > > On Oct 7, 2013, at 10:36 AM, Joe Bowser  wrote:
> > > > >
> > > > > I think we need to just have everyone go through their work over
> the
> > > > > past month and see if they missed backports.  I didn't actually
> have
> > > > > very much missed, and I just backported the File plugin in the
> 2.9.1
> > > > > branch.  Of course, with backporting, we need more people to look
> at
> > > > > what was in 3.1.0 and the plugins and check to make sure we
> backport
> > > > > everything, since this is really tricky and spans all the plugin
> > > > > repos. :(
> > > > >
> > > > >> On Mon, Oct 7, 2013 at 10:00 AM, Marcel Kinard <
> cmarc...@gmail.com>
> > > > wrote:
> > > > >> This thread seems to have gone quiet without a consensus. Should
> > there
> > > > be additional 2.9.x releases going forward?
> > > > >>
> > > > >> If so, how often? What kind of fixes should be backported? Include
> > > > updated docs?
> > > > >>
> > > > >>> On Oct 1, 2013, at 2:50 PM, Jesse 
> wrote:
> > > > >>>
> > > > >>> As soon as we are done with 3.1.0 it would be a good time to go
> > back
> > > > and
> > > > >>> back-fill for a 2,9,1 release.
> > > > >>>
> > > > >>> Who's with me?
> > > >
> > >
> >
>

Re: Tag 2.9.1

[Jesse]

Decide what is completely broken in your platform, that is reasonable to
fix, and fix it.
No promises ... just fix what we can, and document that it is fixed. I
think...

@purplecabbage
risingj.com


On Tue, Oct 15, 2013 at 3:10 PM, Shazron  wrote:

> One question about this that was not answered. When does back-porting end?
> I'm not sure what we promised for 2.9.x support going forward...
>
>
> On Tue, Oct 15, 2013 at 1:16 PM, Jesse  wrote:
>
> > Okay, I am actively working on back-porting plugin fixes into 2.9.1 for
> > WP7, WP8, and Windows8
> > What is the status of Android, BB, iOS, ... ?
> >
> >
> >
> > @purplecabbage
> > risingj.com
> >
> >
> > On Mon, Oct 7, 2013 at 12:58 PM, Jesse MacFadyen <
> purplecabb...@gmail.com
> > >wrote:
> >
> > > Yes, now that 3.1.0 is out the door, we can do this.
> > >
> > > Sent from my iPad
> > >
> > > > On Oct 7, 2013, at 10:36 AM, Joe Bowser  wrote:
> > > >
> > > > I think we need to just have everyone go through their work over the
> > > > past month and see if they missed backports.  I didn't actually have
> > > > very much missed, and I just backported the File plugin in the 2.9.1
> > > > branch.  Of course, with backporting, we need more people to look at
> > > > what was in 3.1.0 and the plugins and check to make sure we backport
> > > > everything, since this is really tricky and spans all the plugin
> > > > repos. :(
> > > >
> > > >> On Mon, Oct 7, 2013 at 10:00 AM, Marcel Kinard 
> > > wrote:
> > > >> This thread seems to have gone quiet without a consensus. Should
> there
> > > be additional 2.9.x releases going forward?
> > > >>
> > > >> If so, how often? What kind of fixes should be backported? Include
> > > updated docs?
> > > >>
> > > >>> On Oct 1, 2013, at 2:50 PM, Jesse  wrote:
> > > >>>
> > > >>> As soon as we are done with 3.1.0 it would be a good time to go
> back
> > > and
> > > >>> back-fill for a 2,9,1 release.
> > > >>>
> > > >>> Who's with me?
> > >
> >
>

Re: third-party cordova plugin registry

[Gorkem Ercan]

Should 3rd party plugin registries be encouraged or not? I personally would
like to see more of them but I do not think we are technically supporting
them enough. Introducing a new registry to plugman/cli is done through
config.js. I guess the first problem is that "it is done through config.js"
rather than a CLI parameter.

And even through config.js it is basically replacing the registry rather
than introducing a new one. This is somewhat limiting if a plugin
dependency is done through plugin ids (registry based ). The current
implementation limits plugins to have registry based dependencies from the
same repo that they are pulled in from.

And I think this is related to the officially supported plugins discussion
as well. I think the plugins that "cordova community" (take community in
its largest form here) provides with a reasonable quality and support
should be in cordova registry. The other experimental stuff should live
elsewhere but be easily consumable for the brave.
--
Gorkem


On Sat, Oct 12, 2013 at 9:02 PM, Joni Rustulka  wrote:

> I started work on an updated UI for the cordova registry yesterday,
> coincidentally.
>
> -j
>
> On 13-10-11 5:04 PM, "Steven Gill"  wrote:
>
> >Maybe we should contact him to help out with our official registry! We
> >could use some UX
> >
> >
> >On Fri, Oct 11, 2013 at 4:55 PM, Shazron  wrote:
> >
> >> Yeah especially since I'm sure none of us submitted anything he's
> >>just
> >> seeding stuff more like
> >>
> >>
> >> On Fri, Oct 11, 2013 at 4:54 PM, Jesse  wrote:
> >>
> >> > and apparently I have 2 ... this is going to confuse people, since
> >>most
> >> of
> >> > them are just different forks of the same repos.
> >> >
> >> > @purplecabbage
> >> > risingj.com
> >> >
> >> >
> >> > On Fri, Oct 11, 2013 at 4:52 PM, Jesse 
> >>wrote:
> >> >
> >> > > herm wong has 3 plugins up there! wtf?
> >> > >
> >> > > @purplecabbage
> >> > > risingj.com
> >> > >
> >> > >
> >> > > On Fri, Oct 11, 2013 at 4:46 PM, Anis KADRI 
> >> > wrote:
> >> > >
> >> > >> I welcome the initiative. However, If I am not mistaken it only
> >> > >> references git URLs. There is no notion of version so you'd have to
> >> > >> pull from master.
> >> > >> It definitely looks better than plugins.cordova.io though xD!
> >> > >>
> >> > >> On Fri, Oct 11, 2013 at 4:40 PM, Shazron 
> wrote:
> >> > >> > Saw this from a comment on one of my blog posts:
> >> > >> > http://www.plugreg.com/
> >> > >>
> >> > >
> >> > >
> >> >
> >>
>
>

RE: officially supported plugins from the Cordova community

[Smith, Peter]

+1 for some kind of list

Whenever the documented API refers to plugins which are not found in
what I thought was the official set plugins at
https://github.com/search?q=%40apache+cordova-plugin my brain hurts.
e.g. https://issues.apache.org/jira/browse/CB-5090

Peter.


-Original Message-
From: James Jong [mailto:wjamesj...@gmail.com] 
Sent: Wednesday, 16 October 2013 5:17 AM
To: dev@cordova.apache.org
Subject: officially supported plugins from the Cordova community

As we're breaking out and developing more and more plugins, one question
I have been getting is "what is the set of plugins officially supported
by the Cordova community?"  It's unclear to me what defines this set.
Here's how I've been categorizing them.

Supported
1) Publicly documented APIs on cordova.apache.org/docs (Accelerometer,
Compass, etc...).  These plugins fall under the org.apache.cordova
namespace.

Unsupported
2) plugins not under org.apache.cordova namespace
3) org.apache.cordova plugins under cordova-labs (like the new iOS
keyboard, status bar plugins)

Gray areas
4) Undocumented plugins that were formerly part of the core.  For
example, the console plugin.  This is a org,apache.cordova plugin, but
not documented as part of public APIs.  Also, not all platforms support
it.  Should we support it?  If we support it, should we document the API
in our Cordova docs?

Thoughts?  Should we have a list of supported plugins in our
documentation to point Cordova users to?

-James Jong

Re: Tag 2.9.1

[Shazron]

One question about this that was not answered. When does back-porting end?
I'm not sure what we promised for 2.9.x support going forward...


On Tue, Oct 15, 2013 at 1:16 PM, Jesse  wrote:

> Okay, I am actively working on back-porting plugin fixes into 2.9.1 for
> WP7, WP8, and Windows8
> What is the status of Android, BB, iOS, ... ?
>
>
>
> @purplecabbage
> risingj.com
>
>
> On Mon, Oct 7, 2013 at 12:58 PM, Jesse MacFadyen  >wrote:
>
> > Yes, now that 3.1.0 is out the door, we can do this.
> >
> > Sent from my iPad
> >
> > > On Oct 7, 2013, at 10:36 AM, Joe Bowser  wrote:
> > >
> > > I think we need to just have everyone go through their work over the
> > > past month and see if they missed backports.  I didn't actually have
> > > very much missed, and I just backported the File plugin in the 2.9.1
> > > branch.  Of course, with backporting, we need more people to look at
> > > what was in 3.1.0 and the plugins and check to make sure we backport
> > > everything, since this is really tricky and spans all the plugin
> > > repos. :(
> > >
> > >> On Mon, Oct 7, 2013 at 10:00 AM, Marcel Kinard 
> > wrote:
> > >> This thread seems to have gone quiet without a consensus. Should there
> > be additional 2.9.x releases going forward?
> > >>
> > >> If so, how often? What kind of fixes should be backported? Include
> > updated docs?
> > >>
> > >>> On Oct 1, 2013, at 2:50 PM, Jesse  wrote:
> > >>>
> > >>> As soon as we are done with 3.1.0 it would be a good time to go back
> > and
> > >>> back-fill for a 2,9,1 release.
> > >>>
> > >>> Who's with me?
> >
>

Re: officially supported plugins from the Cordova community

[Brian LeRoux]

oversight

opened a bug: http://issues.cordova.io/5089


On Tue, Oct 15, 2013 at 4:24 PM, Marcel Kinard  wrote:

> Here's the question I'm wondering about:
>
> The console plugin is not documented in cordova-docs. Is that an
> oversight, or is it a plugin that is treated differently?
>
> My take is that it is an oversight. If not, then what is the reasoning?

Re: Jira admin

[Anis KADRI]

done

On Tue, Oct 15, 2013 at 2:09 PM, Marcel Kinard  wrote:
> Could one of the folks with Jira karma add "3.1.0" to the list of released 
> versions? Thanks!

Jira admin

[Marcel Kinard]

Could one of the folks with Jira karma add "3.1.0" to the list of released 
versions? Thanks!

Re: officially supported plugins from the Cordova community

[Marcel Kinard]

Here's the question I'm wondering about:

The console plugin is not documented in cordova-docs. Is that an oversight, or 
is it a plugin that is treated differently?

My take is that it is an oversight. If not, then what is the reasoning?

Re: Tag 2.9.1

[Jesse]

Okay, I am actively working on back-porting plugin fixes into 2.9.1 for
WP7, WP8, and Windows8
What is the status of Android, BB, iOS, ... ?



@purplecabbage
risingj.com


On Mon, Oct 7, 2013 at 12:58 PM, Jesse MacFadyen wrote:

> Yes, now that 3.1.0 is out the door, we can do this.
>
> Sent from my iPad
>
> > On Oct 7, 2013, at 10:36 AM, Joe Bowser  wrote:
> >
> > I think we need to just have everyone go through their work over the
> > past month and see if they missed backports.  I didn't actually have
> > very much missed, and I just backported the File plugin in the 2.9.1
> > branch.  Of course, with backporting, we need more people to look at
> > what was in 3.1.0 and the plugins and check to make sure we backport
> > everything, since this is really tricky and spans all the plugin
> > repos. :(
> >
> >> On Mon, Oct 7, 2013 at 10:00 AM, Marcel Kinard 
> wrote:
> >> This thread seems to have gone quiet without a consensus. Should there
> be additional 2.9.x releases going forward?
> >>
> >> If so, how often? What kind of fixes should be backported? Include
> updated docs?
> >>
> >>> On Oct 1, 2013, at 2:50 PM, Jesse  wrote:
> >>>
> >>> As soon as we are done with 3.1.0 it would be a good time to go back
> and
> >>> back-fill for a 2,9,1 release.
> >>>
> >>> Who's with me?
>

Fwd: (CB-2234) add "about" command to CLI

[Marcel Kinard]

I was doing separate searches on "Lucas" and "Holmquist" and not finding you. 
It would be nice if the public name on the ICLA had your last name. An entry 
saying only "Luke" is fairly ambiguous. Would you be OK asking the secretary to 
make that change?

Begin forwarded message:

> From: "Lucas Holmquist (JIRA)" 
> Subject: [jira] [Commented] (CB-2234) add "about" command to CLI
> Date: October 15, 2013 2:42:43 PM EDT
> To: iss...@cordova.apache.org
> Reply-To: dev@cordova.apache.org
> 
> 
>[ 
> https://issues.apache.org/jira/browse/CB-2234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795495#comment-13795495
>  ] 
> 
> Lucas Holmquist commented on CB-2234:
> -
> 
> Looks like i'm on the list,  search for just "Luke",  looking at the form i 
> submitted,  the public name field is just "Luke"
> 
>> add "about" command to CLI
>> --
>> 
>>Key: CB-2234
>>URL: https://issues.apache.org/jira/browse/CB-2234
>>Project: Apache Cordova
>> Issue Type: Improvement
>> Components: CLI
>>   Reporter: Marcel Kinard
>>   Assignee: Lucas Holmquist
>>   Priority: Minor
>> 
>> When users post a question about "function x in Cordova isn't working", 
>> there is a default set of info that would be helpful to have, such as the 
>> Cordova version, OS version, perhaps the config.xml, and so forth. So how 
>> about if there is a "cordova about" command added to the CLI that can 
>> programmatically gather that information up, stuff it into a file, and leave 
>> the file on the user's system. Then we can ask the users to "run the 
>> 'cordova about' command and attach your about.txt file to the Jira issue". 
>> The intention is to make it easy and consistent to get information about the 
>> user's environment to help us debug issues. The information should be 
>> totally transparent, so the user can see what data they are sending.
> 
> 
> 
> --
> This message was sent by Atlassian JIRA
> (v6.1#6144)

Re: (CB-2234) add "about" command to CLI

[Lucas Holmquist]

yea,  i didn't realize it was going to be like that :)
On Oct 15, 2013, at 3:17 PM, Marcel Kinard  wrote:

> I was doing separate searches on "Lucas" and "Holmquist" and not finding you. 
> It would be nice if the public name on the ICLA had your last name. An entry 
> saying only "Luke" is fairly ambiguous. Would you be OK asking the secretary 
> to make that change?
> 
> Begin forwarded message:
> 
>> From: "Lucas Holmquist (JIRA)" 
>> Subject: [jira] [Commented] (CB-2234) add "about" command to CLI
>> Date: October 15, 2013 2:42:43 PM EDT
>> To: iss...@cordova.apache.org
>> Reply-To: dev@cordova.apache.org
>> 
>> 
>>   [ 
>> https://issues.apache.org/jira/browse/CB-2234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795495#comment-13795495
>>  ] 
>> 
>> Lucas Holmquist commented on CB-2234:
>> -
>> 
>> Looks like i'm on the list,  search for just "Luke",  looking at the form i 
>> submitted,  the public name field is just "Luke"
>> 
>>> add "about" command to CLI
>>> --
>>> 
>>>   Key: CB-2234
>>>   URL: https://issues.apache.org/jira/browse/CB-2234
>>>   Project: Apache Cordova
>>>Issue Type: Improvement
>>>Components: CLI
>>>  Reporter: Marcel Kinard
>>>  Assignee: Lucas Holmquist
>>>  Priority: Minor
>>> 
>>> When users post a question about "function x in Cordova isn't working", 
>>> there is a default set of info that would be helpful to have, such as the 
>>> Cordova version, OS version, perhaps the config.xml, and so forth. So how 
>>> about if there is a "cordova about" command added to the CLI that can 
>>> programmatically gather that information up, stuff it into a file, and 
>>> leave the file on the user's system. Then we can ask the users to "run the 
>>> 'cordova about' command and attach your about.txt file to the Jira issue". 
>>> The intention is to make it easy and consistent to get information about 
>>> the user's environment to help us debug issues. The information should be 
>>> totally transparent, so the user can see what data they are sending.
>> 
>> 
>> 
>> --
>> This message was sent by Atlassian JIRA
>> (v6.1#6144)
> 

Re: officially supported plugins from the Cordova community

[Brian LeRoux]

The tacit plan is to observe the plugin installation/download counts to
inform our decisions about what remains official and not. I suspect we
maintain more stuff than our community currently uses or needs.

Also, agree w/ Andrew that we should start migrating docs to the plugins
themselves.


On Tue, Oct 15, 2013 at 2:23 PM, Andrew Grieve  wrote:

> I think it depends on what your definition of "officially supported" is. If
> it's that we'll try and fix bugs that arise in them, I think they are all
> officially supported.
>
> In a 3.0 world, I think we'll move more towards having docs bundled with
> plugins instead of hosted on docs.cordova.io, so I don't think the docs
> are
> indicative of what we will "officially support"
>
>
> On Tue, Oct 15, 2013 at 2:17 PM, James Jong  wrote:
>
> > As we're breaking out and developing more and more plugins, one question
> I
> > have been getting is "what is the set of plugins officially supported by
> > the Cordova community?"  It's unclear to me what defines this set.
>  Here's
> > how I've been categorizing them.
> >
> > Supported
> > 1) Publicly documented APIs on cordova.apache.org/docs (Accelerometer,
> > Compass, etc…).  These plugins fall under the org.apache.cordova
> namespace.
> >
> > Unsupported
> > 2) plugins not under org.apache.cordova namespace
> > 3) org.apache.cordova plugins under cordova-labs (like the new iOS
> > keyboard, status bar plugins)
> >
> > Gray areas
> > 4) Undocumented plugins that were formerly part of the core.  For
> example,
> > the console plugin.  This is a org,apache.cordova plugin, but not
> > documented as part of public APIs.  Also, not all platforms support it.
> >  Should we support it?  If we support it, should we document the API in
> our
> > Cordova docs?
> >
> > Thoughts?  Should we have a list of supported plugins in our
> documentation
> > to point Cordova users to?
> >
> > -James Jong
> >
> >
>

Re: officially supported plugins from the Cordova community

[Andrew Grieve]

I think it depends on what your definition of "officially supported" is. If
it's that we'll try and fix bugs that arise in them, I think they are all
officially supported.

In a 3.0 world, I think we'll move more towards having docs bundled with
plugins instead of hosted on docs.cordova.io, so I don't think the docs are
indicative of what we will "officially support"


On Tue, Oct 15, 2013 at 2:17 PM, James Jong  wrote:

> As we're breaking out and developing more and more plugins, one question I
> have been getting is "what is the set of plugins officially supported by
> the Cordova community?"  It's unclear to me what defines this set.  Here's
> how I've been categorizing them.
>
> Supported
> 1) Publicly documented APIs on cordova.apache.org/docs (Accelerometer,
> Compass, etc…).  These plugins fall under the org.apache.cordova namespace.
>
> Unsupported
> 2) plugins not under org.apache.cordova namespace
> 3) org.apache.cordova plugins under cordova-labs (like the new iOS
> keyboard, status bar plugins)
>
> Gray areas
> 4) Undocumented plugins that were formerly part of the core.  For example,
> the console plugin.  This is a org,apache.cordova plugin, but not
> documented as part of public APIs.  Also, not all platforms support it.
>  Should we support it?  If we support it, should we document the API in our
> Cordova docs?
>
> Thoughts?  Should we have a list of supported plugins in our documentation
> to point Cordova users to?
>
> -James Jong
>
>

officially supported plugins from the Cordova community

[James Jong]

As we're breaking out and developing more and more plugins, one question I have 
been getting is "what is the set of plugins officially supported by the Cordova 
community?"  It's unclear to me what defines this set.  Here's how I've been 
categorizing them.

Supported
1) Publicly documented APIs on cordova.apache.org/docs (Accelerometer, Compass, 
etc…).  These plugins fall under the org.apache.cordova namespace.

Unsupported
2) plugins not under org.apache.cordova namespace
3) org.apache.cordova plugins under cordova-labs (like the new iOS keyboard, 
status bar plugins)

Gray areas
4) Undocumented plugins that were formerly part of the core.  For example, the 
console plugin.  This is a org,apache.cordova plugin, but not documented as 
part of public APIs.  Also, not all platforms support it.  Should we support 
it?  If we support it, should we document the API in our Cordova docs?

Thoughts?  Should we have a list of supported plugins in our documentation to 
point Cordova users to?

-James Jong

Re: Node-Webkit

[Shazron]

This is interesting (I like the 3 platforms support) - if this gets in, I
propose retiring the cordova-osx repo.


On Tue, Oct 15, 2013 at 11:00 AM, Maxime LUCE  wrote:

> Yes Jesse,
>
> It's about supporting node-webkit as a new, different platform.
> I see some great value added to a desktop platform :
>
> - Really easy to debug (chromium dev tools integrated)
> - Allow kiosk mode and other desktop integration which can be usefull in
> touch aware application.
> - Allow packaging and distribution on 3 main desktop OS.
>
> I think Cordova is mostly a bridge between HTML and Native APIs.
> Node-webkit enable a bridged communication between Webkit and Node.JS so
> can be used as a command proxy for Cordova.
>
> You also have the new packaged Chrome Apps which can be great to support
> too, I think.
>
> I think a cordova-desktop repository could be a great place to try out
> theses platforms.
>
>
> Cordialement.
>
>
> Maxime LUCE
>
>
> max...@touchit.fr
> 06 28 60 72 34
> http://touchit.fr
>
>
> -Original Message-
> From: Jesse [mailto:purplecabb...@gmail.com]
> Sent: mardi 15 octobre 2013 19:45
> To: dev@cordova.apache.org
> Subject: Re: Node-Webkit
>
> No, we are talking about node-webkit OR appjs as another target platform
> to support, which would mean we could build for apps for Windows, Linux,
> OSX desktop applications.
> I think node-webkit is the more mature platform, but I have only glanced
> at both. Definitely interesting.
>
>
> @purplecabbage
> risingj.com
>
>
> On Tue, Oct 15, 2013 at 10:38 AM, Brian LeRoux  wrote:
>
> > Cordova is mostly about phones (except when its OS X and Windows).
> > Node support is not a project goal though I would encourage you to
> > look at authoring plugins for iOS, Android, Windows Phone that mimic
> > Node APIs if that is something you're looking for.
> >
> >
> > On Tue, Oct 15, 2013 at 1:27 PM, Maxime LUCE  wrote:
> >
> > > What about a node-webkit or appjs platform integration ?
> > >
> > > It could help debugging with Cordova related projects and permit to
> > > add three platform with one platform : "Windows", "Linux", "OSX".
> > > I'm thinking about a platform proxy for node-webkit and/or
> > appjs-deskshell.
> > >
> > > What do you think of this improvement ?
> > > Is there some node-webkit specialists which can helps in this project ?
> > >
> > > Cordialement.
> > >
> > > [Touch it]
> > >
> > > Maxime LUCE
> > >
> > > [Facebook]
> > >
> > > [Twitter]
> > >
> > > max...@touchit.fr
> > > 06 28 60 72 34
> > > http://touchit.fr
> > >
> > >
> > >
> > >
> >
>

RE: Node-Webkit

[Maxime LUCE]

Yes Jesse,

It's about supporting node-webkit as a new, different platform.
I see some great value added to a desktop platform :

- Really easy to debug (chromium dev tools integrated)
- Allow kiosk mode and other desktop integration which can be usefull in touch 
aware application.
- Allow packaging and distribution on 3 main desktop OS.

I think Cordova is mostly a bridge between HTML and Native APIs. Node-webkit 
enable a bridged communication between Webkit and Node.JS so can be used as a 
command proxy for Cordova.

You also have the new packaged Chrome Apps which can be great to support too, I 
think.

I think a cordova-desktop repository could be a great place to try out theses 
platforms.


Cordialement.


Maxime LUCE


max...@touchit.fr
06 28 60 72 34
http://touchit.fr


-Original Message-
From: Jesse [mailto:purplecabb...@gmail.com] 
Sent: mardi 15 octobre 2013 19:45
To: dev@cordova.apache.org
Subject: Re: Node-Webkit

No, we are talking about node-webkit OR appjs as another target platform to 
support, which would mean we could build for apps for Windows, Linux, OSX 
desktop applications.
I think node-webkit is the more mature platform, but I have only glanced at 
both. Definitely interesting.


@purplecabbage
risingj.com


On Tue, Oct 15, 2013 at 10:38 AM, Brian LeRoux  wrote:

> Cordova is mostly about phones (except when its OS X and Windows). 
> Node support is not a project goal though I would encourage you to 
> look at authoring plugins for iOS, Android, Windows Phone that mimic 
> Node APIs if that is something you're looking for.
>
>
> On Tue, Oct 15, 2013 at 1:27 PM, Maxime LUCE  wrote:
>
> > What about a node-webkit or appjs platform integration ?
> >
> > It could help debugging with Cordova related projects and permit to 
> > add three platform with one platform : "Windows", "Linux", "OSX".
> > I'm thinking about a platform proxy for node-webkit and/or
> appjs-deskshell.
> >
> > What do you think of this improvement ?
> > Is there some node-webkit specialists which can helps in this project ?
> >
> > Cordialement.
> >
> > [Touch it]
> >
> > Maxime LUCE
> >
> > [Facebook]
> >
> > [Twitter]
> >
> > max...@touchit.fr
> > 06 28 60 72 34
> > http://touchit.fr
> >
> >
> >
> >
>

Re: Node-Webkit

[Jesse]

No, we are talking about node-webkit OR appjs as another target platform to
support, which would mean we could build for apps for Windows, Linux, OSX
desktop applications.
I think node-webkit is the more mature platform, but I have only glanced at
both. Definitely interesting.


@purplecabbage
risingj.com


On Tue, Oct 15, 2013 at 10:38 AM, Brian LeRoux  wrote:

> Cordova is mostly about phones (except when its OS X and Windows). Node
> support is not a project goal though I would encourage you to look at
> authoring plugins for iOS, Android, Windows Phone that mimic Node APIs if
> that is something you're looking for.
>
>
> On Tue, Oct 15, 2013 at 1:27 PM, Maxime LUCE  wrote:
>
> > What about a node-webkit or appjs platform integration ?
> >
> > It could help debugging with Cordova related projects and permit to add
> > three platform with one platform : "Windows", "Linux", "OSX".
> > I'm thinking about a platform proxy for node-webkit and/or
> appjs-deskshell.
> >
> > What do you think of this improvement ?
> > Is there some node-webkit specialists which can helps in this project ?
> >
> > Cordialement.
> >
> > [Touch it]
> >
> > Maxime LUCE
> >
> > [Facebook]
> >
> > [Twitter]
> >
> > max...@touchit.fr
> > 06 28 60 72 34
> > http://touchit.fr
> >
> >
> >
> >
>

Re: Node-Webkit

[Anis KADRI]

phones...and tablets :-)

On Tue, Oct 15, 2013 at 10:38 AM, Brian LeRoux  wrote:
> Cordova is mostly about phones (except when its OS X and Windows). Node
> support is not a project goal though I would encourage you to look at
> authoring plugins for iOS, Android, Windows Phone that mimic Node APIs if
> that is something you're looking for.
>
>
> On Tue, Oct 15, 2013 at 1:27 PM, Maxime LUCE  wrote:
>
>> What about a node-webkit or appjs platform integration ?
>>
>> It could help debugging with Cordova related projects and permit to add
>> three platform with one platform : "Windows", "Linux", "OSX".
>> I'm thinking about a platform proxy for node-webkit and/or appjs-deskshell.
>>
>> What do you think of this improvement ?
>> Is there some node-webkit specialists which can helps in this project ?
>>
>> Cordialement.
>>
>> [Touch it]
>>
>> Maxime LUCE
>>
>> [Facebook]
>>
>> [Twitter]
>>
>> max...@touchit.fr
>> 06 28 60 72 34
>> http://touchit.fr
>>
>>
>>
>>

Re: Review Request 14621: Fix plugin JS installation during cordova prepare

[Jeffrey Heifetz]

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

Ship it!


Ship It!

- Jeffrey Heifetz


On Oct. 12, 2013, 2:45 a.m., Ian Clelland wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14621/
> ---
> 
> (Updated Oct. 12, 2013, 2:45 a.m.)
> 
> 
> Review request for cordova and Jeffrey Heifetz.
> 
> 
> Bugs: CB-4774
> https://issues.apache.org/jira/browse/CB-4774
> 
> 
> Repository: cordova-cli
> 
> 
> Description
> ---
> 
> Changes order of operations in `cordova prepare` so that the app www 
> directory is clobbered before plugins are prepared. Without this, the 
> platforms' www directories do not have end up with plugins installed after a 
> `cordova prepare` execution.
> 
> 
> Diffs
> -
> 
>   src/metadata/android_parser.js 2df37e6 
>   src/metadata/blackberry10_parser.js 5ad4f0b 
>   src/metadata/firefoxos_parser.js 51f6e1a 
>   src/metadata/ios_parser.js 15854e8 
>   src/metadata/wp7_parser.js 5bda771 
>   src/metadata/wp8_parser.js ad914b6 
>   src/prepare.js 62dbf65 
> 
> Diff: https://reviews.apache.org/r/14621/diff/
> 
> 
> Testing
> ---
> 
> Created new mobile spec project:
> 
> cordova-cli/bin/cordova create mobilespec com.example.mobilespec 
> mobilespec
> cd mobilespec
> ../cordova-cli/bin/cordova platform add android
> ../cordova-cli/bin/cordova platform add ios
> ../cordova-cli/bin/cordova plugin add 
> ../cordova-mobile-spec/dependencies-plugin
> rm -r www
> ln -s ../cordova-mobile-spec/ www
> ../cordova-cli/bin/cordova prepare
> 
> Checked for existence of platforms/android/assets/www/plugins and 
> platforms/ios/www/plugins.
> Ran mobile spec tests on android and ios to verify that plugins were loading 
> correctly.
> 
> Other platform parsers are changed to match ios and android, but I don't have 
> hardware to verify the changes.
> 
> 
> Thanks,
> 
> Ian Clelland
> 
>

Re: Node-Webkit

[Brian LeRoux]

Cordova is mostly about phones (except when its OS X and Windows). Node
support is not a project goal though I would encourage you to look at
authoring plugins for iOS, Android, Windows Phone that mimic Node APIs if
that is something you're looking for.


On Tue, Oct 15, 2013 at 1:27 PM, Maxime LUCE  wrote:

> What about a node-webkit or appjs platform integration ?
>
> It could help debugging with Cordova related projects and permit to add
> three platform with one platform : "Windows", "Linux", "OSX".
> I'm thinking about a platform proxy for node-webkit and/or appjs-deskshell.
>
> What do you think of this improvement ?
> Is there some node-webkit specialists which can helps in this project ?
>
> Cordialement.
>
> [Touch it]
>
> Maxime LUCE
>
> [Facebook]
>
> [Twitter]
>
> max...@touchit.fr
> 06 28 60 72 34
> http://touchit.fr
>
>
>
>

Node-Webkit

[Maxime LUCE]

What about a node-webkit or appjs platform integration ?

It could help debugging with Cordova related projects and permit to add three 
platform with one platform : "Windows", "Linux", "OSX".
I'm thinking about a platform proxy for node-webkit and/or appjs-deskshell.

What do you think of this improvement ?
Is there some node-webkit specialists which can helps in this project ?

Cordialement.

[Touch it]

Maxime LUCE

[Facebook]

[Twitter]

max...@touchit.fr
06 28 60 72 34
http://touchit.fr

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

[David Kemp]

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  >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 
> >> 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 tools to recognize a . We
> >> > *could* work around it by adding the tests to new plugins that depend
> on
> >> > the thing they are testing, but I think changing the tools would be
> >> nicer.
> >> >
> >>
> >> I also mentioned splitting tests into second plugin but thats overkill
> >> except in extreme circumstances.  Note that the tests aren't actually
> >> loaded unless you require them, so its just a matter of larger binaries
> >> which could be filtered out manually.
> >>
> >> My person preference would be to support conditional build types, which
> >> have come up before.  ie, cordova prepare debug, cordova prepare
> release,
> >> cordova prepare test -- and plugin.xml could specify a different set of
> >> js-module for either.
> >>
> >> A specific  would be fine, but isnt "0 new tooling".
> >>
> >> Also, I forgot to mention, but we do need to add support for getting the
> >> full list of plugins installed, which should be trivial to add to
> >> modulemapper (maybe there  is already a way to reach in, but I don't
> think
> >> we have a documented api for it).
> >>
> >>
> >> > Another nit is that it would be nice if the CordovaTests app didn't
> >> depend
> >> > on any plugins. e.g., don't have it depend on device plugin.
> >> >
> >>
> >> CordovaTests doesn't explicitly depend on device plugin, except that at
> >> the
> >> moment I have it printing the same info that MobileSpec does at startup.
> >>  This could be wrapped in a try{}catch in case the require fails, but
> its
> >> good info to have in the common case.
> >>
> >>
> >> >
> >> > Overall, really like the approach!
> >> >
> >>
> >> Thanks!
> >>
> >>
> >> >
> >> >
> >> > On Fri, Oct 11, 2013 at 5:17 PM, Michal Mocny 
> >> wrote:
> >> >
> >> >> TLDR; I've implemented a plugin testing strategy that requires 0 new
> >> >> tooling features, can support non-core plugins, and hopefully even
> >> support
> >

RE: Updating docs

[Michael Sierra]

Achana, Good questions. I've been reorganizing the content a great
deal, and have been meaning to write up some sort of doc roadmap,
which I'll bootstrap here.

The "Platform Guides" are where most of the platform-specific content
lives, in various directories within edge/guide/platforms.  See the
content within the android subdirectory for guidance, and feel free to
adapt it as boilerplate text:

* The index.md should demo how to install any SDK tools that impose a
  dependency on the CLI, and how optionally to compile a Cordova
  project within the SDK. Also, how to set up the platform's emulator.

* config.md: any config.xml options specific to the platform.  For any
  shared with one or more platforms, info goes in
  edge/config_ref/index.md. Use edge/config_ref/images.md for custom
  content about icon/splashscreen image formats.

* tools.md: detail any lower-level non-CLI command-line workflow here.

* plugin.md: how to implement native-side plugin classes, if supported.

* webview.md: how to implement Cordova as a webview within a native
  app, if supported.

* upgrading.md: mostly for pre-CLI tooling, how to modify/restructure
  a project with each Cordova upgrade. (Not applicable for new
  platforms)

These are the basics, but there are a lot of details to getting it
right, such as linking new pages from appropriate spash screens, which
I won't detail here other than to say: OK to add new platform content,
but please do not expose links to it until it's stable from the
end-user POV.

Content about API features currently lives in edge/cordova, but will
soon be split off into separate plugin repos. Three bits of
platform-specific content here:

* Modify each API method/property's "Supported Platforms"

* Add separate "Quirks" sections for partial support

* Modify higher-level "Accessing the Feature" section to specify any
  platform-level config.xml markup the CLI generates.

The table in edge/guide/overview/index.md also shows more accessible
high-level compatibility info. Add a new column for the platform,
applying a custom "data-col" to help consistently position the
columns. Applying a class for each cell of "y", "n", or "p" colors
them green/red/yellow (for partial).

Again, searching for another platform's string helps identify where
you may need to place content:

  $ grep -ri android edge/*

For images, markup such as:
![](img/guide/platforms/ios/file.png)
requires image files mirrored in::
cordova-docs/template/docs/default/img/guide/platforms/ios

You should ignore the various release directories. They're
snap-shotted from "edge" content at each release.

Please also consult the repo's top-level style sheet before adding
content.

Let me know if this makes sense. Would be happy to help.

--Mike Sierra



From: Naik, Archana [na...@lab126.com]
Sent: Thursday, October 10, 2013 2:17 PM
To: dev@cordova.apache.org
Subject: Updating docs

Hi, All

I want to update docs for amazon-fireos platform port for cordova. I have been 
exploring cordova-docs.git repo. I have specific questions about doc changes:
Here are my specific questions:

* What is the process for updating docs? Where do we make changes in edge 
folder?
* Where do we check-in our screenshots(images) for getting started,platform 
guides etc...?
* cordova-docs repo has folders for each release. Do we make changes in all the 
releases that we support?

Thanks
Archana

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

[Michal Mocny]

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 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 
>> 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 tools to recognize a . We
>> > *could* work around it by adding the tests to new plugins that depend on
>> > the thing they are testing, but I think changing the tools would be
>> nicer.
>> >
>>
>> I also mentioned splitting tests into second plugin but thats overkill
>> except in extreme circumstances.  Note that the tests aren't actually
>> loaded unless you require them, so its just a matter of larger binaries
>> which could be filtered out manually.
>>
>> My person preference would be to support conditional build types, which
>> have come up before.  ie, cordova prepare debug, cordova prepare release,
>> cordova prepare test -- and plugin.xml could specify a different set of
>> js-module for either.
>>
>> A specific  would be fine, but isnt "0 new tooling".
>>
>> Also, I forgot to mention, but we do need to add support for getting the
>> full list of plugins installed, which should be trivial to add to
>> modulemapper (maybe there  is already a way to reach in, but I don't think
>> we have a documented api for it).
>>
>>
>> > Another nit is that it would be nice if the CordovaTests app didn't
>> depend
>> > on any plugins. e.g., don't have it depend on device plugin.
>> >
>>
>> CordovaTests doesn't explicitly depend on device plugin, except that at
>> the
>> moment I have it printing the same info that MobileSpec does at startup.
>>  This could be wrapped in a try{}catch in case the require fails, but its
>> good info to have in the common case.
>>
>>
>> >
>> > Overall, really like the approach!
>> >
>>
>> Thanks!
>>
>>
>> >
>> >
>> > On Fri, Oct 11, 2013 at 5:17 PM, Michal Mocny 
>> wrote:
>> >
>> >> TLDR; I've implemented a plugin testing strategy that requires 0 new
>> >> tooling features, can support non-core plugins, and hopefully even
>> support
>> >> a variety of methods for running/reporting the test results.  Super
>> alpha
>> >> preview, but take a look if you like the direction!
>> >>
>> >>
>> >> NEW: CDVTest Plugin: https://github.com/mmocny/CDVTest
>> >>
>> >> NEW: CordovaTest App: https://github.com/mmocny/CordovaTests
>> >>
>> >> UPDATED: Converted three existing plugins to this "new style".  Code
>> is on
>> >> feature branches of respective repos (cdvtest branch):
>> >> org.apache.cordova.device
>> >> org.apache.cordova.device-motion
>> >> org.chromium.storage
>> >> (must clone locally, switch t

Re: Review Request 14621: Fix plugin JS installation during cordova prepare

[Braden Shepherdson]

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

Ship it!


Ship It!

- Braden Shepherdson


On Oct. 12, 2013, 2:45 a.m., Ian Clelland wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14621/
> ---
> 
> (Updated Oct. 12, 2013, 2:45 a.m.)
> 
> 
> Review request for cordova and Jeffrey Heifetz.
> 
> 
> Bugs: CB-4774
> https://issues.apache.org/jira/browse/CB-4774
> 
> 
> Repository: cordova-cli
> 
> 
> Description
> ---
> 
> Changes order of operations in `cordova prepare` so that the app www 
> directory is clobbered before plugins are prepared. Without this, the 
> platforms' www directories do not have end up with plugins installed after a 
> `cordova prepare` execution.
> 
> 
> Diffs
> -
> 
>   src/metadata/android_parser.js 2df37e6 
>   src/metadata/blackberry10_parser.js 5ad4f0b 
>   src/metadata/firefoxos_parser.js 51f6e1a 
>   src/metadata/ios_parser.js 15854e8 
>   src/metadata/wp7_parser.js 5bda771 
>   src/metadata/wp8_parser.js ad914b6 
>   src/prepare.js 62dbf65 
> 
> Diff: https://reviews.apache.org/r/14621/diff/
> 
> 
> Testing
> ---
> 
> Created new mobile spec project:
> 
> cordova-cli/bin/cordova create mobilespec com.example.mobilespec 
> mobilespec
> cd mobilespec
> ../cordova-cli/bin/cordova platform add android
> ../cordova-cli/bin/cordova platform add ios
> ../cordova-cli/bin/cordova plugin add 
> ../cordova-mobile-spec/dependencies-plugin
> rm -r www
> ln -s ../cordova-mobile-spec/ www
> ../cordova-cli/bin/cordova prepare
> 
> Checked for existence of platforms/android/assets/www/plugins and 
> platforms/ios/www/plugins.
> Ran mobile spec tests on android and ios to verify that plugins were loading 
> correctly.
> 
> Other platform parsers are changed to match ios and android, but I don't have 
> hardware to verify the changes.
> 
> 
> Thanks,
> 
> Ian Clelland
> 
>

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

[Braden Shepherdson]

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 
> 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 tools to recognize a . We
> > *could* work around it by adding the tests to new plugins that depend on
> > the thing they are testing, but I think changing the tools would be
> nicer.
> >
>
> I also mentioned splitting tests into second plugin but thats overkill
> except in extreme circumstances.  Note that the tests aren't actually
> loaded unless you require them, so its just a matter of larger binaries
> which could be filtered out manually.
>
> My person preference would be to support conditional build types, which
> have come up before.  ie, cordova prepare debug, cordova prepare release,
> cordova prepare test -- and plugin.xml could specify a different set of
> js-module for either.
>
> A specific  would be fine, but isnt "0 new tooling".
>
> Also, I forgot to mention, but we do need to add support for getting the
> full list of plugins installed, which should be trivial to add to
> modulemapper (maybe there  is already a way to reach in, but I don't think
> we have a documented api for it).
>
>
> > Another nit is that it would be nice if the CordovaTests app didn't
> depend
> > on any plugins. e.g., don't have it depend on device plugin.
> >
>
> CordovaTests doesn't explicitly depend on device plugin, except that at the
> moment I have it printing the same info that MobileSpec does at startup.
>  This could be wrapped in a try{}catch in case the require fails, but its
> good info to have in the common case.
>
>
> >
> > Overall, really like the approach!
> >
>
> Thanks!
>
>
> >
> >
> > On Fri, Oct 11, 2013 at 5:17 PM, Michal Mocny 
> wrote:
> >
> >> TLDR; I've implemented a plugin testing strategy that requires 0 new
> >> tooling features, can support non-core plugins, and hopefully even
> support
> >> a variety of methods for running/reporting the test results.  Super
> alpha
> >> preview, but take a look if you like the direction!
> >>
> >>
> >> NEW: CDVTest Plugin: https://github.com/mmocny/CDVTest
> >>
> >> NEW: CordovaTest App: https://github.com/mmocny/CordovaTests
> >>
> >> UPDATED: Converted three existing plugins to this "new style".  Code is
> on
> >> feature branches of respective repos (cdvtest branch):
> >> org.apache.cordova.device
> >> org.apache.cordova.device-motion
> >> org.chromium.storage
> >> (must clone locally, switch to branch, and plugin add from local path)
> >>
> >>
> >> Now, any plugin that wants to join in on the fun needs to provide a
> >>  >> src="..." name="test" /> and use this template:
> >>
> >> exports.init = function() {
> >>
> >>
> eval(require('org.apache.cordova.test.test').injectJasmineInterface(this,
> >> 'this'));
> >>
> >>   // TESTS GO HERE
> >>   describe(..., function() {
> >> it(...);
> >>   });
> >> };
> >> (The eval is optional but super useful; it will inject the jasmine
> >> interface into your scope, so you don't have to type jasmine.describe,
> >> jasmine.it, etc.  Not sure of any cleaner way to do this.)
> >>
> >>
> >> STEPS:
> >> 1. create a new cordova project
> >> 2. import the CordovaTest app into your www
> >> 3. add any or all of the above plugins
> >> 4. give it a run, and try out the auto tests (all pass on ipad, some
> still
> >> fail on android)
> >>
> >> Lots of work left to do, but hopefully good enough to whet your
> appetite.
> >>
> >> One thing to note, I've attempted to make CDVTest and plugin tests
> unaware
> >> of the specific jasmine version 

Re: Post 3.1 release committer & community meeting

[Andrew Grieve]

This is coming up this Thursday! What do people want to talk about? Here's
a couple to get us going:

- Plugin registry download counts (Are these available yet)
- Idea: Split cordova-cli-lib from cordova-cli on NPM (have cordova-cli and
phonegap-cli depend on cordova-cli-lib)
- Michal's work on CDVTest



On Tue, Oct 8, 2013 at 4:16 PM, Michal Mocny  wrote:

> Alright, Looks like Thu 17 is the clear winner, with not a single person
> having any complaints about that time.
>
> Brian cannot make it until 6pm EST, but I'm going to schedule start time
> for 5:30 for the inevitable hiccups and introductions and any agenda
> overview etc.  It will very likely be 6pm before we get into the thick of
> things.
>
> We will send out exact details on this thread the day of, See you all then.
>
> -Michal
>
>
> On Mon, Oct 7, 2013 at 1:05 PM, Michal Mocny  wrote:
>
> > Okay, options are updated for the poll (
> http://doodle.com/2pmy2ptafmxsrna2
> > )
> >
> > For those who filled it out, sorry, you will need to do it again.
> >
> >
> > On Sun, Oct 6, 2013 at 7:27 PM, Michal Mocny  wrote:
> >
> >> Ugh Sorry that was a misreading of course. I'll set up a new doodle
> >> tomorrow morning.
> >>  On 2013-10-06 1:52 AM, "Tommy Williams"  wrote:
> >>
> >>> +1 for post 16th for Joe availability.
> >>>
> >>> Also, thanks for thinking of Australia... One benefit of the time of
> >>> year,
> >>> the nasty time difference just got an hour better today...
> >>>
> >>> - tommy
> >>>  On 5 Oct 2013 08:33, "Jesse"  wrote:
> >>>
> >>> > I filled it out, however, Joe is not available until after the 15th.
> >>> Maybe
> >>> > we should aim for the 16-18th as a window.
> >>> >
> >>> > @purplecabbage
> >>> > risingj.com
> >>> >
> >>> >
> >>> > On Fri, Oct 4, 2013 at 3:09 PM, Michal Mocny 
> >>> wrote:
> >>> >
> >>> > > http://www.doodle.com/2pmy2ptafmxsrna2
> >>> > >
> >>> > > I put a lot of options for time (sorry) since I wasn't sure if we
> >>> should
> >>> > be
> >>> > > europe or australia friendly this time.
> >>> > >
> >>> > > There are also three options this time: yes, (yes), no, where the
> >>> middle
> >>> > > option is supposed to be a "prefer not, but if need be, fine"
> >>> > >
> >>> > > -Michal
> >>> > >
> >>> > >
> >>> > > On Fri, Oct 4, 2013 at 6:06 PM, Michal Mocny 
> >>> > wrote:
> >>> > >
> >>> > > > 11-15 sounds like the range to shoot for.  I'll set up a doodle..
> >>> > > >
> >>> > > >
> >>> > > > On Fri, Oct 4, 2013 at 4:48 PM, Joe Bowser 
> >>> wrote:
> >>> > > >
> >>> > > >> I'm unavailable until after the 15th. I'll be at Big Android
> BBQ.
> >>> > > >>
> >>> > > >
> >>> > > >
> >>> > >
> >>> >
> >>>
> >>
> >
>

Re: Platforms Meet-up @ Waterloo

[Andrew Grieve]

Awesome! Glad that you guys can come!

>From the Google side - I think everyone will be here except for Braden
(he's going to MTV to give a talk on AngularJS!).

Here's a slightly expanded list of work topics I've thought of. Feel free
to add or to take ownership of topics:

- API Audit of File API (plus talking about fixing CB-285)
- Accessibility (both IBM and Adobe have mentioned this recently, not sure
if there's anything to share / report yet)
- Audit of Native API
  - Plugin API look good?
  - WebView / Embedding API look good?
  - Settings API look good?
- Using Gradle on Android (I've read a couple "intro to Gradle" articles,
but haven't fiddled yet)
- Android Splash Screen uses a hard-coded delay (iOS goes away when page is
ready)
- Platform Roadmaps (other platforms too depending on who's attending)




On Mon, Oct 14, 2013 at 5:36 PM, Anis KADRI  wrote:

> +1!
>
> On Fri, Oct 11, 2013 at 10:35 AM, Gorkem Ercan 
> wrote:
> > +1
> > would like to come, Red Hat is interested to contribute on platforms as
> > well.
> > --
> > Gorkem
> >
> >
> > On Wed, Oct 9, 2013 at 10:10 AM, Andrew Grieve 
> wrote:
> >
> >> Working via email is fun, but seeing each other in person is fun too!
> >>
> >> I'd like to invite committers / active contributors who are able to join
> >> the Google team for a couple days of work and fun at the Google Waterloo
> >> office!
> >>
> >> When: Oct 29th, 30th (Tuesday, Wednesday)
> >> Where: Google Waterloo (http://goo.gl/jI99Fr)
> >> Full Address: 151 Charles Street West, Kitchener, Ontario
> >> What: Working together + dinner and a social activity evening of the
> 29th
> >>
> >> More details:
> >> A lot of focus recently has been on CLI/Plugman, so I wanted this
> meet-up
> >> to instead focus on *platforms*.
> >>
> >> Specifically:
> >> - iOS & Android Roadmaps (other platforms too depending on who's
> attending)
> >> - Storage locations (CB-285) (oldie but a goldie!)
> >> - Accessibility (both IBM and Adobe have mentioned this recently, not
> sure
> >> if there's anything to share / report yet)
> >>
> >> If you're able to come, please respond to this thread so I can get an
> idea
> >> of numbers. We'll provide food and a work space, but you'll have to
> figure
> >> out how to get here. As always, we'll be sure to not make any decisions
> >> without going through the ML.
> >>
> >> Andrew
> >>
>

Re: Assign an issue

[Bryan Higgins]

Thanks! We will test this out today and get it merged in.


On Mon, Oct 14, 2013 at 5:01 PM, Maxime LUCE  wrote:

> Thanks it's OK now !!
> So quick !!!
>
> I created a pull request on Github :
> https://github.com/apache/cordova-blackberry/pull/105
> If someone could review it and merge into apache repo...
>
> Cordialement.
> 
> Maxime LUCE
> max...@touchit.fr
> 06 28 60 72 34
> http://touchit.fr
>
> -Original Message-
> From: Anis KADRI [mailto:anis.ka...@gmail.com]
> Sent: lundi 14 octobre 2013 22:54
> To: dev@cordova.apache.org
> Subject: Re: Assign an issue
>
> try again
>
> On Mon, Oct 14, 2013 at 1:51 PM, Maxime LUCE  wrote:
> > Hi,
> >
> > I reported two issue on JIRA, I want to assign myself to resolve one of
> this issue as I already resolved it.
> > How can I do it ?
> >
> > To details :
> > On windows 7+ OS I saw an error on project creation.
> > The init.bat executable assign environment variable CORDOVA_NODE and
> CORDOVA_BBTOOLS but they are never interpreted so the command line fail
> with error node cannot be found.
> >
> > Has anyone an idea ?
> >
> > Cordialement.
> > 
> > Maxime LUCE
> > max...@touchit.fr
> > 06 28 60 72 34
> > http://touchit.fr
> >
> >
>