RE: Buildbot: buildslave cordova-osx-slave was lost

[Dmitry Blotsky]

Doing debugging on the machine. Should be back up within the hour.

-Original Message-
From: build...@apache.org [mailto:build...@apache.org] 
Sent: Thursday, January 7, 2016 3:11 PM
To: dev@cordova.apache.org
Subject: Buildbot: buildslave cordova-osx-slave was lost

The Buildbot working for 'ASF Buildbot'
has noticed that the buildslave named cordova-osx-slave went away

It last disconnected at Thu Jan  7 23:06:26 2016 (buildmaster-local time)

The admin on record (as reported by BUILDSLAVE:info/admin) was 'Dmitry Blotsky 
 '.

Sincerely,
 The Buildbot
 
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fci.apache.org%2f=01%7c01%7cdblotsky%40microsoft.com%7c10c67aafc3f543bd0bd608d317b7dfe7%7c72f988bf86f141af91ab2d7cd011db47%7c1=6wNtxJI9IlWUtiN2iq3yCLdw9x%2f4m3oqAn%2fSNoYa3IA%3d

https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fci.apache.org%2fbuildslaves%2fcordova-osx-slave=01%7c01%7cdblotsky%40microsoft.com%7c10c67aafc3f543bd0bd608d317b7dfe7%7c72f988bf86f141af91ab2d7cd011db47%7c1=Ga7tBEsoAp4txrzMLRRFCx2yZUWtYdDHQZRwucbU4sc%3d

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Late Response: Does Cordova make Developer happy

[Joerg Holz]

Hi,

in the last two month I supported Cordova on stackoverflow a lot and I want to 
give you a quick overview:

Questions per month about 1000, unanswared about 75%.

Ionic: 550/65%

Telerik: 115/64%

NativeScript: 18/64%

jQuery: 1/44%


My peronal result of response is, that I got an accept of my answers on about 
every 7. answer. A lot of my answers and the most of my comments got no 
response.


There are two main types of Cordova users, which are asking: 

– The absolut beginner

– The Middle-Type: one, who is in the middle of a project, but less experience 
on how to handle projects and writing code.


The Beginner-Type (From my feeling about 80% from all):

My favorite is: «I want to make a service like Facebook. What do I need?».

They do not have experience/knowledge in handling a project, how to write clean 
code … They think it is just screwing some HTML, CSS and JS together. They put  
everything of scripts, libraries  together, which they get.

The basics are missing.


The Middle–Type:

The standard problem is, missing or wrong Content-Security-Policy. And the 
other problem is, they do not read the docs or they can’t find the info.

From my feeling: About 50% have problems with event-driven-software.


The less rate of answered questions comes from askers which have a max. 
reputation of 50 on stackoverflow. A lot of them are starting to write software 
and have chosen Cordova, because it seams to be easy.

The answering of «real» questions is from my feeling in a rate of 50%..


Quit a lot of trouble  is coming from the Cordova-daugthers, like PhoneGap, 
Ionic, … «I want to integrate plugin xyz. It doesn’t work».


What should be done in my opinion?

1. We should more populate, maybe create a slogan: Write clean HTML, CSS, JS, 
then your Cordova App will work.

2. We should write in the top of «Get Started Fast», that there are some skills 
to build Hybrid-Apps.

3. We should have a small section, where we write what the best way is to make 
Cordova apps unusable.

4. We should make more clear what the difference between Cordova, Ionic, 
PhoneGap, … is.




Greets from the Canary Islands,


Joerg


Jörg Holz | +49-175-640 35 80   
h...@hamburg.de

https://www.workflow-management.net




smime.p7s
Description: S/MIME cryptographic signature

Re: [DISCUSS] Core Plugins and Android API 23

[Joe Bowser]

On Thu, Jan 7, 2016 at 2:42 PM, Jason Ginchereau 
wrote:

> Hi Joe,
>
> Can you provide more specific reasons why you think using reflection is
> problematic in this case? This seems to me like exactly the sort of
> situation where reflection is an appropriate solution.
>

I can provide two good reasons, and one personal reason:

1. Since the helper class lives in the plugin, we have to have the same
code in numerous plugins.
2. This doesn't help the people using the apps, it only helps the
developers writing them, and it only helps the developers not upgrade.  I
don't want to help people to avoid upgrading to a later version of Cordova.
3. I've been burned by reflection too many times to want it anywhere.


>
> There are valid reasons why many app developers might not be ready to move
> to API level 23:
>   1) They have an app which is stabilizing or in maintenance mode and they
> don't want to risk destabilization by moving to a new major Cordova
> version, Cordova Android platform, and Android API level.
>

Sure, not moving to a new version of Cordova right away may be valid
because our upgrade process feels broken and untested, but when it's paired
with an Android API level, you either move up or you get left behind and
that should include plugins.  We can't guarantee that the latest plugins
will work with all versions of Cordova, and I don't think anyone wants to
do the testing for the plugins.  I sure don't want to open that pandora's
box, which is why I oppoose this change so strongly.


>   2) They are using a 3rd-party plugin which has not yet been updated to
> request Android permissions as required by API level 23. There are probably
> a lot of plugins affected, since access to any of the following things on
> Android M requires runtime permission requests: calendar, contacts, phone,
> camera, microphone, location, beacons, sensors, SMS, storage.
>

Marshmallow is rolling out to real devices now and these third party
plugins are going to have to get updated sooner or later.  My two year old
Moto X (2nd gen) just got an update to Marshmallow.  We can't constantly
fight the future every time the Android project changes something just
because we don't have a very healthy plugin ecosystem (I consider the mass
abandonment of third-party plugins by their developers unhealthy).  This
project already has a bad habit of doing that.



>   3) They might not have the capacity or ability to test their app on
> devices running Android M. Because API 23 enables the new permissions model
> only on Android M, it requires testing on that platform.
>

I don't agree with this argument, because you can run apps compiled against
API 23 on older devices, and if you have to, you can still spot check the
permissions on the emulator.  As much as I hate the emulator, the new
changes Google made to it are good, and it's probably worth using.  I still
think that apps need to be tested on a real device, but spot checking
certain things on an emulator is fine if you don't have the latest and
greatest.


> In any of the above cases, developers might still like to benefit from
> some of the major bug fixes in those 5 popular core plugins mentioned
> below. Or even if they weren't specifically looking for bug fixes, it would
> be a much better experience if adding or updating one of those plugins
> would just work, rather than failing on Android. The explanation for the
> failure will not be obvious to many users, if they overlooked the warning
> when installing the plugin or if they were using another tool to add the
> plugin where the warning wasn't surfaced.
>
>
> Of course developers should be encouraged to upgrade to the latest most
> secure highest-quality version of Cordova. But the encouragement does not
> need to be so forceful. This proposed change gives developers more time to
> upgrade, and allows for more choice about when to upgrade individual parts
> (plugins) rather than limiting them to all-or-nothing.
>
>
I completely disagree and I think it does need to be forceful, because
otherwise developers will NEVER upgrade.  The only time developers who use
Cordova upgrade is when we force them to, and even then there's still tons
of old versions of Cordova out there that people are using despite the
Google Security issues.  We can't test these new plugins against every old
version of Cordova, and this change goes against what we talked about
earlier.


> Jason
>
>
> -Original Message-
> From: Joe Bowser [mailto:bows...@gmail.com]
> Sent: Wednesday, January 6, 2016 4:45 PM
> To: dev 
> Subject: Re: [DISCUSS] Core Plugins and Android API 23
>
> I'm very against this idea because we've been burned by using reflection
> in the past.  I also feel that this allows developers be terrible and to
> stick with older, more insecure versions of Cordova, which is the main
> reason I'm against it.  I don't think that requiring API level 23 is a
> problem.
> There's nothing 

Re: [DISCUSS] Core Plugins and Android API 23

[Simon MacDonald]

I'm going to play devils advocate a bit here:


> There are valid reasons why many app developers might not be ready to move
> to API level 23:
>   1) They have an app which is stabilizing or in maintenance mode and they
> don't want to risk destabilization by moving to a new major Cordova
> version, Cordova Android platform, and Android API level.
>

If the developer is not ready to move to a new version of Cordova Android
or the Android API would it not also follow that they shouldn't be changing
their plugin versions?


>   2) They are using a 3rd-party plugin which has not yet been updated to
> request Android permissions as required by API level 23. There are probably
> a lot of plugins affected, since access to any of the following things on
> Android M requires runtime permission requests: calendar, contacts, phone,
> camera, microphone, location, beacons, sensors, SMS, storage.
>

Right, so if the 3rd party plugin they are using doesn't support Android M
they should either a) not upgrade or b) send a PR to the plugin maintainer
so everyone can benefit.


>   3) They might not have the capacity or ability to test their app on
> devices running Android M. Because API 23 enables the new permissions model
> only on Android M, it requires testing on that platform.
>
>
Everyone has access to the Android emulator.


> In any of the above cases, developers might still like to benefit from
> some of the major bug fixes in those 5 popular core plugins mentioned
> below. Or even if they weren't specifically looking for bug fixes, it would
> be a much better experience if adding or updating one of those plugins
> would just work, rather than failing on Android. The explanation for the
> failure will not be obvious to many users, if they overlooked the warning
> when installing the plugin or if they were using another tool to add the
> plugin where the warning wasn't surfaced.
>

 Seems like you are describing a tooling problem here. If the tool doesn't
surface the warning or allows the user to add a plugin that is incompatible
with the version of Cordova Android that is being used really sounds like a
bug in the tooling to me.


> Of course developers should be encouraged to upgrade to the latest most
> secure highest-quality version of Cordova. But the encouragement does not
> need to be so forceful. This proposed change gives developers more time to
> upgrade, and allows for more choice about when to upgrade individual parts
> (plugins) rather than limiting them to all-or-nothing.


 I would argue that the developer has an infinite amount of time to
upgrade. Nothing is forcing you to upgrade to the latest Cordova Android or
Android API. They can continue to use the same version of Cordova Android
and plugins that are currently working in their app. If the developer is
using semver properly and we do our job right they shouldn't pick up
breaking changes. For instance, if the API of a plugin changes we bump the
major version of the plugin so users who setup their config.xml to use:



will effectively prevent the user from picking up the breaking change in
camera version 2.0.0.

Simon Mac Donald
http://hi.im/simonmacdonald

Buildbot: buildslave cordova-osx-slave was lost

[buildbot]

The Buildbot working for 'ASF Buildbot'
has noticed that the buildslave named cordova-osx-slave went away

It last disconnected at Thu Jan  7 23:06:26 2016 (buildmaster-local time)

The admin on record (as reported by BUILDSLAVE:info/admin)
was 'Dmitry Blotsky 
'.

Sincerely,
 The Buildbot
 http://ci.apache.org/

http://ci.apache.org/buildslaves/cordova-osx-slave

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[GitHub] cordova-plugin-file-transfer pull request: Fix exception thrown by...

[anemitoff]

GitHub user anemitoff opened a pull request:

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

Fix exception thrown by call to remapApi on main thread

When reamapApi was being called for device file it was performing IO on
the WebCore thread and throwing an IllegalState exception.  This seems
to have only been a problem when local URL corresponded to a video file.

Moved calls to remapApi for device URLs within new thread context so
that IO is performed on background thread.

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

$ git pull https://github.com/mcsqd/cordova-plugin-file-transfer master

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

https://github.com/apache/cordova-plugin-file-transfer/pull/124.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 #124


commit f2fbdf8afc8c5f5255a4f93c608044040a4f9697
Author: Adam Nemitoff 
Date:   2016-01-07T16:43:28Z

Fix exception thrown by call to remapApi on main thread

When reamapApi was being called for device file it was performing IO on
the WebCore thread and throwing an IllegalState exception.  This seems
to have only been a problem when local URL corresponded to a video file.

Moved calls to remapApi for device URLs within new thread context so
that IO is performed on background thread.




---
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.
---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[GitHub] cordova-plugin-splashscreen pull request: Get AutoHideSplashScreen...

[Bnaya]

Github user Bnaya commented on the pull request:


https://github.com/apache/cordova-plugin-splashscreen/pull/66#issuecomment-169727420
  
+1 for this


---
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.
---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[GitHub] cordova-lib pull request: CB-10121 added deprecation notice for am...

[stevengill]

Github user stevengill closed the pull request at:

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


---
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.
---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[GitHub] cordova-android pull request: CB-10014: Set gradle applicationId t...

[dpogue]

Github user dpogue closed the pull request at:

https://github.com/apache/cordova-android/pull/247


---
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.
---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[GitHub] cordova-android pull request: CB-10014: Set gradle applicationId t...

[dpogue]

Github user dpogue commented on the pull request:

https://github.com/apache/cordova-android/pull/247#issuecomment-169754307
  
Merged in fb9cf60c4100d5bc6f9320747611da1ca0ced289


---
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.
---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[GitHub] cordova-android pull request: Update theme to Theme.DeviceDefault....

[nikhilkh]

Github user nikhilkh commented on the pull request:

https://github.com/apache/cordova-android/pull/245#issuecomment-169753325
  
@dpogue Could you change the title to point to this JIRA: CB-10295. Looks 
like a good one to merge.



---
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.
---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[GitHub] cordova-osx pull request: Support for multi-dimensional js array/o...

[tripodsan]

Github user tripodsan commented on the pull request:

https://github.com/apache/cordova-osx/pull/29#issuecomment-169758462
  
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.
---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[GitHub] cordova-plugin-splashscreen pull request: CB-9374 Android: add Spl...

[nikhilkh]

Github user nikhilkh commented on the pull request:


https://github.com/apache/cordova-plugin-splashscreen/pull/57#issuecomment-169778462
  
@daserge  Can you help merge this after making the docs update?


---
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.
---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[GitHub] cordova-android pull request: Update theme to Theme.DeviceDefault....

[dpogue]

Github user dpogue closed the pull request at:

https://github.com/apache/cordova-android/pull/245


---
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.
---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

RE: CB-10201: Why is gradlew not executable? Design reason?

[Nikhil Khandelwal]

I don’t think there was a design reason. As Bill mentions in CB-10201 - for 
some odd reason gradlew from the android SDK directory (the source of the file) 
does not have the execute permissions. It makes sense for us to set the 
permissions either after copying or before invoking it. We do this is a number 
of places in cordova-lib as well.

Let's go ahead and fix this.

Thanks,
Nikhil

-Original Message-
From: Joe Bowser [mailto:bows...@gmail.com] 
Sent: Thursday, January 7, 2016 1:14 PM
To: dev 
Subject: CB-10201: Why is gradlew not executable? Design reason?

Hey

I'm wondering if we have a design reason for the gradle executable to not be 
executable? Does anyone know? If not, I'm probably going to change it if nobody 
else gets to it first.

Re: How does orientation work, and what is shouldRotateToOrientation?

[Shazron]

What Julio said. The original intent for this was for a way for
Cordova users to control orientation dynamically (say a view you have
is supposed to work in landscape only) --  the orientation methods
currently are all static (Info.plist based).

On Wed, Jan 6, 2016 at 11:01 PM, julio cesar sanchez
 wrote:
> Can you share the whole bug report?
>
> On iOS the rotation doesn't work unless you configure it on the config.xml
>
> 
> 
> 
>
> The shouldRotateToOrientation javascript function is deprecated on cordova
> ios 4.x.x
>
> https://issues.apache.org/jira/browse/CB-5690
> https://issues.apache.org/jira/browse/CB-8893
>
>
>
>
> 2016-01-07 6:38 GMT+01:00 Dmitry Blotsky :
>
>> Hey folks,
>>
>> I’ve had a bug forwarded my way where a Cordova app wouldn’t switch
>> orientation on iOS unless the following code was present:
>>
>> function onDeviceReady() {
>> ...
>> window.shouldRotateToOrientation = function (degrees) {
>> return true;
>> }
>> ...
>> };
>>
>> Could someone please explain why it is needed? Is this in one of our
>> plugins? And perhaps also: what else/instead is needed to have a Cordova
>> app properly support flipping of screen orientation?
>>
>> Kindly,
>> Dmitry

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

CB-10201: Why is gradlew not executable? Design reason?

[Joe Bowser]

Hey

I'm wondering if we have a design reason for the gradle executable to not
be executable? Does anyone know? If not, I'm probably going to change it if
nobody else gets to it first.

[GitHub] cordova-plugin-splashscreen pull request: CB-9374 Android: add Spl...

[wilsonpinto360]

Github user wilsonpinto360 commented on the pull request:


https://github.com/apache/cordova-plugin-splashscreen/pull/57#issuecomment-169828497
  
@nikhilkh it already was merged, check #70.


---
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.
---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

RE: [DISCUSS] Core Plugins and Android API 23

[Jason Ginchereau]

Hi Joe,

Can you provide more specific reasons why you think using reflection is 
problematic in this case? This seems to me like exactly the sort of situation 
where reflection is an appropriate solution.


There are valid reasons why many app developers might not be ready to move to 
API level 23:
  1) They have an app which is stabilizing or in maintenance mode and they 
don't want to risk destabilization by moving to a new major Cordova version, 
Cordova Android platform, and Android API level.
  2) They are using a 3rd-party plugin which has not yet been updated to 
request Android permissions as required by API level 23. There are probably a 
lot of plugins affected, since access to any of the following things on Android 
M requires runtime permission requests: calendar, contacts, phone, camera, 
microphone, location, beacons, sensors, SMS, storage.
  3) They might not have the capacity or ability to test their app on devices 
running Android M. Because API 23 enables the new permissions model only on 
Android M, it requires testing on that platform.

In any of the above cases, developers might still like to benefit from some of 
the major bug fixes in those 5 popular core plugins mentioned below. Or even if 
they weren't specifically looking for bug fixes, it would be a much better 
experience if adding or updating one of those plugins would just work, rather 
than failing on Android. The explanation for the failure will not be obvious to 
many users, if they overlooked the warning when installing the plugin or if 
they were using another tool to add the plugin where the warning wasn't 
surfaced.


Of course developers should be encouraged to upgrade to the latest most secure 
highest-quality version of Cordova. But the encouragement does not need to be 
so forceful. This proposed change gives developers more time to upgrade, and 
allows for more choice about when to upgrade individual parts (plugins) rather 
than limiting them to all-or-nothing. 


Jason


-Original Message-
From: Joe Bowser [mailto:bows...@gmail.com] 
Sent: Wednesday, January 6, 2016 4:45 PM
To: dev 
Subject: Re: [DISCUSS] Core Plugins and Android API 23

I'm very against this idea because we've been burned by using reflection in the 
past.  I also feel that this allows developers be terrible and to stick with 
older, more insecure versions of Cordova, which is the main reason I'm against 
it.  I don't think that requiring API level 23 is a problem.
There's nothing saying that they can't use prior versions of plugins with their 
applications, but we shouldn't be using reflection because these users are too 
lazy to update their Android environment or get their plugins to work.  I'm 
almost certain that this will burn us in the future when some users wants some 
API that we removed for a good reason.

Seriously, if we allow this to happen, what was the point of even incrementing 
the version to Android 5.0? Also, do we have to basically write the apps for 
our users as well at this point, because they're unable to deal with change?


On Wed, Jan 6, 2016 at 4:08 PM, Richard Knoll  wrote:

> Hey all,
>
> As has been very thoroughly discussed at this point, the 
> cordova-android
> 5.0.0 update included breaking changes for plugins in response to the 
> new permission model that Android Marshmallow introduced. 
> Unfortunately, this means that our plugins that took advantage of the 
> new permission APIs are no longer able to build on Cordova platforms before 
> cordova-android 5.0.0.
> Really, this update only came down to two new methods in CordovaInterface:
> one for requesting permissions and one for checking them. Since this 
> is such a minor API change, it is trivial for us to modify the core 
> plugins that require permissions to use reflection and allow projects 
> that are still using the earlier Android APIs to keep using them. I 
> have done so for the camera plugin as an example [1]. All it took was 
> writing a helper class for permissions that I made general enough to 
> be easily included in the other core plugins.
>
> This change gives users who are not ready to embrace Android API 23 
> some more time before they are forced to update (e.g. if they are 
> still using some other plugins that have yet to be updated). It also 
> helps us reduce some of the current plugin versioning woes we're 
> having. Anyone using Cordova 5.x stands to benefit, since this can 
> prevent some confusion and frustration caused by broken builds when 
> their cli fetches the latest plugins. In my opinion, the cost of 
> copying a helper class is worth that potential payoff. What do others think?
>
> I did a little testing with my modified camera plugin and 
> cordova-android
> 3.7.1 (which I arbitrarily chose) and it built/seemed to work fine. If 
> people support this idea, I can do a bit more testing and make PRs for 
> the other plugins.
>
> For the record, the affected plugins are