Re: Cordova 2.9.0 Final

[Filip Maj]

Sgtm!

On 6/21/13 6:27 PM, "Steven Gill"  wrote:

>I say we begin the tagging process for 2.9.0 final on Monday. That gives
>us
>a couple of days to get everything tested, tagged and released before the
>end of the month. We can also merge in 3.0.0 branches after the 2.9
>release.

Cordova 2.9.0 Final

[Steven Gill]

I say we begin the tagging process for 2.9.0 final on Monday. That gives us
a couple of days to get everything tested, tagged and released before the
end of the month. We can also merge in 3.0.0 branches after the 2.9
release.

Re: Review Request: Fixing exec bug.

[Joe Bowser]

> On June 21, 2013, 11:47 p.m., Joe Bowser wrote:
> > Ship It!

I really just wanted to push the "Ship it!" button, but yeah, this looks good. 


- Joe


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


On June 21, 2013, 5:21 p.m., Jeffrey Willms wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12013/
> ---
> 
> (Updated June 21, 2013, 5:21 p.m.)
> 
> 
> Review request for cordova and Andrew Grieve.
> 
> 
> Description
> ---
> 
> Fixing exec bug.
> 
> 
> This addresses bug CB-3927.
> https://issues.apache.org/jira/browse/CB-3927
> 
> 
> Diffs
> -
> 
>   framework/src/org/apache/cordova/api/PluginEntry.java 
> 9b9af6bc303965e7263bca75037256da81868fb2 
>   framework/src/org/apache/cordova/api/PluginManager.java 
> adaec907e216c101cc78ee72ff30ec6b7d875a45 
> 
> Diff: https://reviews.apache.org/r/12013/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jeffrey Willms
> 
>

Re: Review Request: Fixing exec bug.

[Joe Bowser]

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

Ship it!


Ship It!

- Joe Bowser


On June 21, 2013, 5:21 p.m., Jeffrey Willms wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12013/
> ---
> 
> (Updated June 21, 2013, 5:21 p.m.)
> 
> 
> Review request for cordova and Andrew Grieve.
> 
> 
> Description
> ---
> 
> Fixing exec bug.
> 
> 
> This addresses bug CB-3927.
> https://issues.apache.org/jira/browse/CB-3927
> 
> 
> Diffs
> -
> 
>   framework/src/org/apache/cordova/api/PluginEntry.java 
> 9b9af6bc303965e7263bca75037256da81868fb2 
>   framework/src/org/apache/cordova/api/PluginManager.java 
> adaec907e216c101cc78ee72ff30ec6b7d875a45 
> 
> Diff: https://reviews.apache.org/r/12013/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jeffrey Willms
> 
>

Re: Jake woes

[Andrew Grieve]

:) who needs the dalek.


On Fri, Jun 21, 2013 at 7:17 PM, Gord Tanner  wrote:

> Ex-term-in-ate
>
> Sent from my iPhone
>
> On 2013-06-21, at 6:52 PM, Simon MacDonald 
> wrote:
>
> > Guys no one can completely defeat the daleks. I'm sure that they will be
> > back. Possibly in rainbow colours.
> > On Jun 21, 2013 6:27 PM, "Lorin Beer"  wrote:
> >
> >> HORRIBLE
> >>
> >>
> >> On Fri, Jun 21, 2013 at 2:43 PM, Jesse  wrote:
> >>
> >>> Punishable by death or bunga-bunga, your choice.
> >>>
> >>> @purplecabbage
> >>> risingj.com
> >>>
> >>>
> >>> On Fri, Jun 21, 2013 at 2:09 PM, Filip Maj  wrote:
> >>>
>  noo
> 
>  On 6/21/13 2:01 PM, "Patrick Mueller"  wrote:
> 
> > It appears you've made a horrible, HORRIBLE mistake with your patch
> >> [1],
> > and deleted the dalek.  HORRIBLE.
> >
> > [1]
> >>
> https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=273e0a
> > 3a
> >
> > ps: I too once tried to delete the dalek, and look what happened to
> >> me.
> > and
> > the dalek :-(
> >
> >
> > On Fri, Jun 21, 2013 at 2:17 PM, Benn Mapes 
> >>> wrote:
> >
> >> Could you also update the README?
> >> https://issues.apache.org/jira/browse/CB-3966
> >>
> >> Thanks!
> >>
> >>
> >> On Fri, Jun 21, 2013 at 7:23 AM, Andrew Grieve <
> >> agri...@chromium.org>
> >> wrote:
> >>
> >>> Okay, CB-3960 is the tracker.
> >>>
> >>>
> >>> On Fri, Jun 21, 2013 at 9:57 AM, Jeffrey Heifetz <
> >> jheif...@blackberry.com
>  wrote:
> >>>
>  +1
> 
>  Sent from my BlackBerry 10 smartphone on the Rogers network.
>  From: Bryan Higgins
>  Sent: Friday, June 21, 2013 9:39 AM
>  To: dev@cordova.apache.org
>  Reply To: dev@cordova.apache.org
>  Subject: Re: Jake woes
> 
> 
>  +1
> 
> 
>  On Fri, Jun 21, 2013 at 7:11 AM, Lucas Holmquist
> >>  > wrote:
> 
> > +1
> > On Jun 20, 2013, at 11:20 PM, Steven Gill <
> >>> stevengil...@gmail.com
> >
>  wrote:
> >
> >> +1 Grunt
> >>
> >>
> >> On Thu, Jun 20, 2013 at 7:15 PM, Andrew Grieve <
> >> agri...@chromium.org
> 
> > wrote:
> >>
> >>> I've burned quite a bit of time trying to get it to work,
> >> and
> >> I'm
> >> a
>  bit
> >>> realizing that it's probably not worth continuing. By
> >>> fiddling
> >> with
> >>> dependencies I can get it to run, but tasks are being run
> >> multiple
>  times
> >>> when they shouldn't be, and there's no reason I should need
> >>> to
> >>> fiddle
> > the
> >>> deps to get it to run.
> >>>
> >>> So... any objections if I delete Jakefile and replace it
> >> with
> >>> a Gruntfile.js?
> >>
> -
>  This transmission (including any attachments) may contain
> >> confidential
>  information, privileged material (including material protected
> >> by
> >> the
>  solicitor-client or other applicable privileges), or constitute
> >>> non-public
>  information. Any use of this information by anyone other than
> >> the
> >>> intended
>  recipient is prohibited. If you have received this transmission
> >> in
> >> error,
>  please immediately reply to the sender and delete this
> >> information
> >> from
>  your system. Use, dissemination, distribution, or reproduction
> >> of
> >> this
>  transmission by unintended recipients is not authorized and may
> >> be
> >>> unlawful.
> >
> >
> >
> > --
> > Patrick Mueller
> > http://muellerware.org
> >>
>

Re: Review Request: Fixing exec bug.

[Andrew Grieve]

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

Ship it!


Looks good! Just send me the JS change and I'll commit it.


framework/src/org/apache/cordova/api/PluginManager.java





- Andrew Grieve


On June 21, 2013, 5:21 p.m., Jeffrey Willms wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12013/
> ---
> 
> (Updated June 21, 2013, 5:21 p.m.)
> 
> 
> Review request for cordova and Andrew Grieve.
> 
> 
> Description
> ---
> 
> Fixing exec bug.
> 
> 
> This addresses bug CB-3927.
> https://issues.apache.org/jira/browse/CB-3927
> 
> 
> Diffs
> -
> 
>   framework/src/org/apache/cordova/api/PluginEntry.java 
> 9b9af6bc303965e7263bca75037256da81868fb2 
>   framework/src/org/apache/cordova/api/PluginManager.java 
> adaec907e216c101cc78ee72ff30ec6b7d875a45 
> 
> Diff: https://reviews.apache.org/r/12013/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jeffrey Willms
> 
>

Re: Jake woes

[Gord Tanner]

Ex-term-in-ate

Sent from my iPhone

On 2013-06-21, at 6:52 PM, Simon MacDonald  wrote:

> Guys no one can completely defeat the daleks. I'm sure that they will be
> back. Possibly in rainbow colours.
> On Jun 21, 2013 6:27 PM, "Lorin Beer"  wrote:
> 
>> HORRIBLE
>> 
>> 
>> On Fri, Jun 21, 2013 at 2:43 PM, Jesse  wrote:
>> 
>>> Punishable by death or bunga-bunga, your choice.
>>> 
>>> @purplecabbage
>>> risingj.com
>>> 
>>> 
>>> On Fri, Jun 21, 2013 at 2:09 PM, Filip Maj  wrote:
>>> 
 noo
 
 On 6/21/13 2:01 PM, "Patrick Mueller"  wrote:
 
> It appears you've made a horrible, HORRIBLE mistake with your patch
>> [1],
> and deleted the dalek.  HORRIBLE.
> 
> [1]
>> https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=273e0a
> 3a
> 
> ps: I too once tried to delete the dalek, and look what happened to
>> me.
> and
> the dalek :-(
> 
> 
> On Fri, Jun 21, 2013 at 2:17 PM, Benn Mapes 
>>> wrote:
> 
>> Could you also update the README?
>> https://issues.apache.org/jira/browse/CB-3966
>> 
>> Thanks!
>> 
>> 
>> On Fri, Jun 21, 2013 at 7:23 AM, Andrew Grieve <
>> agri...@chromium.org>
>> wrote:
>> 
>>> Okay, CB-3960 is the tracker.
>>> 
>>> 
>>> On Fri, Jun 21, 2013 at 9:57 AM, Jeffrey Heifetz <
>> jheif...@blackberry.com
 wrote:
>>> 
 +1
 
 Sent from my BlackBerry 10 smartphone on the Rogers network.
 From: Bryan Higgins
 Sent: Friday, June 21, 2013 9:39 AM
 To: dev@cordova.apache.org
 Reply To: dev@cordova.apache.org
 Subject: Re: Jake woes
 
 
 +1
 
 
 On Fri, Jun 21, 2013 at 7:11 AM, Lucas Holmquist
>>  wrote:
 
> +1
> On Jun 20, 2013, at 11:20 PM, Steven Gill <
>>> stevengil...@gmail.com
> 
 wrote:
> 
>> +1 Grunt
>> 
>> 
>> On Thu, Jun 20, 2013 at 7:15 PM, Andrew Grieve <
>> agri...@chromium.org
 
> wrote:
>> 
>>> I've burned quite a bit of time trying to get it to work,
>> and
>> I'm
>> a
 bit
>>> realizing that it's probably not worth continuing. By
>>> fiddling
>> with
>>> dependencies I can get it to run, but tasks are being run
>> multiple
 times
>>> when they shouldn't be, and there's no reason I should need
>>> to
>>> fiddle
> the
>>> deps to get it to run.
>>> 
>>> So... any objections if I delete Jakefile and replace it
>> with
>>> a Gruntfile.js?
>> -
 This transmission (including any attachments) may contain
>> confidential
 information, privileged material (including material protected
>> by
>> the
 solicitor-client or other applicable privileges), or constitute
>>> non-public
 information. Any use of this information by anyone other than
>> the
>>> intended
 recipient is prohibited. If you have received this transmission
>> in
>> error,
 please immediately reply to the sender and delete this
>> information
>> from
 your system. Use, dissemination, distribution, or reproduction
>> of
>> this
 transmission by unintended recipients is not authorized and may
>> be
>>> unlawful.
> 
> 
> 
> --
> Patrick Mueller
> http://muellerware.org
>> 

Re: Jake woes

[Simon MacDonald]

Guys no one can completely defeat the daleks. I'm sure that they will be
back. Possibly in rainbow colours.
On Jun 21, 2013 6:27 PM, "Lorin Beer"  wrote:

> HORRIBLE
>
>
> On Fri, Jun 21, 2013 at 2:43 PM, Jesse  wrote:
>
> > Punishable by death or bunga-bunga, your choice.
> >
> > @purplecabbage
> > risingj.com
> >
> >
> > On Fri, Jun 21, 2013 at 2:09 PM, Filip Maj  wrote:
> >
> > > noo
> > >
> > > On 6/21/13 2:01 PM, "Patrick Mueller"  wrote:
> > >
> > > >It appears you've made a horrible, HORRIBLE mistake with your patch
> [1],
> > > >and deleted the dalek.  HORRIBLE.
> > > >
> > > >[1]
> > > >
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=273e0a
> > > >3a
> > > >
> > > >ps: I too once tried to delete the dalek, and look what happened to
> me.
> > > >and
> > > >the dalek :-(
> > > >
> > > >
> > > >On Fri, Jun 21, 2013 at 2:17 PM, Benn Mapes 
> > wrote:
> > > >
> > > >> Could you also update the README?
> > > >> https://issues.apache.org/jira/browse/CB-3966
> > > >>
> > > >> Thanks!
> > > >>
> > > >>
> > > >> On Fri, Jun 21, 2013 at 7:23 AM, Andrew Grieve <
> agri...@chromium.org>
> > > >> wrote:
> > > >>
> > > >> > Okay, CB-3960 is the tracker.
> > > >> >
> > > >> >
> > > >> > On Fri, Jun 21, 2013 at 9:57 AM, Jeffrey Heifetz <
> > > >> jheif...@blackberry.com
> > > >> > >wrote:
> > > >> >
> > > >> > > +1
> > > >> > >
> > > >> > > Sent from my BlackBerry 10 smartphone on the Rogers network.
> > > >> > > From: Bryan Higgins
> > > >> > > Sent: Friday, June 21, 2013 9:39 AM
> > > >> > > To: dev@cordova.apache.org
> > > >> > > Reply To: dev@cordova.apache.org
> > > >> > > Subject: Re: Jake woes
> > > >> > >
> > > >> > >
> > > >> > > +1
> > > >> > >
> > > >> > >
> > > >> > > On Fri, Jun 21, 2013 at 7:11 AM, Lucas Holmquist
> > > >> > > >> > > >wrote:
> > > >> > >
> > > >> > > > +1
> > > >> > > > On Jun 20, 2013, at 11:20 PM, Steven Gill <
> > stevengil...@gmail.com
> > > >
> > > >> > > wrote:
> > > >> > > >
> > > >> > > > > +1 Grunt
> > > >> > > > >
> > > >> > > > >
> > > >> > > > > On Thu, Jun 20, 2013 at 7:15 PM, Andrew Grieve <
> > > >> agri...@chromium.org
> > > >> > >
> > > >> > > > wrote:
> > > >> > > > >
> > > >> > > > >> I've burned quite a bit of time trying to get it to work,
> and
> > > >>I'm
> > > >> a
> > > >> > > bit
> > > >> > > > >> realizing that it's probably not worth continuing. By
> > fiddling
> > > >> with
> > > >> > > > >> dependencies I can get it to run, but tasks are being run
> > > >>multiple
> > > >> > > times
> > > >> > > > >> when they shouldn't be, and there's no reason I should need
> > to
> > > >> > fiddle
> > > >> > > > the
> > > >> > > > >> deps to get it to run.
> > > >> > > > >>
> > > >> > > > >> So... any objections if I delete Jakefile and replace it
> with
> > > >> > > > >> a Gruntfile.js?
> > > >> > > > >>
> > > >> > > >
> > > >> > > >
> > > >> > >
> > > >> > >
> > > >>-
> > > >> > > This transmission (including any attachments) may contain
> > > >>confidential
> > > >> > > information, privileged material (including material protected
> by
> > > >>the
> > > >> > > solicitor-client or other applicable privileges), or constitute
> > > >> > non-public
> > > >> > > information. Any use of this information by anyone other than
> the
> > > >> > intended
> > > >> > > recipient is prohibited. If you have received this transmission
> in
> > > >> error,
> > > >> > > please immediately reply to the sender and delete this
> information
> > > >>from
> > > >> > > your system. Use, dissemination, distribution, or reproduction
> of
> > > >>this
> > > >> > > transmission by unintended recipients is not authorized and may
> be
> > > >> > unlawful.
> > > >> > >
> > > >> >
> > > >>
> > > >
> > > >
> > > >
> > > >--
> > > >Patrick Mueller
> > > >http://muellerware.org
> > >
> > >
> >
>

Re: Jake woes

[Lorin Beer]

HORRIBLE


On Fri, Jun 21, 2013 at 2:43 PM, Jesse  wrote:

> Punishable by death or bunga-bunga, your choice.
>
> @purplecabbage
> risingj.com
>
>
> On Fri, Jun 21, 2013 at 2:09 PM, Filip Maj  wrote:
>
> > noo
> >
> > On 6/21/13 2:01 PM, "Patrick Mueller"  wrote:
> >
> > >It appears you've made a horrible, HORRIBLE mistake with your patch [1],
> > >and deleted the dalek.  HORRIBLE.
> > >
> > >[1]
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=273e0a
> > >3a
> > >
> > >ps: I too once tried to delete the dalek, and look what happened to me.
> > >and
> > >the dalek :-(
> > >
> > >
> > >On Fri, Jun 21, 2013 at 2:17 PM, Benn Mapes 
> wrote:
> > >
> > >> Could you also update the README?
> > >> https://issues.apache.org/jira/browse/CB-3966
> > >>
> > >> Thanks!
> > >>
> > >>
> > >> On Fri, Jun 21, 2013 at 7:23 AM, Andrew Grieve 
> > >> wrote:
> > >>
> > >> > Okay, CB-3960 is the tracker.
> > >> >
> > >> >
> > >> > On Fri, Jun 21, 2013 at 9:57 AM, Jeffrey Heifetz <
> > >> jheif...@blackberry.com
> > >> > >wrote:
> > >> >
> > >> > > +1
> > >> > >
> > >> > > Sent from my BlackBerry 10 smartphone on the Rogers network.
> > >> > > From: Bryan Higgins
> > >> > > Sent: Friday, June 21, 2013 9:39 AM
> > >> > > To: dev@cordova.apache.org
> > >> > > Reply To: dev@cordova.apache.org
> > >> > > Subject: Re: Jake woes
> > >> > >
> > >> > >
> > >> > > +1
> > >> > >
> > >> > >
> > >> > > On Fri, Jun 21, 2013 at 7:11 AM, Lucas Holmquist
> > >> > >> > > >wrote:
> > >> > >
> > >> > > > +1
> > >> > > > On Jun 20, 2013, at 11:20 PM, Steven Gill <
> stevengil...@gmail.com
> > >
> > >> > > wrote:
> > >> > > >
> > >> > > > > +1 Grunt
> > >> > > > >
> > >> > > > >
> > >> > > > > On Thu, Jun 20, 2013 at 7:15 PM, Andrew Grieve <
> > >> agri...@chromium.org
> > >> > >
> > >> > > > wrote:
> > >> > > > >
> > >> > > > >> I've burned quite a bit of time trying to get it to work, and
> > >>I'm
> > >> a
> > >> > > bit
> > >> > > > >> realizing that it's probably not worth continuing. By
> fiddling
> > >> with
> > >> > > > >> dependencies I can get it to run, but tasks are being run
> > >>multiple
> > >> > > times
> > >> > > > >> when they shouldn't be, and there's no reason I should need
> to
> > >> > fiddle
> > >> > > > the
> > >> > > > >> deps to get it to run.
> > >> > > > >>
> > >> > > > >> So... any objections if I delete Jakefile and replace it with
> > >> > > > >> a Gruntfile.js?
> > >> > > > >>
> > >> > > >
> > >> > > >
> > >> > >
> > >> > >
> > >>-
> > >> > > This transmission (including any attachments) may contain
> > >>confidential
> > >> > > information, privileged material (including material protected by
> > >>the
> > >> > > solicitor-client or other applicable privileges), or constitute
> > >> > non-public
> > >> > > information. Any use of this information by anyone other than the
> > >> > intended
> > >> > > recipient is prohibited. If you have received this transmission in
> > >> error,
> > >> > > please immediately reply to the sender and delete this information
> > >>from
> > >> > > your system. Use, dissemination, distribution, or reproduction of
> > >>this
> > >> > > transmission by unintended recipients is not authorized and may be
> > >> > unlawful.
> > >> > >
> > >> >
> > >>
> > >
> > >
> > >
> > >--
> > >Patrick Mueller
> > >http://muellerware.org
> >
> >
>

Re: Jake woes

[Jesse]

Punishable by death or bunga-bunga, your choice.

@purplecabbage
risingj.com


On Fri, Jun 21, 2013 at 2:09 PM, Filip Maj  wrote:

> noo
>
> On 6/21/13 2:01 PM, "Patrick Mueller"  wrote:
>
> >It appears you've made a horrible, HORRIBLE mistake with your patch [1],
> >and deleted the dalek.  HORRIBLE.
> >
> >[1]
> >
> https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=273e0a
> >3a
> >
> >ps: I too once tried to delete the dalek, and look what happened to me.
> >and
> >the dalek :-(
> >
> >
> >On Fri, Jun 21, 2013 at 2:17 PM, Benn Mapes  wrote:
> >
> >> Could you also update the README?
> >> https://issues.apache.org/jira/browse/CB-3966
> >>
> >> Thanks!
> >>
> >>
> >> On Fri, Jun 21, 2013 at 7:23 AM, Andrew Grieve 
> >> wrote:
> >>
> >> > Okay, CB-3960 is the tracker.
> >> >
> >> >
> >> > On Fri, Jun 21, 2013 at 9:57 AM, Jeffrey Heifetz <
> >> jheif...@blackberry.com
> >> > >wrote:
> >> >
> >> > > +1
> >> > >
> >> > > Sent from my BlackBerry 10 smartphone on the Rogers network.
> >> > > From: Bryan Higgins
> >> > > Sent: Friday, June 21, 2013 9:39 AM
> >> > > To: dev@cordova.apache.org
> >> > > Reply To: dev@cordova.apache.org
> >> > > Subject: Re: Jake woes
> >> > >
> >> > >
> >> > > +1
> >> > >
> >> > >
> >> > > On Fri, Jun 21, 2013 at 7:11 AM, Lucas Holmquist
> >> >> > > >wrote:
> >> > >
> >> > > > +1
> >> > > > On Jun 20, 2013, at 11:20 PM, Steven Gill  >
> >> > > wrote:
> >> > > >
> >> > > > > +1 Grunt
> >> > > > >
> >> > > > >
> >> > > > > On Thu, Jun 20, 2013 at 7:15 PM, Andrew Grieve <
> >> agri...@chromium.org
> >> > >
> >> > > > wrote:
> >> > > > >
> >> > > > >> I've burned quite a bit of time trying to get it to work, and
> >>I'm
> >> a
> >> > > bit
> >> > > > >> realizing that it's probably not worth continuing. By fiddling
> >> with
> >> > > > >> dependencies I can get it to run, but tasks are being run
> >>multiple
> >> > > times
> >> > > > >> when they shouldn't be, and there's no reason I should need to
> >> > fiddle
> >> > > > the
> >> > > > >> deps to get it to run.
> >> > > > >>
> >> > > > >> So... any objections if I delete Jakefile and replace it with
> >> > > > >> a Gruntfile.js?
> >> > > > >>
> >> > > >
> >> > > >
> >> > >
> >> > >
> >>-
> >> > > This transmission (including any attachments) may contain
> >>confidential
> >> > > information, privileged material (including material protected by
> >>the
> >> > > solicitor-client or other applicable privileges), or constitute
> >> > non-public
> >> > > information. Any use of this information by anyone other than the
> >> > intended
> >> > > recipient is prohibited. If you have received this transmission in
> >> error,
> >> > > please immediately reply to the sender and delete this information
> >>from
> >> > > your system. Use, dissemination, distribution, or reproduction of
> >>this
> >> > > transmission by unintended recipients is not authorized and may be
> >> > unlawful.
> >> > >
> >> >
> >>
> >
> >
> >
> >--
> >Patrick Mueller
> >http://muellerware.org
>
>

Re: Jake woes

[Filip Maj]

noo

On 6/21/13 2:01 PM, "Patrick Mueller"  wrote:

>It appears you've made a horrible, HORRIBLE mistake with your patch [1],
>and deleted the dalek.  HORRIBLE.
>
>[1]
>https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=273e0a
>3a
>
>ps: I too once tried to delete the dalek, and look what happened to me.
>and
>the dalek :-(
>
>
>On Fri, Jun 21, 2013 at 2:17 PM, Benn Mapes  wrote:
>
>> Could you also update the README?
>> https://issues.apache.org/jira/browse/CB-3966
>>
>> Thanks!
>>
>>
>> On Fri, Jun 21, 2013 at 7:23 AM, Andrew Grieve 
>> wrote:
>>
>> > Okay, CB-3960 is the tracker.
>> >
>> >
>> > On Fri, Jun 21, 2013 at 9:57 AM, Jeffrey Heifetz <
>> jheif...@blackberry.com
>> > >wrote:
>> >
>> > > +1
>> > >
>> > > Sent from my BlackBerry 10 smartphone on the Rogers network.
>> > > From: Bryan Higgins
>> > > Sent: Friday, June 21, 2013 9:39 AM
>> > > To: dev@cordova.apache.org
>> > > Reply To: dev@cordova.apache.org
>> > > Subject: Re: Jake woes
>> > >
>> > >
>> > > +1
>> > >
>> > >
>> > > On Fri, Jun 21, 2013 at 7:11 AM, Lucas Holmquist
>>> > > >wrote:
>> > >
>> > > > +1
>> > > > On Jun 20, 2013, at 11:20 PM, Steven Gill 
>> > > wrote:
>> > > >
>> > > > > +1 Grunt
>> > > > >
>> > > > >
>> > > > > On Thu, Jun 20, 2013 at 7:15 PM, Andrew Grieve <
>> agri...@chromium.org
>> > >
>> > > > wrote:
>> > > > >
>> > > > >> I've burned quite a bit of time trying to get it to work, and
>>I'm
>> a
>> > > bit
>> > > > >> realizing that it's probably not worth continuing. By fiddling
>> with
>> > > > >> dependencies I can get it to run, but tasks are being run
>>multiple
>> > > times
>> > > > >> when they shouldn't be, and there's no reason I should need to
>> > fiddle
>> > > > the
>> > > > >> deps to get it to run.
>> > > > >>
>> > > > >> So... any objections if I delete Jakefile and replace it with
>> > > > >> a Gruntfile.js?
>> > > > >>
>> > > >
>> > > >
>> > >
>> > > 
>>-
>> > > This transmission (including any attachments) may contain
>>confidential
>> > > information, privileged material (including material protected by
>>the
>> > > solicitor-client or other applicable privileges), or constitute
>> > non-public
>> > > information. Any use of this information by anyone other than the
>> > intended
>> > > recipient is prohibited. If you have received this transmission in
>> error,
>> > > please immediately reply to the sender and delete this information
>>from
>> > > your system. Use, dissemination, distribution, or reproduction of
>>this
>> > > transmission by unintended recipients is not authorized and may be
>> > unlawful.
>> > >
>> >
>>
>
>
>
>-- 
>Patrick Mueller
>http://muellerware.org

Re: Jake woes

[Patrick Mueller]

It appears you've made a horrible, HORRIBLE mistake with your patch [1],
and deleted the dalek.  HORRIBLE.

[1]
https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=273e0a3a

ps: I too once tried to delete the dalek, and look what happened to me. and
the dalek :-(


On Fri, Jun 21, 2013 at 2:17 PM, Benn Mapes  wrote:

> Could you also update the README?
> https://issues.apache.org/jira/browse/CB-3966
>
> Thanks!
>
>
> On Fri, Jun 21, 2013 at 7:23 AM, Andrew Grieve 
> wrote:
>
> > Okay, CB-3960 is the tracker.
> >
> >
> > On Fri, Jun 21, 2013 at 9:57 AM, Jeffrey Heifetz <
> jheif...@blackberry.com
> > >wrote:
> >
> > > +1
> > >
> > > Sent from my BlackBerry 10 smartphone on the Rogers network.
> > > From: Bryan Higgins
> > > Sent: Friday, June 21, 2013 9:39 AM
> > > To: dev@cordova.apache.org
> > > Reply To: dev@cordova.apache.org
> > > Subject: Re: Jake woes
> > >
> > >
> > > +1
> > >
> > >
> > > On Fri, Jun 21, 2013 at 7:11 AM, Lucas Holmquist  > > >wrote:
> > >
> > > > +1
> > > > On Jun 20, 2013, at 11:20 PM, Steven Gill 
> > > wrote:
> > > >
> > > > > +1 Grunt
> > > > >
> > > > >
> > > > > On Thu, Jun 20, 2013 at 7:15 PM, Andrew Grieve <
> agri...@chromium.org
> > >
> > > > wrote:
> > > > >
> > > > >> I've burned quite a bit of time trying to get it to work, and I'm
> a
> > > bit
> > > > >> realizing that it's probably not worth continuing. By fiddling
> with
> > > > >> dependencies I can get it to run, but tasks are being run multiple
> > > times
> > > > >> when they shouldn't be, and there's no reason I should need to
> > fiddle
> > > > the
> > > > >> deps to get it to run.
> > > > >>
> > > > >> So... any objections if I delete Jakefile and replace it with
> > > > >> a Gruntfile.js?
> > > > >>
> > > >
> > > >
> > >
> > > -
> > > This transmission (including any attachments) may contain confidential
> > > information, privileged material (including material protected by the
> > > solicitor-client or other applicable privileges), or constitute
> > non-public
> > > information. Any use of this information by anyone other than the
> > intended
> > > recipient is prohibited. If you have received this transmission in
> error,
> > > please immediately reply to the sender and delete this information from
> > > your system. Use, dissemination, distribution, or reproduction of this
> > > transmission by unintended recipients is not authorized and may be
> > unlawful.
> > >
> >
>



-- 
Patrick Mueller
http://muellerware.org

Re: plugman iOS + compiler flags

[Carlos Santana]

I will take look into detecting incompatible ARC files that will
potentially give compiler errors.

So far what I had found is to look if code is using invalid functions
(i.e. retain and release)
Taking into consideration that file could be using macro to have dual path
based on

#if !__has_feature(objc_arc)

--Carlos




On Friday, June 21, 2013, Filip Maj wrote:

> That would be cool, have at it Carlos :D
>
> On 6/21/13 12:11 PM, "Carlos Santana"  wrote:
>
> >+1 on the be able to inject compiler options per file from xml
> >
> >On the same area, what about coding a small script/tool to analyze a
> >plugin
> >folder and generate the plugin.xml section containing the list of files
> >that need the flag?
> >
> >--Carlos
> >
> >
> >On Fri, Jun 21, 2013 at 3:00 PM, Shazron  wrote:
> >
> >> Also, Andrew Grieve did propose it here in proposal #2:
> >>
> >>
> >>
> http://markmail.org/thread/tskkqinboyp5cjdg#query:+page:1+mid:ojea6mtsrtx
> >>x6f2a+state:results
> >>
> >> Awesome, I'll file it
> >>
> >>
> >> On Fri, Jun 21, 2013 at 11:58 AM, Filip Maj  wrote:
> >>
> >> > Sweet, let's file an issue as a feature request for this and I'll do
> >>my
> >> > best to get this in time for 3.0.
> >> >
> >> > On 6/21/13 11:54 AM, "Shazron"  wrote:
> >> >
> >> > >Of course it should be considered. We did discuss this briefly, but I
> >> > >don't
> >> > >think we added it as a feature request in time for 3.0.0.
> >> > >What I did recommend however, is for plugins to use the
> >> > >__has_feature(objc_arc) macro to support both ARC and non-ARC. This
> >>way,
> >> > >including it in any kind of project setting it would work - without
> >> adding
> >> > >this flag. Pre-3.0.0, ARC is _not_ enabled by default in the project
> >> > >template (for plugin compatibility reasons), but in 3.0.0 we are
> >> enabling
> >> > >it in the default template:
> >> https://issues.apache.org/jira/browse/CB-2180
> >> > >
> >> > >More info here:
> >> > >
> >> >
> >>
> >>
> http://shazronatadobe.wordpress.com/2012/09/05/automatic-reference-counti
> >>n
> >> > >g-arc-and-cordova-plugins/
> >> > >
> >> > >For pre-compiled binaries it's no problem (say the TestFlightSDK
> >>ships
> >> > >with
> >> > >libTestFlight.a), and for small plugins to convert to use the macro,
> >> but I
> >> > >can see it being a problem if we had to include the Facebook SDK with
> >> its
> >> > >gajillion files that may or may not be ARC (since converting them may
> >> be a
> >> > >maintenance nightmare for newer versions).
> >> > >
> >> > >For that last scenario, I would recommend having that new compiler
> >>flags
> >> > >attribute.
> >> > >
> >> > >
> >> > >On Fri, Jun 21, 2013 at 11:37 AM, aaron barnes 
> >> wrote:
> >> > >
> >> > >> I've really been enjoying the cordova cli/plugin.xml definition.
> >> > >>
> >> > >> I've been porting a bunch of old plugins to work with plugman's
> >> > >>plugin.xml
> >> > >> definition.  Generally it's been going well, however one problem
> >>I've
> >> > >>come
> >> > >> across a few times particularly when trying to apply it to old
> >>code or
> >> > >> adapting 3rd party code is that the code isn't ARC compliant.  The
> >> > >> preference would obviously be to make the code arc-compliant, but
> >>not
> >> > >>being
> >> > >> a pro in objective c, it's often easier to just add '-fno-objc-arc'
> >> as a
> >> > >> compiler flag for the file in xcode.
> >> > >>
> >> > >> It would be great to add as an option for iOS builders, I'm
> >>thinking
> >> > >> something like:
>


-- 
Carlos Santana

Re: [Announce] Cordova 2.9.0rc1 released

[Filip Maj]

Thanks for getting it out Steve!

On 6/21/13 1:31 PM, "Steven Gill"  wrote:

>Just wanted to announce that Cordova 2.9.0rc1 has been released! You can
>download it on the Cordova website at http://cordova.apache.org/. This is
>the release candidate for Cordova 2.9.0 which should be released next
>week.
>
>A changelog is included in the download.
>
>Have a great weekend!
>
>-Steve

[Announce] Cordova 2.9.0rc1 released

[Steven Gill]

Just wanted to announce that Cordova 2.9.0rc1 has been released! You can
download it on the Cordova website at http://cordova.apache.org/. This is
the release candidate for Cordova 2.9.0 which should be released next week.

A changelog is included in the download.

Have a great weekend!

-Steve

Re: plugman iOS + compiler flags

[aaron barnes]

Holy sh*t guys, that's some fast work.


Much obliged,


--aaron


On 6/21/13 11:54 AM, "Shazron"  wrote:


Filed: https://issues.apache.org/jira/browse/CB-3967

On Fri, Jun 21, 2013 at 11:58 AM, Filip Maj  wrote:

Sweet, let's file an issue as a feature request for this and I'll do my 
best to get this in time for 3.0.


On 6/21/13 11:54 AM, "Shazron"  wrote:

Of course it should be considered. We did discuss this briefly, but I 
don't think we added it as a feature request in time for 3.0.0. What I 
did recommend however, is for plugins to use the __has_feature(objc_arc) 
macro to support both ARC and non-ARC. This way, including it in any 
kind of project setting it would work - without adding this flag. 
Pre-3.0.0, ARC is _not_ enabled by default in the project template (for 
plugin compatibility reasons), but in 3.0.0 we are enabling it in the 
default template: https://issues.apache.org/jira/browse/CB-2180


More info here:

http://shazronatadobe.wordpress.com/2012/09/05/automatic-reference-countin

g-arc-and-cordova-plugins/

For pre-compiled binaries it's no problem (say the TestFlightSDK ships 
with libTestFlight.a), and for small plugins to convert to use the 
macro, but I can see it being a problem if we had to include the 
Facebook SDK with its gajillion files that may or may not be ARC (since 
converting them may be a maintenance nightmare for newer versions).


For that last scenario, I would recommend having that new compiler flags 
attribute.


On Fri, Jun 21, 2013 at 11:37 AM, aaron barnes  wrote:

I've really been enjoying the cordova cli/plugin.xml definition.

I've been porting a bunch of old plugins to work with plugman's 
plugin.xml definition. Generally it's been going well, however one 
problem I've come across a few times particularly when trying to apply 
it to old code or adapting 3rd party code is that the code isn't ARC 
compliant. The preference would obviously be to make the code 
arc-compliant, but not being a pro in objective c, it's often easier to 
just add '-fno-objc-arc' as a compiler flag for the file in xcode.


It would be great to add as an option for iOS builders, I'm thinking 
something like:




in plugin.xml

which would then insert something like :

93803FD21768C79200CB4E50 /* LegacyCode.m in Sources */ = {isa = 
PBXBuildFile; fileRef = 93803FCF1768C79200CB4E50 /* LegacyCode.m */; 
settings = {COMPILER_FLAGS = "-fno-objc-arc"; }; }


into the project.pbxproj.

would anybody else find this useful as a feature-request? can it be 
considered?


--aaron

© 2007-2011 MarkLogic Corporation. All rights reserved.Home 
|Browse |FAQ 
|Advertising 
|Blog 
|Feedback 
|MarkMail^(TM) Legalese 
|About MarkLogic Server 

Re: plugman iOS + compiler flags

[Filip Maj]

Thanks Shaz!

On 6/21/13 12:20 PM, "Shazron"  wrote:

>Filed: https://issues.apache.org/jira/browse/CB-3967
>
>
>On Fri, Jun 21, 2013 at 11:58 AM, Filip Maj  wrote:
>
>> Sweet, let's file an issue as a feature request for this and I'll do my
>> best to get this in time for 3.0.
>>
>> On 6/21/13 11:54 AM, "Shazron"  wrote:
>>
>> >Of course it should be considered. We did discuss this briefly, but I
>> >don't
>> >think we added it as a feature request in time for 3.0.0.
>> >What I did recommend however, is for plugins to use the
>> >__has_feature(objc_arc) macro to support both ARC and non-ARC. This
>>way,
>> >including it in any kind of project setting it would work - without
>>adding
>> >this flag. Pre-3.0.0, ARC is _not_ enabled by default in the project
>> >template (for plugin compatibility reasons), but in 3.0.0 we are
>>enabling
>> >it in the default template:
>>https://issues.apache.org/jira/browse/CB-2180
>> >
>> >More info here:
>> >
>> 
>>http://shazronatadobe.wordpress.com/2012/09/05/automatic-reference-counti
>>n
>> >g-arc-and-cordova-plugins/
>> >
>> >For pre-compiled binaries it's no problem (say the TestFlightSDK ships
>> >with
>> >libTestFlight.a), and for small plugins to convert to use the macro,
>>but I
>> >can see it being a problem if we had to include the Facebook SDK with
>>its
>> >gajillion files that may or may not be ARC (since converting them may
>>be a
>> >maintenance nightmare for newer versions).
>> >
>> >For that last scenario, I would recommend having that new compiler
>>flags
>> >attribute.
>> >
>> >
>> >On Fri, Jun 21, 2013 at 11:37 AM, aaron barnes 
>>wrote:
>> >
>> >> I've really been enjoying the cordova cli/plugin.xml definition.
>> >>
>> >> I've been porting a bunch of old plugins to work with plugman's
>> >>plugin.xml
>> >> definition.  Generally it's been going well, however one problem I've
>> >>come
>> >> across a few times particularly when trying to apply it to old code
>>or
>> >> adapting 3rd party code is that the code isn't ARC compliant.  The
>> >> preference would obviously be to make the code arc-compliant, but not
>> >>being
>> >> a pro in objective c, it's often easier to just add '-fno-objc-arc'
>>as a
>> >> compiler flag for the file in xcode.
>> >>
>> >> It would be great to add as an option for iOS builders, I'm thinking
>> >> something like:
>> >>
>> >> > >>compilerFlags="-fno-objc-arc"/**>
>> >>
>> >> in plugin.xml
>> >>
>> >> which would then insert something like :
>> >>
>> >> 93803FD21768C79200CB4E50 /* LegacyCode.m in Sources */ = {isa =
>> >> PBXBuildFile; fileRef = 93803FCF1768C79200CB4E50 /* LegacyCode.m */;
>> >> settings = {COMPILER_FLAGS = "-fno-objc-arc"; }; }
>> >>
>> >> into the project.pbxproj.
>> >>
>> >> would anybody else find this useful as a feature-request?  can it be
>> >> considered?
>> >>
>> >> --aaron
>> >>
>> >>
>> >>
>>
>>

Re: plugman iOS + compiler flags

[Shazron]

Filed: https://issues.apache.org/jira/browse/CB-3967


On Fri, Jun 21, 2013 at 11:58 AM, Filip Maj  wrote:

> Sweet, let's file an issue as a feature request for this and I'll do my
> best to get this in time for 3.0.
>
> On 6/21/13 11:54 AM, "Shazron"  wrote:
>
> >Of course it should be considered. We did discuss this briefly, but I
> >don't
> >think we added it as a feature request in time for 3.0.0.
> >What I did recommend however, is for plugins to use the
> >__has_feature(objc_arc) macro to support both ARC and non-ARC. This way,
> >including it in any kind of project setting it would work - without adding
> >this flag. Pre-3.0.0, ARC is _not_ enabled by default in the project
> >template (for plugin compatibility reasons), but in 3.0.0 we are enabling
> >it in the default template: https://issues.apache.org/jira/browse/CB-2180
> >
> >More info here:
> >
> http://shazronatadobe.wordpress.com/2012/09/05/automatic-reference-countin
> >g-arc-and-cordova-plugins/
> >
> >For pre-compiled binaries it's no problem (say the TestFlightSDK ships
> >with
> >libTestFlight.a), and for small plugins to convert to use the macro, but I
> >can see it being a problem if we had to include the Facebook SDK with its
> >gajillion files that may or may not be ARC (since converting them may be a
> >maintenance nightmare for newer versions).
> >
> >For that last scenario, I would recommend having that new compiler flags
> >attribute.
> >
> >
> >On Fri, Jun 21, 2013 at 11:37 AM, aaron barnes  wrote:
> >
> >> I've really been enjoying the cordova cli/plugin.xml definition.
> >>
> >> I've been porting a bunch of old plugins to work with plugman's
> >>plugin.xml
> >> definition.  Generally it's been going well, however one problem I've
> >>come
> >> across a few times particularly when trying to apply it to old code or
> >> adapting 3rd party code is that the code isn't ARC compliant.  The
> >> preference would obviously be to make the code arc-compliant, but not
> >>being
> >> a pro in objective c, it's often easier to just add '-fno-objc-arc' as a
> >> compiler flag for the file in xcode.
> >>
> >> It would be great to add as an option for iOS builders, I'm thinking
> >> something like:
> >>
> >>  >>compilerFlags="-fno-objc-arc"/**>
> >>
> >> in plugin.xml
> >>
> >> which would then insert something like :
> >>
> >> 93803FD21768C79200CB4E50 /* LegacyCode.m in Sources */ = {isa =
> >> PBXBuildFile; fileRef = 93803FCF1768C79200CB4E50 /* LegacyCode.m */;
> >> settings = {COMPILER_FLAGS = "-fno-objc-arc"; }; }
> >>
> >> into the project.pbxproj.
> >>
> >> would anybody else find this useful as a feature-request?  can it be
> >> considered?
> >>
> >> --aaron
> >>
> >>
> >>
>
>

Re: plugman iOS + compiler flags

[Filip Maj]

That would be cool, have at it Carlos :D

On 6/21/13 12:11 PM, "Carlos Santana"  wrote:

>+1 on the be able to inject compiler options per file from xml
>
>On the same area, what about coding a small script/tool to analyze a
>plugin
>folder and generate the plugin.xml section containing the list of files
>that need the flag?
>
>--Carlos
>
>
>On Fri, Jun 21, 2013 at 3:00 PM, Shazron  wrote:
>
>> Also, Andrew Grieve did propose it here in proposal #2:
>>
>> 
>>http://markmail.org/thread/tskkqinboyp5cjdg#query:+page:1+mid:ojea6mtsrtx
>>x6f2a+state:results
>>
>> Awesome, I'll file it
>>
>>
>> On Fri, Jun 21, 2013 at 11:58 AM, Filip Maj  wrote:
>>
>> > Sweet, let's file an issue as a feature request for this and I'll do
>>my
>> > best to get this in time for 3.0.
>> >
>> > On 6/21/13 11:54 AM, "Shazron"  wrote:
>> >
>> > >Of course it should be considered. We did discuss this briefly, but I
>> > >don't
>> > >think we added it as a feature request in time for 3.0.0.
>> > >What I did recommend however, is for plugins to use the
>> > >__has_feature(objc_arc) macro to support both ARC and non-ARC. This
>>way,
>> > >including it in any kind of project setting it would work - without
>> adding
>> > >this flag. Pre-3.0.0, ARC is _not_ enabled by default in the project
>> > >template (for plugin compatibility reasons), but in 3.0.0 we are
>> enabling
>> > >it in the default template:
>> https://issues.apache.org/jira/browse/CB-2180
>> > >
>> > >More info here:
>> > >
>> >
>> 
>>http://shazronatadobe.wordpress.com/2012/09/05/automatic-reference-counti
>>n
>> > >g-arc-and-cordova-plugins/
>> > >
>> > >For pre-compiled binaries it's no problem (say the TestFlightSDK
>>ships
>> > >with
>> > >libTestFlight.a), and for small plugins to convert to use the macro,
>> but I
>> > >can see it being a problem if we had to include the Facebook SDK with
>> its
>> > >gajillion files that may or may not be ARC (since converting them may
>> be a
>> > >maintenance nightmare for newer versions).
>> > >
>> > >For that last scenario, I would recommend having that new compiler
>>flags
>> > >attribute.
>> > >
>> > >
>> > >On Fri, Jun 21, 2013 at 11:37 AM, aaron barnes 
>> wrote:
>> > >
>> > >> I've really been enjoying the cordova cli/plugin.xml definition.
>> > >>
>> > >> I've been porting a bunch of old plugins to work with plugman's
>> > >>plugin.xml
>> > >> definition.  Generally it's been going well, however one problem
>>I've
>> > >>come
>> > >> across a few times particularly when trying to apply it to old
>>code or
>> > >> adapting 3rd party code is that the code isn't ARC compliant.  The
>> > >> preference would obviously be to make the code arc-compliant, but
>>not
>> > >>being
>> > >> a pro in objective c, it's often easier to just add '-fno-objc-arc'
>> as a
>> > >> compiler flag for the file in xcode.
>> > >>
>> > >> It would be great to add as an option for iOS builders, I'm
>>thinking
>> > >> something like:
>> > >>
>> > >> > > >>compilerFlags="-fno-objc-arc"/**>
>> > >>
>> > >> in plugin.xml
>> > >>
>> > >> which would then insert something like :
>> > >>
>> > >> 93803FD21768C79200CB4E50 /* LegacyCode.m in Sources */ = {isa =
>> > >> PBXBuildFile; fileRef = 93803FCF1768C79200CB4E50 /* LegacyCode.m
>>*/;
>> > >> settings = {COMPILER_FLAGS = "-fno-objc-arc"; }; }
>> > >>
>> > >> into the project.pbxproj.
>> > >>
>> > >> would anybody else find this useful as a feature-request?  can it
>>be
>> > >> considered?
>> > >>
>> > >> --aaron
>> > >>
>> > >>
>> > >>
>> >
>> >
>>
>
>
>
>-- 
>Carlos Santana
>

Re: plugman iOS + compiler flags

[Carlos Santana]

+1 on the be able to inject compiler options per file from xml

On the same area, what about coding a small script/tool to analyze a plugin
folder and generate the plugin.xml section containing the list of files
that need the flag?

--Carlos


On Fri, Jun 21, 2013 at 3:00 PM, Shazron  wrote:

> Also, Andrew Grieve did propose it here in proposal #2:
>
> http://markmail.org/thread/tskkqinboyp5cjdg#query:+page:1+mid:ojea6mtsrtxx6f2a+state:results
>
> Awesome, I'll file it
>
>
> On Fri, Jun 21, 2013 at 11:58 AM, Filip Maj  wrote:
>
> > Sweet, let's file an issue as a feature request for this and I'll do my
> > best to get this in time for 3.0.
> >
> > On 6/21/13 11:54 AM, "Shazron"  wrote:
> >
> > >Of course it should be considered. We did discuss this briefly, but I
> > >don't
> > >think we added it as a feature request in time for 3.0.0.
> > >What I did recommend however, is for plugins to use the
> > >__has_feature(objc_arc) macro to support both ARC and non-ARC. This way,
> > >including it in any kind of project setting it would work - without
> adding
> > >this flag. Pre-3.0.0, ARC is _not_ enabled by default in the project
> > >template (for plugin compatibility reasons), but in 3.0.0 we are
> enabling
> > >it in the default template:
> https://issues.apache.org/jira/browse/CB-2180
> > >
> > >More info here:
> > >
> >
> http://shazronatadobe.wordpress.com/2012/09/05/automatic-reference-countin
> > >g-arc-and-cordova-plugins/
> > >
> > >For pre-compiled binaries it's no problem (say the TestFlightSDK ships
> > >with
> > >libTestFlight.a), and for small plugins to convert to use the macro,
> but I
> > >can see it being a problem if we had to include the Facebook SDK with
> its
> > >gajillion files that may or may not be ARC (since converting them may
> be a
> > >maintenance nightmare for newer versions).
> > >
> > >For that last scenario, I would recommend having that new compiler flags
> > >attribute.
> > >
> > >
> > >On Fri, Jun 21, 2013 at 11:37 AM, aaron barnes 
> wrote:
> > >
> > >> I've really been enjoying the cordova cli/plugin.xml definition.
> > >>
> > >> I've been porting a bunch of old plugins to work with plugman's
> > >>plugin.xml
> > >> definition.  Generally it's been going well, however one problem I've
> > >>come
> > >> across a few times particularly when trying to apply it to old code or
> > >> adapting 3rd party code is that the code isn't ARC compliant.  The
> > >> preference would obviously be to make the code arc-compliant, but not
> > >>being
> > >> a pro in objective c, it's often easier to just add '-fno-objc-arc'
> as a
> > >> compiler flag for the file in xcode.
> > >>
> > >> It would be great to add as an option for iOS builders, I'm thinking
> > >> something like:
> > >>
> > >>  > >>compilerFlags="-fno-objc-arc"/**>
> > >>
> > >> in plugin.xml
> > >>
> > >> which would then insert something like :
> > >>
> > >> 93803FD21768C79200CB4E50 /* LegacyCode.m in Sources */ = {isa =
> > >> PBXBuildFile; fileRef = 93803FCF1768C79200CB4E50 /* LegacyCode.m */;
> > >> settings = {COMPILER_FLAGS = "-fno-objc-arc"; }; }
> > >>
> > >> into the project.pbxproj.
> > >>
> > >> would anybody else find this useful as a feature-request?  can it be
> > >> considered?
> > >>
> > >> --aaron
> > >>
> > >>
> > >>
> >
> >
>



-- 
Carlos Santana

Re: plugman iOS + compiler flags

[Shazron]

Also, Andrew Grieve did propose it here in proposal #2:
http://markmail.org/thread/tskkqinboyp5cjdg#query:+page:1+mid:ojea6mtsrtxx6f2a+state:results

Awesome, I'll file it


On Fri, Jun 21, 2013 at 11:58 AM, Filip Maj  wrote:

> Sweet, let's file an issue as a feature request for this and I'll do my
> best to get this in time for 3.0.
>
> On 6/21/13 11:54 AM, "Shazron"  wrote:
>
> >Of course it should be considered. We did discuss this briefly, but I
> >don't
> >think we added it as a feature request in time for 3.0.0.
> >What I did recommend however, is for plugins to use the
> >__has_feature(objc_arc) macro to support both ARC and non-ARC. This way,
> >including it in any kind of project setting it would work - without adding
> >this flag. Pre-3.0.0, ARC is _not_ enabled by default in the project
> >template (for plugin compatibility reasons), but in 3.0.0 we are enabling
> >it in the default template: https://issues.apache.org/jira/browse/CB-2180
> >
> >More info here:
> >
> http://shazronatadobe.wordpress.com/2012/09/05/automatic-reference-countin
> >g-arc-and-cordova-plugins/
> >
> >For pre-compiled binaries it's no problem (say the TestFlightSDK ships
> >with
> >libTestFlight.a), and for small plugins to convert to use the macro, but I
> >can see it being a problem if we had to include the Facebook SDK with its
> >gajillion files that may or may not be ARC (since converting them may be a
> >maintenance nightmare for newer versions).
> >
> >For that last scenario, I would recommend having that new compiler flags
> >attribute.
> >
> >
> >On Fri, Jun 21, 2013 at 11:37 AM, aaron barnes  wrote:
> >
> >> I've really been enjoying the cordova cli/plugin.xml definition.
> >>
> >> I've been porting a bunch of old plugins to work with plugman's
> >>plugin.xml
> >> definition.  Generally it's been going well, however one problem I've
> >>come
> >> across a few times particularly when trying to apply it to old code or
> >> adapting 3rd party code is that the code isn't ARC compliant.  The
> >> preference would obviously be to make the code arc-compliant, but not
> >>being
> >> a pro in objective c, it's often easier to just add '-fno-objc-arc' as a
> >> compiler flag for the file in xcode.
> >>
> >> It would be great to add as an option for iOS builders, I'm thinking
> >> something like:
> >>
> >>  >>compilerFlags="-fno-objc-arc"/**>
> >>
> >> in plugin.xml
> >>
> >> which would then insert something like :
> >>
> >> 93803FD21768C79200CB4E50 /* LegacyCode.m in Sources */ = {isa =
> >> PBXBuildFile; fileRef = 93803FCF1768C79200CB4E50 /* LegacyCode.m */;
> >> settings = {COMPILER_FLAGS = "-fno-objc-arc"; }; }
> >>
> >> into the project.pbxproj.
> >>
> >> would anybody else find this useful as a feature-request?  can it be
> >> considered?
> >>
> >> --aaron
> >>
> >>
> >>
>
>

Re: plugman iOS + compiler flags

[Filip Maj]

Sweet, let's file an issue as a feature request for this and I'll do my
best to get this in time for 3.0.

On 6/21/13 11:54 AM, "Shazron"  wrote:

>Of course it should be considered. We did discuss this briefly, but I
>don't
>think we added it as a feature request in time for 3.0.0.
>What I did recommend however, is for plugins to use the
>__has_feature(objc_arc) macro to support both ARC and non-ARC. This way,
>including it in any kind of project setting it would work - without adding
>this flag. Pre-3.0.0, ARC is _not_ enabled by default in the project
>template (for plugin compatibility reasons), but in 3.0.0 we are enabling
>it in the default template: https://issues.apache.org/jira/browse/CB-2180
>
>More info here:
>http://shazronatadobe.wordpress.com/2012/09/05/automatic-reference-countin
>g-arc-and-cordova-plugins/
>
>For pre-compiled binaries it's no problem (say the TestFlightSDK ships
>with
>libTestFlight.a), and for small plugins to convert to use the macro, but I
>can see it being a problem if we had to include the Facebook SDK with its
>gajillion files that may or may not be ARC (since converting them may be a
>maintenance nightmare for newer versions).
>
>For that last scenario, I would recommend having that new compiler flags
>attribute.
>
>
>On Fri, Jun 21, 2013 at 11:37 AM, aaron barnes  wrote:
>
>> I've really been enjoying the cordova cli/plugin.xml definition.
>>
>> I've been porting a bunch of old plugins to work with plugman's
>>plugin.xml
>> definition.  Generally it's been going well, however one problem I've
>>come
>> across a few times particularly when trying to apply it to old code or
>> adapting 3rd party code is that the code isn't ARC compliant.  The
>> preference would obviously be to make the code arc-compliant, but not
>>being
>> a pro in objective c, it's often easier to just add '-fno-objc-arc' as a
>> compiler flag for the file in xcode.
>>
>> It would be great to add as an option for iOS builders, I'm thinking
>> something like:
>>
>> >compilerFlags="-fno-objc-arc"/**>
>>
>> in plugin.xml
>>
>> which would then insert something like :
>>
>> 93803FD21768C79200CB4E50 /* LegacyCode.m in Sources */ = {isa =
>> PBXBuildFile; fileRef = 93803FCF1768C79200CB4E50 /* LegacyCode.m */;
>> settings = {COMPILER_FLAGS = "-fno-objc-arc"; }; }
>>
>> into the project.pbxproj.
>>
>> would anybody else find this useful as a feature-request?  can it be
>> considered?
>>
>> --aaron
>>
>>
>>

Re: plugman iOS + compiler flags

[Shazron]

Of course it should be considered. We did discuss this briefly, but I don't
think we added it as a feature request in time for 3.0.0.
What I did recommend however, is for plugins to use the
__has_feature(objc_arc) macro to support both ARC and non-ARC. This way,
including it in any kind of project setting it would work - without adding
this flag. Pre-3.0.0, ARC is _not_ enabled by default in the project
template (for plugin compatibility reasons), but in 3.0.0 we are enabling
it in the default template: https://issues.apache.org/jira/browse/CB-2180

More info here:
http://shazronatadobe.wordpress.com/2012/09/05/automatic-reference-counting-arc-and-cordova-plugins/

For pre-compiled binaries it's no problem (say the TestFlightSDK ships with
libTestFlight.a), and for small plugins to convert to use the macro, but I
can see it being a problem if we had to include the Facebook SDK with its
gajillion files that may or may not be ARC (since converting them may be a
maintenance nightmare for newer versions).

For that last scenario, I would recommend having that new compiler flags
attribute.


On Fri, Jun 21, 2013 at 11:37 AM, aaron barnes  wrote:

> I've really been enjoying the cordova cli/plugin.xml definition.
>
> I've been porting a bunch of old plugins to work with plugman's plugin.xml
> definition.  Generally it's been going well, however one problem I've come
> across a few times particularly when trying to apply it to old code or
> adapting 3rd party code is that the code isn't ARC compliant.  The
> preference would obviously be to make the code arc-compliant, but not being
> a pro in objective c, it's often easier to just add '-fno-objc-arc' as a
> compiler flag for the file in xcode.
>
> It would be great to add as an option for iOS builders, I'm thinking
> something like:
>
> 
>
> in plugin.xml
>
> which would then insert something like :
>
> 93803FD21768C79200CB4E50 /* LegacyCode.m in Sources */ = {isa =
> PBXBuildFile; fileRef = 93803FCF1768C79200CB4E50 /* LegacyCode.m */;
> settings = {COMPILER_FLAGS = "-fno-objc-arc"; }; }
>
> into the project.pbxproj.
>
> would anybody else find this useful as a feature-request?  can it be
> considered?
>
> --aaron
>
>
>

Re: plugman iOS + compiler flags

[Filip Maj]

It makes sense to me although I'd like to hear what other committers think
about this as well.

Related question: are there any other platforms where compiler flags would
be helpful/useful? 

On 6/21/13 11:37 AM, "aaron barnes"  wrote:

>I've really been enjoying the cordova cli/plugin.xml definition.
>
>I've been porting a bunch of old plugins to work with plugman's
>plugin.xml definition.  Generally it's been going well, however one
>problem I've come across a few times particularly when trying to apply
>it to old code or adapting 3rd party code is that the code isn't ARC
>compliant.  The preference would obviously be to make the code
>arc-compliant, but not being a pro in objective c, it's often easier to
>just add '-fno-objc-arc' as a compiler flag for the file in xcode.
>
>It would be great to add as an option for iOS builders, I'm thinking
>something like:
>
>
>
>in plugin.xml
>
>which would then insert something like :
>
>93803FD21768C79200CB4E50 /* LegacyCode.m in Sources */ = {isa =
>PBXBuildFile; fileRef = 93803FCF1768C79200CB4E50 /* LegacyCode.m */;
>settings = {COMPILER_FLAGS = "-fno-objc-arc"; }; }
>
>into the project.pbxproj.
>
>would anybody else find this useful as a feature-request?  can it be
>considered?
>
>--aaron
>
>

plugman iOS + compiler flags

[aaron barnes]

I've really been enjoying the cordova cli/plugin.xml definition.

I've been porting a bunch of old plugins to work with plugman's 
plugin.xml definition.  Generally it's been going well, however one 
problem I've come across a few times particularly when trying to apply 
it to old code or adapting 3rd party code is that the code isn't ARC 
compliant.  The preference would obviously be to make the code 
arc-compliant, but not being a pro in objective c, it's often easier to 
just add '-fno-objc-arc' as a compiler flag for the file in xcode.


It would be great to add as an option for iOS builders, I'm thinking 
something like:




in plugin.xml

which would then insert something like :

93803FD21768C79200CB4E50 /* LegacyCode.m in Sources */ = {isa = 
PBXBuildFile; fileRef = 93803FCF1768C79200CB4E50 /* LegacyCode.m */; 
settings = {COMPILER_FLAGS = "-fno-objc-arc"; }; }


into the project.pbxproj.

would anybody else find this useful as a feature-request?  can it be 
considered?


--aaron

Re: Suggestion - pluginLoader

[Filip Maj]

+1 on the nice proposal.

I have a fork of the BarcodeScanner plugin [1] that uses the plugin spec
and is plugman-compatible. Right at the top of its plugin.xml you can see
it defines the global for the barcodescanner JS as `window.barcodescanner`.

Also, the cordova team is working on breaking out all of the core APIs
into plugins themselves, and all of these core apis/plugins will be
compatible with plugman. Many of them already work with plugman and the
3.0.0 branches of cordova platforms (which have no APIs other than the
exec bridge). Check out the git-wip repos, anything named cordova-plugin-*
[2].

[1] https://github.com/filmaj/BarcodeScanner/blob/master/plugin.xml
[2] https://git-wip-us.apache.org/repos/asf

On 6/21/13 9:21 AM, "J Prince"  wrote:

>That looks much more like what I need.
>I think there were two things adding to my confusion;
>
>1. I was not aware plugman could affect the javascript
>2. I don't think I've seen any clean plugman plugins "in the wild"
>
>I will look into the plugin spec a bit further and do some testing with
>it to see what can be done.
>
>
>
>> From: agri...@chromium.org
>> Date: Fri, 21 Jun 2013 11:28:28 -0400
>> Subject: Re: Suggestion - pluginLoader
>> To: dev@cordova.apache.org
>> 
>> aha, so previously we didn't help plugins along at all.
>> 
>> With plugman-compatible plugins, we do define a way for plugin JS to be
>> loaded: you add a  tag to your plugin.xml and then plugman
>>will
>> wrap your file in a cordova.define().
>> 
>> Spec: 
>>https://github.com/apache/cordova-plugman/blob/master/plugin_spec.md
>> 
>> You can also specify a  tag in  which just causes your
>> .js file to be executed after cordova.js is parsed.
>> 
>> I think with this, you could layer on another module loading system if
>>you
>> wanted something outside of the cordova.define() system.
>> 
>> Does that make sense?
>> 
>> 
>> 
>> 
>> On Fri, Jun 21, 2013 at 10:41 AM, J Prince
>>wrote:
>> 
>> > Perhaps my terminology is wrong but ALL plugins define how they are
>>loaded.
>> >
>> > Either (old style) window.plugins = ...
>> > or (new style) cordova.define(...
>> >
>> > My fundamental point is they shouldn't. I don't want my plugins
>>loaded in
>> > either of these ways. The loading of plugins should be separate to the
>> > plugin definition.
>> > Hence my suggestion of;
>> >
>> > cordova.pluginLoader(...)
>> >
>> > In this pattern pluginLoader could either have multiple different
>>modes or
>> > developers could override it (or both).
>> > At the moment I am having to change each plugin to not define its
>>loading
>> > implementation.
>> >
>> >
>> > > From: agri...@chromium.org
>> > > Date: Fri, 21 Jun 2013 10:22:35 -0400
>> > > Subject: Re: Suggestion - pluginLoader
>> > > To: dev@cordova.apache.org
>> > >
>> > > For your actual app, you're free to use any JS loader that you'd
>>like.
>> > >
>> > > Are there really many existing Cordova plugins that use alternate
>>module
>> > > package definitions?
>> > >
>> > >
>> > > On Fri, Jun 21, 2013 at 9:39 AM, J Prince
>>> > >wrote:
>> > >
>> > > > Hi Andrew,
>> > > >
>> > > > My main point was to make the actual plugin javascript
>>definitions more
>> > > > flexible.
>> > > > That way it would support more unusual developer requirements
>>(such as
>> > > > mine).
>> > > > If the plugin definitions did not contain any loader
>>implementation
>> > then
>> > > > the same definition can be used different ways by different
>>developers.
>> > > >
>> > > > Currently any existing plugins that I want to use I am making my
>>own
>> > copy
>> > > > of and modifying to suit my project.
>> > > > I found this annoying and produced my suggestion based on that
>> > experience.
>> > > >
>> > > > I suppose it is as much for developer simplicity as anything else.
>> > > > A format that supported different use cases would be better for
>>me!
>> > > > It would also mean that the cordova team could more easily change
>>the
>> > > > javascript plugin loader in future without breaking existing
>>plugins.
>> > > >
>> > > > I hadn't thought about dynamically loading the native side of
>>plugins.
>> > > > I was just assuming that would always be loaded.
>> > > >
>> > > >
>> > > > > From: agri...@chromium.org
>> > > > > Date: Fri, 21 Jun 2013 09:12:42 -0400
>> > > > > Subject: Re: Suggestion - pluginLoader
>> > > > > To: dev@cordova.apache.org
>> > > > >
>> > > > > Hi Jonathan,
>> > > > >
>> > > > > First, thanks for a well-written proposal. At least for me, I'm
>>not
>> > > > really
>> > > > > sure that there is enough of a problem with the current
>>approach that
>> > > > would
>> > > > > justify changing it. That said, business is always an issue, and
>> > bumping
>> > > > > your thread was the right thing to do :)
>> > > > >
>> > > > > For Android and iOS, the large majority of plugins require
>>native
>> > code in
>> > > > > order to be useful, so I don't think that having plugin JS be
>> > dynamically
>> > > > > seems that useful without being able to dynamically lo

Re: Jake woes

[Benn Mapes]

Could you also update the README?
https://issues.apache.org/jira/browse/CB-3966

Thanks!


On Fri, Jun 21, 2013 at 7:23 AM, Andrew Grieve  wrote:

> Okay, CB-3960 is the tracker.
>
>
> On Fri, Jun 21, 2013 at 9:57 AM, Jeffrey Heifetz  >wrote:
>
> > +1
> >
> > Sent from my BlackBerry 10 smartphone on the Rogers network.
> > From: Bryan Higgins
> > Sent: Friday, June 21, 2013 9:39 AM
> > To: dev@cordova.apache.org
> > Reply To: dev@cordova.apache.org
> > Subject: Re: Jake woes
> >
> >
> > +1
> >
> >
> > On Fri, Jun 21, 2013 at 7:11 AM, Lucas Holmquist  > >wrote:
> >
> > > +1
> > > On Jun 20, 2013, at 11:20 PM, Steven Gill 
> > wrote:
> > >
> > > > +1 Grunt
> > > >
> > > >
> > > > On Thu, Jun 20, 2013 at 7:15 PM, Andrew Grieve  >
> > > wrote:
> > > >
> > > >> I've burned quite a bit of time trying to get it to work, and I'm a
> > bit
> > > >> realizing that it's probably not worth continuing. By fiddling with
> > > >> dependencies I can get it to run, but tasks are being run multiple
> > times
> > > >> when they shouldn't be, and there's no reason I should need to
> fiddle
> > > the
> > > >> deps to get it to run.
> > > >>
> > > >> So... any objections if I delete Jakefile and replace it with
> > > >> a Gruntfile.js?
> > > >>
> > >
> > >
> >
> > -
> > This transmission (including any attachments) may contain confidential
> > information, privileged material (including material protected by the
> > solicitor-client or other applicable privileges), or constitute
> non-public
> > information. Any use of this information by anyone other than the
> intended
> > recipient is prohibited. If you have received this transmission in error,
> > please immediately reply to the sender and delete this information from
> > your system. Use, dissemination, distribution, or reproduction of this
> > transmission by unintended recipients is not authorized and may be
> unlawful.
> >
>

Re: Apache VM for Medic's CouchDB

[Brian LeRoux]

If we can get one setup then yes why not (could be good to have more
than one frankly). Pursing the Nodejitsu guys to donate an instance
(as they do for npm itself) which has really good uptime... ;)


On Thu, Jun 20, 2013 at 8:53 AM, Anis KADRI  wrote:
> Should we use this for our NPM registry as well ?
>
>
> On Thu, Jun 20, 2013 at 2:24 AM, Brian LeRoux  wrote:
>
>> Right on. Thanks for taking this on Mike.
>>
>> On Wed, Jun 19, 2013 at 7:12 PM, Lorin Beer 
>> wrote:
>> > that would be fantastic!
>> >
>> >
>> > On Wed, Jun 19, 2013 at 9:59 AM, Filip Maj  wrote:
>> >
>> >> Would love to see this, thanks for taking the initiative on this Mike!
>> >>
>> >> On 6/19/13 7:19 AM, "Andrew Grieve"  wrote:
>> >>
>> >> >Sounds great!
>> >> >
>> >> >
>> >> >On Wed, Jun 19, 2013 at 9:39 AM, Mike Billau 
>> >> >wrote:
>> >> >
>> >> >> Hello everyone,
>> >> >>
>> >> >> I have been working the last week on getting medic up and running
>> here
>> >> >>at
>> >> >> our office, and so far things are going pretty well. I would like to
>> >> >>start
>> >> >> contributing our tests back to the community pretty soon. However, I
>> >> >> contacted Fil about flowing our test results back to the CI database,
>> >> >>and
>> >> >> he informed me that unfortunately the EC2 instance has been removed.
>> >> >>
>> >> >> I would like to propose that we have the Apache folks set us up with
>> a
>> >> >> standard Linux VM that we can use to host the CouchDB server to
>> collect
>> >> >> test results. Using an Apache VM seems to be more in the Apache
>> spirit
>> >> >>as
>> >> >> opposed to an EC2 instance. Since it would be more centralized and
>> >> >> community owned, it would potentially make it easier for other
>> groups to
>> >> >> contribute test results. The VM can also serve as a home for any
>> future
>> >> >> dumps or hosted scripts that we need.
>> >> >>
>> >> >> Any thoughts on this? If there are no problems, then can somebody
>> >> >>involved
>> >> >> with ASF help me create the relevant INFRA issues?
>> >> >>
>> >> >> Thanks,
>> >> >> Mike Billau
>> >> >>
>> >>
>> >>
>>

Re: Review Request: Fixing exec bug.

[Jeffrey Willms]

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

(Updated June 21, 2013, 5:21 p.m.)


Review request for cordova and Andrew Grieve.


Description
---

Fixing exec bug.


This addresses bug CB-3927.
https://issues.apache.org/jira/browse/CB-3927


Diffs (updated)
-

  framework/src/org/apache/cordova/api/PluginEntry.java 
9b9af6bc303965e7263bca75037256da81868fb2 
  framework/src/org/apache/cordova/api/PluginManager.java 
adaec907e216c101cc78ee72ff30ec6b7d875a45 

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


Testing
---


Thanks,

Jeffrey Willms

Re: Cordova Blog

[Brian LeRoux]

OR we could use Github pages for the Cordova org and just host on a subdomain:

http://blog.cordova.io

???

Seems like the least friction.

On Fri, Jun 21, 2013 at 9:56 AM, Carlos Santana  wrote:
> Yes mirror to Github, official and live content will be stored on apache
> servers.
>
> +1 on the repo name cordova-blog
>
>
> On Fri, Jun 21, 2013 at 12:52 PM, Shazron  wrote:
>
>> +1 on Jekyll and Github. All we need is to request a cordova-blog repo on
>> git-wip-us, and then the Github mirror does all the work (I think) :)
>> https://help.github.com/articles/user-organization-and-project-pages
>>
>> So if the repo is cordova-blog, the url would then be
>> http://cordova.github.io/cordova-blog
>>
>>
>> On Fri, Jun 21, 2013 at 9:41 AM, Carlos Santana > >wrote:
>>
>> > @Brian
>> >
>> >I'm not married to WordPress was just referring as an example, JekyII
>> > will do fine ,
>> >
>> > Can we see if we can host the content on git/github instead of svn?, this
>> > way, I think it will be easier to contribute and maintain.
>> >
>> >
>> > --Carlos
>> >
>> >
>> > On Fri, Jun 21, 2013 at 12:29 PM, Brian LeRoux  wrote:
>> >
>> > > +1 on a blog but I'd like to do something static if possible. (Jekyll,
>> > > Scotch, Docpad are all nice enough). We used to use Wordpress for
>> > > http://phonegap.com and it was a complete struggle to keep it up to
>> > > date and online. The running joke when were dealing w/ this was
>> > > 'static sites are web scale'. And its true, since moving to Jekyll
>> > > we've had basically zero downtime.
>> > >
>> > > While our current setup is not ideal (svn) it does accommodate
>> > > anything static. I will talk w/ Yohei about doing a slight refresh to
>> > > that (if cool w/ everyone here).
>> > >
>> > >
>> > >
>> > > On Fri, Jun 21, 2013 at 8:06 AM, Carlos Santana 
>> > > wrote:
>> > > > This is great idea.
>> > > >
>> > > > I don't mind the same content in both places. (PhoneGap and Cordova)
>> > > > Phonegap is spelled Cordova anyway :-)
>> > > >
>> > > >
>> > > > Some of the blog posts in PhoneGap point to personal blogs.
>> > > > I would thin that the Cordova Blog will do the same have blogs hosted
>> > on
>> > > > its site or point to personal blog posts.
>> > > >
>> > > > What about having Pages (i.e. WordPress) on the Cordova Blog in
>> > addition
>> > > of
>> > > > Posts?
>> > > > Ideas for Pages:
>> > > > - Release Notes
>> > > > - Roadmap/Timeline
>> > > > - Videos
>> > > > - Tutorials
>> > > > - List 3rd Party Plugins
>> > > >
>> > > > Here is another one, if Blog (i.e. WordPress) is created why not host
>> > the
>> > > > whole site (cordova.io) with WordPress (Posts and Pages) and move
>> away
>> > > from
>> > > > Ruby for the website :-). If not then you will be maintaining two
>> sites
>> > > > with two different technologies.
>> > > >
>> > > > --Carlos
>> > > >
>> > > > On Thu, Jun 20, 2013 at 10:19 PM, Joe Bowser 
>> > wrote:
>> > > >
>> > > >> Currently, PhoneGap aggregates the blog posts of many committers at
>> > > >> phonegap.com/blog.  The downside of this is that it's an Adobe
>> blog,
>> > > >> and it's not Apache Cordova.  Apache Cordova should probably have
>> its
>> > > >> own blog, but I see a lot of the same content being in two different
>> > > >> places.
>> > > >>
>> > > >> If someone wants to take this on, that'd be awesome.
>> > > >>
>> > > >> On Thu, Jun 20, 2013 at 7:12 PM, Andrew Grieve <
>> agri...@chromium.org>
>> > > >> wrote:
>> > > >> > I brought it up in a separate thread (
>> > > >> > http://callback.markmail.org/thread/y44pmva6gfm257sl) but
>> probably
>> > > >> deserves
>> > > >> > its own.
>> > > >> >
>> > > >> > I'd like to create a Blog for Cordova and make all Committers able
>> > to
>> > > >> post
>> > > >> > to it. We could use it to:
>> > > >> > - Post release announcements & release notes
>> > > >> > - Draw attention to deprecations and upgrade guides
>> > > >> > - Deep dive into significant improvements / changes
>> > > >> >
>> > > >> > Mainly, I think having a blog for the project will be really help
>> by
>> > > >> > providing an authoritative source for Cordova blob posts (as
>> opposed
>> > > to
>> > > >> on
>> > > >> > our personal blogs, which I appreciate, but which I feel are
>> lacking
>> > > >> > authority).
>> > > >> >
>> > > >> > I'm quite inexperienced at blogging, so everyone agrees we should
>> go
>> > > >> ahead
>> > > >> > with this, it'd be good if someone more blog-savvy would own
>> setting
>> > > it
>> > > >> up.
>> > > >>
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > Carlos Santana
>> > > > 
>> > >
>> >
>> >
>> >
>> > --
>> > Carlos Santana
>> > 
>> >
>>
>
>
>
> --
> Carlos Santana
> 

Re: PhoneGap Day tickets

[Brian LeRoux]

NP, Colene (cc'd) can help get any/all committers tickets.

(Its ridiculously cheap for any community that isn't yet a committer
but pls email me if you need help.)

On Thu, Jun 20, 2013 at 6:56 PM, Andrew Grieve  wrote:
> Do I (or other committers thinking of attending) need to buy a ticket?

Re: Cordova Blog

[Carlos Santana]

Yes mirror to Github, official and live content will be stored on apache
servers.

+1 on the repo name cordova-blog


On Fri, Jun 21, 2013 at 12:52 PM, Shazron  wrote:

> +1 on Jekyll and Github. All we need is to request a cordova-blog repo on
> git-wip-us, and then the Github mirror does all the work (I think) :)
> https://help.github.com/articles/user-organization-and-project-pages
>
> So if the repo is cordova-blog, the url would then be
> http://cordova.github.io/cordova-blog
>
>
> On Fri, Jun 21, 2013 at 9:41 AM, Carlos Santana  >wrote:
>
> > @Brian
> >
> >I'm not married to WordPress was just referring as an example, JekyII
> > will do fine ,
> >
> > Can we see if we can host the content on git/github instead of svn?, this
> > way, I think it will be easier to contribute and maintain.
> >
> >
> > --Carlos
> >
> >
> > On Fri, Jun 21, 2013 at 12:29 PM, Brian LeRoux  wrote:
> >
> > > +1 on a blog but I'd like to do something static if possible. (Jekyll,
> > > Scotch, Docpad are all nice enough). We used to use Wordpress for
> > > http://phonegap.com and it was a complete struggle to keep it up to
> > > date and online. The running joke when were dealing w/ this was
> > > 'static sites are web scale'. And its true, since moving to Jekyll
> > > we've had basically zero downtime.
> > >
> > > While our current setup is not ideal (svn) it does accommodate
> > > anything static. I will talk w/ Yohei about doing a slight refresh to
> > > that (if cool w/ everyone here).
> > >
> > >
> > >
> > > On Fri, Jun 21, 2013 at 8:06 AM, Carlos Santana 
> > > wrote:
> > > > This is great idea.
> > > >
> > > > I don't mind the same content in both places. (PhoneGap and Cordova)
> > > > Phonegap is spelled Cordova anyway :-)
> > > >
> > > >
> > > > Some of the blog posts in PhoneGap point to personal blogs.
> > > > I would thin that the Cordova Blog will do the same have blogs hosted
> > on
> > > > its site or point to personal blog posts.
> > > >
> > > > What about having Pages (i.e. WordPress) on the Cordova Blog in
> > addition
> > > of
> > > > Posts?
> > > > Ideas for Pages:
> > > > - Release Notes
> > > > - Roadmap/Timeline
> > > > - Videos
> > > > - Tutorials
> > > > - List 3rd Party Plugins
> > > >
> > > > Here is another one, if Blog (i.e. WordPress) is created why not host
> > the
> > > > whole site (cordova.io) with WordPress (Posts and Pages) and move
> away
> > > from
> > > > Ruby for the website :-). If not then you will be maintaining two
> sites
> > > > with two different technologies.
> > > >
> > > > --Carlos
> > > >
> > > > On Thu, Jun 20, 2013 at 10:19 PM, Joe Bowser 
> > wrote:
> > > >
> > > >> Currently, PhoneGap aggregates the blog posts of many committers at
> > > >> phonegap.com/blog.  The downside of this is that it's an Adobe
> blog,
> > > >> and it's not Apache Cordova.  Apache Cordova should probably have
> its
> > > >> own blog, but I see a lot of the same content being in two different
> > > >> places.
> > > >>
> > > >> If someone wants to take this on, that'd be awesome.
> > > >>
> > > >> On Thu, Jun 20, 2013 at 7:12 PM, Andrew Grieve <
> agri...@chromium.org>
> > > >> wrote:
> > > >> > I brought it up in a separate thread (
> > > >> > http://callback.markmail.org/thread/y44pmva6gfm257sl) but
> probably
> > > >> deserves
> > > >> > its own.
> > > >> >
> > > >> > I'd like to create a Blog for Cordova and make all Committers able
> > to
> > > >> post
> > > >> > to it. We could use it to:
> > > >> > - Post release announcements & release notes
> > > >> > - Draw attention to deprecations and upgrade guides
> > > >> > - Deep dive into significant improvements / changes
> > > >> >
> > > >> > Mainly, I think having a blog for the project will be really help
> by
> > > >> > providing an authoritative source for Cordova blob posts (as
> opposed
> > > to
> > > >> on
> > > >> > our personal blogs, which I appreciate, but which I feel are
> lacking
> > > >> > authority).
> > > >> >
> > > >> > I'm quite inexperienced at blogging, so everyone agrees we should
> go
> > > >> ahead
> > > >> > with this, it'd be good if someone more blog-savvy would own
> setting
> > > it
> > > >> up.
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > Carlos Santana
> > > > 
> > >
> >
> >
> >
> > --
> > Carlos Santana
> > 
> >
>



-- 
Carlos Santana

Re: Cordova Blog

[Shazron]

... the github method would of course, apply to all the repos, they can
have their own Github project pages if they want. And since they are git
repos -- cherry-picking/merging of blog posts I suppose (which can be
automated)


On Fri, Jun 21, 2013 at 9:52 AM, Shazron  wrote:

> +1 on Jekyll and Github. All we need is to request a cordova-blog repo on
> git-wip-us, and then the Github mirror does all the work (I think) :)
> https://help.github.com/articles/user-organization-and-project-pages
>
> So if the repo is cordova-blog, the url would then be
> http://cordova.github.io/cordova-blog
>
>
> On Fri, Jun 21, 2013 at 9:41 AM, Carlos Santana wrote:
>
>> @Brian
>>
>>I'm not married to WordPress was just referring as an example, JekyII
>> will do fine ,
>>
>> Can we see if we can host the content on git/github instead of svn?, this
>> way, I think it will be easier to contribute and maintain.
>>
>>
>> --Carlos
>>
>>
>> On Fri, Jun 21, 2013 at 12:29 PM, Brian LeRoux  wrote:
>>
>> > +1 on a blog but I'd like to do something static if possible. (Jekyll,
>> > Scotch, Docpad are all nice enough). We used to use Wordpress for
>> > http://phonegap.com and it was a complete struggle to keep it up to
>> > date and online. The running joke when were dealing w/ this was
>> > 'static sites are web scale'. And its true, since moving to Jekyll
>> > we've had basically zero downtime.
>> >
>> > While our current setup is not ideal (svn) it does accommodate
>> > anything static. I will talk w/ Yohei about doing a slight refresh to
>> > that (if cool w/ everyone here).
>> >
>> >
>> >
>> > On Fri, Jun 21, 2013 at 8:06 AM, Carlos Santana 
>> > wrote:
>> > > This is great idea.
>> > >
>> > > I don't mind the same content in both places. (PhoneGap and Cordova)
>> > > Phonegap is spelled Cordova anyway :-)
>> > >
>> > >
>> > > Some of the blog posts in PhoneGap point to personal blogs.
>> > > I would thin that the Cordova Blog will do the same have blogs hosted
>> on
>> > > its site or point to personal blog posts.
>> > >
>> > > What about having Pages (i.e. WordPress) on the Cordova Blog in
>> addition
>> > of
>> > > Posts?
>> > > Ideas for Pages:
>> > > - Release Notes
>> > > - Roadmap/Timeline
>> > > - Videos
>> > > - Tutorials
>> > > - List 3rd Party Plugins
>> > >
>> > > Here is another one, if Blog (i.e. WordPress) is created why not host
>> the
>> > > whole site (cordova.io) with WordPress (Posts and Pages) and move
>> away
>> > from
>> > > Ruby for the website :-). If not then you will be maintaining two
>> sites
>> > > with two different technologies.
>> > >
>> > > --Carlos
>> > >
>> > > On Thu, Jun 20, 2013 at 10:19 PM, Joe Bowser 
>> wrote:
>> > >
>> > >> Currently, PhoneGap aggregates the blog posts of many committers at
>> > >> phonegap.com/blog.  The downside of this is that it's an Adobe blog,
>> > >> and it's not Apache Cordova.  Apache Cordova should probably have its
>> > >> own blog, but I see a lot of the same content being in two different
>> > >> places.
>> > >>
>> > >> If someone wants to take this on, that'd be awesome.
>> > >>
>> > >> On Thu, Jun 20, 2013 at 7:12 PM, Andrew Grieve > >
>> > >> wrote:
>> > >> > I brought it up in a separate thread (
>> > >> > http://callback.markmail.org/thread/y44pmva6gfm257sl) but probably
>> > >> deserves
>> > >> > its own.
>> > >> >
>> > >> > I'd like to create a Blog for Cordova and make all Committers able
>> to
>> > >> post
>> > >> > to it. We could use it to:
>> > >> > - Post release announcements & release notes
>> > >> > - Draw attention to deprecations and upgrade guides
>> > >> > - Deep dive into significant improvements / changes
>> > >> >
>> > >> > Mainly, I think having a blog for the project will be really help
>> by
>> > >> > providing an authoritative source for Cordova blob posts (as
>> opposed
>> > to
>> > >> on
>> > >> > our personal blogs, which I appreciate, but which I feel are
>> lacking
>> > >> > authority).
>> > >> >
>> > >> > I'm quite inexperienced at blogging, so everyone agrees we should
>> go
>> > >> ahead
>> > >> > with this, it'd be good if someone more blog-savvy would own
>> setting
>> > it
>> > >> up.
>> > >>
>> > >
>> > >
>> > >
>> > > --
>> > > Carlos Santana
>> > > 
>> >
>>
>>
>>
>> --
>> Carlos Santana
>> 
>>
>
>

Re: Cordova Blog

[Shazron]

+1 on Jekyll and Github. All we need is to request a cordova-blog repo on
git-wip-us, and then the Github mirror does all the work (I think) :)
https://help.github.com/articles/user-organization-and-project-pages

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


On Fri, Jun 21, 2013 at 9:41 AM, Carlos Santana wrote:

> @Brian
>
>I'm not married to WordPress was just referring as an example, JekyII
> will do fine ,
>
> Can we see if we can host the content on git/github instead of svn?, this
> way, I think it will be easier to contribute and maintain.
>
>
> --Carlos
>
>
> On Fri, Jun 21, 2013 at 12:29 PM, Brian LeRoux  wrote:
>
> > +1 on a blog but I'd like to do something static if possible. (Jekyll,
> > Scotch, Docpad are all nice enough). We used to use Wordpress for
> > http://phonegap.com and it was a complete struggle to keep it up to
> > date and online. The running joke when were dealing w/ this was
> > 'static sites are web scale'. And its true, since moving to Jekyll
> > we've had basically zero downtime.
> >
> > While our current setup is not ideal (svn) it does accommodate
> > anything static. I will talk w/ Yohei about doing a slight refresh to
> > that (if cool w/ everyone here).
> >
> >
> >
> > On Fri, Jun 21, 2013 at 8:06 AM, Carlos Santana 
> > wrote:
> > > This is great idea.
> > >
> > > I don't mind the same content in both places. (PhoneGap and Cordova)
> > > Phonegap is spelled Cordova anyway :-)
> > >
> > >
> > > Some of the blog posts in PhoneGap point to personal blogs.
> > > I would thin that the Cordova Blog will do the same have blogs hosted
> on
> > > its site or point to personal blog posts.
> > >
> > > What about having Pages (i.e. WordPress) on the Cordova Blog in
> addition
> > of
> > > Posts?
> > > Ideas for Pages:
> > > - Release Notes
> > > - Roadmap/Timeline
> > > - Videos
> > > - Tutorials
> > > - List 3rd Party Plugins
> > >
> > > Here is another one, if Blog (i.e. WordPress) is created why not host
> the
> > > whole site (cordova.io) with WordPress (Posts and Pages) and move away
> > from
> > > Ruby for the website :-). If not then you will be maintaining two sites
> > > with two different technologies.
> > >
> > > --Carlos
> > >
> > > On Thu, Jun 20, 2013 at 10:19 PM, Joe Bowser 
> wrote:
> > >
> > >> Currently, PhoneGap aggregates the blog posts of many committers at
> > >> phonegap.com/blog.  The downside of this is that it's an Adobe blog,
> > >> and it's not Apache Cordova.  Apache Cordova should probably have its
> > >> own blog, but I see a lot of the same content being in two different
> > >> places.
> > >>
> > >> If someone wants to take this on, that'd be awesome.
> > >>
> > >> On Thu, Jun 20, 2013 at 7:12 PM, Andrew Grieve 
> > >> wrote:
> > >> > I brought it up in a separate thread (
> > >> > http://callback.markmail.org/thread/y44pmva6gfm257sl) but probably
> > >> deserves
> > >> > its own.
> > >> >
> > >> > I'd like to create a Blog for Cordova and make all Committers able
> to
> > >> post
> > >> > to it. We could use it to:
> > >> > - Post release announcements & release notes
> > >> > - Draw attention to deprecations and upgrade guides
> > >> > - Deep dive into significant improvements / changes
> > >> >
> > >> > Mainly, I think having a blog for the project will be really help by
> > >> > providing an authoritative source for Cordova blob posts (as opposed
> > to
> > >> on
> > >> > our personal blogs, which I appreciate, but which I feel are lacking
> > >> > authority).
> > >> >
> > >> > I'm quite inexperienced at blogging, so everyone agrees we should go
> > >> ahead
> > >> > with this, it'd be good if someone more blog-savvy would own setting
> > it
> > >> up.
> > >>
> > >
> > >
> > >
> > > --
> > > Carlos Santana
> > > 
> >
>
>
>
> --
> Carlos Santana
> 
>

Re: Cordova Blog

[Brian LeRoux]

We could mirror but stuff that lives on apache.org is svn deployed and
I'm almost completely certain that infra would not be into changing
that.

On Fri, Jun 21, 2013 at 9:41 AM, Carlos Santana  wrote:
> @Brian
>
>I'm not married to WordPress was just referring as an example, JekyII
> will do fine ,
>
> Can we see if we can host the content on git/github instead of svn?, this
> way, I think it will be easier to contribute and maintain.
>
>
> --Carlos
>
>
> On Fri, Jun 21, 2013 at 12:29 PM, Brian LeRoux  wrote:
>
>> +1 on a blog but I'd like to do something static if possible. (Jekyll,
>> Scotch, Docpad are all nice enough). We used to use Wordpress for
>> http://phonegap.com and it was a complete struggle to keep it up to
>> date and online. The running joke when were dealing w/ this was
>> 'static sites are web scale'. And its true, since moving to Jekyll
>> we've had basically zero downtime.
>>
>> While our current setup is not ideal (svn) it does accommodate
>> anything static. I will talk w/ Yohei about doing a slight refresh to
>> that (if cool w/ everyone here).
>>
>>
>>
>> On Fri, Jun 21, 2013 at 8:06 AM, Carlos Santana 
>> wrote:
>> > This is great idea.
>> >
>> > I don't mind the same content in both places. (PhoneGap and Cordova)
>> > Phonegap is spelled Cordova anyway :-)
>> >
>> >
>> > Some of the blog posts in PhoneGap point to personal blogs.
>> > I would thin that the Cordova Blog will do the same have blogs hosted on
>> > its site or point to personal blog posts.
>> >
>> > What about having Pages (i.e. WordPress) on the Cordova Blog in addition
>> of
>> > Posts?
>> > Ideas for Pages:
>> > - Release Notes
>> > - Roadmap/Timeline
>> > - Videos
>> > - Tutorials
>> > - List 3rd Party Plugins
>> >
>> > Here is another one, if Blog (i.e. WordPress) is created why not host the
>> > whole site (cordova.io) with WordPress (Posts and Pages) and move away
>> from
>> > Ruby for the website :-). If not then you will be maintaining two sites
>> > with two different technologies.
>> >
>> > --Carlos
>> >
>> > On Thu, Jun 20, 2013 at 10:19 PM, Joe Bowser  wrote:
>> >
>> >> Currently, PhoneGap aggregates the blog posts of many committers at
>> >> phonegap.com/blog.  The downside of this is that it's an Adobe blog,
>> >> and it's not Apache Cordova.  Apache Cordova should probably have its
>> >> own blog, but I see a lot of the same content being in two different
>> >> places.
>> >>
>> >> If someone wants to take this on, that'd be awesome.
>> >>
>> >> On Thu, Jun 20, 2013 at 7:12 PM, Andrew Grieve 
>> >> wrote:
>> >> > I brought it up in a separate thread (
>> >> > http://callback.markmail.org/thread/y44pmva6gfm257sl) but probably
>> >> deserves
>> >> > its own.
>> >> >
>> >> > I'd like to create a Blog for Cordova and make all Committers able to
>> >> post
>> >> > to it. We could use it to:
>> >> > - Post release announcements & release notes
>> >> > - Draw attention to deprecations and upgrade guides
>> >> > - Deep dive into significant improvements / changes
>> >> >
>> >> > Mainly, I think having a blog for the project will be really help by
>> >> > providing an authoritative source for Cordova blob posts (as opposed
>> to
>> >> on
>> >> > our personal blogs, which I appreciate, but which I feel are lacking
>> >> > authority).
>> >> >
>> >> > I'm quite inexperienced at blogging, so everyone agrees we should go
>> >> ahead
>> >> > with this, it'd be good if someone more blog-savvy would own setting
>> it
>> >> up.
>> >>
>> >
>> >
>> >
>> > --
>> > Carlos Santana
>> > 
>>
>
>
>
> --
> Carlos Santana
> 

Re: Cordova Blog

[Carlos Santana]

@Brian

   I'm not married to WordPress was just referring as an example, JekyII
will do fine ,

Can we see if we can host the content on git/github instead of svn?, this
way, I think it will be easier to contribute and maintain.


--Carlos


On Fri, Jun 21, 2013 at 12:29 PM, Brian LeRoux  wrote:

> +1 on a blog but I'd like to do something static if possible. (Jekyll,
> Scotch, Docpad are all nice enough). We used to use Wordpress for
> http://phonegap.com and it was a complete struggle to keep it up to
> date and online. The running joke when were dealing w/ this was
> 'static sites are web scale'. And its true, since moving to Jekyll
> we've had basically zero downtime.
>
> While our current setup is not ideal (svn) it does accommodate
> anything static. I will talk w/ Yohei about doing a slight refresh to
> that (if cool w/ everyone here).
>
>
>
> On Fri, Jun 21, 2013 at 8:06 AM, Carlos Santana 
> wrote:
> > This is great idea.
> >
> > I don't mind the same content in both places. (PhoneGap and Cordova)
> > Phonegap is spelled Cordova anyway :-)
> >
> >
> > Some of the blog posts in PhoneGap point to personal blogs.
> > I would thin that the Cordova Blog will do the same have blogs hosted on
> > its site or point to personal blog posts.
> >
> > What about having Pages (i.e. WordPress) on the Cordova Blog in addition
> of
> > Posts?
> > Ideas for Pages:
> > - Release Notes
> > - Roadmap/Timeline
> > - Videos
> > - Tutorials
> > - List 3rd Party Plugins
> >
> > Here is another one, if Blog (i.e. WordPress) is created why not host the
> > whole site (cordova.io) with WordPress (Posts and Pages) and move away
> from
> > Ruby for the website :-). If not then you will be maintaining two sites
> > with two different technologies.
> >
> > --Carlos
> >
> > On Thu, Jun 20, 2013 at 10:19 PM, Joe Bowser  wrote:
> >
> >> Currently, PhoneGap aggregates the blog posts of many committers at
> >> phonegap.com/blog.  The downside of this is that it's an Adobe blog,
> >> and it's not Apache Cordova.  Apache Cordova should probably have its
> >> own blog, but I see a lot of the same content being in two different
> >> places.
> >>
> >> If someone wants to take this on, that'd be awesome.
> >>
> >> On Thu, Jun 20, 2013 at 7:12 PM, Andrew Grieve 
> >> wrote:
> >> > I brought it up in a separate thread (
> >> > http://callback.markmail.org/thread/y44pmva6gfm257sl) but probably
> >> deserves
> >> > its own.
> >> >
> >> > I'd like to create a Blog for Cordova and make all Committers able to
> >> post
> >> > to it. We could use it to:
> >> > - Post release announcements & release notes
> >> > - Draw attention to deprecations and upgrade guides
> >> > - Deep dive into significant improvements / changes
> >> >
> >> > Mainly, I think having a blog for the project will be really help by
> >> > providing an authoritative source for Cordova blob posts (as opposed
> to
> >> on
> >> > our personal blogs, which I appreciate, but which I feel are lacking
> >> > authority).
> >> >
> >> > I'm quite inexperienced at blogging, so everyone agrees we should go
> >> ahead
> >> > with this, it'd be good if someone more blog-savvy would own setting
> it
> >> up.
> >>
> >
> >
> >
> > --
> > Carlos Santana
> > 
>



-- 
Carlos Santana

Re: Cordova Blog

[Brian LeRoux]

+1 on a blog but I'd like to do something static if possible. (Jekyll,
Scotch, Docpad are all nice enough). We used to use Wordpress for
http://phonegap.com and it was a complete struggle to keep it up to
date and online. The running joke when were dealing w/ this was
'static sites are web scale'. And its true, since moving to Jekyll
we've had basically zero downtime.

While our current setup is not ideal (svn) it does accommodate
anything static. I will talk w/ Yohei about doing a slight refresh to
that (if cool w/ everyone here).



On Fri, Jun 21, 2013 at 8:06 AM, Carlos Santana  wrote:
> This is great idea.
>
> I don't mind the same content in both places. (PhoneGap and Cordova)
> Phonegap is spelled Cordova anyway :-)
>
>
> Some of the blog posts in PhoneGap point to personal blogs.
> I would thin that the Cordova Blog will do the same have blogs hosted on
> its site or point to personal blog posts.
>
> What about having Pages (i.e. WordPress) on the Cordova Blog in addition of
> Posts?
> Ideas for Pages:
> - Release Notes
> - Roadmap/Timeline
> - Videos
> - Tutorials
> - List 3rd Party Plugins
>
> Here is another one, if Blog (i.e. WordPress) is created why not host the
> whole site (cordova.io) with WordPress (Posts and Pages) and move away from
> Ruby for the website :-). If not then you will be maintaining two sites
> with two different technologies.
>
> --Carlos
>
> On Thu, Jun 20, 2013 at 10:19 PM, Joe Bowser  wrote:
>
>> Currently, PhoneGap aggregates the blog posts of many committers at
>> phonegap.com/blog.  The downside of this is that it's an Adobe blog,
>> and it's not Apache Cordova.  Apache Cordova should probably have its
>> own blog, but I see a lot of the same content being in two different
>> places.
>>
>> If someone wants to take this on, that'd be awesome.
>>
>> On Thu, Jun 20, 2013 at 7:12 PM, Andrew Grieve 
>> wrote:
>> > I brought it up in a separate thread (
>> > http://callback.markmail.org/thread/y44pmva6gfm257sl) but probably
>> deserves
>> > its own.
>> >
>> > I'd like to create a Blog for Cordova and make all Committers able to
>> post
>> > to it. We could use it to:
>> > - Post release announcements & release notes
>> > - Draw attention to deprecations and upgrade guides
>> > - Deep dive into significant improvements / changes
>> >
>> > Mainly, I think having a blog for the project will be really help by
>> > providing an authoritative source for Cordova blob posts (as opposed to
>> on
>> > our personal blogs, which I appreciate, but which I feel are lacking
>> > authority).
>> >
>> > I'm quite inexperienced at blogging, so everyone agrees we should go
>> ahead
>> > with this, it'd be good if someone more blog-savvy would own setting it
>> up.
>>
>
>
>
> --
> Carlos Santana
> 

RE: Suggestion - pluginLoader

[J Prince]

That looks much more like what I need.
I think there were two things adding to my confusion;

1. I was not aware plugman could affect the javascript
2. I don't think I've seen any clean plugman plugins "in the wild"

I will look into the plugin spec a bit further and do some testing with it to 
see what can be done.



> From: agri...@chromium.org
> Date: Fri, 21 Jun 2013 11:28:28 -0400
> Subject: Re: Suggestion - pluginLoader
> To: dev@cordova.apache.org
> 
> aha, so previously we didn't help plugins along at all.
> 
> With plugman-compatible plugins, we do define a way for plugin JS to be
> loaded: you add a  tag to your plugin.xml and then plugman will
> wrap your file in a cordova.define().
> 
> Spec: https://github.com/apache/cordova-plugman/blob/master/plugin_spec.md
> 
> You can also specify a  tag in  which just causes your
> .js file to be executed after cordova.js is parsed.
> 
> I think with this, you could layer on another module loading system if you
> wanted something outside of the cordova.define() system.
> 
> Does that make sense?
> 
> 
> 
> 
> On Fri, Jun 21, 2013 at 10:41 AM, J Prince wrote:
> 
> > Perhaps my terminology is wrong but ALL plugins define how they are loaded.
> >
> > Either (old style) window.plugins = ...
> > or (new style) cordova.define(...
> >
> > My fundamental point is they shouldn't. I don't want my plugins loaded in
> > either of these ways. The loading of plugins should be separate to the
> > plugin definition.
> > Hence my suggestion of;
> >
> > cordova.pluginLoader(...)
> >
> > In this pattern pluginLoader could either have multiple different modes or
> > developers could override it (or both).
> > At the moment I am having to change each plugin to not define its loading
> > implementation.
> >
> >
> > > From: agri...@chromium.org
> > > Date: Fri, 21 Jun 2013 10:22:35 -0400
> > > Subject: Re: Suggestion - pluginLoader
> > > To: dev@cordova.apache.org
> > >
> > > For your actual app, you're free to use any JS loader that you'd like.
> > >
> > > Are there really many existing Cordova plugins that use alternate module
> > > package definitions?
> > >
> > >
> > > On Fri, Jun 21, 2013 at 9:39 AM, J Prince  > >wrote:
> > >
> > > > Hi Andrew,
> > > >
> > > > My main point was to make the actual plugin javascript definitions more
> > > > flexible.
> > > > That way it would support more unusual developer requirements (such as
> > > > mine).
> > > > If the plugin definitions did not contain any loader implementation
> > then
> > > > the same definition can be used different ways by different developers.
> > > >
> > > > Currently any existing plugins that I want to use I am making my own
> > copy
> > > > of and modifying to suit my project.
> > > > I found this annoying and produced my suggestion based on that
> > experience.
> > > >
> > > > I suppose it is as much for developer simplicity as anything else.
> > > > A format that supported different use cases would be better for me!
> > > > It would also mean that the cordova team could more easily change the
> > > > javascript plugin loader in future without breaking existing plugins.
> > > >
> > > > I hadn't thought about dynamically loading the native side of plugins.
> > > > I was just assuming that would always be loaded.
> > > >
> > > >
> > > > > From: agri...@chromium.org
> > > > > Date: Fri, 21 Jun 2013 09:12:42 -0400
> > > > > Subject: Re: Suggestion - pluginLoader
> > > > > To: dev@cordova.apache.org
> > > > >
> > > > > Hi Jonathan,
> > > > >
> > > > > First, thanks for a well-written proposal. At least for me, I'm not
> > > > really
> > > > > sure that there is enough of a problem with the current approach that
> > > > would
> > > > > justify changing it. That said, business is always an issue, and
> > bumping
> > > > > your thread was the right thing to do :)
> > > > >
> > > > > For Android and iOS, the large majority of plugins require native
> > code in
> > > > > order to be useful, so I don't think that having plugin JS be
> > dynamically
> > > > > seems that useful without being able to dynamically load the native
> > parts
> > > > > of it.
> > > > >
> > > > > You said that you're serving your app via HTTP. I think your best bet
> > > > would
> > > > > be to concat all of your plugin JS together would be by far your
> > biggest
> > > > > performance boost rather than try to selectively load them.
> > > > >
> > > > > Until very recently, Cordova's module system didn't involve a loader
> > at
> > > > > all, and required that all modules be defined ahead of time. Now, we
> > > > > actually do load plugin .js files during start-up, but still not
> > > > on-demand.
> > > > > So, in my mind we really have two things:
> > > > > 1. A registry
> > > > > 2. A boot-up process.
> > > > >
> > > > > To be clear - is it that you want to change the registry part, or is
> > it
> > > > > just that you want to have plugin .js loaded on-demand? Are you
> > concerned
> > > > > about the native side of the plugins?
> > > > >
> > >

Re: Suggestion - pluginLoader

[Andrew Grieve]

aha, so previously we didn't help plugins along at all.

With plugman-compatible plugins, we do define a way for plugin JS to be
loaded: you add a  tag to your plugin.xml and then plugman will
wrap your file in a cordova.define().

Spec: https://github.com/apache/cordova-plugman/blob/master/plugin_spec.md

You can also specify a  tag in  which just causes your
.js file to be executed after cordova.js is parsed.

I think with this, you could layer on another module loading system if you
wanted something outside of the cordova.define() system.

Does that make sense?




On Fri, Jun 21, 2013 at 10:41 AM, J Prince wrote:

> Perhaps my terminology is wrong but ALL plugins define how they are loaded.
>
> Either (old style) window.plugins = ...
> or (new style) cordova.define(...
>
> My fundamental point is they shouldn't. I don't want my plugins loaded in
> either of these ways. The loading of plugins should be separate to the
> plugin definition.
> Hence my suggestion of;
>
> cordova.pluginLoader(...)
>
> In this pattern pluginLoader could either have multiple different modes or
> developers could override it (or both).
> At the moment I am having to change each plugin to not define its loading
> implementation.
>
>
> > From: agri...@chromium.org
> > Date: Fri, 21 Jun 2013 10:22:35 -0400
> > Subject: Re: Suggestion - pluginLoader
> > To: dev@cordova.apache.org
> >
> > For your actual app, you're free to use any JS loader that you'd like.
> >
> > Are there really many existing Cordova plugins that use alternate module
> > package definitions?
> >
> >
> > On Fri, Jun 21, 2013 at 9:39 AM, J Prince  >wrote:
> >
> > > Hi Andrew,
> > >
> > > My main point was to make the actual plugin javascript definitions more
> > > flexible.
> > > That way it would support more unusual developer requirements (such as
> > > mine).
> > > If the plugin definitions did not contain any loader implementation
> then
> > > the same definition can be used different ways by different developers.
> > >
> > > Currently any existing plugins that I want to use I am making my own
> copy
> > > of and modifying to suit my project.
> > > I found this annoying and produced my suggestion based on that
> experience.
> > >
> > > I suppose it is as much for developer simplicity as anything else.
> > > A format that supported different use cases would be better for me!
> > > It would also mean that the cordova team could more easily change the
> > > javascript plugin loader in future without breaking existing plugins.
> > >
> > > I hadn't thought about dynamically loading the native side of plugins.
> > > I was just assuming that would always be loaded.
> > >
> > >
> > > > From: agri...@chromium.org
> > > > Date: Fri, 21 Jun 2013 09:12:42 -0400
> > > > Subject: Re: Suggestion - pluginLoader
> > > > To: dev@cordova.apache.org
> > > >
> > > > Hi Jonathan,
> > > >
> > > > First, thanks for a well-written proposal. At least for me, I'm not
> > > really
> > > > sure that there is enough of a problem with the current approach that
> > > would
> > > > justify changing it. That said, business is always an issue, and
> bumping
> > > > your thread was the right thing to do :)
> > > >
> > > > For Android and iOS, the large majority of plugins require native
> code in
> > > > order to be useful, so I don't think that having plugin JS be
> dynamically
> > > > seems that useful without being able to dynamically load the native
> parts
> > > > of it.
> > > >
> > > > You said that you're serving your app via HTTP. I think your best bet
> > > would
> > > > be to concat all of your plugin JS together would be by far your
> biggest
> > > > performance boost rather than try to selectively load them.
> > > >
> > > > Until very recently, Cordova's module system didn't involve a loader
> at
> > > > all, and required that all modules be defined ahead of time. Now, we
> > > > actually do load plugin .js files during start-up, but still not
> > > on-demand.
> > > > So, in my mind we really have two things:
> > > > 1. A registry
> > > > 2. A boot-up process.
> > > >
> > > > To be clear - is it that you want to change the registry part, or is
> it
> > > > just that you want to have plugin .js loaded on-demand? Are you
> concerned
> > > > about the native side of the plugins?
> > > >
> > > > One thing I think maybe we should add is the ability to disable the
> > > > start-up plugin_loader.js logic for when people want to package the
> .js
> > > > themselves.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Fri, Jun 21, 2013 at 8:30 AM, J Prince <
> princej.w...@hotmail.co.uk
> > > >wrote:
> > > >
> > > > > So it's been about a week now and I haven't really had any
> feedback on
> > > > > this.
> > > > > https://github.com/jxp/cordova.pluginLoader
> > > > >  I'm not sure if this means;
> > > > >
> > > > > a) Everyone is too busy
> > > > > b) Everyone assumed someone else would respond
> > > > > c) No-one is that interested in plugin javascript definitions
> > > > > d) You've had si

Re: Cordova Blog

[Carlos Santana]

This is great idea.

I don't mind the same content in both places. (PhoneGap and Cordova)
Phonegap is spelled Cordova anyway :-)


Some of the blog posts in PhoneGap point to personal blogs.
I would thin that the Cordova Blog will do the same have blogs hosted on
its site or point to personal blog posts.

What about having Pages (i.e. WordPress) on the Cordova Blog in addition of
Posts?
Ideas for Pages:
- Release Notes
- Roadmap/Timeline
- Videos
- Tutorials
- List 3rd Party Plugins

Here is another one, if Blog (i.e. WordPress) is created why not host the
whole site (cordova.io) with WordPress (Posts and Pages) and move away from
Ruby for the website :-). If not then you will be maintaining two sites
with two different technologies.

--Carlos

On Thu, Jun 20, 2013 at 10:19 PM, Joe Bowser  wrote:

> Currently, PhoneGap aggregates the blog posts of many committers at
> phonegap.com/blog.  The downside of this is that it's an Adobe blog,
> and it's not Apache Cordova.  Apache Cordova should probably have its
> own blog, but I see a lot of the same content being in two different
> places.
>
> If someone wants to take this on, that'd be awesome.
>
> On Thu, Jun 20, 2013 at 7:12 PM, Andrew Grieve 
> wrote:
> > I brought it up in a separate thread (
> > http://callback.markmail.org/thread/y44pmva6gfm257sl) but probably
> deserves
> > its own.
> >
> > I'd like to create a Blog for Cordova and make all Committers able to
> post
> > to it. We could use it to:
> > - Post release announcements & release notes
> > - Draw attention to deprecations and upgrade guides
> > - Deep dive into significant improvements / changes
> >
> > Mainly, I think having a blog for the project will be really help by
> > providing an authoritative source for Cordova blob posts (as opposed to
> on
> > our personal blogs, which I appreciate, but which I feel are lacking
> > authority).
> >
> > I'm quite inexperienced at blogging, so everyone agrees we should go
> ahead
> > with this, it'd be good if someone more blog-savvy would own setting it
> up.
>



-- 
Carlos Santana

Re: Review Request: Fixing exec bug.

[Jeffrey Willms]

> On June 21, 2013, 2:33 a.m., Andrew Grieve wrote:
> > framework/src/org/apache/cordova/api/PluginManager.java, line 226
> > 
> >
> > These params don't need to be final.

Isn't it better to make them final unless there is a need to modify them?


> On June 21, 2013, 2:33 a.m., Andrew Grieve wrote:
> > framework/src/org/apache/cordova/api/PluginManager.java, line 434
> > 
> >
> > I realized tonight that a boolean here isn't enough. 
> > Consider this case:
> > 
> > 1. set runExecOnUiThread = true
> > 2. runExecOnUiThread=false Runnable queued.
> > 3. Exec call "foo" gets made, Runnable queued.
> > 4. runExecOnUiThread=false runs
> > 5. Exec call "bar" gets made, executes right away
> > 6. Exec call "foo" Runnable is run
> > 
> > We don't want to ever execute calls out-of-order. "bar" shouldn't get 
> > run before "foo".
> > 
> > I think to fix this, we can use an AtomicInteger. Increment it every 
> > time an exec is queued, decrement it each time an exec finishes. Turn off 
> > runExecOnUiThread only once the count reaches 0.
> > 
> > make sense?
> > 
> >

If an app is making execs too fast couldn't it cause every exec to be run the 
UI thread and never switch to using the WebCore thread? Is it possible to leave 
runExecOnUiThread getting set like it currently is, use your AtomicInteger idea 
to track the number of pending execs on the UI thread and then make WebCore 
execs block until this value is 0. We would have to make sure that if multiple 
WebCore execs get blocked, when they get unblocked they get execute in the same 
order that they came in.


- Jeffrey


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


On June 20, 2013, 8:16 p.m., Jeffrey Willms wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12013/
> ---
> 
> (Updated June 20, 2013, 8:16 p.m.)
> 
> 
> Review request for cordova and Andrew Grieve.
> 
> 
> Description
> ---
> 
> Fixing exec bug.
> 
> 
> This addresses bug CB-3927.
> https://issues.apache.org/jira/browse/CB-3927
> 
> 
> Diffs
> -
> 
>   framework/src/org/apache/cordova/api/PluginEntry.java 
> 9b9af6bc303965e7263bca75037256da81868fb2 
>   framework/src/org/apache/cordova/api/PluginManager.java 
> 71fc25817b5d58bb2fbf5a29158ef2c7d424d4ab 
> 
> Diff: https://reviews.apache.org/r/12013/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jeffrey Willms
> 
>

RE: Opinions Needed: Platform specific features and mobilespec tests

[Li, Jonathan]

Probably call the test failure for the unimplemented feature as "Unimplemented 
Failure", and show in jasmine using a different color. Those failure are like a 
warning, and means the feature is expected to be supported by the platform, but 
is just not yet implemented. 

"Expected failure" is little confusing, as if when "expected failure" happens, 
it means a success test case.

Jonathan

-Original Message-
From: Ian Clelland [mailto:iclell...@google.com] 
Sent: Friday, June 21, 2013 8:35 AM
To: dev@cordova.apache.org
Subject: Re: Opinions Needed: Platform specific features and mobilespec tests

For tests like this, I'd like to see something in Jasmine that is akin to
the "Expected Failure" result in JUinit / python unittest.

It means that we still run all of the tests, but a failure on a device that
doesn't support the feature doesn't cause the whole test suite to turn red.

On the other hand, if a test which is expected to fail actually succeeds,
that is reported as "unexpected success" in the test output. We can then go
and look at what has changed -- either the test is broken, or the issue was
actually resolved.

I don't think it's available as an idiom in Jasmine, but it's just
JavaScript; it shouldn't be too hard to implement.

Ian

> On 13-06-20 9:06 AM, "Andrew Grieve"  wrote:

> >
> > Definitely torn on this one. On one hand, if there are features
> > implemented
> > on some platforms that should be implemented on others than having them
> > fail is a constant reminder that your platform needs to implement the
> > missing functionality. OTOH, things like camera clean-up are meant to be
> > platform specific, so it's nothing but an annoyance if that fails on
> other
> > platforms.
> >
> > So, I think my take on it is:
> >
> > 1. Have them shared and failing if the API should eventually be
> > implemented
> > on all platforms
> > 2. Wrap tests in if (platform.name == 'ios') {} if they are meant to
> only
> > work on one platform.
> >
> >
> >
> >
> >
> >
> > On Thu, Jun 20, 2013 at 8:44 AM, Lisa Seacat DeLuca
> > wrote:
> >
> >> One issue I ran with respects to the mobile spec is some tests are only
> >> applicable to certain device types.  We have a couple options when it
> >> comes to those types of tests:
> >>
> >> 1. Not include them in the automated tests
> >> 2. Include them knowing that they *might* cause failures with certain
> >> device types (see example)
> >> 3. Add javascript logic to check for device type before performing the
> >> tests
> >> 4. OR we could create platform specific automated tests that should be
> >> ran
> >> in addition to the base automated test per device. ex. automatedAndroid,
> >> automatedIOS, etc.
> >>
> >> An example is:
> >> https://issues.apache.org/jira/browse/CB-3484
> >> camera.cleanup is only supported on iOS.
> >>
> >> I added a test case to verify that the function existed.  But it doesn't
> >> actually run camera.cleanup so there are no failure on other platforms.
> >> So
> >> really there shouldn't be any harm in keeping the test.
> >>
> >>
> >> What are everyone's opinions on a good approach to handle this type of
> >> situation?
> >>
> >> Lisa Seacat DeLuca
>
>
> -
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute
> non-public information. Any use of this information by anyone other
> than the intended recipient is prohibited. If you have received this
> transmission in error, please immediately reply to the sender and
> delete this information from your system. Use, dissemination,
> distribution, or reproduction of this transmission by unintended
> recipients is not authorized and may be unlawful.
>

RE: Suggestion - pluginLoader

[J Prince]

Perhaps my terminology is wrong but ALL plugins define how they are loaded.

Either (old style) window.plugins = ...
or (new style) cordova.define(...

My fundamental point is they shouldn't. I don't want my plugins loaded in 
either of these ways. The loading of plugins should be separate to the plugin 
definition.
Hence my suggestion of;

cordova.pluginLoader(...)

In this pattern pluginLoader could either have multiple different modes or 
developers could override it (or both).
At the moment I am having to change each plugin to not define its loading 
implementation.


> From: agri...@chromium.org
> Date: Fri, 21 Jun 2013 10:22:35 -0400
> Subject: Re: Suggestion - pluginLoader
> To: dev@cordova.apache.org
> 
> For your actual app, you're free to use any JS loader that you'd like.
> 
> Are there really many existing Cordova plugins that use alternate module
> package definitions?
> 
> 
> On Fri, Jun 21, 2013 at 9:39 AM, J Prince wrote:
> 
> > Hi Andrew,
> >
> > My main point was to make the actual plugin javascript definitions more
> > flexible.
> > That way it would support more unusual developer requirements (such as
> > mine).
> > If the plugin definitions did not contain any loader implementation then
> > the same definition can be used different ways by different developers.
> >
> > Currently any existing plugins that I want to use I am making my own copy
> > of and modifying to suit my project.
> > I found this annoying and produced my suggestion based on that experience.
> >
> > I suppose it is as much for developer simplicity as anything else.
> > A format that supported different use cases would be better for me!
> > It would also mean that the cordova team could more easily change the
> > javascript plugin loader in future without breaking existing plugins.
> >
> > I hadn't thought about dynamically loading the native side of plugins.
> > I was just assuming that would always be loaded.
> >
> >
> > > From: agri...@chromium.org
> > > Date: Fri, 21 Jun 2013 09:12:42 -0400
> > > Subject: Re: Suggestion - pluginLoader
> > > To: dev@cordova.apache.org
> > >
> > > Hi Jonathan,
> > >
> > > First, thanks for a well-written proposal. At least for me, I'm not
> > really
> > > sure that there is enough of a problem with the current approach that
> > would
> > > justify changing it. That said, business is always an issue, and bumping
> > > your thread was the right thing to do :)
> > >
> > > For Android and iOS, the large majority of plugins require native code in
> > > order to be useful, so I don't think that having plugin JS be dynamically
> > > seems that useful without being able to dynamically load the native parts
> > > of it.
> > >
> > > You said that you're serving your app via HTTP. I think your best bet
> > would
> > > be to concat all of your plugin JS together would be by far your biggest
> > > performance boost rather than try to selectively load them.
> > >
> > > Until very recently, Cordova's module system didn't involve a loader at
> > > all, and required that all modules be defined ahead of time. Now, we
> > > actually do load plugin .js files during start-up, but still not
> > on-demand.
> > > So, in my mind we really have two things:
> > > 1. A registry
> > > 2. A boot-up process.
> > >
> > > To be clear - is it that you want to change the registry part, or is it
> > > just that you want to have plugin .js loaded on-demand? Are you concerned
> > > about the native side of the plugins?
> > >
> > > One thing I think maybe we should add is the ability to disable the
> > > start-up plugin_loader.js logic for when people want to package the .js
> > > themselves.
> > >
> > >
> > >
> > >
> > >
> > > On Fri, Jun 21, 2013 at 8:30 AM, J Prince  > >wrote:
> > >
> > > > So it's been about a week now and I haven't really had any feedback on
> > > > this.
> > > > https://github.com/jxp/cordova.pluginLoader
> > > >  I'm not sure if this means;
> > > >
> > > > a) Everyone is too busy
> > > > b) Everyone assumed someone else would respond
> > > > c) No-one is that interested in plugin javascript definitions
> > > > d) You've had similar discussions before and don't want to start THAT
> > again
> > > >
> > > >
> > > > > From: princej.w...@hotmail.co.uk
> > > > > To: dev@cordova.apache.org
> > > > > Subject: RE: Suggestion - pluginLoader
> > > > > Date: Tue, 18 Jun 2013 16:55:19 +0100
> > > > >
> > > > > I have (briefly) looked at Harmony loaders before but that is a spec
> > for
> > > > a future javascript language version.
> > > > > I have found a module loader that I wish to use (require.js).
> > > > >
> > > > > My point is that the current suggested module definition for cordova
> > > > plugins INCLUDES a loader implementation.
> > > > >
> > > > > I am suggesting that the loader implementation be removed from the
> > > > plugin to a new method cordova.pluginLoader
> > > > > This would make the plugins cleaner (as they would only describe
> > their
> > > > own behaviour) and it would also allow cordova

Re: Jake woes

[Andrew Grieve]

Okay, CB-3960 is the tracker.


On Fri, Jun 21, 2013 at 9:57 AM, Jeffrey Heifetz wrote:

> +1
>
> Sent from my BlackBerry 10 smartphone on the Rogers network.
> From: Bryan Higgins
> Sent: Friday, June 21, 2013 9:39 AM
> To: dev@cordova.apache.org
> Reply To: dev@cordova.apache.org
> Subject: Re: Jake woes
>
>
> +1
>
>
> On Fri, Jun 21, 2013 at 7:11 AM, Lucas Holmquist  >wrote:
>
> > +1
> > On Jun 20, 2013, at 11:20 PM, Steven Gill 
> wrote:
> >
> > > +1 Grunt
> > >
> > >
> > > On Thu, Jun 20, 2013 at 7:15 PM, Andrew Grieve 
> > wrote:
> > >
> > >> I've burned quite a bit of time trying to get it to work, and I'm a
> bit
> > >> realizing that it's probably not worth continuing. By fiddling with
> > >> dependencies I can get it to run, but tasks are being run multiple
> times
> > >> when they shouldn't be, and there's no reason I should need to fiddle
> > the
> > >> deps to get it to run.
> > >>
> > >> So... any objections if I delete Jakefile and replace it with
> > >> a Gruntfile.js?
> > >>
> >
> >
>
> -
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from
> your system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be unlawful.
>

Re: Suggestion - pluginLoader

[Andrew Grieve]

For your actual app, you're free to use any JS loader that you'd like.

Are there really many existing Cordova plugins that use alternate module
package definitions?


On Fri, Jun 21, 2013 at 9:39 AM, J Prince wrote:

> Hi Andrew,
>
> My main point was to make the actual plugin javascript definitions more
> flexible.
> That way it would support more unusual developer requirements (such as
> mine).
> If the plugin definitions did not contain any loader implementation then
> the same definition can be used different ways by different developers.
>
> Currently any existing plugins that I want to use I am making my own copy
> of and modifying to suit my project.
> I found this annoying and produced my suggestion based on that experience.
>
> I suppose it is as much for developer simplicity as anything else.
> A format that supported different use cases would be better for me!
> It would also mean that the cordova team could more easily change the
> javascript plugin loader in future without breaking existing plugins.
>
> I hadn't thought about dynamically loading the native side of plugins.
> I was just assuming that would always be loaded.
>
>
> > From: agri...@chromium.org
> > Date: Fri, 21 Jun 2013 09:12:42 -0400
> > Subject: Re: Suggestion - pluginLoader
> > To: dev@cordova.apache.org
> >
> > Hi Jonathan,
> >
> > First, thanks for a well-written proposal. At least for me, I'm not
> really
> > sure that there is enough of a problem with the current approach that
> would
> > justify changing it. That said, business is always an issue, and bumping
> > your thread was the right thing to do :)
> >
> > For Android and iOS, the large majority of plugins require native code in
> > order to be useful, so I don't think that having plugin JS be dynamically
> > seems that useful without being able to dynamically load the native parts
> > of it.
> >
> > You said that you're serving your app via HTTP. I think your best bet
> would
> > be to concat all of your plugin JS together would be by far your biggest
> > performance boost rather than try to selectively load them.
> >
> > Until very recently, Cordova's module system didn't involve a loader at
> > all, and required that all modules be defined ahead of time. Now, we
> > actually do load plugin .js files during start-up, but still not
> on-demand.
> > So, in my mind we really have two things:
> > 1. A registry
> > 2. A boot-up process.
> >
> > To be clear - is it that you want to change the registry part, or is it
> > just that you want to have plugin .js loaded on-demand? Are you concerned
> > about the native side of the plugins?
> >
> > One thing I think maybe we should add is the ability to disable the
> > start-up plugin_loader.js logic for when people want to package the .js
> > themselves.
> >
> >
> >
> >
> >
> > On Fri, Jun 21, 2013 at 8:30 AM, J Prince  >wrote:
> >
> > > So it's been about a week now and I haven't really had any feedback on
> > > this.
> > > https://github.com/jxp/cordova.pluginLoader
> > >  I'm not sure if this means;
> > >
> > > a) Everyone is too busy
> > > b) Everyone assumed someone else would respond
> > > c) No-one is that interested in plugin javascript definitions
> > > d) You've had similar discussions before and don't want to start THAT
> again
> > >
> > >
> > > > From: princej.w...@hotmail.co.uk
> > > > To: dev@cordova.apache.org
> > > > Subject: RE: Suggestion - pluginLoader
> > > > Date: Tue, 18 Jun 2013 16:55:19 +0100
> > > >
> > > > I have (briefly) looked at Harmony loaders before but that is a spec
> for
> > > a future javascript language version.
> > > > I have found a module loader that I wish to use (require.js).
> > > >
> > > > My point is that the current suggested module definition for cordova
> > > plugins INCLUDES a loader implementation.
> > > >
> > > > I am suggesting that the loader implementation be removed from the
> > > plugin to a new method cordova.pluginLoader
> > > > This would make the plugins cleaner (as they would only describe
> their
> > > own behaviour) and it would also allow cordova or app developers to
> > > change/customize the loader implementation as needed.
> > > >
> > > > My suggested approach would result in plugins that could be loaded in
> > > multiple different ways including (but not limited to); "classic"
> > > window.plugins, cordova.define and require.js
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: J Prince [mailto:princej.w...@hotmail.co.uk]
> > > > > Sent: Monday, June 17, 2013 7:27 AM
> > > > > To: dev@cordova.apache.org
> > > > > Subject: RE: Suggestion - pluginLoader
> > > > >
> > > > > There are a few main reasons.
> > > > >
> > > > > 1. The app I am working on is an Enterprise app. We are designing
> the
> > > app as a Cordova shell that re-directs to all the html content. This
> means
> > > that we have to dynamically load a different cordova.js (depending on
> > > platform) following the redirect.
> > > > > So we are actually unable to do anything other

Re: Jake woes

[Jeffrey Heifetz]

+1

Sent from my BlackBerry 10 smartphone on the Rogers network.
From: Bryan Higgins
Sent: Friday, June 21, 2013 9:39 AM
To: dev@cordova.apache.org
Reply To: dev@cordova.apache.org
Subject: Re: Jake woes


+1


On Fri, Jun 21, 2013 at 7:11 AM, Lucas Holmquist wrote:

> +1
> On Jun 20, 2013, at 11:20 PM, Steven Gill  wrote:
>
> > +1 Grunt
> >
> >
> > On Thu, Jun 20, 2013 at 7:15 PM, Andrew Grieve 
> wrote:
> >
> >> I've burned quite a bit of time trying to get it to work, and I'm a bit
> >> realizing that it's probably not worth continuing. By fiddling with
> >> dependencies I can get it to run, but tasks are being run multiple times
> >> when they shouldn't be, and there's no reason I should need to fiddle
> the
> >> deps to get it to run.
> >>
> >> So... any objections if I delete Jakefile and replace it with
> >> a Gruntfile.js?
> >>
>
>

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

RE: Suggestion - pluginLoader

[J Prince]

Hi Andrew,

My main point was to make the actual plugin javascript definitions more 
flexible.
That way it would support more unusual developer requirements (such as mine).
If the plugin definitions did not contain any loader implementation then the 
same definition can be used different ways by different developers.

Currently any existing plugins that I want to use I am making my own copy of 
and modifying to suit my project.
I found this annoying and produced my suggestion based on that experience.

I suppose it is as much for developer simplicity as anything else.
A format that supported different use cases would be better for me!
It would also mean that the cordova team could more easily change the 
javascript plugin loader in future without breaking existing plugins.

I hadn't thought about dynamically loading the native side of plugins. 
I was just assuming that would always be loaded.


> From: agri...@chromium.org
> Date: Fri, 21 Jun 2013 09:12:42 -0400
> Subject: Re: Suggestion - pluginLoader
> To: dev@cordova.apache.org
> 
> Hi Jonathan,
> 
> First, thanks for a well-written proposal. At least for me, I'm not really
> sure that there is enough of a problem with the current approach that would
> justify changing it. That said, business is always an issue, and bumping
> your thread was the right thing to do :)
> 
> For Android and iOS, the large majority of plugins require native code in
> order to be useful, so I don't think that having plugin JS be dynamically
> seems that useful without being able to dynamically load the native parts
> of it.
> 
> You said that you're serving your app via HTTP. I think your best bet would
> be to concat all of your plugin JS together would be by far your biggest
> performance boost rather than try to selectively load them.
> 
> Until very recently, Cordova's module system didn't involve a loader at
> all, and required that all modules be defined ahead of time. Now, we
> actually do load plugin .js files during start-up, but still not on-demand.
> So, in my mind we really have two things:
> 1. A registry
> 2. A boot-up process.
> 
> To be clear - is it that you want to change the registry part, or is it
> just that you want to have plugin .js loaded on-demand? Are you concerned
> about the native side of the plugins?
> 
> One thing I think maybe we should add is the ability to disable the
> start-up plugin_loader.js logic for when people want to package the .js
> themselves.
> 
> 
> 
> 
> 
> On Fri, Jun 21, 2013 at 8:30 AM, J Prince wrote:
> 
> > So it's been about a week now and I haven't really had any feedback on
> > this.
> > https://github.com/jxp/cordova.pluginLoader
> >  I'm not sure if this means;
> >
> > a) Everyone is too busy
> > b) Everyone assumed someone else would respond
> > c) No-one is that interested in plugin javascript definitions
> > d) You've had similar discussions before and don't want to start THAT again
> >
> >
> > > From: princej.w...@hotmail.co.uk
> > > To: dev@cordova.apache.org
> > > Subject: RE: Suggestion - pluginLoader
> > > Date: Tue, 18 Jun 2013 16:55:19 +0100
> > >
> > > I have (briefly) looked at Harmony loaders before but that is a spec for
> > a future javascript language version.
> > > I have found a module loader that I wish to use (require.js).
> > >
> > > My point is that the current suggested module definition for cordova
> > plugins INCLUDES a loader implementation.
> > >
> > > I am suggesting that the loader implementation be removed from the
> > plugin to a new method cordova.pluginLoader
> > > This would make the plugins cleaner (as they would only describe their
> > own behaviour) and it would also allow cordova or app developers to
> > change/customize the loader implementation as needed.
> > >
> > > My suggested approach would result in plugins that could be loaded in
> > multiple different ways including (but not limited to); "classic"
> > window.plugins, cordova.define and require.js
> > >
> > >
> > > > -Original Message-
> > > > From: J Prince [mailto:princej.w...@hotmail.co.uk]
> > > > Sent: Monday, June 17, 2013 7:27 AM
> > > > To: dev@cordova.apache.org
> > > > Subject: RE: Suggestion - pluginLoader
> > > >
> > > > There are a few main reasons.
> > > >
> > > > 1. The app I am working on is an Enterprise app. We are designing the
> > app as a Cordova shell that re-directs to all the html content. This means
> > that we have to dynamically load a different cordova.js (depending on
> > platform) following the redirect.
> > > > So we are actually unable to do anything other than dynamically load
> > plugins once the platform specific cordova.js is loaded
> > > >
> > > > 2. Some of the plugins will be used incredibly rarely. It doesn't seem
> > necessary to always load plugins until they are needed.
> > > >
> > > > 3. We are building with a single page architecture so don't want to
> > end up with lots of script includes in the index.html page.
> > > > The define/require pattern feels much cleaner and 

Re: Jake woes

[Bryan Higgins]

+1


On Fri, Jun 21, 2013 at 7:11 AM, Lucas Holmquist wrote:

> +1
> On Jun 20, 2013, at 11:20 PM, Steven Gill  wrote:
>
> > +1 Grunt
> >
> >
> > On Thu, Jun 20, 2013 at 7:15 PM, Andrew Grieve 
> wrote:
> >
> >> I've burned quite a bit of time trying to get it to work, and I'm a bit
> >> realizing that it's probably not worth continuing. By fiddling with
> >> dependencies I can get it to run, but tasks are being run multiple times
> >> when they shouldn't be, and there's no reason I should need to fiddle
> the
> >> deps to get it to run.
> >>
> >> So... any objections if I delete Jakefile and replace it with
> >> a Gruntfile.js?
> >>
>
>

Re: Suggestion - pluginLoader

[Andrew Grieve]

Hi Jonathan,

First, thanks for a well-written proposal. At least for me, I'm not really
sure that there is enough of a problem with the current approach that would
justify changing it. That said, business is always an issue, and bumping
your thread was the right thing to do :)

For Android and iOS, the large majority of plugins require native code in
order to be useful, so I don't think that having plugin JS be dynamically
seems that useful without being able to dynamically load the native parts
of it.

You said that you're serving your app via HTTP. I think your best bet would
be to concat all of your plugin JS together would be by far your biggest
performance boost rather than try to selectively load them.

Until very recently, Cordova's module system didn't involve a loader at
all, and required that all modules be defined ahead of time. Now, we
actually do load plugin .js files during start-up, but still not on-demand.
So, in my mind we really have two things:
1. A registry
2. A boot-up process.

To be clear - is it that you want to change the registry part, or is it
just that you want to have plugin .js loaded on-demand? Are you concerned
about the native side of the plugins?

One thing I think maybe we should add is the ability to disable the
start-up plugin_loader.js logic for when people want to package the .js
themselves.





On Fri, Jun 21, 2013 at 8:30 AM, J Prince wrote:

> So it's been about a week now and I haven't really had any feedback on
> this.
> https://github.com/jxp/cordova.pluginLoader
>  I'm not sure if this means;
>
> a) Everyone is too busy
> b) Everyone assumed someone else would respond
> c) No-one is that interested in plugin javascript definitions
> d) You've had similar discussions before and don't want to start THAT again
>
>
> > From: princej.w...@hotmail.co.uk
> > To: dev@cordova.apache.org
> > Subject: RE: Suggestion - pluginLoader
> > Date: Tue, 18 Jun 2013 16:55:19 +0100
> >
> > I have (briefly) looked at Harmony loaders before but that is a spec for
> a future javascript language version.
> > I have found a module loader that I wish to use (require.js).
> >
> > My point is that the current suggested module definition for cordova
> plugins INCLUDES a loader implementation.
> >
> > I am suggesting that the loader implementation be removed from the
> plugin to a new method cordova.pluginLoader
> > This would make the plugins cleaner (as they would only describe their
> own behaviour) and it would also allow cordova or app developers to
> change/customize the loader implementation as needed.
> >
> > My suggested approach would result in plugins that could be loaded in
> multiple different ways including (but not limited to); "classic"
> window.plugins, cordova.define and require.js
> >
> >
> > > -Original Message-
> > > From: J Prince [mailto:princej.w...@hotmail.co.uk]
> > > Sent: Monday, June 17, 2013 7:27 AM
> > > To: dev@cordova.apache.org
> > > Subject: RE: Suggestion - pluginLoader
> > >
> > > There are a few main reasons.
> > >
> > > 1. The app I am working on is an Enterprise app. We are designing the
> app as a Cordova shell that re-directs to all the html content. This means
> that we have to dynamically load a different cordova.js (depending on
> platform) following the redirect.
> > > So we are actually unable to do anything other than dynamically load
> plugins once the platform specific cordova.js is loaded
> > >
> > > 2. Some of the plugins will be used incredibly rarely. It doesn't seem
> necessary to always load plugins until they are needed.
> > >
> > > 3. We are building with a single page architecture so don't want to
> end up with lots of script includes in the index.html page.
> > > The define/require pattern feels much cleaner and better
> compartmentalized.
> > > Our main page currently has 2 script includes: require.js and jqmobi.
> > >
> > >
> > >
> >
>
>

Re: cordova-ios/iphone/beep.wav

[Ian Clelland]

That was an accidental commit, if it's ended up in cordova-ios.

The file was previously in version control; I went back through the git
repo history to find and restore it for cordova-mobile-spec, since iOS
devices require it for the notification tests.

I didn't expect that there would be a licensing issue with the file, but if
so, we should replace the version in mobile-spec.



On Wed, Jun 19, 2013 at 4:10 PM, Shazron  wrote:

> Looking at the issue, I don't think it needed a beep.wav, which makes me
> think this was accidentally checked in
>
>
> On Wed, Jun 19, 2013 at 4:00 PM, Jesse  wrote:
>
>> If you need a wav file for the beep, I have composed a CC licensed  file
>> here:
>>
>> https://git-wip-us.apache.org/repos/asf?p=cordova-wp8.git;a=tree;f=common/resources;h=a9558f417570ee1793d34be30b81291750597153;hb=HEAD
>>
>>
>> @purplecabbage
>> risingj.com
>>
>>
>> On Wed, Jun 19, 2013 at 3:30 PM, Shazron  wrote:
>>
>> > Ian, was this file supposed to be checked in?
>> > https://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;h=4c63589
>> >
>> > https://issues.apache.org/jira/browse/CB-2840
>> >
>> > Ran Apache RAT and noticed that one.
>> >
>>
>
>

Re: Opinions Needed: Platform specific features and mobilespec tests

[Ian Clelland]

For tests like this, I'd like to see something in Jasmine that is akin to
the "Expected Failure" result in JUinit / python unittest.

It means that we still run all of the tests, but a failure on a device that
doesn't support the feature doesn't cause the whole test suite to turn red.

On the other hand, if a test which is expected to fail actually succeeds,
that is reported as "unexpected success" in the test output. We can then go
and look at what has changed -- either the test is broken, or the issue was
actually resolved.

I don't think it's available as an idiom in Jasmine, but it's just
JavaScript; it shouldn't be too hard to implement.

Ian

> On 13-06-20 9:06 AM, "Andrew Grieve"  wrote:

> >
> > Definitely torn on this one. On one hand, if there are features
> > implemented
> > on some platforms that should be implemented on others than having them
> > fail is a constant reminder that your platform needs to implement the
> > missing functionality. OTOH, things like camera clean-up are meant to be
> > platform specific, so it's nothing but an annoyance if that fails on
> other
> > platforms.
> >
> > So, I think my take on it is:
> >
> > 1. Have them shared and failing if the API should eventually be
> > implemented
> > on all platforms
> > 2. Wrap tests in if (platform.name == 'ios') {} if they are meant to
> only
> > work on one platform.
> >
> >
> >
> >
> >
> >
> > On Thu, Jun 20, 2013 at 8:44 AM, Lisa Seacat DeLuca
> > wrote:
> >
> >> One issue I ran with respects to the mobile spec is some tests are only
> >> applicable to certain device types.  We have a couple options when it
> >> comes to those types of tests:
> >>
> >> 1. Not include them in the automated tests
> >> 2. Include them knowing that they *might* cause failures with certain
> >> device types (see example)
> >> 3. Add javascript logic to check for device type before performing the
> >> tests
> >> 4. OR we could create platform specific automated tests that should be
> >> ran
> >> in addition to the base automated test per device. ex. automatedAndroid,
> >> automatedIOS, etc.
> >>
> >> An example is:
> >> https://issues.apache.org/jira/browse/CB-3484
> >> camera.cleanup is only supported on iOS.
> >>
> >> I added a test case to verify that the function existed.  But it doesn't
> >> actually run camera.cleanup so there are no failure on other platforms.
> >> So
> >> really there shouldn't be any harm in keeping the test.
> >>
> >>
> >> What are everyone's opinions on a good approach to handle this type of
> >> situation?
> >>
> >> Lisa Seacat DeLuca
>
>
> -
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute
> non-public information. Any use of this information by anyone other
> than the intended recipient is prohibited. If you have received this
> transmission in error, please immediately reply to the sender and
> delete this information from your system. Use, dissemination,
> distribution, or reproduction of this transmission by unintended
> recipients is not authorized and may be unlawful.
>

RE: Suggestion - pluginLoader

[J Prince]

So it's been about a week now and I haven't really had any feedback on this.
https://github.com/jxp/cordova.pluginLoader
 I'm not sure if this means;

a) Everyone is too busy
b) Everyone assumed someone else would respond
c) No-one is that interested in plugin javascript definitions
d) You've had similar discussions before and don't want to start THAT again


> From: princej.w...@hotmail.co.uk
> To: dev@cordova.apache.org
> Subject: RE: Suggestion - pluginLoader
> Date: Tue, 18 Jun 2013 16:55:19 +0100
> 
> I have (briefly) looked at Harmony loaders before but that is a spec for a 
> future javascript language version.
> I have found a module loader that I wish to use (require.js).
> 
> My point is that the current suggested module definition for cordova plugins 
> INCLUDES a loader implementation.
> 
> I am suggesting that the loader implementation be removed from the plugin to 
> a new method cordova.pluginLoader
> This would make the plugins cleaner (as they would only describe their own 
> behaviour) and it would also allow cordova or app developers to 
> change/customize the loader implementation as needed.
> 
> My suggested approach would result in plugins that could be loaded in 
> multiple different ways including (but not limited to); "classic" 
> window.plugins, cordova.define and require.js
> 
> 
> > -Original Message-
> > From: J Prince [mailto:princej.w...@hotmail.co.uk] 
> > Sent: Monday, June 17, 2013 7:27 AM
> > To: dev@cordova.apache.org
> > Subject: RE: Suggestion - pluginLoader
> > 
> > There are a few main reasons.
> > 
> > 1. The app I am working on is an Enterprise app. We are designing the app 
> > as a Cordova shell that re-directs to all the html content. This means that 
> > we have to dynamically load a different cordova.js (depending on platform) 
> > following the redirect.
> > So we are actually unable to do anything other than dynamically load 
> > plugins once the platform specific cordova.js is loaded
> > 
> > 2. Some of the plugins will be used incredibly rarely. It doesn't seem 
> > necessary to always load plugins until they are needed.
> > 
> > 3. We are building with a single page architecture so don't want to end up 
> > with lots of script includes in the index.html page. 
> > The define/require pattern feels much cleaner and better compartmentalized.
> > Our main page currently has 2 script includes: require.js and jqmobi.
> > 
> >   
> > 
> 
  

Re: Media API, DataResource, and empty URLs

[Ian Clelland]

On Thu, Jun 20, 2013 at 11:45 AM, Andrew Grieve wrote:

> WebView.getUrl() ?
>
>
Or that, modulo any base tags that we detect?





>
> On Thu, Jun 20, 2013 at 9:49 AM, Braden Shepherdson  >wrote:
>
> > So the current state of handling URLs in DataResource is: if it has a
> > scheme, all good; if it doesn't and is absolute, also good; if it is
> > relative and has no scheme, throw new IllegalArgumentException.
> >
> > I agree that this behavior is dumb and there should be a sane default for
> > relative URLs, and DataResource should rewrite them. The tricky bit is
> what
> > they should be relative to. file:///android_asset/www? The currently
> loaded
> > page in the WebView? Can we reliably check that in the presence of
> > CordovaView and InAppBrowser?
> >
> > Braden
> >
> >
> > On Thu, Jun 20, 2013 at 12:34 AM, Andrew Grieve  > >wrote:
> >
> > > Agree that we should make Media() an error, but we don't want to change
> > the
> > > semantics of relative URLs for APIs without proper deprecation.
> > >
> > >
> > > On Thu, Jun 20, 2013 at 12:00 AM, Ian Clelland 
> > > wrote:
> > >
> > > > On Wed, Jun 19, 2013 at 7:41 PM, Andrew Grieve  >
> > > > wrote:
> > > >
> > > > > "null" could be interpreted as a relative URL I think. The current
> > > > handling
> > > > > of relative URLs by plugins is sadly plugin-specific.
> > > > >
> > > >
> > > > Isn't that one of the things that DataResource is supposed to
> > > standardize?
> > > >
> > > >
> > > > The string "null" is certainly a relative URL, and all plugins should
> > > > interpret that as one. The empty string is a relative url as well.
> (See
> > > the
> > > > 'image src=""' problem). DataResource should probably handle relative
> > > URLs;
> > > > that seems like a deficiency if it can't.
> > > >
> > > > We shouldn't be representing the JavaScript null value as "null", or
> as
> > > "",
> > > > though. I don't think there's any rational reason to support new
> > Media()
> > > as
> > > > a construct. Media is fairly clearly documented as taking two
> required
> > > > parameters, and two optional ones. I don't think Media() makes sense
> --
> > > it
> > > > doesn't give you a useful object. The calls to Media() are likely
> just
> > in
> > > > mobile-spec, and we should clean those up.
> > > >
> > > >
> > > >
> > > >
> > > > >
> > > > > On Wed, Jun 19, 2013 at 4:04 PM, Braden Shepherdson <
> > > bra...@chromium.org
> > > > > >wrote:
> > > > >
> > > > > > The automated tests for Media frequently call new Media() with no
> > > URL,
> > > > > > which sends a null to the "create" action. In the past, this got
> > > turned
> > > > > > into the string "null" in Java, which was handled as a file named
> > > > "null"
> > > > > > that didn't exist, and nothing crashed.
> > > > > >
> > > > > > DataResource is fine with the files not existing, but it's not
> fine
> > > > with
> > > > > > "null" as a filename since it neither has a URL scheme nor is it
> an
> > > > > > absolute path.
> > > > > >
> > > > > > Is there a reason why new Media() should work rather than
> throwing
> > > > > > IllegalArgumentExceptions for trying to read files with relative
> > > paths?
> > > > > > Should I detect and gracefully handle null being given as the
> media
> > > URL
> > > > > in
> > > > > > Javascript? In Java? Should I instead change the mobile-spec
> tests
> > to
> > > > use
> > > > > > "file:///dummy" or similar?
> > > > > >
> > > > > > Braden
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Jake woes

[Lucas Holmquist]

+1
On Jun 20, 2013, at 11:20 PM, Steven Gill  wrote:

> +1 Grunt
> 
> 
> On Thu, Jun 20, 2013 at 7:15 PM, Andrew Grieve  wrote:
> 
>> I've burned quite a bit of time trying to get it to work, and I'm a bit
>> realizing that it's probably not worth continuing. By fiddling with
>> dependencies I can get it to run, but tasks are being run multiple times
>> when they shouldn't be, and there's no reason I should need to fiddle the
>> deps to get it to run.
>> 
>> So... any objections if I delete Jakefile and replace it with
>> a Gruntfile.js?
>>