Re: Review Request 15775: Add --src & --link to "cordova create"

[Josh Soref]

>> What is this, and why don¹t I see it in packages.json?

This was my fault. I hadn't updated locally and thus it wasn't present. When I 
updated, things broke and npm install fixed it.

Mark wrote‎:
> Ok, I agree this is somewhat hacky. Changed it to a simpler if and removed 
> the option to call CLI() without the 'node' and script name elements as the 
> first two elements of inputArgs.
> But now with the CLI() accessing process.argv

Thanks.

> Sorry, this reordering while wasn't absolutely necessary for the additional 
> flags was still a prerequisite and
> I definitely didn't have it planned before hitting some problems with adding 
> the new flags.

There are ways to split up git commits, I know they're somewhat painful, but 
doing it helps everyone who comes later.

> I'll try to separate larger patches into several git commits in the future.
> By the way, on github it's easy to see diffs for different git commits in one 
> pull request,

Yeah. A feature I love.

> but is there a way to individually inspect diffs from different git commits 
> on review board?

Dunno, as is probably clear from above, I'm not a review board user.

Until someone gives me a good reason not to use github.com pull requests, I'll 
continue to use them

> It lumps a patch containing several commits into a single diff when clicking 
> "view diff" and I didn't find a way to look at the commits separately.


> I just realized that for some reason JSHing (that I started experimenting 
> with recently)

Bryan Higgins was playing with one this week too...

> only complained  about comparison with zero but not about comparison with 1 
> or a string.



> Will be glad to hear some style wisdom from experienced JS people.

> Do we have some written style guidelines specifically for Cordova?

The wiki or git (can't remember which) does have some. And they aren't followed 
well.

> If not, are there some popular, well written guides that we could adopt?

Dunno

It's partially a can of worms.

I generally subscribe to "when in Rome"

> This line moved to line 155. We first need to figure out whether the www dir 
> will be a real dir or a symlink.

Yeah, I eventually found it, but my point is that it was lost. Also, could you 
delay the other mkdir's to the later point so that readers see they're related?

I'm not asking for changes here, just trying to understand and underline 
readability...

-
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: Review Request 15775: Add --src & --link to "cordova create"

[Andrew Grieve]

Reviewboard accounts aren't connected to anything sadly. Just like JIRA,
and the Wiki, you need to create a new account.


On Thu, Dec 12, 2013 at 4:59 PM, Josh Soref  wrote:

> Mark wrote:
> >https://reviews.apache.org/r/15775/
> >--link was a boolean before, now it accepts a path, so it's either
> >--src=path or --link=path.
> >Added a check in config_parser to make sure we are looking at an xml file
> >that looks like Cordova config.xml to avoid overwriting some unrelated
> >config.xml when symlinking to www dir.
> >
> >Same diff on github:
> https://github.com/kamrik/cordova-cli/compare/src_www
>
> I can¹t figure out how to use review board (I guess the account isn¹t
> connected to JIRA, is it connected to anything else?)
>
> > [--src|source=] .. use custom www assets instead of the stock
> >cordova hello-world.
>
> Please use ³Cordova² not ³cordova² unless you mean ³./cordova² or some
> other script.
> (I¹m aware that there¹s a line in another file which has the same
> convention, that¹s a bug, which is hopefully being fixed by some other
> pending pull request, but if it¹s in flight, then it will miss yours)
>
> > [--link=]  as above, but symlink the custom www dir
> >instead of copying.
>
>
> Please don¹t use ³as above², it¹s asking for things to break when the next
> person inserts a line into the help file.
>
> +var path = require('path');
> +var optimist; // required in try-catch below to print a nice error
> message if it's not installed.
>
>
> I believe general style would be:
>
> var path = require('path'),
> optimist,
> Š;
>
> +// If no inputArgs given, use preocess.argv but without the
>
>
> Please don¹t introduce spelling errors, not even in comments.
>
> > _ = require('lodash');
>
>
> What is this, and why don¹t I see it in packages.json?
>
>
> MacBook-Pro:docs $ node
> > require('lodash')
> Error: Cannot find module 'lodash'
> at Function.Module._resolveFilename (module.js:338:15)
>
>
>
> +if (inputArgs[0].match('node')) { // On Win first element is full
> path to node.exe
>
>
>
> This is way too hacky.
>
> You¹re reordering a lot of unrelated code. I¹m very uncomfortable with
> mixing rewrites and new features. I¹d personally prefer you split them
> into distinct commits. ‹ It¹s making reviewing the changes here incredibly
> painful.
>
>
> +if((r.tag !== 'widget') || !r.attrib || (r.attrib.xmlns !== xmlns)) {
>
>
> There should probably be a space after `if`Š
>
> -if (contents.length == 0) {
> +if (contents.length === 0) {
>
>
> If this is a style fix, please have it in a style-fix commit instead of
> mixed with a refactor and a feature.
>
>  } else if (contents.length == 1) {
> Also, why didn¹t you change this??
>
>
> -shell.mkdir('-p', www_dir);
>
>
> there¹s probably a good reason for this, but it¹s now so burried that
> there¹s no way I can figure out what it is :(
>
>
> -
> 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: Review Request 15775: Add --src & --link to "cordova create"

[Mark Koudritsky]

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

(Updated Dec. 13, 2013, 2:35 a.m.)


Review request for cordova.


Changes
---

Addressed comments by Josh Soref (on the dev mailing list).


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


Repository: cordova-cli


Description
---

Add --src & --link to "cordova create".

Both --src and --source are accepted.
The path is passed via the lib.www.uri of the configuration object
that is later written to .cordova/config.json.

Cordova will keep going into child www folder(s) of the provided path.


Diffs (updated)
-

  doc/help.txt 3361dd3 
  e2e/create.spec.js 560f82a 
  spec/metadata/android_parser.spec.js 52fc78a 
  spec/metadata/ios_parser.spec.js b56ddce 
  spec/metadata/windows8_parser.spec.js 5117148 
  spec/metadata/wp7_parser.spec.js 6dc0695 
  spec/metadata/wp8_parser.spec.js 8cd1923 
  src/cli.js 2916062 
  src/config_parser.js b6293d8 
  src/create.js 961d787 
  src/metadata/wp8_parser.js 163d56b 

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


Testing
---

npm test;
cordova -d  create TstApp --source=some/www --link
a bunch of other cordova commands in the app


Thanks,

Mark Koudritsky

Re: [proposal] Deprecate WP7 as a target platform

[Jesse]

My blog post is here: http://www.risingj.com/archives/585
Please have a look and make any suggestions before I syndicate ...

Cheers,
  Jesse

@purplecabbage
risingj.com


On Thu, Dec 12, 2013 at 12:38 PM, Jesse  wrote:

> I am considering this to have passed.
>
> Writing up a blog post about it, as well as adding the deprecation notice
> to WP7.
>
> @purplecabbage
> risingj.com
>
>
> On Tue, Nov 19, 2013 at 1:54 PM, Olivier Bloch (MS OPEN TECH) <
> obl...@microsoft.com> wrote:
>
>> +1
>>
>> I think it is ok to deprecate WP7 considering WP developers already have
>> to decide dropping WP7 support for their apps when using WP8 specific
>> features. Also devs can still count on earlier versions of Cordova to
>> deploy their apps to WP7.
>>
>> That will certainly give the great team working on WP support the
>> opportunity to spend more time on WP8. (I can hear Jesse and Sergey
>> cheering from here... :-))
>>
>> ---
>> Olivier Bloch
>> Microsoft Open Technologies, Inc.
>>
>>
>> -Original Message-
>> From: Dick Van den Brink [mailto:d_vandenbr...@outlook.com]
>> Sent: Monday, November 18, 2013 11:48 PM
>> To: dev@cordova.apache.org
>> Subject: RE: [proposal] Deprecate WP7 as a target platform
>>
>> +1
>>
>> Sent from my Windows Phone
>> 
>> From: Michael Brooks
>> Sent: 11/18/2013 23:54
>>
>> To: dev@cordova.apache.org
>> Subject: Re: [proposal] Deprecate WP7 as a target platform
>>
>> +1
>>
>>
>> On Mon, Nov 18, 2013 at 2:12 PM, Brian LeRoux  wrote:
>>
>> > +1
>> >
>> >
>> > On Mon, Nov 18, 2013 at 1:53 PM, RUDD, Brett 
>> wrote:
>> >
>> > > +1
>> > >
>> > >
>> > > -Brett
>> > >
>> > >
>> > > On Mon, Nov 18, 2013 at 1:29 PM, Herm Wong
>> > > > > > >wrote:
>> > >
>> > > > +1
>> > > >
>> > > > > Date: Mon, 18 Nov 2013 13:00:27 -0800
>> > > > > Subject: Re: [proposal] Deprecate WP7 as a target platform
>> > > > > From: lorin.beer@gmail.com
>> > > > > To: dev@cordova.apache.org
>> > > > >
>> > > > > +1
>> > > > >
>> > > > >
>> > > > > On Mon, Nov 18, 2013 at 12:43 PM, Sergey Grebnov (Akvelon) <
>> > > > > v-seg...@microsoft.com> wrote:
>> > > > >
>> > > > > > +1
>> > > > > >
>> > > > > > Some interesting usage statistics:
>> > > > > >
>> > > >
>> > http://blog.adduplex.com/2013/09/adduplex-windows-phone-statistics.htm
>> > l
>> > > > > >
>> > > > > > -Sergey
>> > > > > > -Original Message-
>> > > > > > From: Steven Gill [mailto:stevengil...@gmail.com]
>> > > > > > Sent: Tuesday, November 19, 2013 12:42 AM
>> > > > > > To: dev@cordova.apache.org
>> > > > > > Subject: Re: [proposal] Deprecate WP7 as a target platform
>> > > > > >
>> > > > > > +1
>> > > > > >
>> > > > > >
>> > > > > > On Mon, Nov 18, 2013 at 12:22 PM, Jesse
>> > > > > > 
>> > > > wrote:
>> > > > > >
>> > > > > > > I would like to add a deprecation notice to WP7, so we can
>> > > > > > > move forward with one platform for Windows Phone.
>> > > > > > > Windows Phone 8 has been available for over a year, and
>> > > > > > > mostly
>> > > taken
>> > > > > > > over for WP7.
>> > > > > > > WP7 devices are currently still available, mostly as an
>> > inexpensive
>> > > > > > > way to get a windows phone.
>> > > > > > > The WP8 Lumia 520 has made considerable impact as a low cost
>> > > > > > > WP8 device, and Nokia is expected to stop selling WP7
>> > > > > > > devices
>> > shortly.
>> > > > > > > Our ~6 month deprecation windows would put us at May of 2014
>> > > > > > > for officially dropping support.
>> > > > > > >
>> > > > > > > The upgrade path for converting your WP7 Cordova app to WP8
>> > Cordova
>> > > > is
>> > > > > > > trivial, with the exception that it requires updated tools.
>> > > > > > > WP8
>> > > app
>> > > > > > > dev requires Windows 8 and Visual Studio 2012. ( WP7
>> > > > > > > required
>> > > Windows
>> > > > > > > 7 +
>> > > > > > > VS-2010 + Zune )
>> > > > > > >
>> > > > > > >
>> > > > > > > @purplecabbage
>> > > > > > > risingj.com
>> > > > > > >
>> > > > > >
>> > > >
>> > > >
>> > >
>> >
>>
>
>

Re: plugins.cordova.io: UX redesign

[Jesse]

Shouldn't the little plugger have multiple prongs on it's head, so it can
be universally applied, or is there a specially designed adapter-hat [1]
that is not shown in that picture?
Actually, thinking more about the gender thing, he is definitely male [2],
on both ends even ... ?


[1]
http://img.alibaba.com/wsphoto/360207307/10pcs-lot-All-in-one-World-Travel-Adapter-Universal-Plug-Converter-US-UK-EU-AU-black.jpg
[2] http://en.wikipedia.org/wiki/Gender_of_connectors_and_fasteners


@purplecabbage
risingj.com


On Thu, Dec 12, 2013 at 4:41 PM, Shazron  wrote:

> Well of course Plugman makes sense, d'oh didn't think of that :)
> (but erm... maybe we want to skip any gender specificity after that libuv
> brouhaha)
>
>
> On Thu, Dec 12, 2013 at 4:38 PM, Brian LeRoux  wrote:
>
> > I vote that we call him Plugman
> >
> > (But his friends call him Pluggy =)
> >
> >
> > On Fri, Dec 13, 2013 at 10:57 AM, Shazron  wrote:
> >
> > > Awesome, love Pluggy(?) the robot.
> > >
> > > Some comments if I may:
> > > 1. Plugin Details - maintainers should be linkable, so we can go to a
> > list
> > > of their authored packages (like npmjs)
> > > 2. Plugin Details - not sure if we want "previous versions" here. npmjs
> > > does this by appending the version to the url, but this is not
> > discoverable
> > > easily: eg https://npmjs.org/package/ios-sim -->
> > > https://npmjs.org/package/ios-sim/1.8.0  . Ideally we want the user to
> > > always grab the latest, but there will be cases where they might want
> to
> > > grab an older one for compatibility reasons, and they might not know
> how,
> > > even through the command line
> > > 3. Plugin Details - I assume the Readme here is just pulled from the
> > > Readme.md of the plugin package (like npmjs) - that will be great if so
> > >
> > >
> > > On Wed, Dec 11, 2013 at 7:26 PM, Joni Rustulka  wrote:
> > >
> > > > Hi all,
> > > >
> > > > I'm Joni. I work at Adobe as a UX designer on the PhoneGap team, and
> I
> > > > have recently thrown some time at redesigning the
> > > > http://plugins.cordova.io site. I'm looking for feedback prior to
> > > > implementation - your thoughts are appreciated.
> > > >
> > > > The main screens that have been reworked are as follows:
> > > >
> > > >
> > > >   1.  Home (http://cl.ly/image/2n3l1N0Z0g0w)
> > > > The primary goal for the site is to help users find the plugins they
> > > need.
> > > > As such, the main focus is on search/findability.
> > > >
> > > >   2.  Search Results (http://cl.ly/image/0c3X3T1E1L0j)
> > > > Upon search for a plugin, the user is returned results. The user can
> > > > filter to include only desired platforms (
> > > http://cl.ly/image/3W2f321I211r),
> > > > and the results table can be sorted by number of downloads, or plugin
> > ID.
> > > >
> > > >   3.  Plugin Details (http://cl.ly/image/2n1p2s3E0a2t)
> > > > The details screen intends to provide all of the necessary
> information
> > on
> > > > a plugin.
> > > > ** From what I understand, one piece of information that may be
> missing
> > > > from this screen is "Installation Instructions". This being,
> config.xml
> > > > feature tags. Is this something that you guys plan to automate, or
> > should
> > > > we be telling plugin authors to put this information in their Read
> Me?
> > > > Please advise.
> > > >
> > > > Further, we do intend to make this a responsive site - so it will be
> > > > easily viewed on smaller screen sizes.
> > > >
> > > > Thanks for your input,
> > > > -joni
> > > >
> > > >
> > > > PS - big thanks and kudos to Yohei for putting together the pluggy
> > robot!
> > > >
> > > >
> > > >
> > >
> >
>

Re: plugins.cordova.io: UX redesign

[Shazron]

Well of course Plugman makes sense, d'oh didn't think of that :)
(but erm... maybe we want to skip any gender specificity after that libuv
brouhaha)


On Thu, Dec 12, 2013 at 4:38 PM, Brian LeRoux  wrote:

> I vote that we call him Plugman
>
> (But his friends call him Pluggy =)
>
>
> On Fri, Dec 13, 2013 at 10:57 AM, Shazron  wrote:
>
> > Awesome, love Pluggy(?) the robot.
> >
> > Some comments if I may:
> > 1. Plugin Details - maintainers should be linkable, so we can go to a
> list
> > of their authored packages (like npmjs)
> > 2. Plugin Details - not sure if we want "previous versions" here. npmjs
> > does this by appending the version to the url, but this is not
> discoverable
> > easily: eg https://npmjs.org/package/ios-sim -->
> > https://npmjs.org/package/ios-sim/1.8.0  . Ideally we want the user to
> > always grab the latest, but there will be cases where they might want to
> > grab an older one for compatibility reasons, and they might not know how,
> > even through the command line
> > 3. Plugin Details - I assume the Readme here is just pulled from the
> > Readme.md of the plugin package (like npmjs) - that will be great if so
> >
> >
> > On Wed, Dec 11, 2013 at 7:26 PM, Joni Rustulka  wrote:
> >
> > > Hi all,
> > >
> > > I'm Joni. I work at Adobe as a UX designer on the PhoneGap team, and I
> > > have recently thrown some time at redesigning the
> > > http://plugins.cordova.io site. I'm looking for feedback prior to
> > > implementation - your thoughts are appreciated.
> > >
> > > The main screens that have been reworked are as follows:
> > >
> > >
> > >   1.  Home (http://cl.ly/image/2n3l1N0Z0g0w)
> > > The primary goal for the site is to help users find the plugins they
> > need.
> > > As such, the main focus is on search/findability.
> > >
> > >   2.  Search Results (http://cl.ly/image/0c3X3T1E1L0j)
> > > Upon search for a plugin, the user is returned results. The user can
> > > filter to include only desired platforms (
> > http://cl.ly/image/3W2f321I211r),
> > > and the results table can be sorted by number of downloads, or plugin
> ID.
> > >
> > >   3.  Plugin Details (http://cl.ly/image/2n1p2s3E0a2t)
> > > The details screen intends to provide all of the necessary information
> on
> > > a plugin.
> > > ** From what I understand, one piece of information that may be missing
> > > from this screen is "Installation Instructions". This being, config.xml
> > > feature tags. Is this something that you guys plan to automate, or
> should
> > > we be telling plugin authors to put this information in their Read Me?
> > > Please advise.
> > >
> > > Further, we do intend to make this a responsive site - so it will be
> > > easily viewed on smaller screen sizes.
> > >
> > > Thanks for your input,
> > > -joni
> > >
> > >
> > > PS - big thanks and kudos to Yohei for putting together the pluggy
> robot!
> > >
> > >
> > >
> >
>

Re: plugins.cordova.io: UX redesign

[Brian LeRoux]

I vote that we call him Plugman

(But his friends call him Pluggy =)


On Fri, Dec 13, 2013 at 10:57 AM, Shazron  wrote:

> Awesome, love Pluggy(?) the robot.
>
> Some comments if I may:
> 1. Plugin Details - maintainers should be linkable, so we can go to a list
> of their authored packages (like npmjs)
> 2. Plugin Details - not sure if we want "previous versions" here. npmjs
> does this by appending the version to the url, but this is not discoverable
> easily: eg https://npmjs.org/package/ios-sim -->
> https://npmjs.org/package/ios-sim/1.8.0  . Ideally we want the user to
> always grab the latest, but there will be cases where they might want to
> grab an older one for compatibility reasons, and they might not know how,
> even through the command line
> 3. Plugin Details - I assume the Readme here is just pulled from the
> Readme.md of the plugin package (like npmjs) - that will be great if so
>
>
> On Wed, Dec 11, 2013 at 7:26 PM, Joni Rustulka  wrote:
>
> > Hi all,
> >
> > I'm Joni. I work at Adobe as a UX designer on the PhoneGap team, and I
> > have recently thrown some time at redesigning the
> > http://plugins.cordova.io site. I'm looking for feedback prior to
> > implementation - your thoughts are appreciated.
> >
> > The main screens that have been reworked are as follows:
> >
> >
> >   1.  Home (http://cl.ly/image/2n3l1N0Z0g0w)
> > The primary goal for the site is to help users find the plugins they
> need.
> > As such, the main focus is on search/findability.
> >
> >   2.  Search Results (http://cl.ly/image/0c3X3T1E1L0j)
> > Upon search for a plugin, the user is returned results. The user can
> > filter to include only desired platforms (
> http://cl.ly/image/3W2f321I211r),
> > and the results table can be sorted by number of downloads, or plugin ID.
> >
> >   3.  Plugin Details (http://cl.ly/image/2n1p2s3E0a2t)
> > The details screen intends to provide all of the necessary information on
> > a plugin.
> > ** From what I understand, one piece of information that may be missing
> > from this screen is "Installation Instructions". This being, config.xml
> > feature tags. Is this something that you guys plan to automate, or should
> > we be telling plugin authors to put this information in their Read Me?
> > Please advise.
> >
> > Further, we do intend to make this a responsive site - so it will be
> > easily viewed on smaller screen sizes.
> >
> > Thanks for your input,
> > -joni
> >
> >
> > PS - big thanks and kudos to Yohei for putting together the pluggy robot!
> >
> >
> >
>

Re: [Node 101] Part 1: Small Modules

[Brian LeRoux]

Oh interesting. I can see what you mean though I think the only thing I
should know about the output is the return value. (In your case, just a
test for 'done'.) The behavior of the module is super important of course.
In the small modules philosophy the foo, bar.method, and baz would have
thier own tests for interface/output to satisfy the case you describe.

Again, IT DEPENDS! The rimraf example is a perfect case for what you
describe.


On Fri, Dec 13, 2013 at 10:59 AM, Gord Tanner  wrote:

> It depends what you define as outputs.
>
> in a given module:
>
> var foo = require('foo'), bar = require('bar'), baz = require('baz');
>
> module.exports = function(a, b) {
> foo(3);
> bar.method(a);
> baz(b);
>
>return "done";
> }
>
> I have always counted the calls to foo, bar and baz as output that needs to
> be tested.  This would produce a spec like:
>
> "when calling this module":
>"it calls foo with 3"
>"it calls bar.method with a"
>"it calls baz with b"
>"it returns done"
>
> It is just easier to mock bar.method then foo
>
> ie:
>
> var rewire = require('rewire');
> var example = rewire('example'); //NOTE: rewire rather then require
> example.__set__('foo', jasmine.createSpy());
>
> vrs:
>
> var example = require('example');
> var bar = require('bar');
> spyOn(bar, "method");
>
> I came across this problem when using one of Isaac's modules (rimraf [1])
> where I obviously didn't want to call that in a unit test from my module
> but I need to mock it out.  Rewire was the only way I could.
>
> [1] - https://github.com/isaacs/rimraf
>
>
>
> On Thu, Dec 12, 2013 at 6:37 PM, Brian LeRoux  wrote:
>
> > ALSO: lets avoid using terms like 'I agree' or 'I disagree'. Its
> > programming. The answer is ALWAYS 'it depends'. No absolutes in the sea
> of
> > change.
> >
> >
> > On Fri, Dec 13, 2013 at 10:34 AM, Brian LeRoux  wrote:
> >
> > > Maybe. Have a look at Substack's code and you'll see he has no trouble
> > > testing. The reason being he tests interfaces and outputs instead of
> > > implementations. That will be another Node 101!
> > >
> > >
> > > On Fri, Dec 13, 2013 at 10:24 AM, Gord Tanner 
> wrote:
> > >
> > >> I also agree with this except for returning a function from
> > >> module.exports.
> > >>
> > >> It is possible but makes mocking much much harder for testing.
> > >>
> > >> think of:
> > >>
> > >>
> > >> var foo = require('foo');
> > >>
> > >> module.exports = {
> > >> awesome: function (a) {
> > >> foo(a+1);
> > >>}
> > >> };
> > >>
> > >> It is kind of awkward to test this module's use of the foo module.  It
> > can
> > >> be done with rewire [1] but is a little awkward.
> > >>
> > >> If foo was designed where it exported an object literal with functions
> > it
> > >> would be much easier to mock:
> > >>
> > >> var foo = require('foo');
> > >>
> > >> module.exports = {
> > >> awesome: function (a) {
> > >> foo.bar(a+1);
> > >>}
> > >> };
> > >>
> > >> it("calls foo.bar", function () {
> > >> var foo = require('foo');
> > >> spyOn(foo, "bar");
> > >> });
> > >>
> > >> Just my 2 cents from a testing perspective.
> > >>
> > >>
> > >> [1] - https://github.com/jhnns/rewire
> > >>
> > >>
> > >> On Thu, Dec 12, 2013 at 6:06 PM, Brian LeRoux  wrote:
> > >>
> > >> > Create modules that are the smallest possible unit of code. Less
> code
> > is
> > >> > fast code. Faster to write. Faster to maintain. Faster to test. On
> the
> > >> > extreme end characters in the Node community such as Substack
> > advocate a
> > >> > single function per module definition.
> > >> >
> > >> > module.exports = function() {
> > >> >   // my logic here
> > >> > }
> > >> >
> > >> > This is kind of extreme and not always possible but a good practice
> > >> > nonetheless. The idea is not new. Its a part of the UNIX philosophy:
> > "do
> > >> > one thing well" coined by Doug Mcilroy. [1]
> > >> >
> > >> > It can help you make code that looks like this [2] into this [3].
> > >> >
> > >> >
> > >> >
> > >> > [1]
> > http://homepage.cs.uri.edu/~thenry/resources/unix_art/ch01s06.html
> > >> > [2]
> > >> >
> > >> >
> > >>
> >
> https://github.com/apache/cordova-js/blob/c320378b484a172a02d3ee26634bcc584f43b939/Gruntfile.js
> > >> > [3] https://github.com/apache/cordova-js/blob/master/Gruntfile.js
> > >> >
> > >>
> > >
> > >
> >
>

Re: [Node 101] Part 2: Avoid the Triangle of Doom

[Brian LeRoux]

Sorry, lets see if I can make it more obvious.

https://gist.github.com/brianleroux/7938149


On Fri, Dec 13, 2013 at 10:41 AM, Josh Soref  wrote:

> Brian wrote:
> >Flatten your async code. New fashion advocates promises, generators,
> >events, or one of the streams apis.
>
> While flattening with promises is greatŠ
>
>
> >The classic method is to write small testable modules (see part 1) and
> >flatten your tree.
> >
> >Turn code that looks like this [1] into this [2].
>
> Š I can¹t figure out how your two example blobs relate.
>
> For the sake of people trying to learn patterns, can you please ensure
> that your [1] and [2] are obvious ³before² and ³after²?
>
> >[1]
> >
> https://github.com/apache/cordova-js/blob/b75096a1bade9ca6aa0d38a2039fd922
> >ad7c1a95/test/runner.js#L99-L136
> >[2]
> >
> https://github.com/apache/cordova-js/blob/ced04a4ec71f144dd2cd6c2e9392e3b1
> >fc725ec1/tasks/lib/test-browser.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: [Node 101] Part 2: Avoid the Triangle of Doom

[Brian LeRoux]

And yes promises are great. I find them to be more sugar than actual help
but to each his own. Same practices apply.


On Fri, Dec 13, 2013 at 11:32 AM, Brian LeRoux  wrote:

> Sorry, lets see if I can make it more obvious.
>
> https://gist.github.com/brianleroux/7938149
>
>
> On Fri, Dec 13, 2013 at 10:41 AM, Josh Soref wrote:
>
>> Brian wrote:
>> >Flatten your async code. New fashion advocates promises, generators,
>> >events, or one of the streams apis.
>>
>> While flattening with promises is greatŠ
>>
>>
>> >The classic method is to write small testable modules (see part 1) and
>> >flatten your tree.
>> >
>> >Turn code that looks like this [1] into this [2].
>>
>> Š I can¹t figure out how your two example blobs relate.
>>
>> For the sake of people trying to learn patterns, can you please ensure
>> that your [1] and [2] are obvious ³before² and ³after²?
>>
>> >[1]
>> >
>> https://github.com/apache/cordova-js/blob/b75096a1bade9ca6aa0d38a2039fd922
>> >ad7c1a95/test/runner.js#L99-L136
>> >[2]
>> >
>> https://github.com/apache/cordova-js/blob/ced04a4ec71f144dd2cd6c2e9392e3b1
>> >fc725ec1/tasks/lib/test-browser.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: [Node 101] Part 1: Small Modules

[Gord Tanner]

It depends what you define as outputs.

in a given module:

var foo = require('foo'), bar = require('bar'), baz = require('baz');

module.exports = function(a, b) {
foo(3);
bar.method(a);
baz(b);

   return "done";
}

I have always counted the calls to foo, bar and baz as output that needs to
be tested.  This would produce a spec like:

"when calling this module":
   "it calls foo with 3"
   "it calls bar.method with a"
   "it calls baz with b"
   "it returns done"

It is just easier to mock bar.method then foo

ie:

var rewire = require('rewire');
var example = rewire('example'); //NOTE: rewire rather then require
example.__set__('foo', jasmine.createSpy());

vrs:

var example = require('example');
var bar = require('bar');
spyOn(bar, "method");

I came across this problem when using one of Isaac's modules (rimraf [1])
where I obviously didn't want to call that in a unit test from my module
but I need to mock it out.  Rewire was the only way I could.

[1] - https://github.com/isaacs/rimraf



On Thu, Dec 12, 2013 at 6:37 PM, Brian LeRoux  wrote:

> ALSO: lets avoid using terms like 'I agree' or 'I disagree'. Its
> programming. The answer is ALWAYS 'it depends'. No absolutes in the sea of
> change.
>
>
> On Fri, Dec 13, 2013 at 10:34 AM, Brian LeRoux  wrote:
>
> > Maybe. Have a look at Substack's code and you'll see he has no trouble
> > testing. The reason being he tests interfaces and outputs instead of
> > implementations. That will be another Node 101!
> >
> >
> > On Fri, Dec 13, 2013 at 10:24 AM, Gord Tanner  wrote:
> >
> >> I also agree with this except for returning a function from
> >> module.exports.
> >>
> >> It is possible but makes mocking much much harder for testing.
> >>
> >> think of:
> >>
> >>
> >> var foo = require('foo');
> >>
> >> module.exports = {
> >> awesome: function (a) {
> >> foo(a+1);
> >>}
> >> };
> >>
> >> It is kind of awkward to test this module's use of the foo module.  It
> can
> >> be done with rewire [1] but is a little awkward.
> >>
> >> If foo was designed where it exported an object literal with functions
> it
> >> would be much easier to mock:
> >>
> >> var foo = require('foo');
> >>
> >> module.exports = {
> >> awesome: function (a) {
> >> foo.bar(a+1);
> >>}
> >> };
> >>
> >> it("calls foo.bar", function () {
> >> var foo = require('foo');
> >> spyOn(foo, "bar");
> >> });
> >>
> >> Just my 2 cents from a testing perspective.
> >>
> >>
> >> [1] - https://github.com/jhnns/rewire
> >>
> >>
> >> On Thu, Dec 12, 2013 at 6:06 PM, Brian LeRoux  wrote:
> >>
> >> > Create modules that are the smallest possible unit of code. Less code
> is
> >> > fast code. Faster to write. Faster to maintain. Faster to test. On the
> >> > extreme end characters in the Node community such as Substack
> advocate a
> >> > single function per module definition.
> >> >
> >> > module.exports = function() {
> >> >   // my logic here
> >> > }
> >> >
> >> > This is kind of extreme and not always possible but a good practice
> >> > nonetheless. The idea is not new. Its a part of the UNIX philosophy:
> "do
> >> > one thing well" coined by Doug Mcilroy. [1]
> >> >
> >> > It can help you make code that looks like this [2] into this [3].
> >> >
> >> >
> >> >
> >> > [1]
> http://homepage.cs.uri.edu/~thenry/resources/unix_art/ch01s06.html
> >> > [2]
> >> >
> >> >
> >>
> https://github.com/apache/cordova-js/blob/c320378b484a172a02d3ee26634bcc584f43b939/Gruntfile.js
> >> > [3] https://github.com/apache/cordova-js/blob/master/Gruntfile.js
> >> >
> >>
> >
> >
>

Re: plugins.cordova.io: UX redesign

[Shazron]

Awesome, love Pluggy(?) the robot.

Some comments if I may:
1. Plugin Details - maintainers should be linkable, so we can go to a list
of their authored packages (like npmjs)
2. Plugin Details - not sure if we want "previous versions" here. npmjs
does this by appending the version to the url, but this is not discoverable
easily: eg https://npmjs.org/package/ios-sim -->
https://npmjs.org/package/ios-sim/1.8.0  . Ideally we want the user to
always grab the latest, but there will be cases where they might want to
grab an older one for compatibility reasons, and they might not know how,
even through the command line
3. Plugin Details - I assume the Readme here is just pulled from the
Readme.md of the plugin package (like npmjs) - that will be great if so


On Wed, Dec 11, 2013 at 7:26 PM, Joni Rustulka  wrote:

> Hi all,
>
> I'm Joni. I work at Adobe as a UX designer on the PhoneGap team, and I
> have recently thrown some time at redesigning the
> http://plugins.cordova.io site. I'm looking for feedback prior to
> implementation - your thoughts are appreciated.
>
> The main screens that have been reworked are as follows:
>
>
>   1.  Home (http://cl.ly/image/2n3l1N0Z0g0w)
> The primary goal for the site is to help users find the plugins they need.
> As such, the main focus is on search/findability.
>
>   2.  Search Results (http://cl.ly/image/0c3X3T1E1L0j)
> Upon search for a plugin, the user is returned results. The user can
> filter to include only desired platforms (http://cl.ly/image/3W2f321I211r),
> and the results table can be sorted by number of downloads, or plugin ID.
>
>   3.  Plugin Details (http://cl.ly/image/2n1p2s3E0a2t)
> The details screen intends to provide all of the necessary information on
> a plugin.
> ** From what I understand, one piece of information that may be missing
> from this screen is "Installation Instructions". This being, config.xml
> feature tags. Is this something that you guys plan to automate, or should
> we be telling plugin authors to put this information in their Read Me?
> Please advise.
>
> Further, we do intend to make this a responsive site - so it will be
> easily viewed on smaller screen sizes.
>
> Thanks for your input,
> -joni
>
>
> PS - big thanks and kudos to Yohei for putting together the pluggy robot!
>
>
>

Re: [Node 101] Part 2: Avoid the Triangle of Doom

[Josh Soref]

Brian wrote:
>Flatten your async code. New fashion advocates promises, generators,
>events, or one of the streams apis.

While flattening with promises is greatŠ
 

>The classic method is to write small testable modules (see part 1) and
>flatten your tree.
>
>Turn code that looks like this [1] into this [2].

Š I can¹t figure out how your two example blobs relate.

For the sake of people trying to learn patterns, can you please ensure
that your [1] and [2] are obvious ³before² and ³after²?

>[1]
>https://github.com/apache/cordova-js/blob/b75096a1bade9ca6aa0d38a2039fd922
>ad7c1a95/test/runner.js#L99-L136
>[2]
>https://github.com/apache/cordova-js/blob/ced04a4ec71f144dd2cd6c2e9392e3b1
>fc725ec1/tasks/lib/test-browser.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: [Node 101] Part 1: Small Modules

[Brian LeRoux]

ALSO: lets avoid using terms like 'I agree' or 'I disagree'. Its
programming. The answer is ALWAYS 'it depends'. No absolutes in the sea of
change.


On Fri, Dec 13, 2013 at 10:34 AM, Brian LeRoux  wrote:

> Maybe. Have a look at Substack's code and you'll see he has no trouble
> testing. The reason being he tests interfaces and outputs instead of
> implementations. That will be another Node 101!
>
>
> On Fri, Dec 13, 2013 at 10:24 AM, Gord Tanner  wrote:
>
>> I also agree with this except for returning a function from
>> module.exports.
>>
>> It is possible but makes mocking much much harder for testing.
>>
>> think of:
>>
>>
>> var foo = require('foo');
>>
>> module.exports = {
>> awesome: function (a) {
>> foo(a+1);
>>}
>> };
>>
>> It is kind of awkward to test this module's use of the foo module.  It can
>> be done with rewire [1] but is a little awkward.
>>
>> If foo was designed where it exported an object literal with functions it
>> would be much easier to mock:
>>
>> var foo = require('foo');
>>
>> module.exports = {
>> awesome: function (a) {
>> foo.bar(a+1);
>>}
>> };
>>
>> it("calls foo.bar", function () {
>> var foo = require('foo');
>> spyOn(foo, "bar");
>> });
>>
>> Just my 2 cents from a testing perspective.
>>
>>
>> [1] - https://github.com/jhnns/rewire
>>
>>
>> On Thu, Dec 12, 2013 at 6:06 PM, Brian LeRoux  wrote:
>>
>> > Create modules that are the smallest possible unit of code. Less code is
>> > fast code. Faster to write. Faster to maintain. Faster to test. On the
>> > extreme end characters in the Node community such as Substack advocate a
>> > single function per module definition.
>> >
>> > module.exports = function() {
>> >   // my logic here
>> > }
>> >
>> > This is kind of extreme and not always possible but a good practice
>> > nonetheless. The idea is not new. Its a part of the UNIX philosophy: "do
>> > one thing well" coined by Doug Mcilroy. [1]
>> >
>> > It can help you make code that looks like this [2] into this [3].
>> >
>> >
>> >
>> > [1] http://homepage.cs.uri.edu/~thenry/resources/unix_art/ch01s06.html
>> > [2]
>> >
>> >
>> https://github.com/apache/cordova-js/blob/c320378b484a172a02d3ee26634bcc584f43b939/Gruntfile.js
>> > [3] https://github.com/apache/cordova-js/blob/master/Gruntfile.js
>> >
>>
>
>

Re: [Node 101] Part 1: Small Modules

[Brian LeRoux]

Maybe. Have a look at Substack's code and you'll see he has no trouble
testing. The reason being he tests interfaces and outputs instead of
implementations. That will be another Node 101!


On Fri, Dec 13, 2013 at 10:24 AM, Gord Tanner  wrote:

> I also agree with this except for returning a function from module.exports.
>
> It is possible but makes mocking much much harder for testing.
>
> think of:
>
>
> var foo = require('foo');
>
> module.exports = {
> awesome: function (a) {
> foo(a+1);
>}
> };
>
> It is kind of awkward to test this module's use of the foo module.  It can
> be done with rewire [1] but is a little awkward.
>
> If foo was designed where it exported an object literal with functions it
> would be much easier to mock:
>
> var foo = require('foo');
>
> module.exports = {
> awesome: function (a) {
> foo.bar(a+1);
>}
> };
>
> it("calls foo.bar", function () {
> var foo = require('foo');
> spyOn(foo, "bar");
> });
>
> Just my 2 cents from a testing perspective.
>
>
> [1] - https://github.com/jhnns/rewire
>
>
> On Thu, Dec 12, 2013 at 6:06 PM, Brian LeRoux  wrote:
>
> > Create modules that are the smallest possible unit of code. Less code is
> > fast code. Faster to write. Faster to maintain. Faster to test. On the
> > extreme end characters in the Node community such as Substack advocate a
> > single function per module definition.
> >
> > module.exports = function() {
> >   // my logic here
> > }
> >
> > This is kind of extreme and not always possible but a good practice
> > nonetheless. The idea is not new. Its a part of the UNIX philosophy: "do
> > one thing well" coined by Doug Mcilroy. [1]
> >
> > It can help you make code that looks like this [2] into this [3].
> >
> >
> >
> > [1] http://homepage.cs.uri.edu/~thenry/resources/unix_art/ch01s06.html
> > [2]
> >
> >
> https://github.com/apache/cordova-js/blob/c320378b484a172a02d3ee26634bcc584f43b939/Gruntfile.js
> > [3] https://github.com/apache/cordova-js/blob/master/Gruntfile.js
> >
>

Re: [Node 101] Part 1: Small Modules

[Gord Tanner]

I also agree with this except for returning a function from module.exports.

It is possible but makes mocking much much harder for testing.

think of:


var foo = require('foo');

module.exports = {
awesome: function (a) {
foo(a+1);
   }
};

It is kind of awkward to test this module's use of the foo module.  It can
be done with rewire [1] but is a little awkward.

If foo was designed where it exported an object literal with functions it
would be much easier to mock:

var foo = require('foo');

module.exports = {
awesome: function (a) {
foo.bar(a+1);
   }
};

it("calls foo.bar", function () {
var foo = require('foo');
spyOn(foo, "bar");
});

Just my 2 cents from a testing perspective.


[1] - https://github.com/jhnns/rewire


On Thu, Dec 12, 2013 at 6:06 PM, Brian LeRoux  wrote:

> Create modules that are the smallest possible unit of code. Less code is
> fast code. Faster to write. Faster to maintain. Faster to test. On the
> extreme end characters in the Node community such as Substack advocate a
> single function per module definition.
>
> module.exports = function() {
>   // my logic here
> }
>
> This is kind of extreme and not always possible but a good practice
> nonetheless. The idea is not new. Its a part of the UNIX philosophy: "do
> one thing well" coined by Doug Mcilroy. [1]
>
> It can help you make code that looks like this [2] into this [3].
>
>
>
> [1] http://homepage.cs.uri.edu/~thenry/resources/unix_art/ch01s06.html
> [2]
>
> https://github.com/apache/cordova-js/blob/c320378b484a172a02d3ee26634bcc584f43b939/Gruntfile.js
> [3] https://github.com/apache/cordova-js/blob/master/Gruntfile.js
>

[Node 101] Part 2: Avoid the Triangle of Doom

[Brian LeRoux]

Flatten your async code. New fashion advocates promises, generators,
events, or one of the streams apis.

The classic method is to write small testable modules (see part 1) and
flatten your tree.

Turn code that looks like this [1] into this [2].

[1]
https://github.com/apache/cordova-js/blob/b75096a1bade9ca6aa0d38a2039fd922ad7c1a95/test/runner.js#L99-L136
[2]
https://github.com/apache/cordova-js/blob/ced04a4ec71f144dd2cd6c2e9392e3b1fc725ec1/tasks/lib/test-browser.js

[Node 101] Part 1: Small Modules

[Brian LeRoux]

Create modules that are the smallest possible unit of code. Less code is
fast code. Faster to write. Faster to maintain. Faster to test. On the
extreme end characters in the Node community such as Substack advocate a
single function per module definition.

module.exports = function() {
  // my logic here
}

This is kind of extreme and not always possible but a good practice
nonetheless. The idea is not new. Its a part of the UNIX philosophy: "do
one thing well" coined by Doug Mcilroy. [1]

It can help you make code that looks like this [2] into this [3].



[1] http://homepage.cs.uri.edu/~thenry/resources/unix_art/ch01s06.html
[2]
https://github.com/apache/cordova-js/blob/c320378b484a172a02d3ee26634bcc584f43b939/Gruntfile.js
[3] https://github.com/apache/cordova-js/blob/master/Gruntfile.js

[Node 101] Part 0

[Brian LeRoux]

I've had some time to revisit our codebase and been doing some refactoring.
Its fun. Cordova is an somewhat mature project (or maturing) and with age
comes a few wrinkles.

I'd like for not only our code to get better but all of committership.
Programming is a lifelong learning exercise, and we should share knowledge
and help each other grow.

For my part, I'm going to do a series of posts to the list sharing some
techniques for writing better JavaScript (and Node).

Please chime in! I would love to see [C# 101], [Java 101], [Obj C 101], and
[Bash 101] posts.

Re: Medic CI failures

[David Kemp]

Seems like it. I am seeing some passes now. I will check into the details
in a bit.
 On Dec 12, 2013 5:52 PM, "Steven Gill"  wrote:

> I have removed btests from running for now. We can add them back in once we
> get them to a working state. This should fix the CI issues you are seeing
> David.
>
>
> On Thu, Dec 12, 2013 at 1:51 PM, Brian LeRoux  wrote:
>
> > The tests aren't new. They just run now instead of silent failure.
> >
> > I'll have a look at restoring old behavior and kick up a thread about
> > testing. Current/old solution tested nothing.
> > On Dec 13, 2013 8:02 AM, "David Kemp"  wrote:
> >
> > > Brian,
> > > The new tests also appear to open a tab on my chrome browser to display
> > the
> > > jasmine results after every test. This results in a rather unmanageable
> > > number of tabs on the slave machine after a while.
> > >
> > > I still have all master tests failing.
> > >
> > >
> > >
> > >
> > > On Thu, Dec 12, 2013 at 10:42 AM, David Kemp 
> wrote:
> > >
> > > > From the perspective of the js tests, medic (testing master) does:
> > > > - rm -rf ~/.cordova/lib/ios (this ensures no cached crap)
> > > > - use coho to checkout the sources into a clean directory
> > > > - cd into cordova-js
> > > > - git checkout master (for the release branch this currently checks
> out
> > > > 3.2.x)
> > > > - npm install
> > > > - grunt
> > > >
> > > > running on Mavericks, Xcode 5.01
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Thu, Dec 12, 2013 at 10:29 AM, Brian LeRoux  wrote:
> > > >
> > > >> Still? How do I reproduce?
> > > >> On Dec 13, 2013 2:28 AM, "David Kemp"  wrote:
> > > >>
> > > >> > Sorry - I did sort of forget to say which test..
> > > >> >
> > > >> > Yes the failure is in cordova-js.
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> > On Thu, Dec 12, 2013 at 10:15 AM, Brian LeRoux 
> wrote:
> > > >> >
> > > >> > > cordova-js ?? (Should be passing now but gruntfile was
> > refactored.)
> > > >> > > On Dec 13, 2013 12:06 AM, "David Kemp" 
> wrote:
> > > >> > >
> > > >> > > > last night a commit to change tests seems to have created a
> > > problem
> > > >> > with
> > > >> > > > the iOS and android testing. The grunt test for iOS failed
> with:
> > > >> > > >
> > > >> > > > deviceready has not fired after 5 seconds.
> > > >> > > >
> > > >> > > > Channel not fired: onNativeReady
> > > >> > > > Channel not fired: onCordovaReady
> > > >> > > > command timed out: 1200 seconds without output, attempting to
> > kill
> > > >> > > >
> > > >> > > > The Android test didn't get that far because it tried to start
> > the
> > > >> test
> > > >> > > > concurrently with the iOS test and :
> > > >> > > >
> > > >> > > > starting browser-based tests
> > > >> > > > Test Server running on:
> > > >> > > > http://127.0.0.1:3000
> > > >> > > >
> > > >> > > >  [31mFatal error: listen EADDRINUSE
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
>

Re: Medic CI failures

[Steven Gill]

I have removed btests from running for now. We can add them back in once we
get them to a working state. This should fix the CI issues you are seeing
David.


On Thu, Dec 12, 2013 at 1:51 PM, Brian LeRoux  wrote:

> The tests aren't new. They just run now instead of silent failure.
>
> I'll have a look at restoring old behavior and kick up a thread about
> testing. Current/old solution tested nothing.
> On Dec 13, 2013 8:02 AM, "David Kemp"  wrote:
>
> > Brian,
> > The new tests also appear to open a tab on my chrome browser to display
> the
> > jasmine results after every test. This results in a rather unmanageable
> > number of tabs on the slave machine after a while.
> >
> > I still have all master tests failing.
> >
> >
> >
> >
> > On Thu, Dec 12, 2013 at 10:42 AM, David Kemp  wrote:
> >
> > > From the perspective of the js tests, medic (testing master) does:
> > > - rm -rf ~/.cordova/lib/ios (this ensures no cached crap)
> > > - use coho to checkout the sources into a clean directory
> > > - cd into cordova-js
> > > - git checkout master (for the release branch this currently checks out
> > > 3.2.x)
> > > - npm install
> > > - grunt
> > >
> > > running on Mavericks, Xcode 5.01
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Thu, Dec 12, 2013 at 10:29 AM, Brian LeRoux  wrote:
> > >
> > >> Still? How do I reproduce?
> > >> On Dec 13, 2013 2:28 AM, "David Kemp"  wrote:
> > >>
> > >> > Sorry - I did sort of forget to say which test..
> > >> >
> > >> > Yes the failure is in cordova-js.
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > On Thu, Dec 12, 2013 at 10:15 AM, Brian LeRoux  wrote:
> > >> >
> > >> > > cordova-js ?? (Should be passing now but gruntfile was
> refactored.)
> > >> > > On Dec 13, 2013 12:06 AM, "David Kemp"  wrote:
> > >> > >
> > >> > > > last night a commit to change tests seems to have created a
> > problem
> > >> > with
> > >> > > > the iOS and android testing. The grunt test for iOS failed with:
> > >> > > >
> > >> > > > deviceready has not fired after 5 seconds.
> > >> > > >
> > >> > > > Channel not fired: onNativeReady
> > >> > > > Channel not fired: onCordovaReady
> > >> > > > command timed out: 1200 seconds without output, attempting to
> kill
> > >> > > >
> > >> > > > The Android test didn't get that far because it tried to start
> the
> > >> test
> > >> > > > concurrently with the iOS test and :
> > >> > > >
> > >> > > > starting browser-based tests
> > >> > > > Test Server running on:
> > >> > > > http://127.0.0.1:3000
> > >> > > >
> > >> > > >  [31mFatal error: listen EADDRINUSE
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>

RE: plugins.cordova.io: UX redesign

[Smith, Peter]

I have some feedback about versions and the download counts.

When a particular plugin (eg org.apache.cordova.XYZ) has multiple
versions 0.1.0, 0.1.5, 0.2.0, 0.2.1, 0.2.3, 0.2.4 then how will the list
of all those different versions displayed? And what does the download
count mean in that case - is it count per id across all versions or for
each version?
 
For example, it is not so clear where clicking on a "Most Downloaded"
link on the "home" page goes to - is it to the details page of the most
downloaded version? E.g. maybe the plugin XYZ version v0.2.3 is most
downloaded but that is only because XYZ v0.2.4 is very new and nobody is
aware of it yet.

Similarly, if the "search results" page is sorted by download counts
maybe v0.2.3 has 10,000 downloads but the newer v0.2.4 has only 57
dowloads so falls off bottom of that results list. So the user might
accidentally download what they believe is most popular and fetch v0.2.3
simply because they are unaware of a newer version of the same plugin.
Or am I misreading this page, and that "Version" column actually means
"*Latest* Version" (??)

Users ought to be able to get any version of a plugin they want -
perhaps they do not want the latest version, but it would be a pity if
they accidentally didn't get the latest version simply because they
didn't even know it existed.

Maybe that plugin "details" page could always default to show the latest
version but providing a "Version History" section on that page would
help by giving links back to older versions of the same plugin id...
12 Dec 2013: v0.2.4, 57 downloads
25 Nov 2013: v0.2.3, 10,000 downloads
04 May 2013: v0.2.1, 6777 downloads
03 May 2013: v0.2.0, 16 downloads
12 Mar 2013: v0.1.5, 503 downloads
05 Jan 2013: v0.1.0, 50 downloads

Cheers,
Peter.

-Original Message-
From: Joni Rustulka [mailto:j...@adobe.com] 
Sent: Thursday, 12 December 2013 2:27 PM
To: dev@cordova.apache.org
Cc: Yohei Shimomae
Subject: plugins.cordova.io: UX redesign

Hi all,

I'm Joni. I work at Adobe as a UX designer on the PhoneGap team, and I
have recently thrown some time at redesigning the
http://plugins.cordova.io site. I'm looking for feedback prior to
implementation - your thoughts are appreciated.

The main screens that have been reworked are as follows:


  1.  Home (http://cl.ly/image/2n3l1N0Z0g0w) The primary goal for the
site is to help users find the plugins they need. As such, the main
focus is on search/findability.

  2.  Search Results (http://cl.ly/image/0c3X3T1E1L0j) Upon search for a
plugin, the user is returned results. The user can filter to include
only desired platforms (http://cl.ly/image/3W2f321I211r), and the
results table can be sorted by number of downloads, or plugin ID.

  3.  Plugin Details (http://cl.ly/image/2n1p2s3E0a2t) The details
screen intends to provide all of the necessary information on a plugin.
** From what I understand, one piece of information that may be missing
from this screen is "Installation Instructions". This being, config.xml
feature tags. Is this something that you guys plan to automate, or
should we be telling plugin authors to put this information in their
Read Me? Please advise.

Further, we do intend to make this a responsive site - so it will be
easily viewed on smaller screen sizes.

Thanks for your input,
-joni


PS - big thanks and kudos to Yohei for putting together the pluggy
robot!

Re: Review Request 15775: Add --src & --link to "cordova create"

[Josh Soref]

Mark wrote:
>https://reviews.apache.org/r/15775/
>--link was a boolean before, now it accepts a path, so it's either
>--src=path or --link=path.
>Added a check in config_parser to make sure we are looking at an xml file
>that looks like Cordova config.xml to avoid overwriting some unrelated
>config.xml when symlinking to www dir.
>
>Same diff on github: https://github.com/kamrik/cordova-cli/compare/src_www

I can¹t figure out how to use review board (I guess the account isn¹t
connected to JIRA, is it connected to anything else?)

> [--src|source=] .. use custom www assets instead of the stock
>cordova hello-world.

Please use ³Cordova² not ³cordova² unless you mean ³./cordova² or some
other script.
(I¹m aware that there¹s a line in another file which has the same
convention, that¹s a bug, which is hopefully being fixed by some other
pending pull request, but if it¹s in flight, then it will miss yours)

> [--link=]  as above, but symlink the custom www dir
>instead of copying.


Please don¹t use ³as above², it¹s asking for things to break when the next
person inserts a line into the help file.

+var path = require('path');
+var optimist; // required in try-catch below to print a nice error
message if it's not installed.


I believe general style would be:

var path = require('path'),
optimist,
Š;

+// If no inputArgs given, use preocess.argv but without the


Please don¹t introduce spelling errors, not even in comments.

> _ = require('lodash');


What is this, and why don¹t I see it in packages.json?


MacBook-Pro:docs $ node
> require('lodash')
Error: Cannot find module 'lodash'
at Function.Module._resolveFilename (module.js:338:15)



+if (inputArgs[0].match('node')) { // On Win first element is full
path to node.exe



This is way too hacky.

You¹re reordering a lot of unrelated code. I¹m very uncomfortable with
mixing rewrites and new features. I¹d personally prefer you split them
into distinct commits. ‹ It¹s making reviewing the changes here incredibly
painful.


+if((r.tag !== 'widget') || !r.attrib || (r.attrib.xmlns !== xmlns)) {


There should probably be a space after `if`Š

-if (contents.length == 0) {
+if (contents.length === 0) {


If this is a style fix, please have it in a style-fix commit instead of
mixed with a refactor and a feature.

 } else if (contents.length == 1) {
Also, why didn¹t you change this??


-shell.mkdir('-p', www_dir);


there¹s probably a good reason for this, but it¹s now so burried that
there¹s no way I can figure out what it is :(


-
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: Medic CI failures

[Brian LeRoux]

The tests aren't new. They just run now instead of silent failure.

I'll have a look at restoring old behavior and kick up a thread about
testing. Current/old solution tested nothing.
On Dec 13, 2013 8:02 AM, "David Kemp"  wrote:

> Brian,
> The new tests also appear to open a tab on my chrome browser to display the
> jasmine results after every test. This results in a rather unmanageable
> number of tabs on the slave machine after a while.
>
> I still have all master tests failing.
>
>
>
>
> On Thu, Dec 12, 2013 at 10:42 AM, David Kemp  wrote:
>
> > From the perspective of the js tests, medic (testing master) does:
> > - rm -rf ~/.cordova/lib/ios (this ensures no cached crap)
> > - use coho to checkout the sources into a clean directory
> > - cd into cordova-js
> > - git checkout master (for the release branch this currently checks out
> > 3.2.x)
> > - npm install
> > - grunt
> >
> > running on Mavericks, Xcode 5.01
> >
> >
> >
> >
> >
> >
> > On Thu, Dec 12, 2013 at 10:29 AM, Brian LeRoux  wrote:
> >
> >> Still? How do I reproduce?
> >> On Dec 13, 2013 2:28 AM, "David Kemp"  wrote:
> >>
> >> > Sorry - I did sort of forget to say which test..
> >> >
> >> > Yes the failure is in cordova-js.
> >> >
> >> >
> >> >
> >> >
> >> > On Thu, Dec 12, 2013 at 10:15 AM, Brian LeRoux  wrote:
> >> >
> >> > > cordova-js ?? (Should be passing now but gruntfile was refactored.)
> >> > > On Dec 13, 2013 12:06 AM, "David Kemp"  wrote:
> >> > >
> >> > > > last night a commit to change tests seems to have created a
> problem
> >> > with
> >> > > > the iOS and android testing. The grunt test for iOS failed with:
> >> > > >
> >> > > > deviceready has not fired after 5 seconds.
> >> > > >
> >> > > > Channel not fired: onNativeReady
> >> > > > Channel not fired: onCordovaReady
> >> > > > command timed out: 1200 seconds without output, attempting to kill
> >> > > >
> >> > > > The Android test didn't get that far because it tried to start the
> >> test
> >> > > > concurrently with the iOS test and :
> >> > > >
> >> > > > starting browser-based tests
> >> > > > Test Server running on:
> >> > > > http://127.0.0.1:3000
> >> > > >
> >> > > >  [31mFatal error: listen EADDRINUSE
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>

Re: Review Request 15775: Add --src & --link to "cordova create"

[Mark Koudritsky]

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

(Updated Dec. 12, 2013, 9:27 p.m.)


Review request for cordova.


Changes
---

--link was a boolean before, now it accepts a path, so it's either --src=path 
or --link=path.
Added a check in config_parser to make sure we are looking at an xml file that 
looks like Cordova config.xml to avoid overwriting some unrelated config.xml 
when symlinking to www dir.

Same diff on github: https://github.com/kamrik/cordova-cli/compare/src_www


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


Repository: cordova-cli


Description
---

Add --src & --link to "cordova create".

Both --src and --source are accepted.
The path is passed via the lib.www.uri of the configuration object
that is later written to .cordova/config.json.

Cordova will keep going into child www folder(s) of the provided path.


Diffs (updated)
-

  doc/help.txt 3361dd3 
  e2e/create.spec.js 560f82a 
  spec/metadata/android_parser.spec.js 52fc78a 
  spec/metadata/ios_parser.spec.js b56ddce 
  spec/metadata/windows8_parser.spec.js 5117148 
  spec/metadata/wp7_parser.spec.js 6dc0695 
  spec/metadata/wp8_parser.spec.js 8cd1923 
  src/cli.js 2916062 
  src/config_parser.js b6293d8 
  src/create.js 961d787 
  src/metadata/wp8_parser.js 163d56b 

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


Testing
---

npm test;
cordova -d  create TstApp --source=some/www --link
a bunch of other cordova commands in the app


Thanks,

Mark Koudritsky

Re: Medic CI failures

[David Kemp]

Brian,
The new tests also appear to open a tab on my chrome browser to display the
jasmine results after every test. This results in a rather unmanageable
number of tabs on the slave machine after a while.

I still have all master tests failing.




On Thu, Dec 12, 2013 at 10:42 AM, David Kemp  wrote:

> From the perspective of the js tests, medic (testing master) does:
> - rm -rf ~/.cordova/lib/ios (this ensures no cached crap)
> - use coho to checkout the sources into a clean directory
> - cd into cordova-js
> - git checkout master (for the release branch this currently checks out
> 3.2.x)
> - npm install
> - grunt
>
> running on Mavericks, Xcode 5.01
>
>
>
>
>
>
> On Thu, Dec 12, 2013 at 10:29 AM, Brian LeRoux  wrote:
>
>> Still? How do I reproduce?
>> On Dec 13, 2013 2:28 AM, "David Kemp"  wrote:
>>
>> > Sorry - I did sort of forget to say which test..
>> >
>> > Yes the failure is in cordova-js.
>> >
>> >
>> >
>> >
>> > On Thu, Dec 12, 2013 at 10:15 AM, Brian LeRoux  wrote:
>> >
>> > > cordova-js ?? (Should be passing now but gruntfile was refactored.)
>> > > On Dec 13, 2013 12:06 AM, "David Kemp"  wrote:
>> > >
>> > > > last night a commit to change tests seems to have created a problem
>> > with
>> > > > the iOS and android testing. The grunt test for iOS failed with:
>> > > >
>> > > > deviceready has not fired after 5 seconds.
>> > > >
>> > > > Channel not fired: onNativeReady
>> > > > Channel not fired: onCordovaReady
>> > > > command timed out: 1200 seconds without output, attempting to kill
>> > > >
>> > > > The Android test didn't get that far because it tried to start the
>> test
>> > > > concurrently with the iOS test and :
>> > > >
>> > > > starting browser-based tests
>> > > > Test Server running on:
>> > > > http://127.0.0.1:3000
>> > > >
>> > > >  [31mFatal error: listen EADDRINUSE
>> > > >
>> > >
>> >
>>
>
>

[Contacts] Should remove a missing contact be an error?

[Piotr Zalewa]

Hi,

I've been implementing Contacts API proxy on Firefox OS and been asked 
if there is a reason for calling error callback on removing a non 
existing contact.


FFOS is calling success.

Let mi quote Ben Kelly :
"Hmm, does the spec actually call this out as an error?  I find success 
in the "remove a non-existent entry" case more intuitive.  The client 
asked for the state where the DB does not contain X and open completion 
the DB does not contain X.  Whether any work is done is not really 
relevant to the caller, is it?"

https://bugzilla.mozilla.org/show_bug.cgi?id=949575#c1

We might consider changing that behaviour in FFOS if there is a good reason.

Thanks
--
Piotr Zalewa
Mozilla

Re: [proposal] Deprecate WP7 as a target platform

[Jesse]

I am considering this to have passed.

Writing up a blog post about it, as well as adding the deprecation notice
to WP7.

@purplecabbage
risingj.com


On Tue, Nov 19, 2013 at 1:54 PM, Olivier Bloch (MS OPEN TECH) <
obl...@microsoft.com> wrote:

> +1
>
> I think it is ok to deprecate WP7 considering WP developers already have
> to decide dropping WP7 support for their apps when using WP8 specific
> features. Also devs can still count on earlier versions of Cordova to
> deploy their apps to WP7.
>
> That will certainly give the great team working on WP support the
> opportunity to spend more time on WP8. (I can hear Jesse and Sergey
> cheering from here... :-))
>
> ---
> Olivier Bloch
> Microsoft Open Technologies, Inc.
>
>
> -Original Message-
> From: Dick Van den Brink [mailto:d_vandenbr...@outlook.com]
> Sent: Monday, November 18, 2013 11:48 PM
> To: dev@cordova.apache.org
> Subject: RE: [proposal] Deprecate WP7 as a target platform
>
> +1
>
> Sent from my Windows Phone
> 
> From: Michael Brooks
> Sent: 11/18/2013 23:54
> To: dev@cordova.apache.org
> Subject: Re: [proposal] Deprecate WP7 as a target platform
>
> +1
>
>
> On Mon, Nov 18, 2013 at 2:12 PM, Brian LeRoux  wrote:
>
> > +1
> >
> >
> > On Mon, Nov 18, 2013 at 1:53 PM, RUDD, Brett 
> wrote:
> >
> > > +1
> > >
> > >
> > > -Brett
> > >
> > >
> > > On Mon, Nov 18, 2013 at 1:29 PM, Herm Wong
> > >  > > >wrote:
> > >
> > > > +1
> > > >
> > > > > Date: Mon, 18 Nov 2013 13:00:27 -0800
> > > > > Subject: Re: [proposal] Deprecate WP7 as a target platform
> > > > > From: lorin.beer@gmail.com
> > > > > To: dev@cordova.apache.org
> > > > >
> > > > > +1
> > > > >
> > > > >
> > > > > On Mon, Nov 18, 2013 at 12:43 PM, Sergey Grebnov (Akvelon) <
> > > > > v-seg...@microsoft.com> wrote:
> > > > >
> > > > > > +1
> > > > > >
> > > > > > Some interesting usage statistics:
> > > > > >
> > > >
> > http://blog.adduplex.com/2013/09/adduplex-windows-phone-statistics.htm
> > l
> > > > > >
> > > > > > -Sergey
> > > > > > -Original Message-
> > > > > > From: Steven Gill [mailto:stevengil...@gmail.com]
> > > > > > Sent: Tuesday, November 19, 2013 12:42 AM
> > > > > > To: dev@cordova.apache.org
> > > > > > Subject: Re: [proposal] Deprecate WP7 as a target platform
> > > > > >
> > > > > > +1
> > > > > >
> > > > > >
> > > > > > On Mon, Nov 18, 2013 at 12:22 PM, Jesse
> > > > > > 
> > > > wrote:
> > > > > >
> > > > > > > I would like to add a deprecation notice to WP7, so we can
> > > > > > > move forward with one platform for Windows Phone.
> > > > > > > Windows Phone 8 has been available for over a year, and
> > > > > > > mostly
> > > taken
> > > > > > > over for WP7.
> > > > > > > WP7 devices are currently still available, mostly as an
> > inexpensive
> > > > > > > way to get a windows phone.
> > > > > > > The WP8 Lumia 520 has made considerable impact as a low cost
> > > > > > > WP8 device, and Nokia is expected to stop selling WP7
> > > > > > > devices
> > shortly.
> > > > > > > Our ~6 month deprecation windows would put us at May of 2014
> > > > > > > for officially dropping support.
> > > > > > >
> > > > > > > The upgrade path for converting your WP7 Cordova app to WP8
> > Cordova
> > > > is
> > > > > > > trivial, with the exception that it requires updated tools.
> > > > > > > WP8
> > > app
> > > > > > > dev requires Windows 8 and Visual Studio 2012. ( WP7
> > > > > > > required
> > > Windows
> > > > > > > 7 +
> > > > > > > VS-2010 + Zune )
> > > > > > >
> > > > > > >
> > > > > > > @purplecabbage
> > > > > > > risingj.com
> > > > > > >
> > > > > >
> > > >
> > > >
> > >
> >
>

Re: 3.3.0 Release

[Steven Gill]

The docs will also be going out today :).

I will review your pull requests after lunch and catch you on IRC.


On Thu, Dec 12, 2013 at 12:19 PM, David Barth wrote:

> Le 12/12/2013 14:34, David Barth a écrit :
>
>
>>> Other platforms ran into the permission issue you mentioned. I think
>>> https://issues.apache.org/jira/browse/CB-3812 should have fixed it.
>>> Maybe
>>> others can chime in with some suggestions here too.
>>>
>> Yes, I couldn't re-install support for android in a test example either.
>> This will help.
>>
>
> Switching to shelljs@2.0.6 fixes the issue
>
> So, from a runtime perspective, we're just a few pull request from a +1
> here for Ubuntu.
> https://github.com/apache/cordova-ubuntu/pull/4
>
> I'll send 2 more pull requests for the doc. Not sure if that is tagged the
> same day.
>
> David
>

Re: 3.3.0 Release

[David Barth]

Le 12/12/2013 14:34, David Barth a écrit :


Other platforms ran into the permission issue you mentioned. I think
https://issues.apache.org/jira/browse/CB-3812 should have fixed it. 
Maybe

others can chime in with some suggestions here too.
Yes, I couldn't re-install support for android in a test example 
either. This will help.


Switching to shelljs@2.0.6 fixes the issue

So, from a runtime perspective, we're just a few pull request from a +1 
here for Ubuntu.

https://github.com/apache/cordova-ubuntu/pull/4

I'll send 2 more pull requests for the doc. Not sure if that is tagged 
the same day.


David

Re: Transitioning to a better File API implementation

[Shazron]

Reminds me of the iOS LocalStorage (CDVLocalStorage plugin) bs that needed
to be handled - we definitely need a migration path (automatic hopefully)
if not users are in for a world of hurt...


On Wed, Dec 11, 2013 at 11:33 AM, Tommy Williams  wrote:

> +1
> On 12/12/2013 6:26 am, "Ian Clelland"  wrote:
>
> > Yeah, it would definitely require some kind of migration support. Not
> > suggesting that this is something that we ever actually do, but we could
> > give developers a bit of code that automatically looks in both places,
> and
> > moves files to the new location on open. Or we do it under a flag that is
> > off for existing apps (off-on-upgrade) and only enabled-by-default for
> new
> > apps.
> >
> > I agree with you: this could cause worlds of pain, with developers, and
> > worse with users. We shouldn't take any steps in that direction without a
> > lot of very careful thought. For now, /Documents, sub-optimal though it
> may
> > be, is where Cordova puts persistent files.
> >
> > Ian
> >
> > On Wed, Dec 11, 2013 at 2:18 PM, Tommy Williams 
> > wrote:
> >
> > > Changing where PERSISTENT is located sounds like a very very bad idea.
> > >
> > > I know that would cause me personally a lot of grief with existing user
> > > data.
> > > On 11/12/2013 8:58 am, "Ian Clelland"  wrote:
> > >
> > > > On Tue, Dec 10, 2013 at 4:37 PM, Michael Gauthier <
> > m...@silverorange.com
> > > > >wrote:
> > > >
> > > > > On 10/12/13 05:02 PM, Ian Clelland wrote:
> > > > >
> > > > >> Yep.
> > > > >>
> > > > >> I think that Library is the more natural place for the HTML
> > persistent
> > > > >> filesystem, since it's used by an app for whatever persistent
> > storage
> > > it
> > > > >> needs, without exposing all of it's implementation details to the
> > > user.
> > > > >> (There's lots of room for debate on this, I'm sure)
> > > > >>
> > > > >> The trouble is that we've historically used /Documents for
> > persistent
> > > > >> storage, and changing that will break apps.
> > > > >>
> > > > >>  I'm fine with a BC break, but I don't have to maintain any legacy
> > > > > applications. /Library does make more sense as the default for
> > > > PERSISTENT.
> > > > > The big problem with BC is for installed apps with existing data on
> > the
> > > > > filesystem, right?
> > > >
> > > >
> > > > Exactly. I'd hate for developers to update their plugins, and push a
> > new
> > > > version of their app that seems fine -- everything works great when
> you
> > > > start from scratch -- but users with existing data find themselves
> > > > completely locked out of it.
> > > >
> > > >
> > > > >
> > > > >  One idea is to allow something like requestFilesystem(DOCUMENT),
> in
> > > > >> addition to PERSISTENT and TEMPORARY. Another suggestion has been
> to
> > > add
> > > > >> extra arguments -- hints -- such as "{sync: true}", or maybe in
> this
> > > > case
> > > > >> "{purpose: documents}" to specify the attributes of the filesystem
> > > that
> > > > is
> > > > >> returned.
> > > > >>
> > > > > >
> > > > > {sync: true} is a bit tricky because /Library/Cache is not synced
> but
> > > > > /Library/Application Data is synced. Having a DOCUMENT type would
> > match
> > > > > /tmp and /Library as the top-level dirs mapping to file-system
> > > constants.
> > > > >
> > > > > All my feedback is only from the iOS perspective though. Not sure
> if
> > > > these
> > > > > ideas make other platforms more or less complicated.
> > > > >
> > > > > Cheers,
> > > > > Mike
> > > > >
> > > > >
> > > > >>
> > > > >>
> > > > >> On Tue, Dec 10, 2013 at 2:39 PM, Michael Gauthier <
> > > > m...@silverorange.com
> > > > >> >wrote:
> > > > >>
> > > > >>  Hmm.. The two directories have different defined roles on iOS and
> > > both
> > > > >>> are
> > > > >>> normal targets for applications to read/write files. Library is
> for
> > > > cache
> > > > >>> data or app-specific resources. Documents is for saving/loading
> > > actual
> > > > >>> things created by users within apps.
> > > > >>>
> > > > >>> See https://developer.apple.com/library/ios/documentation/
> > > > >>>
> > > >
> > FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/
> > > > >>> FileSystemOverview.html#//apple_ref/doc/uid/TP40010672-CH2-SW14
> > > > >>>
> > > > >>> Supporting both should be a goal.
> > > > >>>
> > > > >>> Cheers,
> > > > >>> Mike
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> On 2013-12-10 14:39, Ian Clelland wrote:
> > > > >>>
> > > > >>>  If you could do that before, it was probably a bug :) (You
> > shouldn't
> > > > be
> > > >  able to use getParent on the filesystem root, and the native
> code
> > > was
> > > >  supposed to be checking for the correct path prefix before
> > allowing
> > > >  access
> > > >  to any files on the device)
> > > > 
> > > >  At the moment, it's not possible to do that -- the filesystems
> > > should
> > > > be
> > > >  properly isolated, and only allow access to correctly formed
> urls,
> > > > li

Re: 3.3.0 Release

[Shazron]

Thanks for looking at iOS James
3.3 iOS is essentially 3.2 since most of the work has gone into plugins.
I will be tagging 3.3 iOS final soon.


On Thu, Dec 12, 2013 at 5:34 AM, David Barth wrote:

> Le 11/12/2013 23:49, Steven Gill a écrit :
>
>  The master branch on CLI now depends on the correct plugman. That problem
>> should be good.
>>
>> I will review the two pull requests and merge in if they look good.
>>
> And there is a 3rd one to make it run more reliably:
> https://github.com/Zaspire/cordova-ubuntu/commit/
> faff5d6f1d710426181ea966bf88214ff076d91f
>
>
>> I am not sure about the CLI not honoring the dependencies expressed in
>> package.json. I don't think the CLI has any logic to do that. I think it
>> should be handled in a platform level script. Maybe force npm install
>> before the create command runs? Maybe create an init script like
>> blackberry10 has and run that while running check reqs? Others might have
>> better suggestions for this one.
>>
> Carlos clarified things. The pull requests above are going in the same
> direction, ie ensuring the installation of dependencies by the platform
> scripts themselves.
>
>
>
>> Other platforms ran into the permission issue you mentioned. I think
>> https://issues.apache.org/jira/browse/CB-3812 should have fixed it. Maybe
>> others can chime in with some suggestions here too.
>>
> Yes, I couldn't re-install support for android in a test example either.
> This will help.
>
> David
>

Re: plugins.cordova.io: UX redesign

[Ken Wallis]

Looks awesome, great work and sorely needed!

I assume the filter is an ³and² operation?


-- 
Ken Wallis
Senior Product Manager - WebWorks
BlackBerry
650-620-2404





-Original Message-
From: Steven Gill 
Reply-To: "dev@cordova.apache.org" 
Date: Thursday, December 12, 2013 at 11:46 AM
To: "dev@cordova.apache.org" 
Subject: Re: plugins.cordova.io: UX redesign

>Awesome Job Joni!  Love it!
>
>Carlos, I think the plan for 3 is to display the readme npm style. Good
>suggestion ;). A template to give out would be a great idea. Maybe it gets
>generated in the plugin create command (did that ever make it in?)
>
>
>On Thu, Dec 12, 2013 at 11:36 AM, Josh Soref 
>wrote:
>
>> Jesse wrote:
>> - Search prominence is great,
>>
>>
>> but I am confused about the difference
>> between what the 'Find Plugins' link at the top does, and the search
>>box.
>>
>> I was confused too (+1)
>>
>> - Contribute, and Utilize seem to be given too much prominence here, and
>>
>> +1
>>
>> I'm not crazy about the word 'Utilize'.
>>
>> +1
>>
>>   Maybe 'Get Started' with subs of 'Publish a plugin' and 'Install a
>> plugin' ... ?
>>
>> - Plugin listing by ID seems overly geeky, can't we use the Name field?
>>
>> +1
>>
>> can we include latest published date,
>>
>> +1
>>
>> - It would be awesome if we could add some sort of image/logo to the
>> publish process,
>>
>> +1
>> -
>> 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.
>>
>>

-
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: plugins.cordova.io: UX redesign

[Steven Gill]

Awesome Job Joni!  Love it!

Carlos, I think the plan for 3 is to display the readme npm style. Good
suggestion ;). A template to give out would be a great idea. Maybe it gets
generated in the plugin create command (did that ever make it in?)


On Thu, Dec 12, 2013 at 11:36 AM, Josh Soref  wrote:

> Jesse wrote:
> - Search prominence is great,
>
>
> but I am confused about the difference
> between what the 'Find Plugins' link at the top does, and the search box.
>
> I was confused too (+1)
>
> - Contribute, and Utilize seem to be given too much prominence here, and
>
> +1
>
> I'm not crazy about the word 'Utilize'.
>
> +1
>
>   Maybe 'Get Started' with subs of 'Publish a plugin' and 'Install a
> plugin' ... ?
>
> - Plugin listing by ID seems overly geeky, can't we use the Name field?
>
> +1
>
> can we include latest published date,
>
> +1
>
> - It would be awesome if we could add some sort of image/logo to the
> publish process,
>
> +1
> -
> 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: plugins.cordova.io: UX redesign

[Josh Soref]

Jesse wrote:
- Search prominence is great,


but I am confused about the difference
between what the 'Find Plugins' link at the top does, and the search box.

I was confused too (+1)

- Contribute, and Utilize seem to be given too much prominence here, and

+1

I'm not crazy about the word 'Utilize'.

+1

  Maybe 'Get Started' with subs of 'Publish a plugin' and 'Install a plugin' 
... ?

- Plugin listing by ID seems overly geeky, can't we use the Name field?

+1

can we include latest published date,

+1

- It would be awesome if we could add some sort of image/logo to the
publish process,

+1
-
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: plugins.cordova.io: UX redesign

[Jesse]

Looks good Joni.  Great tone, character and feel.
Some of the utilitarian pieces I think need fine tuning.

Re: 1. ( opinions, which may be misguided )
- Search prominence is great, but I am confused about the difference
between what the 'Find Plugins' link at the top does, and the search box.
- Contribute, and Utilize seem to be given too much prominence here, and
I'm not crazy about the word 'Utilize'.  Maybe 'Get Started' with subs of
'Publish a plugin' and 'Install a plugin' ... ?
- Plugin listing by ID seems overly geeky, can't we use the Name field?

Re: 2.
- The Version column does not seem very useful, can we include latest
published date, or is there some author information?

Re: 3
- Perfect!
- It would be awesome if we could add some sort of image/logo to the
publish process, as we are going to be stuck with a very texty site
otherwise.


I think the nuget site is a very good example of a site based on doing a
very similar thing.
http://www.nuget.org/
Here is what knockoutjs looks like there:
http://www.nuget.org/packages/knockoutjs/




@purplecabbage
risingj.com


On Thu, Dec 12, 2013 at 8:17 AM, Max Woghiren  wrote:

> Looks great indeed!
>
>
> On Wed, Dec 11, 2013 at 10:26 PM, Joni Rustulka  wrote:
>
> > Hi all,
> >
> > I'm Joni. I work at Adobe as a UX designer on the PhoneGap team, and I
> > have recently thrown some time at redesigning the
> > http://plugins.cordova.io site. I'm looking for feedback prior to
> > implementation - your thoughts are appreciated.
> >
> > The main screens that have been reworked are as follows:
> >
> >
> >   1.  Home (http://cl.ly/image/2n3l1N0Z0g0w)
> > The primary goal for the site is to help users find the plugins they
> need.
> > As such, the main focus is on search/findability.
> >
> >   2.  Search Results (http://cl.ly/image/0c3X3T1E1L0j)
> > Upon search for a plugin, the user is returned results. The user can
> > filter to include only desired platforms (
> http://cl.ly/image/3W2f321I211r),
> > and the results table can be sorted by number of downloads, or plugin ID.
> >
> >   3.  Plugin Details (http://cl.ly/image/2n1p2s3E0a2t)
> > The details screen intends to provide all of the necessary information on
> > a plugin.
> > ** From what I understand, one piece of information that may be missing
> > from this screen is "Installation Instructions". This being, config.xml
> > feature tags. Is this something that you guys plan to automate, or should
> > we be telling plugin authors to put this information in their Read Me?
> > Please advise.
> >
> > Further, we do intend to make this a responsive site - so it will be
> > easily viewed on smaller screen sizes.
> >
> > Thanks for your input,
> > -joni
> >
> >
> > PS - big thanks and kudos to Yohei for putting together the pluggy robot!
> >
> >
> >
>

Re: failing tests / experiment to move to phantomjs for testing cordovajs

[Bryan Bishop]

On Thu, Dec 12, 2013 at 4:38 AM, Brian LeRoux  wrote:

> ideally the solution is drop in, closer to what the env we're targeting,
> and has an IE analogue
>

There's the pyjamas framework, which has MSHTML integration. But the
downside is that pyjamas' webkitgtk+ integration has been lagging for a
while and would need to be rebuilt.

- Bryan
http://heybryan.org/
1 512 203 0507

Re: plugins.cordova.io: UX redesign

[Max Woghiren]

Looks great indeed!


On Wed, Dec 11, 2013 at 10:26 PM, Joni Rustulka  wrote:

> Hi all,
>
> I'm Joni. I work at Adobe as a UX designer on the PhoneGap team, and I
> have recently thrown some time at redesigning the
> http://plugins.cordova.io site. I'm looking for feedback prior to
> implementation - your thoughts are appreciated.
>
> The main screens that have been reworked are as follows:
>
>
>   1.  Home (http://cl.ly/image/2n3l1N0Z0g0w)
> The primary goal for the site is to help users find the plugins they need.
> As such, the main focus is on search/findability.
>
>   2.  Search Results (http://cl.ly/image/0c3X3T1E1L0j)
> Upon search for a plugin, the user is returned results. The user can
> filter to include only desired platforms (http://cl.ly/image/3W2f321I211r),
> and the results table can be sorted by number of downloads, or plugin ID.
>
>   3.  Plugin Details (http://cl.ly/image/2n1p2s3E0a2t)
> The details screen intends to provide all of the necessary information on
> a plugin.
> ** From what I understand, one piece of information that may be missing
> from this screen is "Installation Instructions". This being, config.xml
> feature tags. Is this something that you guys plan to automate, or should
> we be telling plugin authors to put this information in their Read Me?
> Please advise.
>
> Further, we do intend to make this a responsive site - so it will be
> easily viewed on smaller screen sizes.
>
> Thanks for your input,
> -joni
>
>
> PS - big thanks and kudos to Yohei for putting together the pluggy robot!
>
>
>

Re: Medic CI failures

[David Kemp]

>From the perspective of the js tests, medic (testing master) does:
- rm -rf ~/.cordova/lib/ios (this ensures no cached crap)
- use coho to checkout the sources into a clean directory
- cd into cordova-js
- git checkout master (for the release branch this currently checks out
3.2.x)
- npm install
- grunt

running on Mavericks, Xcode 5.01






On Thu, Dec 12, 2013 at 10:29 AM, Brian LeRoux  wrote:

> Still? How do I reproduce?
> On Dec 13, 2013 2:28 AM, "David Kemp"  wrote:
>
> > Sorry - I did sort of forget to say which test..
> >
> > Yes the failure is in cordova-js.
> >
> >
> >
> >
> > On Thu, Dec 12, 2013 at 10:15 AM, Brian LeRoux  wrote:
> >
> > > cordova-js ?? (Should be passing now but gruntfile was refactored.)
> > > On Dec 13, 2013 12:06 AM, "David Kemp"  wrote:
> > >
> > > > last night a commit to change tests seems to have created a problem
> > with
> > > > the iOS and android testing. The grunt test for iOS failed with:
> > > >
> > > > deviceready has not fired after 5 seconds.
> > > >
> > > > Channel not fired: onNativeReady
> > > > Channel not fired: onCordovaReady
> > > > command timed out: 1200 seconds without output, attempting to kill
> > > >
> > > > The Android test didn't get that far because it tried to start the
> test
> > > > concurrently with the iOS test and :
> > > >
> > > > starting browser-based tests
> > > > Test Server running on:
> > > > http://127.0.0.1:3000
> > > >
> > > >  [31mFatal error: listen EADDRINUSE
> > > >
> > >
> >
>

Re: Medic CI failures

[Brian LeRoux]

Still? How do I reproduce?
On Dec 13, 2013 2:28 AM, "David Kemp"  wrote:

> Sorry - I did sort of forget to say which test..
>
> Yes the failure is in cordova-js.
>
>
>
>
> On Thu, Dec 12, 2013 at 10:15 AM, Brian LeRoux  wrote:
>
> > cordova-js ?? (Should be passing now but gruntfile was refactored.)
> > On Dec 13, 2013 12:06 AM, "David Kemp"  wrote:
> >
> > > last night a commit to change tests seems to have created a problem
> with
> > > the iOS and android testing. The grunt test for iOS failed with:
> > >
> > > deviceready has not fired after 5 seconds.
> > >
> > > Channel not fired: onNativeReady
> > > Channel not fired: onCordovaReady
> > > command timed out: 1200 seconds without output, attempting to kill
> > >
> > > The Android test didn't get that far because it tried to start the test
> > > concurrently with the iOS test and :
> > >
> > > starting browser-based tests
> > > Test Server running on:
> > > http://127.0.0.1:3000
> > >
> > >  [31mFatal error: listen EADDRINUSE
> > >
> >
>

Re: Medic CI failures

[David Kemp]

Sorry - I did sort of forget to say which test..

Yes the failure is in cordova-js.




On Thu, Dec 12, 2013 at 10:15 AM, Brian LeRoux  wrote:

> cordova-js ?? (Should be passing now but gruntfile was refactored.)
> On Dec 13, 2013 12:06 AM, "David Kemp"  wrote:
>
> > last night a commit to change tests seems to have created a problem with
> > the iOS and android testing. The grunt test for iOS failed with:
> >
> > deviceready has not fired after 5 seconds.
> >
> > Channel not fired: onNativeReady
> > Channel not fired: onCordovaReady
> > command timed out: 1200 seconds without output, attempting to kill
> >
> > The Android test didn't get that far because it tried to start the test
> > concurrently with the iOS test and :
> >
> > starting browser-based tests
> > Test Server running on:
> > http://127.0.0.1:3000
> >
> >  [31mFatal error: listen EADDRINUSE
> >
>

Re: Medic CI failures

[Brian LeRoux]

cordova-js ?? (Should be passing now but gruntfile was refactored.)
On Dec 13, 2013 12:06 AM, "David Kemp"  wrote:

> last night a commit to change tests seems to have created a problem with
> the iOS and android testing. The grunt test for iOS failed with:
>
> deviceready has not fired after 5 seconds.
>
> Channel not fired: onNativeReady
> Channel not fired: onCordovaReady
> command timed out: 1200 seconds without output, attempting to kill
>
> The Android test didn't get that far because it tried to start the test
> concurrently with the iOS test and :
>
> starting browser-based tests
> Test Server running on:
> http://127.0.0.1:3000
>
>  [31mFatal error: listen EADDRINUSE
>

Re: plugins.cordova.io: UX redesign

[Mike Billau]

Looks awesome! We've been needing this for a while! Great job, thanks!

+1 to Carlos' suggestion above of providing users a readme.md template that
they can fill out that we just display on the plugin info page. If they
provide nothing, we can probably auto fill this with the registry
information. If they need to provide more information for more complicated
setup, this will be an easy way to provide that info without cramming it in
the description or something else.


On Thu, Dec 12, 2013 at 8:57 AM, Dick Van den Brink <
d_vandenbr...@outlook.com> wrote:

> Nice Joni!
> Really love the plugin robot! :)
>
> Also a +1 for making it responsive.
>
>
>
> > Subject: Re: plugins.cordova.io: UX redesign
> > From: wjamesj...@gmail.com
> > Date: Thu, 12 Dec 2013 08:38:06 -0500
> > CC: yo...@adobe.com
> > To: dev@cordova.apache.org
> >
> > UX looks great!! Thanks for the efforts!
> >
> > 2. For search, perhaps the ability to add/remove filters?
> >
> > +1 to making it responsive
> >
> > -James Jong
> >
> > On Dec 11, 2013, at 10:26 PM, Joni Rustulka  wrote:
> >
> >> Hi all,
> >>
> >> I'm Joni. I work at Adobe as a UX designer on the PhoneGap team, and I
> have recently thrown some time at redesigning the
> http://plugins.cordova.io site. I'm looking for feedback prior to
> implementation - your thoughts are appreciated.
> >>
> >> The main screens that have been reworked are as follows:
> >>
> >>
> >> 1. Home (http://cl.ly/image/2n3l1N0Z0g0w)
> >> The primary goal for the site is to help users find the plugins they
> need. As such, the main focus is on search/findability.
> >>
> >> 2. Search Results (http://cl.ly/image/0c3X3T1E1L0j)
> >> Upon search for a plugin, the user is returned results. The user can
> filter to include only desired platforms (http://cl.ly/image/3W2f321I211r),
> and the results table can be sorted by number of downloads, or plugin ID.
> >>
> >> 3. Plugin Details (http://cl.ly/image/2n1p2s3E0a2t)
> >> The details screen intends to provide all of the necessary information
> on a plugin.
> >> ** From what I understand, one piece of information that may be missing
> from this screen is "Installation Instructions". This being, config.xml
> feature tags. Is this something that you guys plan to automate, or should
> we be telling plugin authors to put this information in their Read Me?
> Please advise.
> >>
> >> Further, we do intend to make this a responsive site - so it will be
> easily viewed on smaller screen sizes.
> >>
> >> Thanks for your input,
> >> -joni
> >>
> >>
> >> PS - big thanks and kudos to Yohei for putting together the pluggy
> robot!
> >>
> >>
> >
>

RE: plugins.cordova.io: UX redesign

[Dick Van den Brink]

Nice Joni!
Really love the plugin robot! :)

Also a +1 for making it responsive.



> Subject: Re: plugins.cordova.io: UX redesign
> From: wjamesj...@gmail.com
> Date: Thu, 12 Dec 2013 08:38:06 -0500
> CC: yo...@adobe.com
> To: dev@cordova.apache.org
> 
> UX looks great!! Thanks for the efforts!
> 
> 2. For search, perhaps the ability to add/remove filters?
> 
> +1 to making it responsive
> 
> -James Jong
> 
> On Dec 11, 2013, at 10:26 PM, Joni Rustulka  wrote:
> 
>> Hi all,
>> 
>> I'm Joni. I work at Adobe as a UX designer on the PhoneGap team, and I have 
>> recently thrown some time at redesigning the http://plugins.cordova.io site. 
>> I'm looking for feedback prior to implementation - your thoughts are 
>> appreciated.
>> 
>> The main screens that have been reworked are as follows:
>> 
>> 
>> 1. Home (http://cl.ly/image/2n3l1N0Z0g0w)
>> The primary goal for the site is to help users find the plugins they need. 
>> As such, the main focus is on search/findability.
>> 
>> 2. Search Results (http://cl.ly/image/0c3X3T1E1L0j)
>> Upon search for a plugin, the user is returned results. The user can filter 
>> to include only desired platforms (http://cl.ly/image/3W2f321I211r), and the 
>> results table can be sorted by number of downloads, or plugin ID.
>> 
>> 3. Plugin Details (http://cl.ly/image/2n1p2s3E0a2t)
>> The details screen intends to provide all of the necessary information on a 
>> plugin.
>> ** From what I understand, one piece of information that may be missing from 
>> this screen is "Installation Instructions". This being, config.xml feature 
>> tags. Is this something that you guys plan to automate, or should we be 
>> telling plugin authors to put this information in their Read Me? Please 
>> advise.
>> 
>> Further, we do intend to make this a responsive site - so it will be easily 
>> viewed on smaller screen sizes.
>> 
>> Thanks for your input,
>> -joni
>> 
>> 
>> PS - big thanks and kudos to Yohei for putting together the pluggy robot!
>> 
>> 
> 

Re: plugins.cordova.io: UX redesign

[Bryan Higgins]

Those comps look great Joni! Nice work!

The details page needs a way to view prior versions.


On Thu, Dec 12, 2013 at 8:38 AM, James Jong  wrote:

> UX looks great!!  Thanks for the efforts!
>
> 2. For search, perhaps the ability to add/remove filters?
>
> +1 to making it responsive
>
> -James Jong
>
> On Dec 11, 2013, at 10:26 PM, Joni Rustulka  wrote:
>
> > Hi all,
> >
> > I'm Joni. I work at Adobe as a UX designer on the PhoneGap team, and I
> have recently thrown some time at redesigning the
> http://plugins.cordova.io site. I'm looking for feedback prior to
> implementation - your thoughts are appreciated.
> >
> > The main screens that have been reworked are as follows:
> >
> >
> >  1.  Home (http://cl.ly/image/2n3l1N0Z0g0w)
> > The primary goal for the site is to help users find the plugins they
> need. As such, the main focus is on search/findability.
> >
> >  2.  Search Results (http://cl.ly/image/0c3X3T1E1L0j)
> > Upon search for a plugin, the user is returned results. The user can
> filter to include only desired platforms (http://cl.ly/image/3W2f321I211r),
> and the results table can be sorted by number of downloads, or plugin ID.
> >
> >  3.  Plugin Details (http://cl.ly/image/2n1p2s3E0a2t)
> > The details screen intends to provide all of the necessary information
> on a plugin.
> > ** From what I understand, one piece of information that may be missing
> from this screen is "Installation Instructions". This being, config.xml
> feature tags. Is this something that you guys plan to automate, or should
> we be telling plugin authors to put this information in their Read Me?
> Please advise.
> >
> > Further, we do intend to make this a responsive site - so it will be
> easily viewed on smaller screen sizes.
> >
> > Thanks for your input,
> > -joni
> >
> >
> > PS - big thanks and kudos to Yohei for putting together the pluggy robot!
> >
> >
>
>

Re: plugins.cordova.io: UX redesign

[James Jong]

UX looks great!!  Thanks for the efforts!

2. For search, perhaps the ability to add/remove filters?

+1 to making it responsive

-James Jong

On Dec 11, 2013, at 10:26 PM, Joni Rustulka  wrote:

> Hi all,
> 
> I'm Joni. I work at Adobe as a UX designer on the PhoneGap team, and I have 
> recently thrown some time at redesigning the http://plugins.cordova.io site. 
> I'm looking for feedback prior to implementation - your thoughts are 
> appreciated.
> 
> The main screens that have been reworked are as follows:
> 
> 
>  1.  Home (http://cl.ly/image/2n3l1N0Z0g0w)
> The primary goal for the site is to help users find the plugins they need. As 
> such, the main focus is on search/findability.
> 
>  2.  Search Results (http://cl.ly/image/0c3X3T1E1L0j)
> Upon search for a plugin, the user is returned results. The user can filter 
> to include only desired platforms (http://cl.ly/image/3W2f321I211r), and the 
> results table can be sorted by number of downloads, or plugin ID.
> 
>  3.  Plugin Details (http://cl.ly/image/2n1p2s3E0a2t)
> The details screen intends to provide all of the necessary information on a 
> plugin.
> ** From what I understand, one piece of information that may be missing from 
> this screen is "Installation Instructions". This being, config.xml feature 
> tags. Is this something that you guys plan to automate, or should we be 
> telling plugin authors to put this information in their Read Me? Please 
> advise.
> 
> Further, we do intend to make this a responsive site - so it will be easily 
> viewed on smaller screen sizes.
> 
> Thanks for your input,
> -joni
> 
> 
> PS - big thanks and kudos to Yohei for putting together the pluggy robot!
> 
> 

Re: 3.3.0 Release

[David Barth]

Le 11/12/2013 23:49, Steven Gill a écrit :

The master branch on CLI now depends on the correct plugman. That problem
should be good.

I will review the two pull requests and merge in if they look good.

And there is a 3rd one to make it run more reliably:
https://github.com/Zaspire/cordova-ubuntu/commit/faff5d6f1d710426181ea966bf88214ff076d91f


I am not sure about the CLI not honoring the dependencies expressed in
package.json. I don't think the CLI has any logic to do that. I think it
should be handled in a platform level script. Maybe force npm install
before the create command runs? Maybe create an init script like
blackberry10 has and run that while running check reqs? Others might have
better suggestions for this one.
Carlos clarified things. The pull requests above are going in the same 
direction, ie ensuring the installation of dependencies by the platform 
scripts themselves.




Other platforms ran into the permission issue you mentioned. I think
https://issues.apache.org/jira/browse/CB-3812 should have fixed it. Maybe
others can chime in with some suggestions here too.
Yes, I couldn't re-install support for android in a test example either. 
This will help.


David

Re: 3.3.0 Release

[David Barth]

Le 12/12/2013 03:21, Carlos Santana a écrit :

CLI design contract is to just run platforms//bin/create nothing
about running npm install on platform repo files.

If your platform scripts have dependencies platform is responsible to
satisfy its dependencies.

BlackBerry and Android have dependencies on npm modules, both handle
differently

Android include npm dependencies in the repo
https://github.com/apache/cordova-android/tree/master/bin/node_modules

BlackBerry runs npm install to install on demand as part of create script
https://github.com/apache/cordova-blackberry/blob/master/blackberry10/bin/create#L38

hope this clarifies

Thanks Carlos, it does.

David

Medic CI failures

[David Kemp]

last night a commit to change tests seems to have created a problem with
the iOS and android testing. The grunt test for iOS failed with:

deviceready has not fired after 5 seconds.

Channel not fired: onNativeReady
Channel not fired: onCordovaReady
command timed out: 1200 seconds without output, attempting to kill

The Android test didn't get that far because it tried to start the test
concurrently with the iOS test and :

starting browser-based tests
Test Server running on:
http://127.0.0.1:3000

Fatal error: listen EADDRINUSE

Re: plugins.cordova.io: UX redesign

[Tommy-Carlos Williams]

That. Is. So. Exciting!

Also, PLUGIN ROBOT


On 12 Dec 2013, at 2:26 pm, Joni Rustulka  wrote:

> Hi all,
> 
> I'm Joni. I work at Adobe as a UX designer on the PhoneGap team, and I have 
> recently thrown some time at redesigning the http://plugins.cordova.io site. 
> I'm looking for feedback prior to implementation - your thoughts are 
> appreciated.
> 
> The main screens that have been reworked are as follows:
> 
> 
>  1.  Home (http://cl.ly/image/2n3l1N0Z0g0w)
> The primary goal for the site is to help users find the plugins they need. As 
> such, the main focus is on search/findability.
> 
>  2.  Search Results (http://cl.ly/image/0c3X3T1E1L0j)
> Upon search for a plugin, the user is returned results. The user can filter 
> to include only desired platforms (http://cl.ly/image/3W2f321I211r), and the 
> results table can be sorted by number of downloads, or plugin ID.
> 
>  3.  Plugin Details (http://cl.ly/image/2n1p2s3E0a2t)
> The details screen intends to provide all of the necessary information on a 
> plugin.
> ** From what I understand, one piece of information that may be missing from 
> this screen is "Installation Instructions". This being, config.xml feature 
> tags. Is this something that you guys plan to automate, or should we be 
> telling plugin authors to put this information in their Read Me? Please 
> advise.
> 
> Further, we do intend to make this a responsive site - so it will be easily 
> viewed on smaller screen sizes.
> 
> Thanks for your input,
> -joni
> 
> 
> PS - big thanks and kudos to Yohei for putting together the pluggy robot!
> 
> 

Re: plugins.cordova.io: UX redesign

[Josh Soref]

I think I may want plugins compatible with Cordova version X or license Y. 

(License may be "not in Z...")‎
-
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: failing tests / experiment to move to phantomjs for testing cordovajs

[Brian LeRoux]

well, we use whatever browser is default currently or we run in jsdom but I
suspect neither gets run very often given the tests I'm seeing

(frankly this part of the platform has been rather static for a while)

ideally the solution is drop in, closer to what the env we're targeting,
and has an IE analogue

so far nothing is looking very promising which kind of sucks


On Thu, Dec 12, 2013 at 6:22 PM, Bryan Bishop  wrote:

> On Thu, Dec 12, 2013 at 12:11 AM, Brian LeRoux  wrote:
>
> > The tests all pass in Chrome and Node but some are failing in Phantom.
> >
>
> PhantomJS is using a fairly old version of qtwebkit
> (Function.prototype.bind is missing, for example). Is there any reason you
> can't use upstream webkit to do testing? For example, webkitgtk+ has pretty
> good bindings into any language supported by gobject/gir stuff.
>
> - Bryan
> http://heybryan.org/
> 1 512 203 0507
>