date:20140619

GitHub user vladimir-kotikov opened a pull request:

https://github.com/apache/cordova-wp8/pull/42

CB-6977 Support chip architecture as an option for run command for Windows 
and Windows Phone projects

Implementation for [CB-6977](https://issues.apache.org/jira/browse/CB-6977)

* Adds support for `--archs` option to `run` command.
* Adds ability to CordovaDeploy to deploy specific .xap file.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/MSOpenTech/cordova-wp8 CB-6977

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-wp8/pull/42.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #42


commit 91811549d82c035d924838da860d05f3abc5903d
Author: Vladimir Kotikov v-vlk...@microsoft.com
Date:   2014-06-18T11:56:19Z

Adds support for chip architectures to run command




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

RE: Support for Windows Universal apps (Windows 8.1 and Windows Phone 8.1)

2014-06-19 Thread Sergey Grebnov (Akvelon)

Created new feature to track this work - CB-6976 Add support for Windows 
Universal apps (Windows 8.1 and WP 8.1)

Should we create a new Jira component specially for this? Windows Universal 
apps vs Windows 8.1 vs Windows?

I personally prefer just Windows since:
1. this is what we target to - single 'windows' platform and single 'windows' 
tag (similar to iOS where we don't have separate iPhone/iPad components);
2. easy to use/understand for developers. For example, w/o knowing what Windows 
Universal apps are it will be hard for developers to report new issue and 
assign correct component.

Thoughts?

Thx!
Sergey
-Original Message-
From: Jesse [mailto:purplecabb...@gmail.com] 
Sent: Tuesday, June 17, 2014 5:20 AM
To: dev@cordova.apache.org
Subject: Re: Support for Windows Universal apps (Windows 8.1 and Windows Phone 
8.1)

I have discussed this at length already with Parashuram and completely support 
the proposal as documented, which might not be evident from just looking at the 
docs and links.
Since there has not been much action on this item, I think we are okay to just 
move ahead Parashuram.

Let's consider this last call.

Cheers,
  Jesse


@purplecabbage
risingj.com


On Thu, Jun 12, 2014 at 12:21 PM, Parashuram Narasimhan (MS OPEN TECH)  
panar...@microsoft.com wrote:

 Hi,

 With Windows 8.1 and Windows Phone 8.1 platforms released, it would be 
 great to get Cordova support building apps for those platforms too. A 
 lot of people on this list have also been talking about how to adapt 
 existing apps to the new 8.1 platforms. Here is an initial proposal 
 and prototype of how it may look.

 TL;DR; - Rename windows8 platform to be called windows. This platform 
 can build apps for Windows 8, Windows 8.1 and Windows Phone 8.1. 
 Window Phone 8
 (wp8) stays as a platform.

 Link to the document -
 https://onedrive.live.com/redir?resid=DEA20E6DC28C96DD!2781authkey=!A
 Pz1za6lnJhsaaQithint=file%2c.docx

 Prototype Code
 - https://github.com/msopentech/cordova-cli/tree/win81
 - https://github.com/msopentech/cordova-windows/tree/win81
 - https://github.com/msopentech/cordova-lib/tree/win81


 As discussed in the Cordova hangouts yesterday, we could have a 
 mini-hangout for discussing this in a more focused manner.

 Please reply to this thread if you are interested in this and I could 
 set up the hangouts.

[GitHub] cordova-windows pull request: Adds support for build archs to run ...

GitHub user vladimir-kotikov opened a pull request:

https://github.com/apache/cordova-windows/pull/34

Adds support for build archs to run command

Implementation for [CB-6977](https://issues.apache.org/jira/browse/CB-6977)

Adds support for `--archs` option to `run` command.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/MSOpenTech/cordova-windows CB-6977

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-windows/pull/34.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #34


commit 3d72633d3cb88c290ab8978a8941c6d82d804dbe
Author: Vladimir Kotikov v-vlk...@microsoft.com
Date:   2014-06-18T10:26:20Z

Adds support for build archs to run command




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-medic pull request: CB-6889, CB-6899, CB-6909 Multiple fix...

GitHub user vladimir-kotikov opened a pull request:

https://github.com/apache/cordova-medic/pull/12

CB-6889, CB-6899, CB-6909 Multiple fixes in master.cfg to ensure proper 
work on windows slaves

This includes #9, #10 and #11 with conflicts resolved.
Issues: [CB-6899](https://issues.apache.org/jira/browse/CB-6899), 
[CB-6889](https://issues.apache.org/jira/browse/CB-6889), 
[CB-6909](https://issues.apache.org/jira/browse/CB-6909)

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/MSOpenTech/cordova-medic #493

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-medic/pull/12.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #12


commit 69a6ae92ced92c51cf12ec83b180a24308881bd0
Author: Vladimir Kotikov v-vlk...@microsoft.com
Date:   2014-06-09T11:51:50Z

Change -i sed's argument behaviour, which now works on both mac and 
windows.

commit 8e843e92fee168986859cc34c3adc2302b62e72e
Author: Vladimir Kotikov v-vlk...@microsoft.com
Date:   2014-06-09T13:35:12Z

Removes platform-dependent shellCmd and shellRunParam from master.cfg

commit 71267310940275eb83c8d1b2af1f7c491844fdaf
Author: Vladimir Kotikov v-vlk...@microsoft.com
Date:   2014-06-09T08:57:42Z

Replaces ln -s command, which is not working on windows slaves, with 
inline node script.

commit 4ce33403396ee4edd078bc8bf40a65ca94e79311
Author: Vladimir Kotikov v-vlk...@microsoft.com
Date:   2014-06-19T10:54:37Z

Merge branch 'CB-6889' into #493

commit 75f735a58255c1a75d4fd938273a897df017b32e
Author: Vladimir Kotikov v-vlk...@microsoft.com
Date:   2014-06-19T10:55:05Z

Merge branch 'CB-6909' into #493

commit 628926883ba59fc941c696628276b55b9e590385
Author: Vladimir Kotikov v-vlk...@microsoft.com
Date:   2014-06-19T10:58:18Z

Merge branch 'CB-6899' into #493

Conflicts:
master.cfg




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-medic pull request: CB-6899 Cordova-lib link step fails ...

Github user vladimir-kotikov closed the pull request at:

https://github.com/apache/cordova-medic/pull/9


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-medic pull request: CB-6909 shellCmd and shellRunParam in ...

Github user vladimir-kotikov closed the pull request at:

https://github.com/apache/cordova-medic/pull/11


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-medic pull request: CB-6889 Edit json step in master.cfg...

Github user vladimir-kotikov closed the pull request at:

https://github.com/apache/cordova-medic/pull/10


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-firefoxos pull request: some cleanup and linting

2014-06-19 Thread SunboX

Github user SunboX closed the pull request at:

https://github.com/apache/cordova-firefoxos/pull/2


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

phonegap building issues for ios (Using CLI)

2014-06-19 Thread Fred F Fan

Hi All,

xcode verison : 6 beta
macox version: Mavericks 10.9.3
cordova vresion: 3.5

I got two issues when using CLI add platform, one is xcode-select error the
another one is  Command failed with exit code 2.
Current I am already fixed xcode-select error ,*but I don't know how to fix
the * *Command failed with exit code 2 error.  please give me some
**Suggestions,thanks
for your help.*

*below is debug info:*

fanfq-macbook:hello fanfangqing$ cordova -d platform add ios
cordova library for ios already exists. No need to download. Continuing.
Checking if platform ios passes minimum requirements...
Creating ios project...
Running command:
/Users/fanfangqing/.cordova/lib/ios/cordova/3.5.0/bin/create --arc --cli
/Users/fanfangqing/MyCode/fanfq-html54mobile/phonegap/hello/platforms/ios
com.example.hello HelloWorld
xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer
directory '/Library/Developer/CommandLineTools' is a command line tools
instance
Cordova can only run in Xcode version 4.6 or greater.
Command finished with error code 2:
/Users/fanfangqing/.cordova/lib/ios/cordova/3.5.0/bin/create
--arc,--cli,/Users/fanfangqing/MyCode/fanfq-html54mobile/phonegap/hello/platforms/ios,com.example.hello,HelloWorld
Error: /Users/fanfangqing/.cordova/lib/ios/cordova/3.5.0/bin/create:
Command failed with exit code 2
at ChildProcess.whenDone
(/usr/local/lib/node_modules/cordova/node_modules/cordova-lib/src/cordova/superspawn.js:131:23)
at ChildProcess.emit (events.js:98:17)
at maybeClose (child_process.js:755:16)
at Process.ChildProcess._handle.onexit (child_process.js:822:5)
fanfq-macbook:hello fanfangqing$ cordova platform ls

-- 
Kind Regards,
Fred,Fan Fangqing
P Please consider the environment before printing this email

[GitHub] cordova-plugin-splashscreen pull request: Splashscreen crash on WP...

2014-06-19 Thread sgrebnov

Github user sgrebnov commented on the pull request:


https://github.com/apache/cordova-plugin-splashscreen/pull/20#issuecomment-46556623
  
Merged, thx for the fix. Pls close PR. 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-plugin-splashscreen pull request: Splashscreen crash on WP...

2014-06-19 Thread nadyaA

Github user nadyaA closed the pull request at:

https://github.com/apache/cordova-plugin-splashscreen/pull/20


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-plugin-splashscreen pull request: Splashscreen crash on WP...

2014-06-19 Thread nadyaA

Github user nadyaA commented on the pull request:


https://github.com/apache/cordova-plugin-splashscreen/pull/20#issuecomment-46556813
  
Thank you!


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Using Gradle in an Apache Project

2014-06-19 Thread Ian Clelland

On Wed, Jun 18, 2014 at 7:19 PM, Carlos Santana csantan...@gmail.com
wrote:

 Joe what is the project structure that you don't like and think we should
 not adopt?


http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Project-Structure

The default Gradle Java/Android project structure is to have a `src`
directory, with each of the projects beneath that (`main` for the main app,
`androidTest` for any unit tests, and then also things like `CordovaLib`
and `xwalk_core_library`). Then, each of the projects has a `java` and
`resources` directory, among other things.

Old: src/com/example/app.java
New: src/main/java/com/example/app.java

Old: CordovaLib/src/org/apache/cordova/CordovaActivity.java
New: src/CordovaLib/java/org/apache/cordova/CordovaActivity.java

Old: AndroidManifest.xml
New: src/main/AndroidManifest.xml

etc.

It's not a matter of not liking it, so much as it's incompatible with our
existing (ant) build scripts, and eclipse projects.

It's not an insurmountable problem, as the Gradle `sourceSets` directive
lets us change all of these locations, and that's what I've done in the
build.gradle file I added to cordova-android. All of the paths are
overridden to point back to the existing ant-compatible locations.

Ian

[GitHub] cordova-lib pull request: CB-3571: support for splash element in...

2014-06-19 Thread kamrik

Github user kamrik commented on a diff in the pull request:

https://github.com/apache/cordova-lib/pull/30#discussion_r13974255
  
--- Diff: cordova-lib/src/cordova/metadata/android_parser.js ---
@@ -88,13 +88,54 @@ module.exports.prototype = {
 fs.writeFileSync(this.strings, strings.write({indent: 4}), 
'utf-8');
 events.emit('verbose', 'Wrote out Android application name to ' + 
name + '');
 
+var projectRoot = util.isCordova(this.path);
+
+var splashIcons = config.getIcons('android', 'splash');
+// if there are icon elements in config.xml
+if (splashIcons) {
+   events.emit('verbose', splash icons:  + 
JSON.stringify(splashIcons));
--- End diff --

This line seems to be indented with 3 spaces. Please use consistent 4 space 
indentation.

A suggestion: the whole splashScreen section seems to be long enough to 
live in a function of its own. Preferably in such a way so that it can be 
shared with Amazon FireOS parser, or whatever Android derivative wants to use 
it.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-js pull request: CB-6983 misleading debug statement

2014-06-19 Thread stacic

GitHub user stacic opened a pull request:

https://github.com/apache/cordova-js/pull/71

CB-6983 misleading debug statement



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/stacic/cordova-js CB-6983

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-js/pull/71.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #71


commit cf2ab5190f94de8923aafd5559be940661a32e75
Author: Staci Cooper smcoo...@us.ibm.com
Date:   2014-06-19T15:34:50Z

CB-6983 misleading debug statement




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-plugin-file pull request: CB-6980 Fixing filesystem:null p...

2014-06-19 Thread martincgg

GitHub user martincgg opened a pull request:

https://github.com/apache/cordova-plugin-file/pull/53

CB-6980 Fixing filesystem:null property in Entry

when resolveLocalFileSystemURI or resolveLocalFileSystemURL is called on
the File Plugin under Windows Phone 8, on success it should return a
Entry with several properties, as it is the filesystem information,
which returns as null.
on resolveLocalFileSystemURI.js it calls fileSystem.getFS the object
retrieved it should contain the filesystem information.
Since the fix, CB-6525, only adds support for Android and iOS, for other
platform it retrieves a null object, so adding a condition to retrieve
the information if the object from the callback is null.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/martincgg/cordova-plugin-file CB-6980

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-plugin-file/pull/53.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #53


commit 4f455ac3efe64caede6cbaff9d7c638caf6e5392
Author: Martin Gonzalez martin.c.glez.g...@gmail.com
Date:   2014-06-19T15:38:20Z

CB-6980 Fixing filesystem:null property in Entry

when resolveLocalFileSystemURI or resolveLocalFileSystemURL is called on
the File Plugin under Windows Phone 8, on success it should return a
Entry with several properties, as it is the filesystem information,
which returns as null.
on resolveLocalFileSystemURI.js it calls fileSystem.getFS the object
retrieved it should contain the filesystem information.
Since the fix, CB-6525, only adds support for Android and iOS, for other
platform it retrieves a null object, so adding a condition to retrieve
the information if the object from the callback is null.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-plugin-file pull request: Update Metadata.js

2014-06-19 Thread clelland

Github user clelland commented on the pull request:

https://github.com/apache/cordova-plugin-file/pull/39#issuecomment-46579029
  
This fix has been committed, and the tests are ensuring that the correct 
keys appear in the callbacks. You can close this pull request, I think.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Browserify JS is in

2014-06-19 Thread Andrew Grieve

bump


On Mon, Jun 16, 2014 at 12:51 PM, Andrew Grieve agri...@chromium.org
wrote:

 Cool, yes! Thanks for the update!

 Is there a JIRA for this? Was asked in
 https://issues.apache.org/jira/browse/CB-5671.




 On Mon, Jun 16, 2014 at 10:21 AM, Michal Mocny mmo...@chromium.org
 wrote:

 Awesome Anis.

 Will gladly take a look at this later today.  Just wanted to send a quick
 thanks for landing this this way, and for the useful report.

 -Michal


 On Fri, Jun 13, 2014 at 7:55 PM, Anis KADRI anis.ka...@gmail.com wrote:

  Yo,
 
  Just wanted to let everyone know that I added browserify support to
  plugman (behind a flag for now). CLI is not hooked to this yet. Here
  is how it works:
 
  plugman install --browserify --plugin [PLUGIN] --platform [PLATFORM]
  --project [PROJECT_PATH]
 
  will generate a browserify version of cordova.js. Plugins and
  everything is bundled in. This version passes mobile-spec on iOS and
  Android. I am not yet setup to test other platforms.
 
  plugman install --plugin [PLUGIN] --platform [PLATFORM] --project
  [PROJECT_PATH]
 
  Will continue to generate cordova.js the way it used to.
 
  Because some of you really care about benchmarks here is some
  comparison for dependencies-plugin install:
 
  No browserify:
 
  real 0m9.546s
  user 0m4.673s
  sys 0m0.692s
 
  Browserify:
  real 0m9.861s
  user 0m4.759s
  sys 0m0.648s
 
  All cordova-lib tests are passing so I am assuming this has minimal
  impact but LET ME KNOW otherwise.
 
  Anis

[GitHub] cordova-plugin-camera pull request: CB- 6958. Port camera test to ...

2014-06-19 Thread javierbb31

GitHub user javierbb31 opened a pull request:

https://github.com/apache/cordova-plugin-camera/pull/34

CB- 6958. Port camera test to plugin-test-framework

Ported tests  from mobile-spec (which are written in jasmine 1.3) in
jasmine 2.0.
Added:
New js-module named tests to plugin.xml
Folder with tests working on jasmine 2.0

This changes are aimed to work with the new plugin-test framework.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/javierbb31/cordova-plugin-camera CB-6958

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-plugin-camera/pull/34.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #34


commit afd392f0f92b58bd2b89e374cb02fda998fd7dde
Author: javierbb31 javier.becerra@gmail.com
Date:   2014-06-19T16:29:33Z

CB- 6958. Port camera test to plugin-test-framework

Ported tests  from mobile-spec (which are written in jasmine 1.3) in
jasmine 2.0.
Added:
New js-module named tests to plugin.xml
Folder with tests working on jasmine 2.0

This changes are aimed to work with the new plugin-test framework.

commit 279b8812d6d75d79f8e851262464c43846a01770
Author: javierbb31 javier.becerra@gmail.com
Date:   2014-06-19T16:52:50Z

Replaced tabs by spaces




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-plugin-media-capture pull request: CB-6959] Port capture t...

2014-06-19 Thread SSRico

GitHub user SSRico opened a pull request:

https://github.com/apache/cordova-plugin-media-capture/pull/19

CB-6959] Port capture tests to plugin-test-framework

Ported capture tests from mobile-spec to the new test framework working
with jasmine 2.0.

Added:
-New js-module named tests to plugin.xml
-Folder with tests.js

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/SSRico/cordova-plugin-media-capture CB-6959

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-plugin-media-capture/pull/19.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #19


commit b2320e39d005e93787794e7f6fe64cfaf7071d46
Author: Samir Silva ssric...@gmail.com
Date:   2014-06-19T18:59:57Z

CB-6959] Port capture tests to plugin-test-framework

Ported capture tests from mobile-spec to the new test framework working
with jasmine 2.0.

Added:
-New js-module named tests to plugin.xml
-Folder with tests.js




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-lib pull request: CB-6698 Fix 'android update lib-project'...

2014-06-19 Thread mbektchiev

GitHub user mbektchiev opened a pull request:

https://github.com/apache/cordova-lib/pull/36

CB-6698 Fix 'android update lib-project' command to work with paths 
containing spaces



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Icenium/cordova-lib 
bektchiev/fix-android-lib-paths-with-spaces

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-lib/pull/36.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #36


commit f48e9b5d633ef212969a57053b7af1abaa71a129
Author: Martin Bektchiev martin.bektch...@telerik.com
Date:   2014-06-19T17:29:15Z

CB-6698 Fix 'android update lib-project' command to work with paths 
containing spaces




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-plugin-camera pull request: CB- 6958. Port camera test to ...

Github user purplecabbage commented on a diff in the pull request:

https://github.com/apache/cordova-plugin-camera/pull/34#discussion_r13982226
  
--- Diff: plugin.xml ---
@@ -33,6 +33,9 @@
 js-module src=www/CameraConstants.js name=Camera
 clobbers target=Camera /
 /js-module
+   
+   js-module src=test/tests.js name=tests
--- End diff --

Doesn't this mean that the tests are going to be added to every project 
that uses this plugin?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-plugin-camera pull request: CB- 6958. Port camera test to ...

Github user purplecabbage commented on a diff in the pull request:

https://github.com/apache/cordova-plugin-camera/pull/34#discussion_r13982279
  
--- Diff: plugin.xml ---
@@ -202,6 +205,7 @@
 !-- windows8 --
 platform name=windows8
 
+dependency id=org.apache.cordova.file /
--- End diff --

Is this a mistake? We just removed this dependency ... 
06ecc91fd1430bf3261990315e7e6361a6bc5cad


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-plugin-camera pull request: CB- 6958. Port camera test to ...

2014-06-19 Thread javierbb31

Github user javierbb31 commented on a diff in the pull request:

https://github.com/apache/cordova-plugin-camera/pull/34#discussion_r13983869
  
--- Diff: plugin.xml ---
@@ -202,6 +205,7 @@
 !-- windows8 --
 platform name=windows8
 
+dependency id=org.apache.cordova.file /
--- End diff --

Yes, this is a mistake, I started to work on that 3 days ago. I will fix it.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-plugin-camera pull request: CB- 6958. Port camera test to ...

2014-06-19 Thread javierbb31

Github user javierbb31 commented on a diff in the pull request:

https://github.com/apache/cordova-plugin-camera/pull/34#discussion_r13984170
  
--- Diff: plugin.xml ---
@@ -33,6 +33,9 @@
 js-module src=www/CameraConstants.js name=Camera
 clobbers target=Camera /
 /js-module
+   
+   js-module src=test/tests.js name=tests
--- End diff --

Yes, it means that the tests are going to be added on every project that 
uses this plugin, however, this PR it should have to be addressed to another 
branch(cdvtest, as it is for the plugin-device, which already has the tests for 
the plugin-test framework.
https://github.com/apache/cordova-plugin-device/tree/cdvtest
Are you able to create the branch cdvtest for this repository?
Is there any way to correctly address this PR to that branch once created?

Thanks for the feedback.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-lib pull request: CB-6698 Fix 'android update lib-project'...

2014-06-19 Thread asfgit

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-lib/pull/36


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [Android] URI routing

OK, I did some tests with the misc content part of Mobile Spec and
everything checks out.  We should write more tests with JUnit on the
Android project itself to test this, but overall things seem to still
work.  This is something that we may want to backport to master as
well.  What do people think of that.  It would resolve a lot of our
current URI routing issues, and allow us to reuse code.

On Wed, Jun 18, 2014 at 5:37 PM, Andrew Grieve agri...@chromium.org wrote:
 Change looks good to me!


 On Wed, Jun 18, 2014 at 7:51 PM, Joe Bowser bows...@gmail.com wrote:

 Hey

 After looking at the breakout code, it seems that there may actually
 be a lot of duplicate code between Crosswalk, default AndroidWebView
 and others, so I created a helper class that could be used to abstract
 the shouldOverrideUrlLoading logic.  While I was in there, I deleted
 most of the handlers, and now we have the correct behaviour for custom
 URIs which register a broadcast receiver.

 I put it on my branch here:
 https://github.com/infil00p/cordova-android/tree/UriHelper

 I've constantly closed every bug that's said Add support for custom
 URIs because Android by design already supports them.  However,
 partly due to legacy Android bugs, there was logic for specific URIs.
 Once I ripped out the old logic and tested it on Kitkat, it appears
 everything works as it should.  I'm going to test this on older
 versions of Cordova, but it'd be good if other people looked at this
 before I land it in the 4.0.x branch.

 Thoughts?

 Joe

Re: plugin test framework

Sorry I missed providing feedback on this earlier ...
Having a deeper look at this, I am not feeling great about the extra
requirement that every plugin have an additional branch.

Several concerns arise :
- test branch can be out of sync with master
- how do we test a specific version?
- tests are not immediately visible when looking at master
- differing versions of plugin.xml depending on the branch

The majority of the work has been done (thanks Michal!), and mostly any
suggestions I make will just require moving code and changing a few
conventions.

What if we? :
1. add a plugin-test.xml file which has the exact format of plugin.xml
2. keep tests/ and plugin-test.xml file in master branch
3. have plugman/cli support an additional flag --test so we can install
like this:
cordova plugin add
http://git-wip-us.apache.org/repos/asf/cordova-plugin-device.git --test
This would mean that in addition to processing the plugin.xml of the
plugin, we would also process the plugin-test.xml file ( identical
processing logic )
4. have all plugin-test.xml files declare a dependency on
cordova-plugin-test-framework

The above suggestions could also be used in conjuction with the cordova run
--tests platform mentioned by Michal, but without the need to manage the
switching of branches.


@purplecabbage
risingj.com


On Tue, Jun 17, 2014 at 2:16 PM, Michal Mocny mmo...@chromium.org wrote:

 Piotr: Actually I'm not sure how running tests in the harness would work,
 since the path to the resource may be different.  However, in general, with
 development using the harness you aren't making any changes to plugins.
  The whole point is for app developers who want to modify only web
 application bits and not deal with native compiles.

 In theory the app harness could support working on the js-modules of
 plugins, but that sounds like a really niche idea.  I'd not be opposed to
 someone working on it but I'm not sure you'll have luck finding volunteers.

 -Michal


 On Tue, Jun 17, 2014 at 5:13 PM, Michal Mocny mmo...@chromium.org wrote:

  At the time I went through my design iterations I just didn't want to
  necessarily depend on cordova tooling changes / documentation.  In other
  words, someone else may have a different strategy for testing..
 
  My personal opinion would be have the test plugin ship with a plugin hook
  (those are in, right? or at least on their way), that will automatically
  update the start page if you pass a flag to run command.  Ie, in an ideal
  world:  `cordova run --tests` runs a plugin hook passing in --tests flag
  which changes the start page, in a way that isn't overwritten by the
  top-level config.xml.
 
  My 2 cents, since I don't want our way of testing mobile spec to be
 the
  only way to test.   Frameworks and opinions on testing change.
 
  -Michal
 
 
  On Tue, Jun 17, 2014 at 4:33 PM, Piotr Zalewa pzal...@mozilla.com
 wrote:
 
  One thing more - it would be great if user could create a test using
 test
  harness app as well. Is it also considered?
 
  Dnia Tue Jun 17 13:27:22 2014 Martin Gonzalez pisze:
 
   It would be a nice to have in the cli, aimed to just setup the right
 path
  in the config.xml, maybe along with an another argument to build,
  run/emulate as well.
  It sounds great.
 
 
  2014-06-17 15:21 GMT-05:00 Piotr Zalewa pzal...@mozilla.com:
 
   Thanks Martin,
 
  Has it been considered to create a separate command testrun or
 similar
  which would remove the need to edit the config.xml?
 
  Dnia Tue Jun 17 11:58:33 2014 Michal Mocny pisze:
 
Martin, thanks for posting those links.
 
 
  And I'll look into the INFRA tickets I need to file to set up a repo
  for
  that plugin, since its ready to come out of labs.
 
 
  On Tue, Jun 17, 2014 at 2:06 PM, Martin Gonzalez 
  martin.c.glez.g...@gmail.com wrote:
 
This is the Cordova Plugin Test Framework readme.md, you can catch
  up
 
  with
  the functionality by reading some of the content:
 
  Repository:
  https://github.com/apache/cordova-labs
 
  Docs:
  https://github.com/apache/cordova-labs/blob/master/README.md
 
  https://github.com/apache/cordova-labs/blob/cdvtest/
  cordova-plugin-test-framework/README.md
 
 
 
  2014-06-17 12:56 GMT-05:00 Piotr Zalewa pzal...@mozilla.com:
 
a documentation explaining how it's gonna work
 
 
  Dnia Tue Jun 17 10:51:58 2014 Michal Mocny pisze:
 
 What do you mean?
 
 
 
  On Tue, Jun 17, 2014 at 1:50 PM, Piotr Zalewa 
 pzal...@mozilla.com
  wrote:
 
 Is there any predev document?
 
 
  Dnia Mon Jun 16 18:30:46 2014 Andrew Grieve pisze:
 
  Yeah, really exciting. Thanks for taking this on.
 
 
 
  On Mon, Jun 16, 2014 at 3:42 PM, Michal Mocny 
  mmo...@chromium.org
  wrote:
 
  Fantastic!
 
 
   I'll try to keep an eye out on the PR's, and please ping me if
  you
  would
  like any help.
 
  -Michal
 
 
  On Mon, Jun 16, 2014 at 3:25 PM, Marcel Kinard 
  cmarc...@gmail.com
  wrote:
 
  Hi, after some discussions here with IBM management, we’re

[GitHub] cordova-plugin-file-transfer pull request: [CB-5059] Remove the de...

2014-06-19 Thread clelland

Github user clelland commented on the pull request:


https://github.com/apache/cordova-plugin-file-transfer/pull/8#issuecomment-46603710
  
Junmin, can you comment any more on this? I'm not sure what the root issue 
is? Does the current filetransfer plugin cause a crash with the crosswalk 
backend? If so, can we create a test case for that?

We definitely do want to keep cookie support for filetransfer, so if there 
are changes needed to the Cordova Crosswalk Webview to enable cookies, then I'd 
like to fix it there.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-plugin-file-transfer pull request: FileTransfer did not ab...

2014-06-19 Thread clelland

Github user clelland commented on the pull request:


https://github.com/apache/cordova-plugin-file-transfer/pull/19#issuecomment-46604018
  
This was fixed, I think, in 0f8467bd -- can you close this pull request?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-plugin-camera pull request: CB- 6958. Port camera test to ...

Github user purplecabbage commented on the pull request:


https://github.com/apache/cordova-plugin-camera/pull/34#issuecomment-46609974
  
I've started a conversation on this, before we go and create `test` 
branches for all ~20ish plugins.
http://markmail.org/message/576yxsj6xvg6rycw




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Jesee, the branch is NOT a requirement (I don't think I documented it as
such, except in the examples for installing plugins for initial look).
Actually, we should delete those stale branches now that we are moving
up-to-date tests into master. It was just for early experimentation on the
feature.

Jesse, I'm not seeing the benefit of using plugins-tests.xml or the
dependency on the test plugin yet, may you elaborate your thoughts?

My hope was that tests are just always installed alongside plugins. If
that is not a good idea for some particular plugin, say because it uses
huge assets, I elaborated my answer in the plugin FAQ (
https://github.com/apache/cordova-labs/blob/cdvtest/cordova-plugin-test-framework/README.md#faq
):
FAQ

Q: Should I add org.apache.cordova.test-harness as a dependancy of my
plugin?
- A: No. The end-user should decide if they want to install the test
harness, not your plugin (most users won't).
-

Q: What do I do if my plugin tests must have very large assets?
- A: Don't bundle those assets with your plugin. If you can, have your
tests fail gracefully if those assets don't don't exist (perhaps log a
warning, perhaps fail a single asset-checking test, and skip the rest).
Then, ideally download those assets automatically into local storage the
first time tests run. Or create a manual test step to download
and install
assets. As a final alternative, split those test assets into a separate
plugin, and instruct users to install that plugin to run your full test
suite.
-

Q: Should I ship my app with the test harness plugin installed?
- A: Not likely. If you want, you can. Then your app could even embed a
link to the test page (cdvtests/index.html) from a help section of
your app, to give end users a way to run your test suite out in
the feild.
That may help diagnose causes of issues within your app. Maybe.

Feel free the debate those answers -- now is certainly the time -- but I
put a lot of effort to make it super flexible and to not require depending
on changes to CLI :P

-Michal

On Thu, Jun 19, 2014 at 3:11 PM, Jesse purplecabb...@gmail.com wrote:

Sorry I missed providing feedback on this earlier ...
Having a deeper look at this, I am not feeling great about the extra
requirement that every plugin have an additional branch.

Several concerns arise :
- test branch can be out of sync with master
- how do we test a specific version?
- tests are not immediately visible when looking at master
- differing versions of plugin.xml depending on the branch

The majority of the work has been done (thanks Michal!), and mostly any
suggestions I make will just require moving code and changing a few
conventions.

What if we? :
1. add a plugin-test.xml file which has the exact format of plugin.xml
2. keep tests/ and plugin-test.xml file in master branch
3. have plugman/cli support an additional flag --test so we can install
like this:
cordova plugin add
http://git-wip-us.apache.org/repos/asf/cordova-plugin-device.git --test
This would mean that in addition to processing the plugin.xml of the
plugin, we would also process the plugin-test.xml file ( identical
processing logic )
4. have all plugin-test.xml files declare a dependency on
cordova-plugin-test-framework

The above suggestions could also be used in conjuction with the cordova run
--tests platform mentioned by Michal, but without the need to manage the
switching of branches.

@purplecabbage
risingj.com

On Tue, Jun 17, 2014 at 2:16 PM, Michal Mocny mmo...@chromium.org wrote:

Piotr: Actually I'm not sure how running tests in the harness would work,
since the path to the resource may be different. However, in general,
with
development using the harness you aren't making any changes to plugins.
The whole point is for app developers who want to modify only web
application bits and not deal with native compiles.

In theory the app harness could support working on the js-modules of
plugins, but that sounds like a really niche idea. I'd not be opposed to
someone working on it but I'm not sure you'll have luck finding
volunteers.

-Michal

On Tue, Jun 17, 2014 at 5:13 PM, Michal Mocny mmo...@chromium.org
wrote:

At the time I went through my design iterations I just didn't want to
necessarily depend on cordova tooling changes / documentation. In
other
words, someone else may have a different strategy for testing..

My personal opinion would be have the test plugin ship with a plugin
hook
(those are in, right? or at least on their way), that will
automatically
update the start page if you pass a flag to run command. Ie, in an
ideal
world: `cordova run --tests` runs a plugin hook passing in --tests
flag
which changes the start page, in a way that isn't overwritten by the
top-level config.xml.

My 2 cents, since I don't want our

[GitHub] cordova-lib pull request: CB-6986 make npm run jshint work without...

GitHub user jsoref opened a pull request:

https://github.com/apache/cordova-lib/pull/37

CB-6986 make npm run jshint work without a global jshint



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jsoref/cordova-lib cb_6986

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-lib/pull/37.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #37


commit a64032cc5a35a8a59cb97bd13f11013b742ed1fb
Author: Josh Soref jso...@blackberry.com
Date:   2014-06-19T20:00:04Z

CB-6986 make npm run jshint work without a global jshint




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-plugin-globalization pull request: CB-6962 globalization t...

2014-06-19 Thread stacic

GitHub user stacic opened a pull request:

https://github.com/apache/cordova-plugin-globalization/pull/12

CB-6962 globalization tests for test-framework



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/stacic/cordova-plugin-globalization cdvtest

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-plugin-globalization/pull/12.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #12


commit 3057362b293f664c135739d2b94a85fea282e2c4
Author: Staci Cooper smcoo...@us.ibm.com
Date:   2014-06-19T20:41:39Z

CB-6962 globalization tests for test-framework




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Amazon Fire Phone

2014-06-19 Thread Michael Brooks

Heads up, I believe we (Adobe) are getting one of the devices for testing.


On Wed, Jun 18, 2014 at 12:41 PM, Carlos Santana csantan...@gmail.com
wrote:

 Announced today:

 http://www.amazon.com/gp/product/B00EOE0WKQ/

 Runs Fire OS 3.5

 https://developer.amazon.com/appsandservices/solutions/devices/fire-phone


 --
 Carlos Santana
 csantan...@gmail.com

Should use only drawable folder for single application icon

2014-06-19 Thread Jan Velecký

When using single icon as application icon in config.xml this way icon src
=icon.png platform=android / cordova should use basic drawable folder,
because doesn't matter of resolution, PPI, etc., so doesn't matter of device
and for this purpose there are drawable folder. Not use drawable-hdpi, 
drawable-ldpi and so on. Icons in these folders in this situation should be 
deleted.

It's really not neccessary to have 5 not similar, but exactly same icon 
files, when we can have only 1 icon file.

Re: Should use only drawable folder for single application icon

On Thu, Jun 19, 2014 at 1:41 PM, Jan Velecký vve...@seznam.cz wrote:
 When using single icon as application icon in config.xml this way icon src
 =icon.png platform=android / cordova should use basic drawable folder,
 because doesn't matter of resolution, PPI, etc., so doesn't matter of device
 and for this purpose there are drawable folder. Not use drawable-hdpi,
 drawable-ldpi and so on. Icons in these folders in this situation should be
 deleted.


I disagree.

 It's really not neccessary to have 5 not similar, but exactly same icon
 files, when we can have only 1 icon file.

People should be changing their icons anyway, and I don't believe we
actually landed any support for the icon element in config.xml.

Re: plugin test framework

re:

Q: What do I do if my plugin tests must have very large assets?
- A: Don't bundle those assets with your plugin. If you can, have your
...

My concern is I do not want to see tests added to every project that uses a
plugin, even if the assets are not large, there are implications to
including the test framework + all the tests because they get loaded and
processed with all of the plugins and will impact load time even if never
run.

99.9% of the time the plugin tests will be used by us the plugin
developers, and not the people who use the plugin in there apps.

I agree, having the tester install the test harness plugin dependency
themselves is probably a better option, as I see you have wrapped all tests
inside a exports.defineAutoTests so we don't have to worry about
describe/it/expects not being defined.

@purplecabbage
risingj.com

On Thu, Jun 19, 2014 at 1:27 PM, Michal Mocny mmo...@chromium.org wrote:

Jesse, I'm not seeing the benefit of using plugins-tests.xml or the
dependency on the test plugin yet, may you elaborate your thoughts?

My hope was that tests are just always installed alongside plugins. If
that is not a good idea for some particular plugin, say because it uses
huge assets, I elaborated my answer in the plugin FAQ (

https://github.com/apache/cordova-labs/blob/cdvtest/cordova-plugin-test-framework/README.md#faq
):
FAQ

Q: Should I add org.apache.cordova.test-harness as a dependancy of my
plugin?
- A: No. The end-user should decide if they want to install the test
harness, not your plugin (most users won't).
-

Q: What do I do if my plugin tests must have very large assets?
- A: Don't bundle those assets with your plugin. If you can, have your
tests fail gracefully if those assets don't don't exist (perhaps log
a
warning, perhaps fail a single asset-checking test, and skip the
rest).
Then, ideally download those assets automatically into local storage
the
first time tests run. Or create a manual test step to download
and install
assets. As a final alternative, split those test assets into a
separate
plugin, and instruct users to install that plugin to run your full
test
suite.
-

Feel free the debate those answers -- now is certainly the time -- but I
put a lot of effort to make it super flexible and to not require depending
on changes to CLI :P

-Michal

On Thu, Jun 19, 2014 at 3:11 PM, Jesse purplecabb...@gmail.com wrote:

Sorry I missed providing feedback on this earlier ...
Having a deeper look at this, I am not feeling great about the extra
requirement that every plugin have an additional branch.

The majority of the work has been done (thanks Michal!), and mostly any
suggestions I make will just require moving code and changing a few
conventions.

The above suggestions could also be used in conjuction with the cordova
run
--tests platform mentioned by Michal, but without the need to manage the
switching of branches.

@purplecabbage
risingj.com

On Tue, Jun 17, 2014 at 2:16 PM, Michal Mocny mmo...@chromium.org
wrote:

Piotr: Actually I'm not sure how running tests in the harness would
work,
since the path to the resource may be different. However, in general,
with
development using the harness you aren't making any changes to plugins.
The whole point is for app developers who want to modify only web
application

Re: Should use only drawable folder for single application icon

2014-06-19 Thread Darryl Pogue

On 19 June 2014 13:52, Joe Bowser bows...@gmail.com wrote:
  It's really not neccessary to have 5 not similar, but exactly same icon
  files, when we can have only 1 icon file.

 People should be changing their icons anyway, and I don't believe we
 actually landed any support for the icon element in config.xml.

This support landed in cordova-cli 3.5.0.

Re: Should use only drawable folder for single application icon

So, it resizes the icon? If not, then the point is still valid.
On Jun 19, 2014 2:11 PM, Darryl Pogue dvpdin...@gmail.com wrote:

 On 19 June 2014 13:52, Joe Bowser bows...@gmail.com wrote:
   It's really not neccessary to have 5 not similar, but exactly same icon
   files, when we can have only 1 icon file.
 
  People should be changing their icons anyway, and I don't believe we
  actually landed any support for the icon element in config.xml.

 This support landed in cordova-cli 3.5.0.

[GitHub] cordova-plugin-contacts pull request: Add pickContact functionalit...

2014-06-19 Thread shazron

Github user shazron commented on the pull request:


https://github.com/apache/cordova-plugin-contacts/pull/26#issuecomment-46621747
  
Please file an issue at:
http://issues.apache.org/jira/browse/CB

... so it can be tracked and evaluated by the devs, and you can be notified.

Sign up here:
https://issues.apache.org/jira/secure/Signup!default.jspa

Thanks!


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Browserify JS is in

2014-06-19 Thread Anis KADRI

Sorry. I forgot you asked the question. There was no issue but there is one now.
https://issues.apache.org/jira/browse/CB-6990

This feature is plugman only for now. How important is it to wire it
to CLI ? Have  you guys had time to test it out yet ? How would it
work with CLI ? Add another flag such as cordova plugin add
--browserify ?

On Thu, Jun 19, 2014 at 9:28 AM, Andrew Grieve agri...@chromium.org wrote:
 bump


 On Mon, Jun 16, 2014 at 12:51 PM, Andrew Grieve agri...@chromium.org
 wrote:

 Cool, yes! Thanks for the update!

 Is there a JIRA for this? Was asked in
 https://issues.apache.org/jira/browse/CB-5671.




 On Mon, Jun 16, 2014 at 10:21 AM, Michal Mocny mmo...@chromium.org
 wrote:

 Awesome Anis.

 Will gladly take a look at this later today.  Just wanted to send a quick
 thanks for landing this this way, and for the useful report.

 -Michal


 On Fri, Jun 13, 2014 at 7:55 PM, Anis KADRI anis.ka...@gmail.com wrote:

  Yo,
 
  Just wanted to let everyone know that I added browserify support to
  plugman (behind a flag for now). CLI is not hooked to this yet. Here
  is how it works:
 
  plugman install --browserify --plugin [PLUGIN] --platform [PLATFORM]
  --project [PROJECT_PATH]
 
  will generate a browserify version of cordova.js. Plugins and
  everything is bundled in. This version passes mobile-spec on iOS and
  Android. I am not yet setup to test other platforms.
 
  plugman install --plugin [PLUGIN] --platform [PLATFORM] --project
  [PROJECT_PATH]
 
  Will continue to generate cordova.js the way it used to.
 
  Because some of you really care about benchmarks here is some
  comparison for dependencies-plugin install:
 
  No browserify:
 
  real 0m9.546s
  user 0m4.673s
  sys 0m0.692s
 
  Browserify:
  real 0m9.861s
  user 0m4.759s
  sys 0m0.648s
 
  All cordova-lib tests are passing so I am assuming this has minimal
  impact but LET ME KNOW otherwise.
 
  Anis

Re: plugin test framework

2014-06-19 Thread Michal Mocny

Andrew has raised that concern as well. My gut says that the bundling of a
few shorts scripts that get parsed but not run as long as they don't get
require() will not affect applications negatively (there are probably many
more significant overheads we live with today in cordova) -- but I
understand why that may not be useful default.

In that case, some ideas: (I recall these were proposed previously but not
sure by whom)
(a) Bundle tests as a plugin-within-the-plugin as such:
myplugin/
- plugin.xml
- src/...
- www/...
- tests/
- plugin.xml
- www/...

Which basically means the plugin tests live in the same repo/branch, and
are fetched as part of plugin add, but are not moved into platforms/ on
cordova prepare by default, thus don't end up in your application (disk and
network are cheap, application startup and size costs are not, right?).
Then, to run tests, we basically need to iterate all plugins looking for a
nested tests/plugin.xml, and install those. This can be added to
CLI/Plugman, or just be a CLI hook even.

(b) add a js-test-module or js-module type=test that is only used if
you run prepare with --test. Similar to the above, but I think requires
more CLI/config file changes, which I'm not a fan of.
(c) Just ship tests as a second plugin in a second repo, and document how
to install tests. Can then perhaps have a dependency type=tests. I
don't like this as much since its basically back to mobile-spec.

WDYT?

-Michal

On Thu, Jun 19, 2014 at 4:53 PM, Jesse purplecabb...@gmail.com wrote:

re:

Q: What do I do if my plugin tests must have very large assets?
- A: Don't bundle those assets with your plugin. If you can, have your
...

99.9% of the time the plugin tests will be used by us the plugin
developers, and not the people who use the plugin in there apps.

@purplecabbage
risingj.com

On Thu, Jun 19, 2014 at 1:27 PM, Michal Mocny mmo...@chromium.org wrote:

Jesse, I'm not seeing the benefit of using plugins-tests.xml or the
dependency on the test plugin yet, may you elaborate your thoughts?

My hope was that tests are just always installed alongside plugins. If
that is not a good idea for some particular plugin, say because it uses
huge assets, I elaborated my answer in the plugin FAQ (

https://github.com/apache/cordova-labs/blob/cdvtest/cordova-plugin-test-framework/README.md#faq
):
FAQ

Q: Should I add org.apache.cordova.test-harness as a dependancy of
my
plugin?
- A: No. The end-user should decide if they want to install the test
harness, not your plugin (most users won't).
-

Q: What do I do if my plugin tests must have very large assets?
- A: Don't bundle those assets with your plugin. If you can, have your
tests fail gracefully if those assets don't don't exist (perhaps
log
a
warning, perhaps fail a single asset-checking test, and skip the
rest).
Then, ideally download those assets automatically into local
storage
the
first time tests run. Or create a manual test step to download
and install
assets. As a final alternative, split those test assets into a
separate
plugin, and instruct users to install that plugin to run your full
test
suite.
-

Q: Should I ship my app with the test harness plugin installed?
- A: Not likely. If you want, you can. Then your app could even embed
a
link to the test page (cdvtests/index.html) from a help section of
your app, to give end users a way to run your test suite out in
the feild.
That may help diagnose causes of issues within your app. Maybe.

Feel free the debate those answers -- now is certainly the time -- but I
put a lot of effort to make it super flexible and to not require
depending
on changes to CLI :P

-Michal

On Thu, Jun 19, 2014 at 3:11 PM, Jesse purplecabb...@gmail.com wrote:

Sorry I missed providing feedback on this earlier ...
Having a deeper look at this, I am not feeling great about the extra

[GitHub] cordova-lib pull request: Fixed issue: CB-6140

2014-06-19 Thread dylin

GitHub user dylin opened a pull request:

https://github.com/apache/cordova-lib/pull/38

Fixed issue: CB-6140

plugman dependency check will ignore platform/dependecy when removing an
intalled plugin, which will result in platform level dependencies is
uninstalled inproperly.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dylin/cordova-lib dylin/CB-6140

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-lib/pull/38.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #38


commit 3241f0776efe9f9bcb3a5d09dedb3cba21c8a5dc
Author: Danyi Lin dany...@blackberry.com
Date:   2014-06-19T22:45:19Z

Fixed issue: CB-6140
plugman dependency check will ignore platform/dependecy when removing an
intalled plugin, which will result in platform level dependencies is
uninstalled inproperly.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-lib pull request: Fixed issue: CB-6140

Github user jsoref commented on the pull request:

https://github.com/apache/cordova-lib/pull/38#issuecomment-46627998
  
1. The first line of your commit message should be of the form:

CB-6140 Don't allow deletion of platform dependencies

2. Please fix any misspellings in the commit message:
platform/dependecy


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: plugin test framework

Option a) was what I suggested a ways back, and I still stand by it.
I think it provides the greatest transparency, and simplicity, yet it is
still very flexible.
I don't think it would be hard to accomplish either. This is the small
re-org I was hinting at, you've already done the hard part.

@purplecabbage
risingj.com

On Thu, Jun 19, 2014 at 3:45 PM, Michal Mocny mmo...@chromium.org wrote:

WDYT?

-Michal

On Thu, Jun 19, 2014 at 4:53 PM, Jesse purplecabb...@gmail.com wrote:

re:

Q: What do I do if my plugin tests must have very large assets?
- A: Don't bundle those assets with your plugin. If you can, have your
...

My concern is I do not want to see tests added to every project that
uses a
plugin, even if the assets are not large, there are implications to
including the test framework + all the tests because they get loaded and
processed with all of the plugins and will impact load time even if never
run.

99.9% of the time the plugin tests will be used by us the plugin
developers, and not the people who use the plugin in there apps.

I agree, having the tester install the test harness plugin dependency
themselves is probably a better option, as I see you have wrapped all
tests
inside a exports.defineAutoTests so we don't have to worry about
describe/it/expects not being defined.

@purplecabbage
risingj.com

On Thu, Jun 19, 2014 at 1:27 PM, Michal Mocny mmo...@chromium.org
wrote:

Jesee, the branch is NOT a requirement (I don't think I documented it
as
such, except in the examples for installing plugins for initial look).
Actually, we should delete those stale branches now that we are moving
up-to-date tests into master. It was just for early experimentation on
the
feature.

Jesse, I'm not seeing the benefit of using plugins-tests.xml or the
dependency on the test plugin yet, may you elaborate your thoughts?

My hope was that tests are just always installed alongside plugins. If
that is not a good idea for some particular plugin, say because it uses
huge assets, I elaborated my answer in the plugin FAQ (

https://github.com/apache/cordova-labs/blob/cdvtest/cordova-plugin-test-framework/README.md#faq
):
FAQ

Q: Should I add org.apache.cordova.test-harness as a dependancy of
my
plugin?
- A: No. The end-user should decide if they want to install the test
harness, not your plugin (most users won't).
-

Q: What do I do if my plugin tests must have very large assets?
- A: Don't bundle those assets with your plugin. If you can, have
your
tests fail gracefully if those assets don't don't exist (perhaps
log
a
warning, perhaps fail a single asset-checking test, and skip the
rest).
Then, ideally download those assets automatically into local
storage
the
first time tests run. Or create a manual test step to download
and install
assets. As a final alternative, split those test assets into a
separate
plugin, and instruct users to install that plugin to run your
full
test
suite.
-

Q: Should I ship my app with the test harness plugin installed?
- A: Not likely. If you want, you can. Then your app could even
embed
a
link to the test page (cdvtests/index.html) from a help section
of
your app, to give end users a way to run your test suite out

[GitHub] cordova-lib pull request: CB-6986 make npm run jshint work without...

2014-06-19 Thread asfgit

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-lib/pull/37


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-lib pull request: CB-3571: support for splash element in...

Github user jsoref commented on the pull request:

https://github.com/apache/cordova-lib/pull/30#issuecomment-46631067
  
Could you please do a rebase so that there isn't an ugly merge (or multiple 
ugly merges) in the history? I've done a number for #9 -- it makes things much 
nicer.

A quick check shows that while there is a conflict, it's incredibly tiny, 
and trivial to resolve (pick your change).


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: plugin test framework

My ultimate would be this:

cordova create TestFilePlugin
cd TestFilePlugin
cordova platform add android
cordova plugin add
http://git-wip-us.apache.org/repos/asf/cordova-labs.git#cdvtest:cordova-plugin-test-framework
cordova plugin add ../cordova-plugin-file/
cordova plugin add ../cordova-plugin-file/test/
cordova run android --start cdvtests/index.html

Then do this for each plugin, and for each platform
Then do this for all combinations of plugins
...

Note the run --start does not yet exist, but this would be awesome!

@purplecabbage
risingj.com

On Thu, Jun 19, 2014 at 4:15 PM, Jesse purplecabb...@gmail.com wrote:

@purplecabbage
risingj.com

On Thu, Jun 19, 2014 at 3:45 PM, Michal Mocny mmo...@chromium.org wrote:

Andrew has raised that concern as well. My gut says that the bundling of
a
few shorts scripts that get parsed but not run as long as they don't get
require() will not affect applications negatively (there are probably many
more significant overheads we live with today in cordova) -- but I
understand why that may not be useful default.

Which basically means the plugin tests live in the same repo/branch, and
are fetched as part of plugin add, but are not moved into platforms/ on
cordova prepare by default, thus don't end up in your application (disk
and
network are cheap, application startup and size costs are not, right?).
Then, to run tests, we basically need to iterate all plugins looking for a
nested tests/plugin.xml, and install those. This can be added to
CLI/Plugman, or just be a CLI hook even.

WDYT?

-Michal

On Thu, Jun 19, 2014 at 4:53 PM, Jesse purplecabb...@gmail.com wrote:

re:

Q: What do I do if my plugin tests must have very large assets?
- A: Don't bundle those assets with your plugin. If you can, have
your
...

My concern is I do not want to see tests added to every project that
uses a
plugin, even if the assets are not large, there are implications to
including the test framework + all the tests because they get loaded and
processed with all of the plugins and will impact load time even if
never
run.

99.9% of the time the plugin tests will be used by us the plugin
developers, and not the people who use the plugin in there apps.

I agree, having the tester install the test harness plugin dependency
themselves is probably a better option, as I see you have wrapped all
tests
inside a exports.defineAutoTests so we don't have to worry about
describe/it/expects not being defined.

@purplecabbage
risingj.com

On Thu, Jun 19, 2014 at 1:27 PM, Michal Mocny mmo...@chromium.org
wrote:

Jesee, the branch is NOT a requirement (I don't think I documented it
as
such, except in the examples for installing plugins for initial look).
Actually, we should delete those stale branches now that we are
moving
up-to-date tests into master. It was just for early experimentation
on
the
feature.

Jesse, I'm not seeing the benefit of using plugins-tests.xml or the
dependency on the test plugin yet, may you elaborate your thoughts?

My hope was that tests are just always installed alongside plugins.
If
that is not a good idea for some particular plugin, say because it
uses
huge assets, I elaborated my answer in the plugin FAQ (

https://github.com/apache/cordova-labs/blob/cdvtest/cordova-plugin-test-framework/README.md#faq
):
FAQ

Q: Should I add org.apache.cordova.test-harness as a dependancy
of
my
plugin?
- A: No. The end-user should decide if they want to install the
test
harness, not your plugin (most users won't).
-

[GitHub] cordova-lib pull request: CB-6661 Add platform 'web server' to cor...

Github user jsoref commented on the pull request:

https://github.com/apache/cordova-lib/pull/22#issuecomment-46631277
  
@kingnebby : those two corrections are right, but you should squash them 
into your other commits, and then you should rebase and resolve the merge 
conflicts.

(Note: I'm not reviewing the feature at this time.)


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Browserify JS is in

2014-06-19 Thread Andrew Grieve

Thanks Anis!

Tougher for CLI since it's actually the prepare step that creates
cordova_plugins.js, but longer term (medium term?) I don't see why we
shouldn't just turn it on always anyways.

So... Maybe cordova prepare --browserify?
Build prepares first, so will also need: cordova run android --browserify

I haven't looked at it yet. Google IO is next week and it's been consuming
most of our time the last few weeks. Will definitely play with it next next
week though!



On Thu, Jun 19, 2014 at 6:28 PM, Anis KADRI anis.ka...@gmail.com wrote:

 Sorry. I forgot you asked the question. There was no issue but there is
 one now.
 https://issues.apache.org/jira/browse/CB-6990

 This feature is plugman only for now. How important is it to wire it
 to CLI ? Have  you guys had time to test it out yet ? How would it
 work with CLI ? Add another flag such as cordova plugin add
 --browserify ?

 On Thu, Jun 19, 2014 at 9:28 AM, Andrew Grieve agri...@chromium.org
 wrote:
  bump
 
 
  On Mon, Jun 16, 2014 at 12:51 PM, Andrew Grieve agri...@chromium.org
  wrote:
 
  Cool, yes! Thanks for the update!
 
  Is there a JIRA for this? Was asked in
  https://issues.apache.org/jira/browse/CB-5671.
 
 
 
 
  On Mon, Jun 16, 2014 at 10:21 AM, Michal Mocny mmo...@chromium.org
  wrote:
 
  Awesome Anis.
 
  Will gladly take a look at this later today.  Just wanted to send a
 quick
  thanks for landing this this way, and for the useful report.
 
  -Michal
 
 
  On Fri, Jun 13, 2014 at 7:55 PM, Anis KADRI anis.ka...@gmail.com
 wrote:
 
   Yo,
  
   Just wanted to let everyone know that I added browserify support to
   plugman (behind a flag for now). CLI is not hooked to this yet. Here
   is how it works:
  
   plugman install --browserify --plugin [PLUGIN] --platform [PLATFORM]
   --project [PROJECT_PATH]
  
   will generate a browserify version of cordova.js. Plugins and
   everything is bundled in. This version passes mobile-spec on iOS and
   Android. I am not yet setup to test other platforms.
  
   plugman install --plugin [PLUGIN] --platform [PLATFORM] --project
   [PROJECT_PATH]
  
   Will continue to generate cordova.js the way it used to.
  
   Because some of you really care about benchmarks here is some
   comparison for dependencies-plugin install:
  
   No browserify:
  
   real 0m9.546s
   user 0m4.673s
   sys 0m0.692s
  
   Browserify:
   real 0m9.861s
   user 0m4.759s
   sys 0m0.648s
  
   All cordova-lib tests are passing so I am assuming this has minimal
   impact but LET ME KNOW otherwise.
  
   Anis

Re: Should use only drawable folder for single application icon

2014-06-19 Thread Andrew Grieve

I don't think it should resize it, but I do agree we should delete the
template ones if any are present. Right now you aren't sure if the icon
tag even did anything if you fail to replace the right size. Android and
iOS both do a pretty good job at resizing at runtime if only one large icon
is present (although you won't get through app-store review).




On Thu, Jun 19, 2014 at 5:17 PM, Joe Bowser bows...@gmail.com wrote:

 So, it resizes the icon? If not, then the point is still valid.
 On Jun 19, 2014 2:11 PM, Darryl Pogue dvpdin...@gmail.com wrote:

  On 19 June 2014 13:52, Joe Bowser bows...@gmail.com wrote:
It's really not neccessary to have 5 not similar, but exactly same
 icon
files, when we can have only 1 icon file.
  
   People should be changing their icons anyway, and I don't believe we
   actually landed any support for the icon element in config.xml.
 
  This support landed in cordova-cli 3.5.0.

Re: plugin test framework

2014-06-19 Thread Michal Mocny

+1 I agree, this would be awesome.

New question, should this merely be the standard we adhere to for core
plugins, or should we actively make it difficult for plugin devs to not
ship tests directly with plugins? (Not sure how we could accomplish that,
so I hope its just a convention that applies to our work).

-Michal

On Thu, Jun 19, 2014 at 7:48 PM, Jesse purplecabb...@gmail.com wrote:

My ultimate would be this:

cordova create TestFilePlugin
cd TestFilePlugin
cordova platform add android
cordova plugin add

http://git-wip-us.apache.org/repos/asf/cordova-labs.git#cdvtest:cordova-plugin-test-framework
cordova plugin add ../cordova-plugin-file/
cordova plugin add ../cordova-plugin-file/test/
cordova run android --start cdvtests/index.html

Then do this for each plugin, and for each platform
Then do this for all combinations of plugins
...

Note the run --start does not yet exist, but this would be awesome!

@purplecabbage
risingj.com

On Thu, Jun 19, 2014 at 4:15 PM, Jesse purplecabb...@gmail.com wrote:

@purplecabbage
risingj.com

On Thu, Jun 19, 2014 at 3:45 PM, Michal Mocny mmo...@chromium.org
wrote:

Andrew has raised that concern as well. My gut says that the bundling
of
a
few shorts scripts that get parsed but not run as long as they don't get
require() will not affect applications negatively (there are probably
many
more significant overheads we live with today in cordova) -- but I
understand why that may not be useful default.

In that case, some ideas: (I recall these were proposed previously but
not
sure by whom)
(a) Bundle tests as a plugin-within-the-plugin as such:
myplugin/
- plugin.xml
- src/...
- www/...
- tests/
- plugin.xml
- www/...

Which basically means the plugin tests live in the same repo/branch, and
are fetched as part of plugin add, but are not moved into platforms/
on
cordova prepare by default, thus don't end up in your application (disk
and
network are cheap, application startup and size costs are not, right?).
Then, to run tests, we basically need to iterate all plugins looking
for a
nested tests/plugin.xml, and install those. This can be added to
CLI/Plugman, or just be a CLI hook even.

(b) add a js-test-module or js-module type=test that is only used
if
you run prepare with --test. Similar to the above, but I think requires
more CLI/config file changes, which I'm not a fan of.
(c) Just ship tests as a second plugin in a second repo, and document
how
to install tests. Can then perhaps have a dependency type=tests. I
don't like this as much since its basically back to mobile-spec.

WDYT?

-Michal

On Thu, Jun 19, 2014 at 4:53 PM, Jesse purplecabb...@gmail.com wrote:

re:

Q: What do I do if my plugin tests must have very large assets?
- A: Don't bundle those assets with your plugin. If you can, have
your
...

My concern is I do not want to see tests added to every project that
uses a
plugin, even if the assets are not large, there are implications to
including the test framework + all the tests because they get loaded
and
processed with all of the plugins and will impact load time even if
never
run.

99.9% of the time the plugin tests will be used by us the plugin
developers, and not the people who use the plugin in there apps.

I agree, having the tester install the test harness plugin dependency
themselves is probably a better option, as I see you have wrapped all
tests
inside a exports.defineAutoTests so we don't have to worry about
describe/it/expects not being defined.

@purplecabbage
risingj.com

On Thu, Jun 19, 2014 at 1:27 PM, Michal Mocny mmo...@chromium.org
wrote:

Jesee, the branch is NOT a requirement (I don't think I documented
it
as
such, except in the examples for installing plugins for initial
look).
Actually, we should delete those stale branches now that we are
moving
up-to-date tests into master. It was just for early experimentation
on
the
feature.

Jesse, I'm not seeing the benefit of using plugins-tests.xml or the
dependency on the test plugin yet, may you elaborate your thoughts?

My hope was that tests are just always installed alongside plugins.
If
that is not a good idea for some particular plugin, say because it
uses
huge assets, I elaborated my answer in the plugin FAQ (

https://github.com/apache/cordova-labs/blob/cdvtest/cordova-plugin-test-framework/README.md#faq
):
FAQ

Q: Should I add

Re: Should use only drawable folder for single application icon

On Thu, Jun 19, 2014 at 6:01 PM, Andrew Grieve agri...@chromium.org wrote:
 I don't think it should resize it, but I do agree we should delete the
 template ones if any are present. Right now you aren't sure if the icon
 tag even did anything if you fail to replace the right size.

The icon tag is ignored entirely if you're not using the CLI, and it's
only a CLI thing.  The problem I have with this right now is that it
doesn't provide a good solution to this problem, since as you stated
earlier, you won't get through App Store review on iOS, and Android
requires numerous icons when you submit your app anyway.  This stupid
anti-feature is what's preventing the platforms from being treated as
build artifacts.

 Android and
 iOS both do a pretty good job at resizing at runtime if only one large icon
 is present (although you won't get through app-store review).


I disagree about Android doing a good job.  We just don't notice it
because we happen to have stupidly high quality template icons and we
mostly test on hdpi and xhdpi devices.  I'm sure if I ran this on an
mdpi or ldpi device, the icon would be all distorted.




 On Thu, Jun 19, 2014 at 5:17 PM, Joe Bowser bows...@gmail.com wrote:

 So, it resizes the icon? If not, then the point is still valid.
 On Jun 19, 2014 2:11 PM, Darryl Pogue dvpdin...@gmail.com wrote:

  On 19 June 2014 13:52, Joe Bowser bows...@gmail.com wrote:
It's really not neccessary to have 5 not similar, but exactly same
 icon
files, when we can have only 1 icon file.
  
   People should be changing their icons anyway, and I don't believe we
   actually landed any support for the icon element in config.xml.
 
  This support landed in cordova-cli 3.5.0.

Re: plugin test framework