[GitHub] cordova-windows pull request: CB-8760 'platform list' doesn't show...

[TimBarham]

GitHub user TimBarham opened a pull request:

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

CB-8760 'platform list' doesn't show version for windows platform.

Added version file for `windows` platform (note that this relies on a 
change in `coho` to keep it in sync).

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

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

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

https://github.com/apache/cordova-windows/pull/64.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 #64


commit 14a470b78c8ddedb8ab60c056dc33d1a89a10cfb
Author: Tim Barham 
Date:   2015-03-27T04:52:59Z

CB-8760 platform list doesn't show version for windows platform.

Added version file for windows platform (note that this relies on a change 
in coho to keep it in sync).




---
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-browser pull request: CB-8760 'platform list' shows wrong ...

[TimBarham]

GitHub user TimBarham opened a pull request:

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

CB-8760 'platform list' shows wrong version for browser platform.

Updated version file for `browser` platform (note that this relies on a 
change in `coho` to keep it in sync).

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

$ git pull https://github.com/MSOpenTech/cordova-browser CB-8760

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

https://github.com/apache/cordova-browser/pull/11.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 #11


commit b6a3826ca7e624c2683729f04672e82dc26a84f5
Author: Tim Barham 
Date:   2015-03-27T04:51:37Z

CB-8760 platform list shows wrong version for browser platform.

Updated version file for browser platform (note that this relies on a 
change in coho to keep it in sync).




---
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-coho pull request: CB-8760 Issues with 'platform list'.

[TimBarham]

GitHub user TimBarham opened a pull request:

https://github.com/apache/cordova-coho/pull/67

CB-8760 Issues with 'platform list'.

Added support for updating `windows` and `browser` platform versions.

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

$ git pull https://github.com/MSOpenTech/cordova-coho CB-8760

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

https://github.com/apache/cordova-coho/pull/67.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 #67


commit 0f1336e517b1d8e482a0c955195953df59a2d4aa
Author: Tim Barham 
Date:   2015-03-27T04:51:10Z

CB-8760 Issues with 'platform list'.

Added support for updating 'windows' and 'browser' platform versions.




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

Plugin Development

[Rahul Bhooteshwar]

Hello All,
I am new to cordova development, and would like to know how to develop
cordova plugins for various platforms. I found the development guide for
the same here
.
But it explains the basic procedure to do the same. I would like to know
how to develop cordova plugins using the SDK provided by device vendor for
specific  platform. I want to develop cordova plugin for LineDevice
. I have the ios SDK provided by vendor, but I don't
 know how to use  it with cordova. The SDK provided contains LineaSDK.h and
libLineaSDK.a files. Please help.

Rahul Bhooteshwar

[GitHub] cordova-plugin-file-transfer pull request: CB-6313 [wp8]: Extra bo...

[dpolivy]

GitHub user dpolivy opened a pull request:

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

CB-6313 [wp8]: Extra boundary in upload

When performing an upload on Windows Phone, an extra boundary is
included after any parameters, and before the file contents. This causes
some servers (such as express/multiparty on node.js) to fail to handle
the request properly.

This commit removes the extraneous boundary.

Fixes https://issues.apache.org/jira/browse/CB-6313

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

$ git pull https://github.com/dpolivy/cordova-plugin-file-transfer CB6313

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

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


commit 237dd43b4d28c1a0e074bafedd404e6a7566cc7e
Author: Dan Polivy 
Date:   2015-03-27T06:13:12Z

CB-6313 [wp8]: Extra boundary in upload

When performing an upload on Windows Phone, an extra boundary is
included after any parameters, and before the file contents. This causes
some servers (such as express/multiparty on node.js) to fail to handle
the request properly.

This commit removes the extraneous boundary.

Fixes https://issues.apache.org/jira/browse/CB-6313




---
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: Fix plugman install failure on iOS conta...

[caseywebdev]

GitHub user caseywebdev opened a pull request:

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

Fix plugman install failure on iOS containing &

I have an iOS project named `Foo & Bar`. When trying to run `cordova plugin 
add ` an error is thrown:

```
Failed to install 'org.apache.cordova.splashscreen':CordovaError: could not 
find -Info.plist file, or config.xml file.
at Object.module.exports.parseProjectFile 
(/Users/casey/projects/example/node_modules/cordova/node_modules/cordova-lib/src/plugman/platforms/ios.js:193:19)
at Object.ActionStack.process 
(/Users/casey/projects/example/node_modules/cordova/node_modules/cordova-lib/src/plugman/util/action-stack.js:55:49)
at handleInstall 
(/Users/casey/projects/example/node_modules/cordova/node_modules/cordova-lib/src/plugman/install.js:575:20)
at 
/Users/casey/projects/example/node_modules/cordova/node_modules/cordova-lib/src/plugman/install.js:335:28
at _fulfilled 
(/Users/casey/projects/example/node_modules/cordova/node_modules/q/q.js:787:54)
at self.promiseDispatch.done 
(/Users/casey/projects/example/node_modules/cordova/node_modules/q/q.js:816:30)
at Promise.promise.promiseDispatch 
(/Users/casey/projects/example/node_modules/cordova/node_modules/q/q.js:749:13)
at 
/Users/casey/projects/example/node_modules/cordova/node_modules/q/q.js:509:49
at flush 
(/Users/casey/projects/example/node_modules/cordova/node_modules/q/q.js:108:17)
at process._tickCallback (node.js:355:11)
could not find -Info.plist file, or config.xml file.
```

The problem is that the xcode parser is saying that the plist path is `Foo 
\& Bar-Info.plist`, which is obviously wrong as there is no actual backslash. 
The ampersand seems to be escaped in the `project.pbxproj` file, so I'm not 
sure this is the best place for the fix, or if this might even be a bug in 
https://github.com/alunny/node-xcode

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

$ git pull https://github.com/caseywebdev/cordova-lib patch-1

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

https://github.com/apache/cordova-lib/pull/193.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 #193


commit cc76abd542a0b86fa9150b63ca100ef200173491
Author: Casey Foster 
Date:   2015-03-27T04:44:04Z

Fix plugman install failure on iOS containing &

I have an iOS project named `Foo & Bar`. When trying to run `cordova plugin 
add ` an error is thrown:

```
Failed to install 'org.apache.cordova.splashscreen':CordovaError: could not 
find -Info.plist file, or config.xml file.
at Object.module.exports.parseProjectFile 
(/Users/casey/projects/example/node_modules/cordova/node_modules/cordova-lib/src/plugman/platforms/ios.js:193:19)
at Object.ActionStack.process 
(/Users/casey/projects/example/node_modules/cordova/node_modules/cordova-lib/src/plugman/util/action-stack.js:55:49)
at handleInstall 
(/Users/casey/projects/example/node_modules/cordova/node_modules/cordova-lib/src/plugman/install.js:575:20)
at 
/Users/casey/projects/example/node_modules/cordova/node_modules/cordova-lib/src/plugman/install.js:335:28
at _fulfilled 
(/Users/casey/projects/example/node_modules/cordova/node_modules/q/q.js:787:54)
at self.promiseDispatch.done 
(/Users/casey/projects/example/node_modules/cordova/node_modules/q/q.js:816:30)
at Promise.promise.promiseDispatch 
(/Users/casey/projects/example/node_modules/cordova/node_modules/q/q.js:749:13)
at 
/Users/casey/projects/example/node_modules/cordova/node_modules/q/q.js:509:49
at flush 
(/Users/casey/projects/example/node_modules/cordova/node_modules/q/q.js:108:17)
at process._tickCallback (node.js:355:11)
could not find -Info.plist file, or config.xml file.
```

The problem is that the xcode parser is saying that the plist path is `Foo 
\& Bar-Info.plist`, which is obviously wrong as there is no actual backslash. 
The ampersand seems to be escaped in the `project.pbxproj` file, so I'm not 
sure this is the best place for the fix, or if this might even be a bug in 
https://github.com/alunny/node-xcode




---
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-docs pull request: CB-8715 Update upgrade guide for Androi...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-docs/pull/274


---
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-docs pull request: CB-8715 Update upgrade guide for Androi...

[jpchase]

GitHub user jpchase opened a pull request:

https://github.com/apache/cordova-docs/pull/274

CB-8715 Update upgrade guide for Android 4.0.0



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

$ git pull https://github.com/jpchase/cordova-docs CB-8715-Upgrade

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

https://github.com/apache/cordova-docs/pull/274.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 #274


commit 62d85aa62b13585253eca681bd5aee755a4cad8b
Author: Jason Chase 
Date:   2015-03-27T02:31:11Z

CB-8715 Update upgrade guide for Android 4.0.0




---
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: hook logging issue

[Shazron]

File it pls thx! No idea of the workaround

On Thursday, March 26, 2015, Raymond Camden  wrote:

> So file a bug?
>
> Know a way around it?
>
> On Thu, Mar 26, 2015 at 5:46 PM, Shazron >
> wrote:
> > actually it has stdio:inherit, and does capture the output and pushes
> > it back up the chain, so somewhere up the chain no one does anything
> > with it
> >
> > On Thu, Mar 26, 2015 at 3:36 PM, Shazron  > wrote:
> >>
> https://github.com/apache/cordova-lib/blob/d77ebc40a16ab27a8ed22c0bbf2ab8a84a5ac448/cordova-lib/src/hooks/HooksRunner.js#L188
> >>
> >> It's using child_process.spawn (if you dig down) and is probably
> >> ignoring all stdio when running the script.
> >>
> >> On Thu, Mar 26, 2015 at 3:10 PM, Raymond Camden <
> raymondcam...@gmail.com > wrote:
> >>> This may stray into the "it should be on the google group" territory,
> >>> if so, just let me know.
> >>>
> >>> I'm rewriting Holly's after_platform_add hook to use module.exports.
> >>> When I do, I notice console.log no longer works. Is that expected -
> >>> and if so - is there a workaround? (To be clear, the hook still works
> >>> perfectly well as far as I can see, I just don't see console output.)
> >>>
> >>> module.exports = function(context) {
> >>>
> >>> console.log("Testing "+context);
> >>> var pluginlist = [
> >>>"org.apache.cordova.device",
> >>>"org.apache.cordova.device-motion",
> >>>"org.apache.cordova.device-orientation",
> >>>"org.apache.cordova.geolocation"
> >>> ];
> >>>
> >>> // no need to configure below
> >>> var fs = require('fs');
> >>> var path = require('path');
> >>> var sys = require('sys')
> >>> var exec = require('child_process').exec;
> >>>
> >>> function puts(error, stdout, stderr) {
> >>> //console.log(stdout);
> >>> }
> >>>
> >>> pluginlist.forEach(function(plug) {
> >>> exec("cordova plugin add " + plug, puts);
> >>> });
> >>>
> >>>
> >>> }
> >>>
> >>> --
> >>>
> ===
> >>> Raymond Camden, Developer Advocate for MobileFirst at IBM
> >>>
> >>> Email : raymondcam...@gmail.com 
> >>> Blog : www.raymondcamden.com
> >>> Twitter: raymondcamden
> >>>
> >>> -
> >>> 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
> 
> >
>
>
>
> --
> ===
> Raymond Camden, Developer Advocate for MobileFirst at IBM
>
> Email : raymondcam...@gmail.com 
> Blog : www.raymondcamden.com
> Twitter: raymondcamden
>
> -
> 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-8484: Adds support creating signe...

[agrieve]

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

https://github.com/apache/cordova-android/pull/164#discussion_r27270342
  
--- Diff: bin/templates/cordova/lib/build.js ---
@@ -422,11 +477,15 @@ function parseOpts(options, resolvedTarget) {
 module.exports.runClean = function(options) {
 var opts = parseOpts(options);
 var builder = builders[opts.buildMethod];
-return builder.prepEnv()
+return builder.prepEnv(opts)
 .then(function() {
-return builder.clean(opts.extraArgs);
+return builder.clean(opts);
 }).then(function() {
 shell.rm('-rf', path.join(ROOT, 'out'));
+}).then(function() {
+['debug', 'release'].forEach(function(config) {
+removeIfExists(path.join(ROOT, config + SIGNING_PROPERTIES));
--- End diff --

hmm, maybe for this reason you should pass the parameters on the command 
line as gradle properties so that there is no file to clean up. Note that it's 
unlikely the ANT workflow is important anymore, as gradle is the new default 
and seems to work much better.


---
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: hook logging issue

[Raymond Camden]

So file a bug?

Know a way around it?

On Thu, Mar 26, 2015 at 5:46 PM, Shazron  wrote:
> actually it has stdio:inherit, and does capture the output and pushes
> it back up the chain, so somewhere up the chain no one does anything
> with it
>
> On Thu, Mar 26, 2015 at 3:36 PM, Shazron  wrote:
>> https://github.com/apache/cordova-lib/blob/d77ebc40a16ab27a8ed22c0bbf2ab8a84a5ac448/cordova-lib/src/hooks/HooksRunner.js#L188
>>
>> It's using child_process.spawn (if you dig down) and is probably
>> ignoring all stdio when running the script.
>>
>> On Thu, Mar 26, 2015 at 3:10 PM, Raymond Camden  
>> wrote:
>>> This may stray into the "it should be on the google group" territory,
>>> if so, just let me know.
>>>
>>> I'm rewriting Holly's after_platform_add hook to use module.exports.
>>> When I do, I notice console.log no longer works. Is that expected -
>>> and if so - is there a workaround? (To be clear, the hook still works
>>> perfectly well as far as I can see, I just don't see console output.)
>>>
>>> module.exports = function(context) {
>>>
>>> console.log("Testing "+context);
>>> var pluginlist = [
>>>"org.apache.cordova.device",
>>>"org.apache.cordova.device-motion",
>>>"org.apache.cordova.device-orientation",
>>>"org.apache.cordova.geolocation"
>>> ];
>>>
>>> // no need to configure below
>>> var fs = require('fs');
>>> var path = require('path');
>>> var sys = require('sys')
>>> var exec = require('child_process').exec;
>>>
>>> function puts(error, stdout, stderr) {
>>> //console.log(stdout);
>>> }
>>>
>>> pluginlist.forEach(function(plug) {
>>> exec("cordova plugin add " + plug, puts);
>>> });
>>>
>>>
>>> }
>>>
>>> --
>>> ===
>>> Raymond Camden, Developer Advocate for MobileFirst at IBM
>>>
>>> Email : raymondcam...@gmail.com
>>> Blog : www.raymondcamden.com
>>> Twitter: raymondcamden
>>>
>>> -
>>> 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
>



-- 
===
Raymond Camden, Developer Advocate for MobileFirst at IBM

Email : raymondcam...@gmail.com
Blog : www.raymondcamden.com
Twitter: raymondcamden

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

Re: Buildbot for Cordova on Apache Infra - Update

[Steven Gill]

I haven't had time to really work on getting nightlies going for a while. I
will try to get them up and going again after phase 1. I'm thinking of
using docker on apaches jenkins might be the best way to attempt it. Apache
build settings issues are what killed the momentum the last time.

On Mon, Mar 23, 2015 at 6:10 PM, Nikhil Khandelwal 
wrote:

> Hi,
> Over the last couple of months, we have been reviving medic and ensuring
> it runs on Apache Buildbot Infra. For those who are not familiar with medic
> - it's a BuildBot continuous integration setup that allows to test Cordova
> plugins and platforms. Today marks a big milestone in that work that we
> have the following platforms running and reporting results on a consistent
> basis:
>   - Android:
>  - Windows (17 failures)
>  - OSX (12 failures)
>- IOS (19 failures)
>- Windows (0 failures)
>- WP8.1 (6 failures)
>- WP8
>
> You can use this link to review the results:
> http://ci.apache.org/waterfall?builder=cordova-ios&builder=cordova-android-osx&builder=cordova-windows&builder=cordova-wp8&builder=cordova-android-win&builder=cordova-blackberry-osx&builder=cordova-blackberry-win
>
> Currently, builds are triggered every two hours. We would like to
> integrate with Cordova nightly build to trigger a run.
>
> Steve Gill: Do you have an update on the nightly build for Cordova?
>
> We need help with the following:
>  - Fix all test failures for Android.
>  - Fix all test failures for iOS.
>  - Add other platforms to this test matrix - FirefoxOS?
>
> Results from test runs are currently being loaded to couchDB instance
> hosted on our servers. We have a longstanding infra ticket open to create a
> couchDB instance on Apache Infra. Please vote it up to help get resolved:
> https://issues.apache.org/jira/browse/INFRA-8588
>
> Thanks,
> Nikhil
>
>
> -Original Message-
> From: Dmitriy Barkalov (Akvelon) [mailto:v-dmb...@microsoft.com]
> Sent: Friday, December 12, 2014 9:24 AM
> To: dev@cordova.apache.org
> Subject: RE: Buildbot for Cordova on Apache Infra - Update
>
> Hi all,
>
> I'd like to provide a status update on this task:
> - External slaves could be wired to Apache infra. (I've successfully wired
> windows slave to Apache Infra in testing purposes)
> - Need to resolve some build bot configuration issues
> - After configuration is ready we will add Github hooks to run the builds.
>
>
> Regards, Dmitriy
>
> -Original Message-
> From: m...@google.com [mailto:m...@google.com] On Behalf Of Max Woghiren
> Sent: Monday, December 8, 2014 9:00 PM
> To: dev
> Subject: Re: Buildbot for Cordova on Apache Infra - Update
>
> Yes, once the master is ready, I can take on having our slaves report to
> it.
>
> On Mon, Dec 8, 2014 at 10:41 AM, Michal Mocny  wrote:
>
> > We've already got a lab and slaves but its been in a rather sorry
> > state of disrepair (http://ci.cordova.io/).  Would gladly put in the
> > effort to clean up and report to the new master.
> >
> > On Fri, Dec 5, 2014 at 8:48 PM, Parashuram Narasimhan (MS OPEN TECH) <
> > panar...@microsoft.com> wrote:
> >
> > > Awesome - Thanks Marcel. Once the master is ready, we will start
> > > setting up the slaves.
> > >
> > > -Original Message-
> > > From: Marcel Kinard [mailto:cmarc...@gmail.com]
> > > Sent: Friday, December 5, 2014 1:42 PM
> > > To: dev@cordova.apache.org
> > > Subject: Re: Buildbot for Cordova on Apache Infra - Update
> > >
> > > The IBM team here would be willing to set up a slave with some of
> > > our devices. We have a collection of Android, iOS, BB10, WP8.
> > > Looking forward to instructions on slave setup ;-)
> > >
> > > On Dec 5, 2014, at 12:20 PM, Parashuram Narasimhan (MS OPEN TECH) <
> > > panar...@microsoft.com> wrote:
> > >
> > > > It would be great if we could have other platforms also run using
> > Apache
> > > Infra. Blackberry, Tizen, FirefoxOS, Amazon - any takers for this?
> > > We
> > would
> > > be happy to help.
> > > >
> > > > -Original Message-
> > > > From: Steven Gill [mailto:stevengil...@gmail.com]
> > > > Sent: Wednesday, December 3, 2014 12:23 PM
> > > > To: dev@cordova.apache.org
> > > > Subject: Re: Buildbot for Cordova on Apache Infra - Update
> > > >
> > > > This is amazing news!
> > > >
> > > > Adobe will definitely setup some slaves and try to get our device
> > > > wall
> > > going again.
> > > >
> > > > It would be great if other companies jumped on board with a few
> > > > slaves
> > > for their devices to get some love from medic.
> > > >
> > > > Setting up a slave instructions would also be very helpful! :)
> > > >
> > >
> > >
> > > 
> > > - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > >
> > >
> > > 
> > > - To unsubscribe, e

Re: Plugins to NPM (Phase 1)

[Steven Gill]

On Thu, Mar 26, 2015 at 12:05 PM, Victor Sosa 
wrote:

> With regarding this Plugins to NPM topic...
>
> This is a change that will impact to IDEs who rely on
> http://registry.plugins.io to show available plugins to users. Even though
> there will be a window for this change, CPR will have a 6-months window (at
> least this is my understanding) to let plugin developers to migrate their
> plugins to NPM and also let users to use in the old way (I mean the current
> plugin IDs), there will be the point that this will be unsupported by
> Cordova, hence support in IDEs will break.
>
> I've been doing a little research and collecting some information and here
> the summary of my findings:
> 1. The plugins will be hosted in http://registry.npmjs.org/
> 2. All NPM documents can be listed by querying the server with the
> following URL: http://registry.npmjs.org/-/all
> 3. If you are interested on the Cordova plugins only (as will be the case),
> use the keyword "ecosystem:cordova" to filter out the contents in this
> list. Here is an error prone point, if the plugin doesn't have this keyword
> it will never be found making hard to developers to know it in fact exists
> (this is one of the major plus sides on CPR imho).


If plugin authors want their plugins to be discoverable, they will have to
include "ecosystem:cordova" for now.


> 4. The only way to get such filtered list is to fetching all documents in
> NPMJS registry and then do the filter locally using the keyword
> "ecosystem:cordova", i.e. there is no way to get a filtered list directly
> from the registry (I looked at NPM code and this is what they do. See in
> NPM module, /node_modules/npm/lib/search.js file,
> around line 60 "getFilteredData" function).
>

When we chatted with npm folks last month, they told us they could help us
expose the plugins. I'm sure we can figure out a way that would be easier
than filtering locally.

>
> With those steps, I'm able to retrieve the list of plugins that follow the
> "ecosystem:cordova" contract that was proposed before in a headless way,
> i.e. no web browser, just a small script.
>
> If any of you have suggestions on how better do this Cordova plugins
> discovery on NPMJS, please let me know.
>

I'll send them a email to see what solutions they have. "ecosystem:cordova"
will start returning platforms + tools as well (not reserved just for
plugins).

We may need to build a better search on our own (like
http://browserifysearch.org/). Hopefully it doesn't come down to that
though.

>
>
> 2015-03-25 15:36 GMT-06:00 Horn, Julian C :
>
> > I'd like to add some more questions to what Leo asked.
> >
> > Can anyone explain how the hundreds of plugins that are published in git
> > repos are supposed to transition to CLI 5 (and beyond)?  It seems like
> the
> > answer is that they don't change anything.  What if they want to (or
> > already do) publish via the registry?  It seems like you can win if you
> > keep the id unchanged and add yourself to the mapping table.  But if
> that's
> > true, then why are we renaming the core plugins?
> >
> > I don't think repo-resident plugins need to update any  tags
> > that refer to core plugins.  That is, you can continue to ask for
> > "org.apache.cordova.file".  If you use CLI 5, then the rename logic will
> > get you the corresponding plugin from npm.  Or is there some reason why
> you
> > will eventually have to change your  tags to use the new
> > names.  Of course you better not change a  tag in your
> > repo-resident plugin before October 1, because that will break projects
> > that use your plugin but aren't yet using CLI 5.
> >
> > I haven't been able to come up with any strategy for changing the id of a
> > repo-resident plugin without great pain.  It's basically equivalent to
> > discontinuing your plugin and creating a new one in its place.  So it
> seems
> > to me that if I have any users I would probably want to stick with my
> > existing id and repo URL, even if it meant that I couldn't publish my
> > plugin in npm format.  Is that a viable strategy, or is there a long term
> > plan that EVERY plugin must eventually publish via npm?
> >
> > One final question.  Suppose I have a CLI 4.x project and I want to
> > transition to CLI 5.  Do I have to start over at "cordova create
> project"?
> >
> > Julian
> >
> > -Original Message-
> > From: Treggiari, Leo [mailto:leo.treggi...@intel.com]
> > Sent: Wednesday, March 25, 2015 3:53 PM
> > To: dev@cordova.apache.org
> > Subject: RE: Plugins to NPM (Phase 1)
> >
> > Thanks for the information Steve.  That helps with our planning.  I have
> a
> > couple of follow-ups.
> >
> > > We don't necessarily have to do a major bump for the CLI. We could
> > > easily save the major jump until we switch npm fetching as default
> > > (approx July 1)
> >
> > Re: the major bump.  This seems like a "delayed" breaking change.  That
> > is, when CPR is removed, all prior CLI releases will be "crippled" to a
> > significant degree

Re: Plugins to NPM (Phase 1)

[Steven Gill]

On Wed, Mar 25, 2015 at 2:36 PM, Horn, Julian C 
wrote:

> I'd like to add some more questions to what Leo asked.
>
> Can anyone explain how the hundreds of plugins that are published in git
> repos are supposed to transition to CLI 5 (and beyond)?  It seems like the
> answer is that they don't change anything.  What if they want to (or
> already do) publish via the registry?  It seems like you can win if you
> keep the id unchanged and add yourself to the mapping table.  But if that's
> true, then why are we renaming the core plugins?
>
If you don't change the id, you don't need to be added to the mapping
table. It will just work once we start checking npm first if it is
published as the same id on npm. We decided to rename our core plugins due
to improved readability and fitting in better with the npm ecosystem.

>
> I don't think repo-resident plugins need to update any  tags
> that refer to core plugins.  That is, you can continue to ask for
> "org.apache.cordova.file".  If you use CLI 5, then the rename logic will
> get you the corresponding plugin from npm.  Or is there some reason why you
> will eventually have to change your  tags to use the new
> names.  Of course you better not change a  tag in your
> repo-resident plugin before October 1, because that will break projects
> that use your plugin but aren't yet using CLI 5.
>

Right now, our mapping just spits out a message to use the new name for
users. It doesn't actually convert the id to the new name, though we will
probably start doing the conversion automatically at some point.

The  tag is an interesting usecase. Not sure what the best
solution is. For core plugins, we are doing a major version jump and we are
probably going to have a requirement that they require a newer version of
the CLI to work. (using the engine tag). Third party developers could do
something similar. All of this would be a part of the effort to get
developers to update their tools.


> I haven't been able to come up with any strategy for changing the id of a
> repo-resident plugin without great pain.  It's basically equivalent to
> discontinuing your plugin and creating a new one in its place.  So it seems
> to me that if I have any users I would probably want to stick with my
> existing id and repo URL, even if it meant that I couldn't publish my
> plugin in npm format.  Is that a viable strategy, or is there a long term
> plan that EVERY plugin must eventually publish via npm?
>

We will still support installing via git or locally. So npm won't be a
requirement. To clarify, org.your.project.id is valid for npm. You are
welcomed to use the existing id as package-name when publishing to npm.

>
> One final question.  Suppose I have a CLI 4.x project and I want to
> transition to CLI 5.  Do I have to start over at "cordova create project"?
>

Depends on what changes land in 5. But currently, it is the same as
updating has been since CLI 3.x.
* Update cordova-cli via npm install -g cordova-cli@5.0.0.
* Update your project platforms if you desire. cordova platform rm android;
cordova platform add android@newVERSION. As far as I know, we don't have
any changes coming into the CLI that prevent older platform versions from
working. Hopefully we can keep this going.

Great questions. Appreciate it.

>
> Julian
>
> -Original Message-
> From: Treggiari, Leo [mailto:leo.treggi...@intel.com]
> Sent: Wednesday, March 25, 2015 3:53 PM
> To: dev@cordova.apache.org
> Subject: RE: Plugins to NPM (Phase 1)
>
> Thanks for the information Steve.  That helps with our planning.  I have a
> couple of follow-ups.
>
> > We don't necessarily have to do a major bump for the CLI. We could
> > easily save the major jump until we switch npm fetching as default
> > (approx July 1)
>
> Re: the major bump.  This seems like a "delayed" breaking change.  That
> is, when CPR is removed, all prior CLI releases will be "crippled" to a
> significant degree since no  reference will be able to be
> resolved.
>
> Re: ~July 1:  Would you verify my understanding?  For a 
> reference which is not in the mapping table, from ~Apr to ~July 1, CPR will
> be tried first and if that fails then npm.  From ~July 1 to ~Oct 1, npm
> will be tried first and if that fails then the CPR.  After ~Oct 1, only npm.
>
> Thanks,
> Leo
>
> -Original Message-
> From: Steven Gill [mailto:stevengil...@gmail.com]
> Sent: Wednesday, March 25, 2015 11:13 AM
> To: dev@cordova.apache.org
> Subject: Re: Plugins to NPM (Phase 1)
>
> Thanks for answering tony. More comments below.
>
> On Tue, Mar 24, 2015 at 12:45 PM, Homer, Tony 
> wrote:
>
> > I¹ll try to answer some of Leo¹s questions, but it would be great if
> > someone else (Steve?) could comment.
> >
> > First, though, I¹ll ask a question of my own.
> > Is there a doc or JIRA task for tracking all of the activity related
> > to moving plugins to NPM?
> > There was the Google Doc that was created last hangout for tracking
> > the proposal, but it doesn¹t list JIRAs a

Re: Plugins to NPM (Phase 1)

[Steven Gill]

On Wed, Mar 25, 2015 at 12:53 PM, Treggiari, Leo 
wrote:

> Thanks for the information Steve.  That helps with our planning.  I have a
> couple of follow-ups.
>
> > We don't necessarily have to do a major bump
> > for the CLI. We could easily save the major jump until we switch npm
> > fetching as default (approx July 1)
>
> Re: the major bump.  This seems like a "delayed" breaking change.  That
> is, when CPR is removed, all prior CLI releases will be "crippled" to a
> significant degree since no  reference will be able to be
> resolved.
>
> Re: ~July 1:  Would you verify my understanding?  For a 
> reference which is not in the mapping table, from ~Apr to ~July 1, CPR will
> be tried first and if that fails then npm.  From ~July 1 to ~Oct 1, npm
> will be tried first and if that fails then the CPR.  After ~Oct 1, only npm.
>
> Timeline is correct. Once again we will try to keep CPR up as long as
possible. But with nodejitsu being bought by godaddy, we have a finite
amount of time.

July 1st we would switch CPR to read-only in an effort to get plugin
authors to migrate over to npm.

As we get closer to CPR shutdown date, we will take a look to see if it
makes sense to auto redirect all requests to CPR to npm. Not sure what
would be involved yet, but I think it will be doable. I'd rather us focus
on trying to get users to upgrade + help plugin authors migrate for now.




> Thanks,
> Leo
>
> -Original Message-
> From: Steven Gill [mailto:stevengil...@gmail.com]
> Sent: Wednesday, March 25, 2015 11:13 AM
> To: dev@cordova.apache.org
> Subject: Re: Plugins to NPM (Phase 1)
>
> Thanks for answering tony. More comments below.
>
> On Tue, Mar 24, 2015 at 12:45 PM, Homer, Tony 
> wrote:
>
> > I¹ll try to answer some of Leo¹s questions, but it would be great if
> > someone else (Steve?) could comment.
> >
> > First, though, I¹ll ask a question of my own.
> > Is there a doc or JIRA task for tracking all of the activity related to
> > moving plugins to NPM?
> > There was the Google Doc that was created last hangout for tracking
> > the proposal, but it doesn¹t list JIRAs and hasn¹t been updated since
> > January.
> > I found CB-8529, CB-8538 and CB-8551 but they are not linked to a master
> > task JIRA.
> > This is not a jab at Steve at all, I¹m just wondering if there is or
> > should be a reference for this set of tasks (other than staying caught up
> > with reading the list)?
> >
>
> Good point. I have created a master issue at
> https://issues.apache.org/jira/browse/CB-8743
>
>
> > On to Leo¹s questions-
> >
> > Will the release be named Cordova 5.0?
> > Unknown at this time?  It seems like this will require a co-ordinated
> > release of CLI, Tools and
> > Plugins, with major version bumps for all.
> >
>
> We haven't discussed this yet. We don't necessarily have to do a major bump
> for the CLI. We could easily save the major jump until we switch npm
> fetching as default (approx July 1)
>
> >
> > Will it trigger a major revision bump?
> > Yes.
> >
>
> For plugins, yes. All of the core plugins will be getting a major version
> bump shortly.
>
> >
> > What is the current estimate for the release?
> >
> > I would say ³when it¹s done² but it would be great to get a more specific
> > answer.
> > I¹m not sure if that¹s possible?
> >
>
> Aiming for April 1st.
>
> >
> > If release of Phase 1 occurs on April 1 does this mean that the CPR
> > becomes read-only on July 1 and is
> > deleted on Oct 1?
>
> I think the real driver was that there is an external hosting issue with
> > CPR after Oct. 1.
> > The 3 month period was adopted so provide a transition window, but there
> > is a hard stop on or around Oct. 1.
> > Steve had mentioned this somewhere but I can¹t find it now.
> >
>
> - CPR becomes read-only July 1st (if we release April 1st)
> - Tools fetch from NPM by default on July 1st (currently checks CPR first,
> npm as fallback)
> - We will try to keep CPR open as read-only for as long as possible.
> Nodejitsu people told us they could give us the 6 months but we will see if
> we can stretch it. A day will come when we will have to shut down CPR
> though.
>
> >
> > -  On Oct 1, all previous releases of Cordova CLI (< 5.0) will
> immediately
> > be "broken"?
>
>
> > Yes, that is my understanding, although in reading back over the
> > discussion I don¹t see where it is explicitly addressed.
> > I was assuming that this is intended in part as a forcing function.
> >
>
> Yes. We could look into setting up some redirect service to keep old
> versions working. But for now, we are saying users will have to upgrade.
>
> >
> > Tony
> >
> >
> > On 3/20/15, 11:05 AM, "Treggiari, Leo"  wrote:
> >
> > >I have a few questions about Phase 1 (and beyond) as I plan how to
> > >migrate the Intel XDK and existing user projects through this change.
> > >
> > >-  Will the release be named Cordova 5.0?  This seems worthy of a major
> > >bump for the CLI in addition to the plugins.
> > >
> > >-  What is the current estimate for th

[GitHub] cordova-android pull request: CB-8484: Adds support creating signe...

[nikhilkh]

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

https://github.com/apache/cordova-android/pull/164#discussion_r27267702
  
--- Diff: bin/templates/cordova/lib/build.js ---
@@ -542,5 +653,12 @@ module.exports.help = function() {
 console.log('\'--versionCode=#\': Override versionCode for this 
build. Useful for uploading multiple APKs. Requires --gradle.');
 console.log('\'--minSdkVersion=#\': Override minSdkVersion for 
this build. Useful for uploading multiple APKs. Requires --gradle.');
 console.log('\'--gradleArg=\': Extra args 
to pass to the gradle command. Use one flag per arg. Ex. 
--gradleArg=-PcdvBuildMultipleApks=true');
+console.log('');
+console.log('Signed APK flags:');
--- End diff --

Resolved in next commit


---
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-8484: Adds support creating signe...

[nikhilkh]

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

https://github.com/apache/cordova-android/pull/164#discussion_r27267568
  
--- Diff: bin/templates/cordova/lib/build.js ---
@@ -530,8 +589,60 @@ module.exports.findBestApkForArchitecture = 
function(buildResults, arch) {
 throw new Error('Could not find apk architecture: ' + arch + ' 
build-type: ' + buildResults.buildType);
 };
 
+function removeIfExists(file) {
--- End diff --

Resolved in next iteration


---
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: [Vote] 3.9.0 Cordova App Hello World Release

[Steven Gill]

The vote has now closed. The results are:

Positive Binding Votes: 3

Steve Gill
Ian Clelland
Andrew Grieve


The vote has passed. I will now publish it to npm and dist. I will
also update the dependency in cordova-lib.


On Wed, Mar 25, 2015 at 12:55 PM, Andrew Grieve 
wrote:

> +1
>
> On Tue, Mar 24, 2015 at 9:29 AM, Ian Clelland 
> wrote:
>
> > +1
> >
> > * Checked signatures and checksums
> > * Verified contents against Git repo at 3.9.0 tag
> > * Successfully built and ran hello world with Cordova-Android 3.7.1 and
> > 4.0.0-dev (master)
> >
> > On Mon, Mar 23, 2015 at 8:13 PM, Steven Gill 
> > wrote:
> >
> > > Please review and vote on this 3.9.0 Cordova App Hello World Release.
> > >
> > > Release issue: https://issues.apache.org/jira/browse/CB-8731
> > >
> > > Repos ready to be released have been published to
> > > dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-8731
> > >
> > > The package was published from its corresponding git tag:
> > > cordova-app-hello-world: 3.9.0 (fb3150bf76)
> > >
> > > Upon a successful vote I will upload the archive to dist/ and publish
> it
> > > to NPM.
> > >
> > > Voting guidelines:
> > >
> >
> https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
> > >
> > > Voting will go on for a minimum of 48 hours.
> > >
> > > I vote +1:
> > > * Ran coho audit-license-headers over the relevant repos
> > > * Ran coho check-license to ensure all dependencies and
> > > subdependencies have Apache-compatible licenses
> > > * Built a hello world app using the CLI
> > >
> >
>

[VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist Plugins Release (attempt 2)

[Steven Gill]

Please review and vote on the releases of cordova-plugin-whitelist and
cordova-plugin-legacy-whitelist plugins.

Release issue: https://issues.apache.org/jira/browse/CB-8739

The plugins have been published to
dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-8739/

The packages were published from their corresponding git tags:
cordova-plugin-whitelist: 1.0.0
(38f5a9fa2c)cordova-plugin-legacy-whitelist: 1.0.0 (1ce26eba64)

Upon a successful vote I will upload the archives to dist/ and upload
them to npm.

Voting guidelines:
https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md

Voting will go on for a minimum of 48 hours.

I vote +1:
* Ran coho audit-license-headers over the relevant repos
* Ran coho check-license to ensure all dependencies and
subdependencies have Apache-compatible licenses

Re: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist Plugins Release

[Steven Gill]

This vote has failed

On Thu, Mar 26, 2015 at 12:41 PM, Steven Gill 
wrote:

> I'll send out a new one soon
> On Mar 26, 2015 10:48 AM, "Ian Clelland"  wrote:
>
>> Yeah :(
>>
>> Hash changes, code changes, checksums and pgp signatures change... all
>> necessitates a new vote.
>> At least we get to abort early.
>>
>> On Thu, Mar 26, 2015 at 1:28 PM, Parashuram N (MS OPEN TECH) <
>> panar...@microsoft.com> wrote:
>>
>> > Should we have to restart the vote thread, now that the tag will change
>> ?
>> >
>> > -Original Message-
>> > From: agri...@google.com [mailto:agri...@google.com] On Behalf Of
>> Andrew
>> > Grieve
>> > Sent: Thursday, March 26, 2015 7:41 AM
>> > To: dev
>> > Subject: Re: [VOTE] Cordova-Plugin-Whitelist and
>> > Cordova-Plugin-Legacy-Whitelist Plugins Release
>> >
>> > That'd be pretty sad if it were expected :P.
>> >
>> > Totally my bad on this one. I've committed a fix.
>> >
>> > On Thu, Mar 26, 2015 at 9:40 AM, Alexander Sorokin (Akvelon) <
>> > v-als...@microsoft.com> wrote:
>> >
>> > > Hi guys,
>> > >
>> > > I am getting the following error when trying to build a project with
>> > > legacy-whitelist plugin installed for android@4.0.0-dev:
>> > >
>> > >
>> >
>> C:\Projects\Cordova\mobspec-android\platforms\android\src\org\apache\cordova\whitelist\LegacyWhitelistPlugin.java:44:
>> > > error: cannot find symbol
>> > > public void handleStartTag(XmlPullParser xml) {
>> > >^
>> > >   symbol: class XmlPullParser
>> > >
>> >
>> C:\Projects\Cordova\mobspec-android\platforms\android\src\org\apache\cordova\whitelist\LegacyWhitelistPlugin.java:68:
>> > > error: cannot find symbol
>> > > public void handleEndTag(XmlPullParser xml) {
>> > >  ^
>> > >   symbol: class XmlPullParser
>> > >
>> > >
>> > > Is this expected?
>> > >
>> > > Thanks,
>> > > Alexander Sorokin
>> > >
>> > > -Original Message-
>> > > From: Steven Gill [mailto:stevengil...@gmail.com]
>> > > Sent: Wednesday, March 25, 2015 23:23
>> > > To: dev@cordova.apache.org
>> > > Subject: [VOTE] Cordova-Plugin-Whitelist and
>> > > Cordova-Plugin-Legacy-Whitelist Plugins Release
>> > >
>> > > Please review and vote on the releases of cordova-plugin-whitelist and
>> > > cordova-plugin-legacy-whitelist plugins.
>> > >
>> > > Release issue: https://issues.apache.org/jira/browse/CB-8739
>> > >
>> > > The plugins have been published to
>> > > dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-8739/
>> > >
>> > > The packages were published from their corresponding git tags:
>> > > cordova-plugin-whitelist: 1.0.0 (38f5a9fa2c)
>> > > cordova-plugin-legacy-whitelist: 1.0.0 (b4e1b3726a)
>> > >
>> > > Upon a successful vote I will upload the archives to dist/ and upload
>> > > them to npm.
>> > >
>> > > Voting guidelines:
>> > >
>> https://github.com/apache/cordova-coho/blob/master/docs/release-voting
>> > > .md
>> > >
>> > > Voting will go on for a minimum of 48 hours.
>> > >
>> > > I vote +1:
>> > > * Ran coho audit-license-headers over the relevant repos
>> > > * Ran coho check-license to ensure all dependencies and
>> > > subdependencies have Apache-compatible licenses
>> > >
>> > > -
>> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> > > For additional commands, e-mail: dev-h...@cordova.apache.org
>> > >
>> > >
>> >
>>
>

[Vote] 3.8.0 WP8 Release

[Steven Gill]

Please review and vote on this 3.8.0 WP8 Release.

Release issue: https://issues.apache.org/jira/browse/CB-8748

Repos ready to be released have been published to
dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-8748

The package was published from its corresponding git tag:
cordova-wp8: 3.8.0 (6e319c9828)

Upon a successful vote I will upload the archive to dist/ and publish it to NPM.

Voting guidelines:
https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md

Voting will go on for a minimum of 48 hours.

I vote +1:
* Ran coho audit-license-headers over the relevant repos
* Ran coho check-license to ensure all dependencies and
subdependencies have Apache-compatible licenses

[Vote] 3.7.0 FirefoxOS Release

[Steven Gill]

Please review and vote on this 3.7.0 FirefoxOS Release.

Release issue: https://issues.apache.org/jira/browse/CB-8732

Repos ready to be released have been published to
dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-8732

The package was published from its corresponding git tag:
cordova-firefoxos: 3.7.0 (0434f7d729)

Upon a successful vote I will upload the archive to dist/, and publish
it to NPM.

Voting guidelines:
https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md

Voting will go on for a minimum of 48 hours.

I vote +1:
* Ran coho audit-license-headers over the relevant repos
* Ran coho check-license to ensure all dependencies and
subdependencies have Apache-compatible licenses

Re: hook logging issue

[Shazron]

actually it has stdio:inherit, and does capture the output and pushes
it back up the chain, so somewhere up the chain no one does anything
with it

On Thu, Mar 26, 2015 at 3:36 PM, Shazron  wrote:
> https://github.com/apache/cordova-lib/blob/d77ebc40a16ab27a8ed22c0bbf2ab8a84a5ac448/cordova-lib/src/hooks/HooksRunner.js#L188
>
> It's using child_process.spawn (if you dig down) and is probably
> ignoring all stdio when running the script.
>
> On Thu, Mar 26, 2015 at 3:10 PM, Raymond Camden  
> wrote:
>> This may stray into the "it should be on the google group" territory,
>> if so, just let me know.
>>
>> I'm rewriting Holly's after_platform_add hook to use module.exports.
>> When I do, I notice console.log no longer works. Is that expected -
>> and if so - is there a workaround? (To be clear, the hook still works
>> perfectly well as far as I can see, I just don't see console output.)
>>
>> module.exports = function(context) {
>>
>> console.log("Testing "+context);
>> var pluginlist = [
>>"org.apache.cordova.device",
>>"org.apache.cordova.device-motion",
>>"org.apache.cordova.device-orientation",
>>"org.apache.cordova.geolocation"
>> ];
>>
>> // no need to configure below
>> var fs = require('fs');
>> var path = require('path');
>> var sys = require('sys')
>> var exec = require('child_process').exec;
>>
>> function puts(error, stdout, stderr) {
>> //console.log(stdout);
>> }
>>
>> pluginlist.forEach(function(plug) {
>> exec("cordova plugin add " + plug, puts);
>> });
>>
>>
>> }
>>
>> --
>> ===
>> Raymond Camden, Developer Advocate for MobileFirst at IBM
>>
>> Email : raymondcam...@gmail.com
>> Blog : www.raymondcamden.com
>> Twitter: raymondcamden
>>
>> -
>> 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

Re: hook logging issue

[Shazron]

https://github.com/apache/cordova-lib/blob/d77ebc40a16ab27a8ed22c0bbf2ab8a84a5ac448/cordova-lib/src/hooks/HooksRunner.js#L188

It's using child_process.spawn (if you dig down) and is probably
ignoring all stdio when running the script.

On Thu, Mar 26, 2015 at 3:10 PM, Raymond Camden  wrote:
> This may stray into the "it should be on the google group" territory,
> if so, just let me know.
>
> I'm rewriting Holly's after_platform_add hook to use module.exports.
> When I do, I notice console.log no longer works. Is that expected -
> and if so - is there a workaround? (To be clear, the hook still works
> perfectly well as far as I can see, I just don't see console output.)
>
> module.exports = function(context) {
>
> console.log("Testing "+context);
> var pluginlist = [
>"org.apache.cordova.device",
>"org.apache.cordova.device-motion",
>"org.apache.cordova.device-orientation",
>"org.apache.cordova.geolocation"
> ];
>
> // no need to configure below
> var fs = require('fs');
> var path = require('path');
> var sys = require('sys')
> var exec = require('child_process').exec;
>
> function puts(error, stdout, stderr) {
> //console.log(stdout);
> }
>
> pluginlist.forEach(function(plug) {
> exec("cordova plugin add " + plug, puts);
> });
>
>
> }
>
> --
> ===
> Raymond Camden, Developer Advocate for MobileFirst at IBM
>
> Email : raymondcam...@gmail.com
> Blog : www.raymondcamden.com
> Twitter: raymondcamden
>
> -
> 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

hook logging issue

[Raymond Camden]

This may stray into the "it should be on the google group" territory,
if so, just let me know.

I'm rewriting Holly's after_platform_add hook to use module.exports.
When I do, I notice console.log no longer works. Is that expected -
and if so - is there a workaround? (To be clear, the hook still works
perfectly well as far as I can see, I just don't see console output.)

module.exports = function(context) {

console.log("Testing "+context);
var pluginlist = [
   "org.apache.cordova.device",
   "org.apache.cordova.device-motion",
   "org.apache.cordova.device-orientation",
   "org.apache.cordova.geolocation"
];

// no need to configure below
var fs = require('fs');
var path = require('path');
var sys = require('sys')
var exec = require('child_process').exec;

function puts(error, stdout, stderr) {
//console.log(stdout);
}

pluginlist.forEach(function(plug) {
exec("cordova plugin add " + plug, puts);
});


}

-- 
===
Raymond Camden, Developer Advocate for MobileFirst at IBM

Email : raymondcam...@gmail.com
Blog : www.raymondcamden.com
Twitter: raymondcamden

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

[GitHub] cordova-medic pull request: CB-8734 add support for firefoxos

[marti1125]

Github user marti1125 commented on the pull request:

https://github.com/apache/cordova-medic/pull/39#issuecomment-86731533
  
I had to move mobilespec to inside of cordova-medic
λ node build_firefoxos.js
G:\cordova-medic\.git G:\cordova-medic
G:\cordova-medic
G:\cordova-medic\bin G:\cordova-medic
G:\cordova-medic
G:\cordova-medic\buildbot-conf G:\cordova-medic
G:\cordova-medic
G:\cordova-medic\mobilespec G:\cordova-medic
G:\cordova-medic
G:\cordova-medic\node_modules G:\cordova-medic
G:\cordova-medic
G:\cordova-medic\runner G:\cordova-medic
G:\cordova-medic
G:\cordova-medic\src G:\cordova-medic
G:\cordova-medic
[FIREFOXOS] Modifying Cordova firefoxos application. (sha: 
FirefoxOS__master__1427406728)


---
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-8484: Adds support creating signe...

[nikhilkh]

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

https://github.com/apache/cordova-android/pull/164#discussion_r27259466
  
--- Diff: bin/templates/cordova/lib/build.js ---
@@ -422,11 +477,15 @@ function parseOpts(options, resolvedTarget) {
 module.exports.runClean = function(options) {
 var opts = parseOpts(options);
 var builder = builders[opts.buildMethod];
-return builder.prepEnv()
+return builder.prepEnv(opts)
 .then(function() {
-return builder.clean(opts.extraArgs);
+return builder.clean(opts);
 }).then(function() {
 shell.rm('-rf', path.join(ROOT, 'out'));
+}).then(function() {
+['debug', 'release'].forEach(function(config) {
+removeIfExists(path.join(ROOT, config + SIGNING_PROPERTIES));
--- End diff --

Good point. To delete these files the user has to explicitly run the 
`clean` script  from platforms\android\cordova. This made me think about other 
scenarios as well for CLI workflow:
1. cordova build 
2. cordova build 
3. cordova build 

The third invocation will use the pacakgeInfo from the previous invocation 
as I do not delete debug-signing.properties & release-signing.properies.

I can make this a bit more sophisticated to account for non-CLI workflows - 
detect if the file is auto-generated (It has the canned comment ("Do not modify 
this file -- YOUR CHANGES WILL BE ERASED")). If it is then I go ahead and 
delete it not only on `clean` but also when starting a build with no package 
info specified.


---
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-medic pull request: CB-8734 add support for firefoxos

[marti1125]

Github user marti1125 commented on the pull request:

https://github.com/apache/cordova-medic/pull/39#issuecomment-86719561
  
Hi, in firefoxos I have this  //fs.writeFileSync(path.join(output, 
'assets', 'www','autotest','pages', 'medic.json'),medic_config,'utf-8'); this 
file doesn't exist 


---
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: Buildbot for Cordova on Apache Infra - Update

[Nikhil Khandelwal]

How does the community feel about fixing these test failures and running them 
automated in Apache Buildbot instance? 

Also, it looks like there is a PR to add support for Firefox OS to this.

Thanks,
Nikhil


-Original Message-
From: Nikhil Khandelwal [mailto:nikhi...@microsoft.com] 
Sent: Monday, March 23, 2015 6:10 PM
To: dev@cordova.apache.org
Subject: RE: Buildbot for Cordova on Apache Infra - Update

Hi,
Over the last couple of months, we have been reviving medic and ensuring it 
runs on Apache Buildbot Infra. For those who are not familiar with medic – it’s 
a BuildBot continuous integration setup that allows to test Cordova plugins and 
platforms. Today marks a big milestone in that work that we have the following 
platforms running and reporting results on a consistent basis: 
  - Android:
 - Windows (17 failures)
 - OSX (12 failures)
   - IOS (19 failures)
   - Windows (0 failures) 
   - WP8.1 (6 failures)
   - WP8

You can use this link to review the results:  
http://ci.apache.org/waterfall?builder=cordova-ios&builder=cordova-android-osx&builder=cordova-windows&builder=cordova-wp8&builder=cordova-android-win&builder=cordova-blackberry-osx&builder=cordova-blackberry-win
 

Currently, builds are triggered every two hours. We would like to integrate 
with Cordova nightly build to trigger a run. 

Steve Gill: Do you have an update on the nightly build for Cordova?

We need help with the following:
 - Fix all test failures for Android.
 - Fix all test failures for iOS. 
 - Add other platforms to this test matrix – FirefoxOS?

Results from test runs are currently being loaded to couchDB instance hosted on 
our servers. We have a longstanding infra ticket open to create a couchDB 
instance on Apache Infra. Please vote it up to help get resolved: 
https://issues.apache.org/jira/browse/INFRA-8588
  
Thanks,
Nikhil


-Original Message-
From: Dmitriy Barkalov (Akvelon) [mailto:v-dmb...@microsoft.com]
Sent: Friday, December 12, 2014 9:24 AM
To: dev@cordova.apache.org
Subject: RE: Buildbot for Cordova on Apache Infra - Update

Hi all,

I'd like to provide a status update on this task:
- External slaves could be wired to Apache infra. (I've successfully wired 
windows slave to Apache Infra in testing purposes)
- Need to resolve some build bot configuration issues
- After configuration is ready we will add Github hooks to run the builds.


Regards, Dmitriy

-Original Message-
From: m...@google.com [mailto:m...@google.com] On Behalf Of Max Woghiren
Sent: Monday, December 8, 2014 9:00 PM
To: dev
Subject: Re: Buildbot for Cordova on Apache Infra - Update

Yes, once the master is ready, I can take on having our slaves report to it.

On Mon, Dec 8, 2014 at 10:41 AM, Michal Mocny  wrote:

> We've already got a lab and slaves but its been in a rather sorry 
> state of disrepair (http://ci.cordova.io/).  Would gladly put in the 
> effort to clean up and report to the new master.
>
> On Fri, Dec 5, 2014 at 8:48 PM, Parashuram Narasimhan (MS OPEN TECH) < 
> panar...@microsoft.com> wrote:
>
> > Awesome - Thanks Marcel. Once the master is ready, we will start 
> > setting up the slaves.
> >
> > -Original Message-
> > From: Marcel Kinard [mailto:cmarc...@gmail.com]
> > Sent: Friday, December 5, 2014 1:42 PM
> > To: dev@cordova.apache.org
> > Subject: Re: Buildbot for Cordova on Apache Infra - Update
> >
> > The IBM team here would be willing to set up a slave with some of 
> > our devices. We have a collection of Android, iOS, BB10, WP8.
> > Looking forward to instructions on slave setup ;-)
> >
> > On Dec 5, 2014, at 12:20 PM, Parashuram Narasimhan (MS OPEN TECH) < 
> > panar...@microsoft.com> wrote:
> >
> > > It would be great if we could have other platforms also run using
> Apache
> > Infra. Blackberry, Tizen, FirefoxOS, Amazon - any takers for this? 
> > We
> would
> > be happy to help.
> > >
> > > -Original Message-
> > > From: Steven Gill [mailto:stevengil...@gmail.com]
> > > Sent: Wednesday, December 3, 2014 12:23 PM
> > > To: dev@cordova.apache.org
> > > Subject: Re: Buildbot for Cordova on Apache Infra - Update
> > >
> > > This is amazing news!
> > >
> > > Adobe will definitely setup some slaves and try to get our device 
> > > wall
> > going again.
> > >
> > > It would be great if other companies jumped on board with a few 
> > > slaves
> > for their devices to get some love from medic.
> > >
> > > Setting up a slave instructions would also be very helpful! :)
> > >
> >
> >
> > 
> > - 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
> >
> >
>

-

Re: Simulating Cordova plugins and device capabilities

[Michal Mocny]

Julian,

I think with the current plan you can proceed to emulate with Ripple
exactly as you explain, right?  Is there a change you would like to see be
made that would make this easier?

For me, device emulation inside the browser is preferable, and actually
no-emulation-just-polyfills is usually even sufficient (I just use desktop
Safari/Chrome as a proxy for mobile equivalents).  If I want to truly
emulate a device I grab it off the shelf.

I understand the above workflow is not universal to everyone, its just my
preference.. and I like that the current proposal gives us both the option
we prefer, yet we can share as much common infrastructure as makes sense at
the plugin-browser-implementation level.

-Michal

On Thu, Mar 26, 2015 at 4:04 PM, Horn, Julian C 
wrote:

> I'll try to follow up on Tim's remark as eloquently as I can ;)
>
> There are clearly advantages to building device simulation into the
> browser, but this strategy does impose limitations.  A company like
> Microsoft or Google has complete control over the browser and the debug
> tools, but this freedom does not exist for other vendors making their own
> emulator.  This creates the feeling of a closed system.
>
> Intel has a rich history of creating software development tools for new
> hardware as it being designed.  We prize the ability to quickly support new
> devices of our choosing, so an open architecture is better for our needs.
>
> Beyond that I see some shortcomings in the way the emulation features in
> Chrome and Internet Explorer work today.  The attributes of a device, once
> selected, cannot be modified by the program under test (or even by the
> non-browser parts of the emulator).  This makes it impossible to simulate
> any actions that change the size of the viewport.  For example, the
> show/hide status bar APIs cannot be simulated under these conditions, nor
> can other popular plugins such as AdMob that reduce the size of the
> viewport to allow room for advertisements. The device sizes provided in
> Chrome and Internet Explorer all assume a “full screen” configuration, that
> is, no status bar.  This is a reasonable choice if you are simulating a
> mobile browser.  However, most packaged apps run with a status bar.  This
> means the device sizes provided by browsers are in fact uniformly incorrect
> for most packaged apps.
>
> In our experience, the photorealistic device skins are surprisingly
> effective in getting across the feeling of what an app would look like
> running on a real device.  We heard from one customer who develops apps for
> a living.  For less technical customers a prototype of an app he would
> build running in the XDK Device Emulator to show what the app would feel
> like.  We lose this capability if we entrust the device emulation problem
> to the browser.
>
>Julian
>
> -Original Message-
> From: Tim Barham [mailto:tim.bar...@microsoft.com]
> Sent: Wednesday, March 25, 2015 1:50 AM
> To: dev@cordova.apache.org
> Subject: RE: Simulating Cordova plugins and device capabilities
>
> Thanks Michal and Jesse!
>
> Jesse, in response to your additional questions...
>
> > What value does Ripple  if the basic functionality becomes part of a
> > generic simulation interface?
> >
> > Ripple currently will simulate screen sizes based on device choice.
> > Chrome dev tools support picking different device viewports also.
> > Where should something like this live?
>
> Julian Horn (Intel) would be a good person to answer that question... He
> can speak more eloquently than me to why Ripple is (and will continue to
> be, after this proposal is implemented) the ideal platform for them. And I
> think there is definitely room for both approaches:
>
> * Some basic simulation host provided by Cordova, which wouldn't provide
> any of the "device choosing" capabilities and other functionality we get
> with Ripple, but would work well with browser dev tools (and rely on them
> to provide that functionality).
> * A richer environment like Ripple, which is also works well embedded in
> tools like the XDK.
>
> Another interesting point is that Chrome device mode means you have the
> Chrome debugger open, which means you can't use an external debugger. If
> your workflow is entirely Chrome, then that works very well. If we're
> talking about using Chrome with external debuggers (like Intel XDK or
> Visual Studio), then device mode becomes problematic and something like
> Ripple works well.
>
> > Is this feature valuable enough to warrant this lengthy discussion?
>
> It's certainly valuable to certain groups :). But for me I think it's more
> a case that it will involve a significant amount of effort and I want to
> get sign off from the community now rather than spending a bunch of time
> going down a path that might get rejected down the line.
>
> Thanks again!
>
> Tim
>
> -Original Message-
> From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal
> Mocny
> Sent: Wednesday, March 25, 2015

Re: Cordova Monthly Hangouts

[Carlos Santana]

Thanks Parashuram for setting up the doodle

On Thu, Mar 26, 2015 at 2:40 PM, Josh Soref  wrote:

> As a headsup, the beginning of April is Passover. I'm on vacation for it.
> I'm not sure how many others might be affected.
>
> There's often an Easter holiday floating around and or a spring break.
>
> 
> From: Parashuram N (MS OPEN TECH) [panar...@microsoft.com]
> Sent: Thursday, March 26, 2015 1:27 PM
> To: dev@cordova.apache.org
> Subject: RE: Cordova Monthly Hangouts
>
> Carlos, you did not miss it, still working on scheduling it :)
>
> Here is the doddle - please respond to this and indicate your
> availability. Since the hangouts usually go to 2 hours, and to keep the
> number of options sane in doddle, I put up 2 hour slots. Let me know if we
> should make it 1 hour slots.
>
> Here is the participation link - http://doodle.com/kydhnyzzwge92hsu
>
> -Original Message-
> From: Carlos Santana [mailto:csantan...@gmail.com]
> Sent: Thursday, March 26, 2015 9:58 AM
> To: dev@cordova.apache.org
> Subject: Re: Cordova Monthly Hangouts
>
> +1 did I missed the hangout? I would like to attend.
>
> Micha I like the new term "npm-ness" :-)
>
> Yes Android 4.0 is important for us, we are about to start new work and
> want to start with a released one.
>
>
> On Tue, Mar 24, 2015 at 7:01 PM, tommy-carlos williams  >
> wrote:
>
> > +1 for package.json discussions
> >
> > --
> > tommy-carlos williams
> >
> > On 25 March 2015 at 09:18:12, Michal Mocny (mmo...@chromium.org) wrote:
> >
> > Another topic is discussion of "package.json" based cli workflow, aka
> > leveraging more npm-ness in our tools.
> >
> > -Michal
> >
> > On Tue, Mar 24, 2015 at 1:59 PM, Andrew Grieve 
> > wrote:
> >
> > > +1!
> > >
> > > On Tue, Mar 24, 2015 at 1:23 PM, Jesse 
> wrote:
> > >
> > > > +1 asap, thanks Parash!
> > > >
> > > > We are much more coherent when we meet.
> > > >
> > > >
> > > >
> > > > > On Mar 24, 2015, at 10:02 AM, Parashuram N (MS OPEN TECH) <
> > > > panar...@microsoft.com> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > I was wondering if folks would be interested in doing a hangout
> > > > > to
> > > > quickly resolve some of the outstanding issues that we have been
> > talking
> > > on
> > > > the mailing list. I think we could talk about the following
> > > > >
> > > > >
> > > > > * Androind 4.0 release
> > > > > * Medic/ParaMedic/Mobile Spec - progress and next steps
> > > > > * Finalize Save/Restore discussions
> > > > > * ApacheCon ?
> > > > >
> > > > > I can volunteer to help set this up if we think there are items
> > > > > that
> > we
> > > > would like to discuss and close on.
> > > >
> > > > --
> > > > --- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > > >
> > > >
> > >
> >
>
>
>
> --
> Carlos Santana
> 
>
> ?B�CB�?�?[��X��ܚX�K??K[XZ[?�??]�][��X��ܚX�P?�ܙ?ݘK�\?X�?K�ܙ�B��܈?Y??]?[ۘ[??��[X[�?�??K[XZ[?�??]�Z?[???�ܙ?ݘK�\?X�?K�ܙ�B
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>



-- 
Carlos Santana

RE: Setting config.json values

[Josh Soref]

You can for some things, via [options].

The json is a catchall, e.g. for things we shouldn't be supporting long term.

If you have a specific set of features you're using that you'd like supported, 
that's a possible conversation.
Also, do your things really need to be done at create, or could they be done 
later?

Note that --copy-from lets you set up a template, which probably covers most 
cases anyway

> -Original Message-
> From: John M. Wargo [mailto:jwarg...@gmail.com]
> Sent: Thursday, March 26, 2015 3:35 PM
> To: dev@cordova.apache.org
> Subject: Re: Setting config.json values
>
> Any chance we can start a conversation about simplifying this too? Passing
> escaped JSON on the command line is, sorry, not a clean way to do this. As
> more config options are added, this becomes less manageable.
>
> On 3/26/2015 2:42 PM, Shazron wrote:
> > Whoever ends up fixing this, please add a test for the functionality
> >
> > On Thu, Mar 26, 2015 at 11:35 AM, Josh Soref 
> wrote:
> >> It's possible i broke it:
> >>
> >> https://github.com/apache/cordova-
> cli/commit/106d8801a70a9b97cd606e27f80c6c7988f368cc#diff-
> ef7004c4000a2616f36c594dc5db207a
> >>
> >> try something from before this?
> >>
> >> i'd suggest a bisect
> >>
> >> specifically, find the last version where the command worked;
> >> then try only upgrading lib, to the version+1 and see if it worked, if 
> >> so, it's
> probably in cli.
> >>
> >> i'd be really embarrassed if it's my fault.
> >>
> >> i've been under the weather this week, so i'm catching up on 
> >> mail/offering
> spot advice and giving up.
> >>
> >> 
> >> From: Shazron [shaz...@gmail.com]
> >> Sent: Thursday, March 26, 2015 1:19 PM
> >> To: dev@cordova.apache.org
> >> Subject: Re: Setting config.json values
> >>
> >> The help still says CONFIG is an option:
> >> cordova create  [ID [NAME [CONFIG]]] [options] [PLATFORM...]
> >>
> >> and config handling seems to still be there..
> >> https://github.com/apache/cordova-
> lib/blob/cc596a37d77a92665292a5370d660a898217e0cb/cordova-
> lib/src/cordova/create.js#L41
> >>
> >> .. so I think it's a bug. Two things here:
> >> 1. this bug
> >> 2. PLATFORM is not defined in the create help (I know it should be
> >> obvious, but...)
> >>
> >>
> >>
> >>
> >>
> >> On Thu, Mar 26, 2015 at 6:57 AM, John M. Wargo 
> wrote:
> >>> Earlier this month, there was a conversation on this thread about 
> >>> enabling
> >>> auto saving of plugin information to the project's config.json file
> >>> (.cordova/config.json, right?) by setting auto_save_plugins to true in 
> >>> the
> >>> file.
> >>>
> >>> I responded on that thread suggesting that users would be able to set 
> >>> this
> >>> value by passing the configuration value on the command line to the
> cordova
> >>> create command like so:
> >>>
> >>>  cordova create test com.johnwargo.test Test
> >>> {\"auto_save_plugins\":\"true\"}
> >>>
> >>> Shouldn't this be a viable way to enable users to automagically set this
> >>> value?
> >>>
> >>> The problem is that this CLI feature no longer seems to work. Last fall, 
> >>> I
> >>> was able to set the plugin search path using the following:
> >>>
> >>>  cordova create test2 com.johnwargo.test2 Test2
> >>> "{\"plugin_search_path\":\"d:/dev\"}"
> >>>
> >>> But I just tested it (for a second time on a different system) and that
> >>> capability, passing config.json values on the command line to create, no
> >>> longer seems to be working. Did I miss something? Was this feature
> removed?
> >>> Or should I submit a ticket on this issue?
> >>>
> >>> Currently the SAP Mobile Platform Hybrid SDK ships as a local installer,
> the
> >>> plugins aren't in the plugin registry or even github. The plugins have 
> >>> local
> >>> dependencies (the AppUpdate plugin relies upon capabilities exposed by
> the
> >>> Logon plugin) and the Cordova CLI isn't able to resolve them locally
> without
> >>> the plugin_search_path being set. We've instructed users to use this
> >>> feature, but now it seems it's not working. Can someone confirm?
> >>>
> >>> Since plugin_search_path is valuable for SAP customers and
> auto_save_plugins
> >>> is important for this new save/restore capability, is it time to design 
> >>> a
> >>> simpler approach to allow developers to easily set these properties as
> >>> needed for their projects?  It seems that having a create command
> parameter
> >>> that points to a configuration file containing default settings for the
> >>> project would be a useful thing to have.
> >>>
> >>> What says the group?
> >>> --
> >>> John M. Wargo
> >>> @johnwargo 
> >>> www.johnwargo.com 
> >>> ---
> -
> --

RE: Simulating Cordova plugins and device capabilities

[Horn, Julian C]

I'll try to follow up on Tim's remark as eloquently as I can ;)

There are clearly advantages to building device simulation into the browser, 
but this strategy does impose limitations.  A company like Microsoft or Google 
has complete control over the browser and the debug tools, but this freedom 
does not exist for other vendors making their own emulator.  This creates the 
feeling of a closed system.

Intel has a rich history of creating software development tools for new 
hardware as it being designed.  We prize the ability to quickly support new 
devices of our choosing, so an open architecture is better for our needs.

Beyond that I see some shortcomings in the way the emulation features in Chrome 
and Internet Explorer work today.  The attributes of a device, once selected, 
cannot be modified by the program under test (or even by the non-browser parts 
of the emulator).  This makes it impossible to simulate any actions that change 
the size of the viewport.  For example, the show/hide status bar APIs cannot be 
simulated under these conditions, nor can other popular plugins such as AdMob 
that reduce the size of the viewport to allow room for advertisements. The 
device sizes provided in Chrome and Internet Explorer all assume a “full 
screen” configuration, that is, no status bar.  This is a reasonable choice if 
you are simulating a mobile browser.  However, most packaged apps run with a 
status bar.  This means the device sizes provided by browsers are in fact 
uniformly incorrect for most packaged apps.

In our experience, the photorealistic device skins are surprisingly effective 
in getting across the feeling of what an app would look like running on a real 
device.  We heard from one customer who develops apps for a living.  For less 
technical customers a prototype of an app he would build running in the XDK 
Device Emulator to show what the app would feel like.  We lose this capability 
if we entrust the device emulation problem to the browser.

   Julian

-Original Message-
From: Tim Barham [mailto:tim.bar...@microsoft.com] 
Sent: Wednesday, March 25, 2015 1:50 AM
To: dev@cordova.apache.org
Subject: RE: Simulating Cordova plugins and device capabilities

Thanks Michal and Jesse!

Jesse, in response to your additional questions...

> What value does Ripple  if the basic functionality becomes part of a 
> generic simulation interface?
>
> Ripple currently will simulate screen sizes based on device choice. 
> Chrome dev tools support picking different device viewports also.  
> Where should something like this live?

Julian Horn (Intel) would be a good person to answer that question... He can 
speak more eloquently than me to why Ripple is (and will continue to be, after 
this proposal is implemented) the ideal platform for them. And I think there is 
definitely room for both approaches:

* Some basic simulation host provided by Cordova, which wouldn't provide any of 
the "device choosing" capabilities and other functionality we get with Ripple, 
but would work well with browser dev tools (and rely on them to provide that 
functionality).
* A richer environment like Ripple, which is also works well embedded in tools 
like the XDK.

Another interesting point is that Chrome device mode means you have the Chrome 
debugger open, which means you can't use an external debugger. If your workflow 
is entirely Chrome, then that works very well. If we're talking about using 
Chrome with external debuggers (like Intel XDK or Visual Studio), then device 
mode becomes problematic and something like Ripple works well.

> Is this feature valuable enough to warrant this lengthy discussion?

It's certainly valuable to certain groups :). But for me I think it's more a 
case that it will involve a significant amount of effort and I want to get sign 
off from the community now rather than spending a bunch of time going down a 
path that might get rejected down the line.

Thanks again!

Tim

-Original Message-
From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny
Sent: Wednesday, March 25, 2015 8:32 AM
To: dev
Subject: Re: Simulating Cordova plugins and device capabilities

This is exceptionally cool (and thanks for doing a video demonstration, great 
way to get the point across)!

I also agree with all your points, and really support this approach.
Specifically:

+1 browser platform will be used for both prod and debugging, so cannot
have always-on emulation.
+1 to have emulation hooks inside cordova browser platform and cordova
plugins' browser versions, but have them no-op by default.
+1 to support any downstream emulation embedders, and perhaps have a 
+very
lightweight cordova project (though perhaps not necessary beyond a simple 
testing app).
+1 to suggest Ripple become an embedder.

I'll also note that Microsoft is one of the primary supporters of Ripple 
recently, so if they think this is a good direction, that is a strong signal to 
me.  Intel is a second strong s

RE: Cordova WP8: switching to Newtonsoft.Json

[Vladimir Kotikov (Akvelon)]

This PR already supports this scenario due to headers object transformation 
logic in JS code: 
https://github.com/apache/cordova-plugin-file-transfer/pull/72/files#diff-0e07bcbc62b6a78cefd53949110bac46R73.
 If header value is represented by array it will be transformed to comma 
separated list, which conforms to RFC: 
http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2 

Probably I would need to note this in comments to PR.

---
Best regards, Vladimir

-Original Message-
From: Nikhil Khandelwal [mailto:nikhi...@microsoft.com] 
Sent: Thursday, March 26, 2015 9:59 PM
To: dev@cordova.apache.org
Subject: RE: Cordova WP8: switching to Newtonsoft.Json

Interesting - good point. I'm curious what's the scenario for specifying 
request header values as an array? 

Do they result in a comma-separated list of strings. 
https://github.com/apache/cordova-plugin-file-transfer/pull/72 can be 
potentially enhanced to support this particular scenario.

There is no doubt Newtonsoft is more robust way to do this, but it's got 
diminishing returns for the work if we have tackled the primary use cases.

Thanks,
Nikhil


-Original Message-
From: Jesse [mailto:purplecabb...@gmail.com]
Sent: Thursday, March 26, 2015 10:37 AM
To: dev@cordova.apache.org
Subject: Re: Cordova WP8: switching to Newtonsoft.Json

Nikhil, that pull request does not resolve this. Using 
DataContractJsonSerializer will fail for nested objects.
There is no guarantee that jsonHeaders is just a dictionary of string,string.
In fact, I'm pretty sure this test will fail :
https://github.com/apache/cordova-plugin-file-transfer/blob/master/tests/tests.js#L856





@purplecabbage
risingj.com

On Thu, Mar 26, 2015 at 10:26 AM, Nikhil Khandelwal 
wrote:

> The main use case for Newtonsoft.Json has been resolved through 
> another implementation approach in this PR:
> https://github.com/apache/cordova-plugin-file-transfer/pull/72
>   
> -Nikhil
>
> -Original Message-
> From: Carlos Santana [mailto:csantan...@gmail.com]
> Sent: Thursday, March 26, 2015 9:47 AM
> To: dev@cordova.apache.org
> Subject: Re: Cordova WP8: switching to Newtonsoft.Json
>
> Jesse dumb question, what else is new 8-]
>
> Can we do that Mark pointed out to add a reference to a location where 
> the windows project can get the dependency?
> Like adding a nuget dependency entry, and then when app get's compile, 
> visual studio takes care of downloading Newtonsoft.Json from nuget 
> repository?
>
>
> On Tue, Mar 24, 2015 at 1:38 PM, Jesse  wrote:
>
> > I am looking into this. We need to include source code, as we cannot 
> > distribute a dll.
> > The pull-req is definitely dead except for the fact it contain part 
> > of this conversation.
> >
> >
> >
> >
> > > On Mar 24, 2015, at 6:37 AM, Ian Clelland 
> > wrote:
> > >
> > > I'm not sure about whether Cordova has any specific policies -- 
> > > there's
> > no
> > > hard rule that says we can't use third-party code, and even 
> > > include it in our distributions (see Cordova-Android and okhttp, 
> > > for instance), but we should probably discuss it on-list first.
> > >
> > > There are definitely rules, policies, and guidelines at the Apache 
> > > level
> > --
> > > no distribution of binaries, for instance, and there are probably
> > questions
> > > of license interaction as well between Apache and MIT licenses, if 
> > > we're combining the code at all.
> > >
> > >
> > >
> > > On Tue, Mar 24, 2015 at 5:04 AM, Sergey Grebnov (Akvelon) < 
> > > v-seg...@microsoft.com> wrote:
> > >
> > >> This[1] PR is being opened for a while so let's make a final 
> > >> decision if we switch to Newtonsoft.Json  or reject it.
> > >>
> > >> The idea of adding Newtonsoft.Json (MIT license) [1] looks good 
> > >> to me
> > and
> > >> I can quickly add necessary improvements to make sure everything 
> > >> looks
> > good
> > >> and works - as per mobile spec tests there are no new issues found.
> > >>
> > >> But I'm not sure about our policies regarding adding new third 
> > >> party dependencies. Should it be discussed/voted here before merge?
> > >> Does it documented somewhere?
> > >>
> > >> PS. If we go w/ Newtonsoft.Json   I propose to just add reference to
> > >> compiled dll and not to keep source code due to size(200kb vs
> > >> 19mb) and compile time reasons.
> > >
> > > Distributing the .dll without the source will *definitely* be a
> problem.
> > > Distributing the .dll with the source *might* be a problem. The 
> > > only way we've been able to do this in the past (see Gradle and 
> > > Crosswalk for two recent examples) is to have a script that the 
> > > user runs (even as part of the platform scripts) that downloads 
> > > the library from somewhere trusted
> > and
> > > installs it. We can't ship binaries as part of an Apache project.
> > >
> > >
> > >>
> > >> [1] https://github.com/apache/cordova-wp8/pull/62
> > >>
> > >> Thx!
> > >> Sergey
> > >>
> > >>
> > >> 

Re: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist Plugins Release

[Steven Gill]

I'll send out a new one soon
On Mar 26, 2015 10:48 AM, "Ian Clelland"  wrote:

> Yeah :(
>
> Hash changes, code changes, checksums and pgp signatures change... all
> necessitates a new vote.
> At least we get to abort early.
>
> On Thu, Mar 26, 2015 at 1:28 PM, Parashuram N (MS OPEN TECH) <
> panar...@microsoft.com> wrote:
>
> > Should we have to restart the vote thread, now that the tag will change ?
> >
> > -Original Message-
> > From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew
> > Grieve
> > Sent: Thursday, March 26, 2015 7:41 AM
> > To: dev
> > Subject: Re: [VOTE] Cordova-Plugin-Whitelist and
> > Cordova-Plugin-Legacy-Whitelist Plugins Release
> >
> > That'd be pretty sad if it were expected :P.
> >
> > Totally my bad on this one. I've committed a fix.
> >
> > On Thu, Mar 26, 2015 at 9:40 AM, Alexander Sorokin (Akvelon) <
> > v-als...@microsoft.com> wrote:
> >
> > > Hi guys,
> > >
> > > I am getting the following error when trying to build a project with
> > > legacy-whitelist plugin installed for android@4.0.0-dev:
> > >
> > >
> >
> C:\Projects\Cordova\mobspec-android\platforms\android\src\org\apache\cordova\whitelist\LegacyWhitelistPlugin.java:44:
> > > error: cannot find symbol
> > > public void handleStartTag(XmlPullParser xml) {
> > >^
> > >   symbol: class XmlPullParser
> > >
> >
> C:\Projects\Cordova\mobspec-android\platforms\android\src\org\apache\cordova\whitelist\LegacyWhitelistPlugin.java:68:
> > > error: cannot find symbol
> > > public void handleEndTag(XmlPullParser xml) {
> > >  ^
> > >   symbol: class XmlPullParser
> > >
> > >
> > > Is this expected?
> > >
> > > Thanks,
> > > Alexander Sorokin
> > >
> > > -Original Message-
> > > From: Steven Gill [mailto:stevengil...@gmail.com]
> > > Sent: Wednesday, March 25, 2015 23:23
> > > To: dev@cordova.apache.org
> > > Subject: [VOTE] Cordova-Plugin-Whitelist and
> > > Cordova-Plugin-Legacy-Whitelist Plugins Release
> > >
> > > Please review and vote on the releases of cordova-plugin-whitelist and
> > > cordova-plugin-legacy-whitelist plugins.
> > >
> > > Release issue: https://issues.apache.org/jira/browse/CB-8739
> > >
> > > The plugins have been published to
> > > dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-8739/
> > >
> > > The packages were published from their corresponding git tags:
> > > cordova-plugin-whitelist: 1.0.0 (38f5a9fa2c)
> > > cordova-plugin-legacy-whitelist: 1.0.0 (b4e1b3726a)
> > >
> > > Upon a successful vote I will upload the archives to dist/ and upload
> > > them to npm.
> > >
> > > Voting guidelines:
> > > https://github.com/apache/cordova-coho/blob/master/docs/release-voting
> > > .md
> > >
> > > Voting will go on for a minimum of 48 hours.
> > >
> > > I vote +1:
> > > * Ran coho audit-license-headers over the relevant repos
> > > * Ran coho check-license to ensure all dependencies and
> > > subdependencies have Apache-compatible licenses
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > >
> > >
> >
>

Re: Setting config.json values

[John M. Wargo]

Any chance we can start a conversation about simplifying this too? Passing 
escaped JSON on the command line is, sorry, not a clean way to do this. As more 
config options are added, this becomes less manageable.

On 3/26/2015 2:42 PM, Shazron wrote:

Whoever ends up fixing this, please add a test for the functionality

On Thu, Mar 26, 2015 at 11:35 AM, Josh Soref  wrote:

It's possible i broke it:

https://github.com/apache/cordova-cli/commit/106d8801a70a9b97cd606e27f80c6c7988f368cc#diff-ef7004c4000a2616f36c594dc5db207a

try something from before this?

i'd suggest a bisect

specifically, find the last version where the command worked;
then try only upgrading lib, to the version+1 and see if it worked, if so, it's 
probably in cli.

i'd be really embarrassed if it's my fault.

i've been under the weather this week, so i'm catching up on mail/offering spot 
advice and giving up.


From: Shazron [shaz...@gmail.com]
Sent: Thursday, March 26, 2015 1:19 PM
To: dev@cordova.apache.org
Subject: Re: Setting config.json values

The help still says CONFIG is an option:
cordova create  [ID [NAME [CONFIG]]] [options] [PLATFORM...]

and config handling seems to still be there..
https://github.com/apache/cordova-lib/blob/cc596a37d77a92665292a5370d660a898217e0cb/cordova-lib/src/cordova/create.js#L41

.. so I think it's a bug. Two things here:
1. this bug
2. PLATFORM is not defined in the create help (I know it should be
obvious, but...)





On Thu, Mar 26, 2015 at 6:57 AM, John M. Wargo  wrote:

Earlier this month, there was a conversation on this thread about enabling
auto saving of plugin information to the project's config.json file
(.cordova/config.json, right?) by setting auto_save_plugins to true in the
file.

I responded on that thread suggesting that users would be able to set this
value by passing the configuration value on the command line to the cordova
create command like so:

 cordova create test com.johnwargo.test Test
{\"auto_save_plugins\":\"true\"}

Shouldn't this be a viable way to enable users to automagically set this
value?

The problem is that this CLI feature no longer seems to work. Last fall, I
was able to set the plugin search path using the following:

 cordova create test2 com.johnwargo.test2 Test2
"{\"plugin_search_path\":\"d:/dev\"}"

But I just tested it (for a second time on a different system) and that
capability, passing config.json values on the command line to create, no
longer seems to be working. Did I miss something? Was this feature removed?
Or should I submit a ticket on this issue?

Currently the SAP Mobile Platform Hybrid SDK ships as a local installer, the
plugins aren't in the plugin registry or even github. The plugins have local
dependencies (the AppUpdate plugin relies upon capabilities exposed by the
Logon plugin) and the Cordova CLI isn't able to resolve them locally without
the plugin_search_path being set. We've instructed users to use this
feature, but now it seems it's not working. Can someone confirm?

Since plugin_search_path is valuable for SAP customers and auto_save_plugins
is important for this new save/restore capability, is it time to design a
simpler approach to allow developers to easily set these properties as
needed for their projects?  It seems that having a create command parameter
that points to a configuration file containing default settings for the
project would be a useful thing to have.

What says the group?
--
John M. Wargo
@johnwargo 
www.johnwargo.com 
--

-
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

Re: Plugins to NPM (Phase 1)

[Victor Sosa]

With regarding this Plugins to NPM topic...

This is a change that will impact to IDEs who rely on
http://registry.plugins.io to show available plugins to users. Even though
there will be a window for this change, CPR will have a 6-months window (at
least this is my understanding) to let plugin developers to migrate their
plugins to NPM and also let users to use in the old way (I mean the current
plugin IDs), there will be the point that this will be unsupported by
Cordova, hence support in IDEs will break.

I've been doing a little research and collecting some information and here
the summary of my findings:
1. The plugins will be hosted in http://registry.npmjs.org/
2. All NPM documents can be listed by querying the server with the
following URL: http://registry.npmjs.org/-/all
3. If you are interested on the Cordova plugins only (as will be the case),
use the keyword "ecosystem:cordova" to filter out the contents in this
list. Here is an error prone point, if the plugin doesn't have this keyword
it will never be found making hard to developers to know it in fact exists
(this is one of the major plus sides on CPR imho).
4. The only way to get such filtered list is to fetching all documents in
NPMJS registry and then do the filter locally using the keyword
"ecosystem:cordova", i.e. there is no way to get a filtered list directly
from the registry (I looked at NPM code and this is what they do. See in
NPM module, /node_modules/npm/lib/search.js file,
around line 60 "getFilteredData" function).

With those steps, I'm able to retrieve the list of plugins that follow the
"ecosystem:cordova" contract that was proposed before in a headless way,
i.e. no web browser, just a small script.

If any of you have suggestions on how better do this Cordova plugins
discovery on NPMJS, please let me know.


2015-03-25 15:36 GMT-06:00 Horn, Julian C :

> I'd like to add some more questions to what Leo asked.
>
> Can anyone explain how the hundreds of plugins that are published in git
> repos are supposed to transition to CLI 5 (and beyond)?  It seems like the
> answer is that they don't change anything.  What if they want to (or
> already do) publish via the registry?  It seems like you can win if you
> keep the id unchanged and add yourself to the mapping table.  But if that's
> true, then why are we renaming the core plugins?
>
> I don't think repo-resident plugins need to update any  tags
> that refer to core plugins.  That is, you can continue to ask for
> "org.apache.cordova.file".  If you use CLI 5, then the rename logic will
> get you the corresponding plugin from npm.  Or is there some reason why you
> will eventually have to change your  tags to use the new
> names.  Of course you better not change a  tag in your
> repo-resident plugin before October 1, because that will break projects
> that use your plugin but aren't yet using CLI 5.
>
> I haven't been able to come up with any strategy for changing the id of a
> repo-resident plugin without great pain.  It's basically equivalent to
> discontinuing your plugin and creating a new one in its place.  So it seems
> to me that if I have any users I would probably want to stick with my
> existing id and repo URL, even if it meant that I couldn't publish my
> plugin in npm format.  Is that a viable strategy, or is there a long term
> plan that EVERY plugin must eventually publish via npm?
>
> One final question.  Suppose I have a CLI 4.x project and I want to
> transition to CLI 5.  Do I have to start over at "cordova create project"?
>
> Julian
>
> -Original Message-
> From: Treggiari, Leo [mailto:leo.treggi...@intel.com]
> Sent: Wednesday, March 25, 2015 3:53 PM
> To: dev@cordova.apache.org
> Subject: RE: Plugins to NPM (Phase 1)
>
> Thanks for the information Steve.  That helps with our planning.  I have a
> couple of follow-ups.
>
> > We don't necessarily have to do a major bump for the CLI. We could
> > easily save the major jump until we switch npm fetching as default
> > (approx July 1)
>
> Re: the major bump.  This seems like a "delayed" breaking change.  That
> is, when CPR is removed, all prior CLI releases will be "crippled" to a
> significant degree since no  reference will be able to be
> resolved.
>
> Re: ~July 1:  Would you verify my understanding?  For a 
> reference which is not in the mapping table, from ~Apr to ~July 1, CPR will
> be tried first and if that fails then npm.  From ~July 1 to ~Oct 1, npm
> will be tried first and if that fails then the CPR.  After ~Oct 1, only npm.
>
> Thanks,
> Leo
>
> -Original Message-
> From: Steven Gill [mailto:stevengil...@gmail.com]
> Sent: Wednesday, March 25, 2015 11:13 AM
> To: dev@cordova.apache.org
> Subject: Re: Plugins to NPM (Phase 1)
>
> Thanks for answering tony. More comments below.
>
> On Tue, Mar 24, 2015 at 12:45 PM, Homer, Tony 
> wrote:
>
> > I¹ll try to answer some of Leo¹s questions, but it would be great if
> > someone else (Steve?) could comment.
> >
> > First, though, I¹ll a

[GitHub] cordova-plugin-file-transfer pull request: CB-8721 Fixes incorrect...

[vladimir-kotikov]

Github user vladimir-kotikov commented on the pull request:


https://github.com/apache/cordova-plugin-file-transfer/pull/72#issuecomment-86671373
  
Yep, they're allowed if you have corresponding data contract.


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

iOS 8.3 beta 4

[Edna Y Morales]

Very minor changes according to the release notes and API diffs but ran
through mobilespec anyway and everything looks good.

Thanks,
Edna Morales

RE: Cordova WP8: switching to Newtonsoft.Json

[Nikhil Khandelwal]

Interesting - good point. I'm curious what's the scenario for specifying 
request header values as an array? 

Do they result in a comma-separated list of strings. 
https://github.com/apache/cordova-plugin-file-transfer/pull/72 can be 
potentially enhanced to support this particular scenario.

There is no doubt Newtonsoft is more robust way to do this, but it's got 
diminishing returns for the work if we have tackled the primary use cases.

Thanks,
Nikhil


-Original Message-
From: Jesse [mailto:purplecabb...@gmail.com] 
Sent: Thursday, March 26, 2015 10:37 AM
To: dev@cordova.apache.org
Subject: Re: Cordova WP8: switching to Newtonsoft.Json

Nikhil, that pull request does not resolve this. Using 
DataContractJsonSerializer will fail for nested objects.
There is no guarantee that jsonHeaders is just a dictionary of string,string.
In fact, I'm pretty sure this test will fail :
https://github.com/apache/cordova-plugin-file-transfer/blob/master/tests/tests.js#L856





@purplecabbage
risingj.com

On Thu, Mar 26, 2015 at 10:26 AM, Nikhil Khandelwal 
wrote:

> The main use case for Newtonsoft.Json has been resolved through 
> another implementation approach in this PR:
> https://github.com/apache/cordova-plugin-file-transfer/pull/72
>   
> -Nikhil
>
> -Original Message-
> From: Carlos Santana [mailto:csantan...@gmail.com]
> Sent: Thursday, March 26, 2015 9:47 AM
> To: dev@cordova.apache.org
> Subject: Re: Cordova WP8: switching to Newtonsoft.Json
>
> Jesse dumb question, what else is new 8-]
>
> Can we do that Mark pointed out to add a reference to a location where 
> the windows project can get the dependency?
> Like adding a nuget dependency entry, and then when app get's compile, 
> visual studio takes care of downloading Newtonsoft.Json from nuget 
> repository?
>
>
> On Tue, Mar 24, 2015 at 1:38 PM, Jesse  wrote:
>
> > I am looking into this. We need to include source code, as we cannot 
> > distribute a dll.
> > The pull-req is definitely dead except for the fact it contain part 
> > of this conversation.
> >
> >
> >
> >
> > > On Mar 24, 2015, at 6:37 AM, Ian Clelland 
> > wrote:
> > >
> > > I'm not sure about whether Cordova has any specific policies -- 
> > > there's
> > no
> > > hard rule that says we can't use third-party code, and even 
> > > include it in our distributions (see Cordova-Android and okhttp, 
> > > for instance), but we should probably discuss it on-list first.
> > >
> > > There are definitely rules, policies, and guidelines at the Apache 
> > > level
> > --
> > > no distribution of binaries, for instance, and there are probably
> > questions
> > > of license interaction as well between Apache and MIT licenses, if 
> > > we're combining the code at all.
> > >
> > >
> > >
> > > On Tue, Mar 24, 2015 at 5:04 AM, Sergey Grebnov (Akvelon) < 
> > > v-seg...@microsoft.com> wrote:
> > >
> > >> This[1] PR is being opened for a while so let's make a final 
> > >> decision if we switch to Newtonsoft.Json  or reject it.
> > >>
> > >> The idea of adding Newtonsoft.Json (MIT license) [1] looks good 
> > >> to me
> > and
> > >> I can quickly add necessary improvements to make sure everything 
> > >> looks
> > good
> > >> and works - as per mobile spec tests there are no new issues found.
> > >>
> > >> But I'm not sure about our policies regarding adding new third 
> > >> party dependencies. Should it be discussed/voted here before merge?
> > >> Does it documented somewhere?
> > >>
> > >> PS. If we go w/ Newtonsoft.Json   I propose to just add reference to
> > >> compiled dll and not to keep source code due to size(200kb vs 
> > >> 19mb) and compile time reasons.
> > >
> > > Distributing the .dll without the source will *definitely* be a
> problem.
> > > Distributing the .dll with the source *might* be a problem. The 
> > > only way we've been able to do this in the past (see Gradle and 
> > > Crosswalk for two recent examples) is to have a script that the 
> > > user runs (even as part of the platform scripts) that downloads 
> > > the library from somewhere trusted
> > and
> > > installs it. We can't ship binaries as part of an Apache project.
> > >
> > >
> > >>
> > >> [1] https://github.com/apache/cordova-wp8/pull/62
> > >>
> > >> Thx!
> > >> Sergey
> > >>
> > >>
> > >> -
> > >> --
> > >> -- 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
> >
> >
>
>
> --
> Carlos Santana
> 
>

[GitHub] cordova-plugin-splashscreen pull request: CB-8758 [wp8]: Unauthori...

[dpolivy]

GitHub user dpolivy opened a pull request:

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

CB-8758 [wp8]: UnauthorizedAccessException on hide()

When calling hide() from JS, the attempt to access Popup could happen on
a background thread, which ends up throwing an
UnauthorizedAccessException about cross-thread access.

To address this, it's best to check the popup's state from within the UI
thread.

Fixes https://issues.apache.org/jira/browse/CB-8758

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

$ git pull https://github.com/dpolivy/cordova-plugin-splashscreen CB8758

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

https://github.com/apache/cordova-plugin-splashscreen/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 179831178b87531392afbf9539146a47689447d3
Author: Dan Polivy 
Date:   2015-03-26T18:52:10Z

CB-8758 [wp8]: UnauthorizedAccessException on hide()

When calling hide() from JS, the attempt to access Popup could happen on
a background thread, which ends up throwing an
UnauthorizedAccessException about cross-thread access.

To address this, it's best to check the popup's state from within the UI
thread.

Fixes https://issues.apache.org/jira/browse/CB-8758




---
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: Who Runs cordova.io?

[Josh Soref]

this has nothing to do w/ cordova.io domaining,

it's a bug in our registry-web repository.

you're encouraged to work on it (it is filed).

once a fix is provided for it (it's a escape/unescape loop), someone will know 
how to fix it.

On the other side, all of the browser vendors should handle this well, I know 
Chrome crashes, which is a bug in chrome.

I'm sorry for everyone. but i've lost a few days debugging it and got lost.

I'm also ill, and don't have any more resources to invest on this until after 
spring.


From: Dmitry Blotsky [dblot...@microsoft.com]
Sent: Thursday, March 26, 2015 2:39 PM
To: dev@cordova.apache.org
Subject: Who Runs cordova.io?

Hi list,

This issue just came up on JIRA for Apache Infra - 
https://issues.apache.org/jira/browse/INFRA-9349 - but they apparently don't 
have the ruling power over cordova.io. Who governs cordova.io?

Kindly,
Dmitry

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

Re: Who Runs cordova.io?

[Jesse]

We do :
https://issues.apache.org/jira/browse/CB-8141


@purplecabbage
risingj.com

On Thu, Mar 26, 2015 at 11:39 AM, Dmitry Blotsky 
wrote:

> Hi list,
>
> This issue just came up on JIRA for Apache Infra -
> https://issues.apache.org/jira/browse/INFRA-9349 - but they apparently
> don't have the ruling power over cordova.io. Who governs cordova.io?
>
> Kindly,
> Dmitry
>

Re: [DISCUSS] cordova-wp8 + Newtonsoft.JSON

[Brian LeRoux]

fairly certain distributing binaries isn't ok (except when it is such as
maven or open office)

=/

an email to legal-discuss is good diligence regardless

On Thu, Mar 26, 2015 at 11:27 AM, Ian Clelland 
wrote:

> Parashuram, from the link you provided in the previous thread (
> http://www.apache.org/legal/resolved.html), it looks like only a small set
> of licenses ("Category B") make binary distribution with Apache projects
> possible, and the MIT license isn't on that list.
>
> We should definitely get Apache legal looped into this discussion before we
> consider distributing this in binary form. I realize it's the smallest and
> easiest, and best for the users, but we have to work with the ASF.
>
> On Thu, Mar 26, 2015 at 2:13 PM, Parashuram N (MS OPEN TECH) <
> panar...@microsoft.com> wrote:
>
> > I think we can use option 4 - distributing DLLs of third party software
> is
> > fine - we only need to ensure that it is clean from an IP perspective. I
> > think 4 is the best option as you said, and we could ask the author of
> the
> > library about any potential patent issues. I also think that Apache puts
> > the due diligence of IP and patent responsibility on the committers
> >
> > -Original Message-
> > From: Jesse [mailto:purplecabb...@gmail.com]
> > Sent: Thursday, March 26, 2015 11:05 AM
> > To: dev@cordova.apache.org
> > Subject: [DISCUSS] cordova-wp8 + Newtonsoft.JSON
> >
> > We have several options, of varying difficulty, legal responsibility,
> > risk, and technical debt.
> >
> > 1. Redistribute Newtonsoft.JSON (NJ) source code as part of every new
> > cordova-wp8 project
> >   - it's a lot of code to add to the project, more that cordova-wp8
> itself
> >   - we completely control our dependencies and will never fall out of
> sync
> >
> > 2. Redistribute NJ source as part of the library and have every new
> > cordova-wp8 project link to it.
> >   - some added complexity, but technically sound, and not as wasteful
> > seeming as #1
> >   - we could have issues with dependencies if NJ included source changes
> > between cordova-wp8 versions
> >
> > 3. Redistribute NJ source, build it when cordova-wp8 is installed on the
> > users machine, add the .dll to every new cordova-wp8 project.
> >- same issues/benefits as #2, some added complexity
> >
> > 4. Redistribute NJ as a pre-built dll and as part of the wp8 template.
> >   - I like this best, but we have to dig through legal some more.
> >
> > 5. Do some magic with nuget dependencies so VS will download it.
> >   - lots of unknowns ( to me, others may know more )
> >   - can only create cordova-wp8 projects when online ( Android already
> has
> > this restriction )
> >
> > 6. Redistribute NJ as a cordova-wp8  plugin and make it a dependency of
> > cordova-wp8
> >   - a little awkward, but doable
> >
> > 7. Do nothing
> >   - realistically wp8 should be deprecated soon, wp8.1 has much more to
> > offer, and win10 is on the horizon. We could just let the sun set.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > @purplecabbage
> > risingj.com
> >
>

RE: [Android] Proposal: Deprecate/No-Op Battery Plugin

[Josh Soref]

Pointer?

(but if Brian says yes, then, that sounds like a good start)


From: brian.ler...@gmail.com [brian.ler...@gmail.com] on behalf of Brian LeRoux 
[b...@brian.io]
Sent: Thursday, March 26, 2015 2:24 PM
To: dev@cordova.apache.org
Subject: Re: [Android] Proposal: Deprecate/No-Op Battery Plugin

I do! -->
3) Recognize and Handle Offline Status

On Thu, Mar 26, 2015 at 11:09 AM, Raymond Camden 
wrote:

> Do you think it fits in the Next Steps doc?
>
> On Thu, Mar 26, 2015 at 1:05 PM, Josh Soref  wrote:
> > I'm really hoping someone like Raymond will write something nice and
> pretty about this.
> >
> > That isn't my strong suite.
> >
> > Brian wrote:
> >> this! is really good advice and should make it into our guides.
> >
> > Thanks
> >
> > Josh Soref  wrote:
> >
> >> Andrew wrote:
> >> > Let's just update the README to state that "the battery plugin is a
> >> plugin
> >> > that uses your battery" :)
> >>
> >> I'm +1 on this
> >>
> >> > Only half joking... probably would be minimal effort and enough to
> just
> >> add
> >> > a warning about this and do nothing more.
> >>
> >> it's not a joke, old battery apis (and probably on other platforms too,
> i
> >> can't remember which) really are harmful.
> >>
> >> plus, it's rarely the right thing to do.
> >>
> >> app developers should really be event driven:
> >>
> >> e.g.:
> >> * gaining network connection to their uplink
> >> * having sufficient data to justify sending
> >> * receiving a notice (e.g. a push) that they have data to fetch
> >>
> >> and they should use some local storage cache for everything else.
> >>
> >> * they should be resilient to users reseting their devices (power cycle,
> >> os OTA, battery pull, device kernel panic).
> >> * they should be resilient to users choosing to go into airplane mode
> for
> >> a 10 hour flight and running out of battery before disembarking.
> >>
> >> a battery api doesn't help w/ these things. being event driven does.
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
>
>
>
> --
> ===
> Raymond Camden, Developer Advocate for MobileFirst at IBM
>
> Email : raymondcam...@gmail.com
> Blog : www.raymondcamden.com
> Twitter: raymondcamden
>
> -
> 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

Re: Setting config.json values

[Shazron]

Whoever ends up fixing this, please add a test for the functionality

On Thu, Mar 26, 2015 at 11:35 AM, Josh Soref  wrote:
> It's possible i broke it:
>
> https://github.com/apache/cordova-cli/commit/106d8801a70a9b97cd606e27f80c6c7988f368cc#diff-ef7004c4000a2616f36c594dc5db207a
>
> try something from before this?
>
> i'd suggest a bisect
>
> specifically, find the last version where the command worked;
> then try only upgrading lib, to the version+1 and see if it worked, if so, 
> it's probably in cli.
>
> i'd be really embarrassed if it's my fault.
>
> i've been under the weather this week, so i'm catching up on mail/offering 
> spot advice and giving up.
>
> 
> From: Shazron [shaz...@gmail.com]
> Sent: Thursday, March 26, 2015 1:19 PM
> To: dev@cordova.apache.org
> Subject: Re: Setting config.json values
>
> The help still says CONFIG is an option:
> cordova create  [ID [NAME [CONFIG]]] [options] [PLATFORM...]
>
> and config handling seems to still be there..
> https://github.com/apache/cordova-lib/blob/cc596a37d77a92665292a5370d660a898217e0cb/cordova-lib/src/cordova/create.js#L41
>
> .. so I think it's a bug. Two things here:
> 1. this bug
> 2. PLATFORM is not defined in the create help (I know it should be
> obvious, but...)
>
>
>
>
>
> On Thu, Mar 26, 2015 at 6:57 AM, John M. Wargo  wrote:
>> Earlier this month, there was a conversation on this thread about enabling
>> auto saving of plugin information to the project's config.json file
>> (.cordova/config.json, right?) by setting auto_save_plugins to true in the
>> file.
>>
>> I responded on that thread suggesting that users would be able to set this
>> value by passing the configuration value on the command line to the cordova
>> create command like so:
>>
>> cordova create test com.johnwargo.test Test
>> {\"auto_save_plugins\":\"true\"}
>>
>> Shouldn't this be a viable way to enable users to automagically set this
>> value?
>>
>> The problem is that this CLI feature no longer seems to work. Last fall, I
>> was able to set the plugin search path using the following:
>>
>> cordova create test2 com.johnwargo.test2 Test2
>> "{\"plugin_search_path\":\"d:/dev\"}"
>>
>> But I just tested it (for a second time on a different system) and that
>> capability, passing config.json values on the command line to create, no
>> longer seems to be working. Did I miss something? Was this feature removed?
>> Or should I submit a ticket on this issue?
>>
>> Currently the SAP Mobile Platform Hybrid SDK ships as a local installer, the
>> plugins aren't in the plugin registry or even github. The plugins have local
>> dependencies (the AppUpdate plugin relies upon capabilities exposed by the
>> Logon plugin) and the Cordova CLI isn't able to resolve them locally without
>> the plugin_search_path being set. We've instructed users to use this
>> feature, but now it seems it's not working. Can someone confirm?
>>
>> Since plugin_search_path is valuable for SAP customers and auto_save_plugins
>> is important for this new save/restore capability, is it time to design a
>> simpler approach to allow developers to easily set these properties as
>> needed for their projects?  It seems that having a create command parameter
>> that points to a configuration file containing default settings for the
>> project would be a useful thing to have.
>>
>> What says the group?
>> --
>> John M. Wargo
>> @johnwargo 
>> www.johnwargo.com 
>> --
>
> -
> 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
>

-
To unsubscribe, e-m

RE: Cordova Monthly Hangouts

[Josh Soref]

As a headsup, the beginning of April is Passover. I'm on vacation for it. I'm 
not sure how many others might be affected.

There's often an Easter holiday floating around and or a spring break.


From: Parashuram N (MS OPEN TECH) [panar...@microsoft.com]
Sent: Thursday, March 26, 2015 1:27 PM
To: dev@cordova.apache.org
Subject: RE: Cordova Monthly Hangouts

Carlos, you did not miss it, still working on scheduling it :)

Here is the doddle - please respond to this and indicate your availability. 
Since the hangouts usually go to 2 hours, and to keep the number of options 
sane in doddle, I put up 2 hour slots. Let me know if we should make it 1 hour 
slots.

Here is the participation link - http://doodle.com/kydhnyzzwge92hsu

-Original Message-
From: Carlos Santana [mailto:csantan...@gmail.com]
Sent: Thursday, March 26, 2015 9:58 AM
To: dev@cordova.apache.org
Subject: Re: Cordova Monthly Hangouts

+1 did I missed the hangout? I would like to attend.

Micha I like the new term "npm-ness" :-)

Yes Android 4.0 is important for us, we are about to start new work and want to 
start with a released one.


On Tue, Mar 24, 2015 at 7:01 PM, tommy-carlos williams 
wrote:

> +1 for package.json discussions
>
> --
> tommy-carlos williams
>
> On 25 March 2015 at 09:18:12, Michal Mocny (mmo...@chromium.org) wrote:
>
> Another topic is discussion of "package.json" based cli workflow, aka
> leveraging more npm-ness in our tools.
>
> -Michal
>
> On Tue, Mar 24, 2015 at 1:59 PM, Andrew Grieve 
> wrote:
>
> > +1!
> >
> > On Tue, Mar 24, 2015 at 1:23 PM, Jesse  wrote:
> >
> > > +1 asap, thanks Parash!
> > >
> > > We are much more coherent when we meet.
> > >
> > >
> > >
> > > > On Mar 24, 2015, at 10:02 AM, Parashuram N (MS OPEN TECH) <
> > > panar...@microsoft.com> wrote:
> > > >
> > > > Hi,
> > > >
> > > > I was wondering if folks would be interested in doing a hangout
> > > > to
> > > quickly resolve some of the outstanding issues that we have been
> talking
> > on
> > > the mailing list. I think we could talk about the following
> > > >
> > > >
> > > > * Androind 4.0 release
> > > > * Medic/ParaMedic/Mobile Spec - progress and next steps
> > > > * Finalize Save/Restore discussions
> > > > * ApacheCon ?
> > > >
> > > > I can volunteer to help set this up if we think there are items
> > > > that
> we
> > > would like to discuss and close on.
> > >
> > > --
> > > --- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > >
> > >
> >
>



--
Carlos Santana

?B�CB�?�?[��X��ܚX�K??K[XZ[?�??]�][��X��ܚX�P?�ܙ?ݘK�\?X�?K�ܙ�B��܈?Y??]?[ۘ[??��[X[�?�??K[XZ[?�??]�Z?[???�ܙ?ݘK�\?X�?K�ܙ�B

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

Re: [DISCUSS] cordova-wp8 + Newtonsoft.JSON

[Shazron]

Definitely get clarification. My reading on that Category B list is
that it only applies to including binaries of code with Weak Copyleft
licenses, this is so people don't accidentally contrib code to it - to
keep it separate. "minimize the chance that a user of an Apache
product will create a derivative work"


On Thu, Mar 26, 2015 at 11:27 AM, Ian Clelland  wrote:
> Parashuram, from the link you provided in the previous thread (
> http://www.apache.org/legal/resolved.html), it looks like only a small set
> of licenses ("Category B") make binary distribution with Apache projects
> possible, and the MIT license isn't on that list.
>
> We should definitely get Apache legal looped into this discussion before we
> consider distributing this in binary form. I realize it's the smallest and
> easiest, and best for the users, but we have to work with the ASF.
>
> On Thu, Mar 26, 2015 at 2:13 PM, Parashuram N (MS OPEN TECH) <
> panar...@microsoft.com> wrote:
>
>> I think we can use option 4 - distributing DLLs of third party software is
>> fine - we only need to ensure that it is clean from an IP perspective. I
>> think 4 is the best option as you said, and we could ask the author of the
>> library about any potential patent issues. I also think that Apache puts
>> the due diligence of IP and patent responsibility on the committers
>>
>> -Original Message-
>> From: Jesse [mailto:purplecabb...@gmail.com]
>> Sent: Thursday, March 26, 2015 11:05 AM
>> To: dev@cordova.apache.org
>> Subject: [DISCUSS] cordova-wp8 + Newtonsoft.JSON
>>
>> We have several options, of varying difficulty, legal responsibility,
>> risk, and technical debt.
>>
>> 1. Redistribute Newtonsoft.JSON (NJ) source code as part of every new
>> cordova-wp8 project
>>   - it's a lot of code to add to the project, more that cordova-wp8 itself
>>   - we completely control our dependencies and will never fall out of sync
>>
>> 2. Redistribute NJ source as part of the library and have every new
>> cordova-wp8 project link to it.
>>   - some added complexity, but technically sound, and not as wasteful
>> seeming as #1
>>   - we could have issues with dependencies if NJ included source changes
>> between cordova-wp8 versions
>>
>> 3. Redistribute NJ source, build it when cordova-wp8 is installed on the
>> users machine, add the .dll to every new cordova-wp8 project.
>>- same issues/benefits as #2, some added complexity
>>
>> 4. Redistribute NJ as a pre-built dll and as part of the wp8 template.
>>   - I like this best, but we have to dig through legal some more.
>>
>> 5. Do some magic with nuget dependencies so VS will download it.
>>   - lots of unknowns ( to me, others may know more )
>>   - can only create cordova-wp8 projects when online ( Android already has
>> this restriction )
>>
>> 6. Redistribute NJ as a cordova-wp8  plugin and make it a dependency of
>> cordova-wp8
>>   - a little awkward, but doable
>>
>> 7. Do nothing
>>   - realistically wp8 should be deprecated soon, wp8.1 has much more to
>> offer, and win10 is on the horizon. We could just let the sun set.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> @purplecabbage
>> risingj.com
>>

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

Who Runs cordova.io?

[Dmitry Blotsky]

Hi list,

This issue just came up on JIRA for Apache Infra - 
https://issues.apache.org/jira/browse/INFRA-9349 - but they apparently don't 
have the ruling power over cordova.io. Who governs cordova.io?

Kindly,
Dmitry

RE: Setting config.json values

[Josh Soref]

It's possible i broke it:

https://github.com/apache/cordova-cli/commit/106d8801a70a9b97cd606e27f80c6c7988f368cc#diff-ef7004c4000a2616f36c594dc5db207a

try something from before this?

i'd suggest a bisect

specifically, find the last version where the command worked;
then try only upgrading lib, to the version+1 and see if it worked, if so, it's 
probably in cli.

i'd be really embarrassed if it's my fault.

i've been under the weather this week, so i'm catching up on mail/offering spot 
advice and giving up.


From: Shazron [shaz...@gmail.com]
Sent: Thursday, March 26, 2015 1:19 PM
To: dev@cordova.apache.org
Subject: Re: Setting config.json values

The help still says CONFIG is an option:
cordova create  [ID [NAME [CONFIG]]] [options] [PLATFORM...]

and config handling seems to still be there..
https://github.com/apache/cordova-lib/blob/cc596a37d77a92665292a5370d660a898217e0cb/cordova-lib/src/cordova/create.js#L41

.. so I think it's a bug. Two things here:
1. this bug
2. PLATFORM is not defined in the create help (I know it should be
obvious, but...)





On Thu, Mar 26, 2015 at 6:57 AM, John M. Wargo  wrote:
> Earlier this month, there was a conversation on this thread about enabling
> auto saving of plugin information to the project's config.json file
> (.cordova/config.json, right?) by setting auto_save_plugins to true in the
> file.
>
> I responded on that thread suggesting that users would be able to set this
> value by passing the configuration value on the command line to the cordova
> create command like so:
>
> cordova create test com.johnwargo.test Test
> {\"auto_save_plugins\":\"true\"}
>
> Shouldn't this be a viable way to enable users to automagically set this
> value?
>
> The problem is that this CLI feature no longer seems to work. Last fall, I
> was able to set the plugin search path using the following:
>
> cordova create test2 com.johnwargo.test2 Test2
> "{\"plugin_search_path\":\"d:/dev\"}"
>
> But I just tested it (for a second time on a different system) and that
> capability, passing config.json values on the command line to create, no
> longer seems to be working. Did I miss something? Was this feature removed?
> Or should I submit a ticket on this issue?
>
> Currently the SAP Mobile Platform Hybrid SDK ships as a local installer, the
> plugins aren't in the plugin registry or even github. The plugins have local
> dependencies (the AppUpdate plugin relies upon capabilities exposed by the
> Logon plugin) and the Cordova CLI isn't able to resolve them locally without
> the plugin_search_path being set. We've instructed users to use this
> feature, but now it seems it's not working. Can someone confirm?
>
> Since plugin_search_path is valuable for SAP customers and auto_save_plugins
> is important for this new save/restore capability, is it time to design a
> simpler approach to allow developers to easily set these properties as
> needed for their projects?  It seems that having a create command parameter
> that points to a configuration file containing default settings for the
> project would be a useful thing to have.
>
> What says the group?
> --
> John M. Wargo
> @johnwargo 
> www.johnwargo.com 
> --

-
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

[GitHub] cordova-plugin-splashscreen pull request: CB-8750 [wp8]: Allow res...

[dpolivy]

GitHub user dpolivy opened a pull request:

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

CB-8750 [wp8]: Allow resolution-specific splashscreen images

There are two aspect ratios for Windows Phone devices: 15:9 and 16:9. At
the moment, though, there is only one splash screen by default for WP8
Cordova apps. When stretched to fit all possible resolutions, this can
sometimes look bad.

WP supports resolution-specific splashscreens, so this commit adds the
same support to the splashscreen plugin. It uses the same base name for
the splashscreen, but adds modifiers such as ".screen-" based on
the device. If a screen-specific image is found, it is used. If not, we
fall back to the single default image.

Fixes https://issues.apache.org/jira/browse/CB-8750

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

$ git pull https://github.com/dpolivy/cordova-plugin-splashscreen CB8750

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

https://github.com/apache/cordova-plugin-splashscreen/pull/41.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 #41


commit 542cf56240ae19592bdba2ee67b61a0325eadd00
Author: Dan Polivy 
Date:   2015-03-26T18:29:50Z

CB-8750 [wp8]: Allow resolution-specific splashscreen images

There are two aspect ratios for Windows Phone devices: 15:9 and 16:9. At
the moment, though, there is only one splash screen by default for WP8
Cordova apps. When stretched to fit all possible resolutions, this can
sometimes look bad.

WP supports resolution-specific splashscreens, so this commit adds the
same support to the splashscreen plugin. It uses the same base name for
the splashscreen, but adds modifiers such as ".screen-" based on
the device. If a screen-specific image is found, it is used. If not, we
fall back to the single default image.

Fixes https://issues.apache.org/jira/browse/CB-8750




---
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] cordova-wp8 + Newtonsoft.JSON

[Ian Clelland]

Parashuram, from the link you provided in the previous thread (
http://www.apache.org/legal/resolved.html), it looks like only a small set
of licenses ("Category B") make binary distribution with Apache projects
possible, and the MIT license isn't on that list.

We should definitely get Apache legal looped into this discussion before we
consider distributing this in binary form. I realize it's the smallest and
easiest, and best for the users, but we have to work with the ASF.

On Thu, Mar 26, 2015 at 2:13 PM, Parashuram N (MS OPEN TECH) <
panar...@microsoft.com> wrote:

> I think we can use option 4 - distributing DLLs of third party software is
> fine - we only need to ensure that it is clean from an IP perspective. I
> think 4 is the best option as you said, and we could ask the author of the
> library about any potential patent issues. I also think that Apache puts
> the due diligence of IP and patent responsibility on the committers
>
> -Original Message-
> From: Jesse [mailto:purplecabb...@gmail.com]
> Sent: Thursday, March 26, 2015 11:05 AM
> To: dev@cordova.apache.org
> Subject: [DISCUSS] cordova-wp8 + Newtonsoft.JSON
>
> We have several options, of varying difficulty, legal responsibility,
> risk, and technical debt.
>
> 1. Redistribute Newtonsoft.JSON (NJ) source code as part of every new
> cordova-wp8 project
>   - it's a lot of code to add to the project, more that cordova-wp8 itself
>   - we completely control our dependencies and will never fall out of sync
>
> 2. Redistribute NJ source as part of the library and have every new
> cordova-wp8 project link to it.
>   - some added complexity, but technically sound, and not as wasteful
> seeming as #1
>   - we could have issues with dependencies if NJ included source changes
> between cordova-wp8 versions
>
> 3. Redistribute NJ source, build it when cordova-wp8 is installed on the
> users machine, add the .dll to every new cordova-wp8 project.
>- same issues/benefits as #2, some added complexity
>
> 4. Redistribute NJ as a pre-built dll and as part of the wp8 template.
>   - I like this best, but we have to dig through legal some more.
>
> 5. Do some magic with nuget dependencies so VS will download it.
>   - lots of unknowns ( to me, others may know more )
>   - can only create cordova-wp8 projects when online ( Android already has
> this restriction )
>
> 6. Redistribute NJ as a cordova-wp8  plugin and make it a dependency of
> cordova-wp8
>   - a little awkward, but doable
>
> 7. Do nothing
>   - realistically wp8 should be deprecated soon, wp8.1 has much more to
> offer, and win10 is on the horizon. We could just let the sun set.
>
>
>
>
>
>
>
>
>
> @purplecabbage
> risingj.com
>

Re: [Android] Proposal: Deprecate/No-Op Battery Plugin

[Brian LeRoux]

I do! -->
3) Recognize and Handle Offline Status

On Thu, Mar 26, 2015 at 11:09 AM, Raymond Camden 
wrote:

> Do you think it fits in the Next Steps doc?
>
> On Thu, Mar 26, 2015 at 1:05 PM, Josh Soref  wrote:
> > I'm really hoping someone like Raymond will write something nice and
> pretty about this.
> >
> > That isn't my strong suite.
> >
> > Brian wrote:
> >> this! is really good advice and should make it into our guides.
> >
> > Thanks
> >
> > Josh Soref  wrote:
> >
> >> Andrew wrote:
> >> > Let's just update the README to state that "the battery plugin is a
> >> plugin
> >> > that uses your battery" :)
> >>
> >> I'm +1 on this
> >>
> >> > Only half joking... probably would be minimal effort and enough to
> just
> >> add
> >> > a warning about this and do nothing more.
> >>
> >> it's not a joke, old battery apis (and probably on other platforms too,
> i
> >> can't remember which) really are harmful.
> >>
> >> plus, it's rarely the right thing to do.
> >>
> >> app developers should really be event driven:
> >>
> >> e.g.:
> >> * gaining network connection to their uplink
> >> * having sufficient data to justify sending
> >> * receiving a notice (e.g. a push) that they have data to fetch
> >>
> >> and they should use some local storage cache for everything else.
> >>
> >> * they should be resilient to users reseting their devices (power cycle,
> >> os OTA, battery pull, device kernel panic).
> >> * they should be resilient to users choosing to go into airplane mode
> for
> >> a 10 hour flight and running out of battery before disembarking.
> >>
> >> a battery api doesn't help w/ these things. being event driven does.
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
>
>
>
> --
> ===
> Raymond Camden, Developer Advocate for MobileFirst at IBM
>
> Email : raymondcam...@gmail.com
> Blog : www.raymondcamden.com
> Twitter: raymondcamden
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

[GitHub] cordova-medic pull request: CB-8734 add support for firefoxos

[dblotsky]

Github user dblotsky commented on the pull request:

https://github.com/apache/cordova-medic/pull/39#issuecomment-86654603
  
You need to follow the same steps that Medic follows to use the build 
scripts. That is:

```bash
$ # make sure all the relevant repositories are cloned, npm-installed, 
and npm-linked
$ node cordova-mobile-spec/createmobilespec/createmobilespec.js 
--firefoxos --copywww --skiplink mobilespec
$ node cordova-medic/updateconfig.js --firefoxos
$ node cordova-medic/build_firefoxos.js
```

If it's still failing for you, please post your directory layout and 
outputs on the mailing list and we can debug 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.
---

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

RE: [DISCUSS] cordova-wp8 + Newtonsoft.JSON

[Parashuram N (MS OPEN TECH)]

I think we can use option 4 - distributing DLLs of third party software is fine 
- we only need to ensure that it is clean from an IP perspective. I think 4 is 
the best option as you said, and we could ask the author of the library about 
any potential patent issues. I also think that Apache puts the due diligence of 
IP and patent responsibility on the committers 

-Original Message-
From: Jesse [mailto:purplecabb...@gmail.com] 
Sent: Thursday, March 26, 2015 11:05 AM
To: dev@cordova.apache.org
Subject: [DISCUSS] cordova-wp8 + Newtonsoft.JSON

We have several options, of varying difficulty, legal responsibility, risk, and 
technical debt.

1. Redistribute Newtonsoft.JSON (NJ) source code as part of every new
cordova-wp8 project
  - it's a lot of code to add to the project, more that cordova-wp8 itself
  - we completely control our dependencies and will never fall out of sync

2. Redistribute NJ source as part of the library and have every new
cordova-wp8 project link to it.
  - some added complexity, but technically sound, and not as wasteful seeming 
as #1
  - we could have issues with dependencies if NJ included source changes 
between cordova-wp8 versions

3. Redistribute NJ source, build it when cordova-wp8 is installed on the users 
machine, add the .dll to every new cordova-wp8 project.
   - same issues/benefits as #2, some added complexity

4. Redistribute NJ as a pre-built dll and as part of the wp8 template.
  - I like this best, but we have to dig through legal some more.

5. Do some magic with nuget dependencies so VS will download it.
  - lots of unknowns ( to me, others may know more )
  - can only create cordova-wp8 projects when online ( Android already has this 
restriction )

6. Redistribute NJ as a cordova-wp8  plugin and make it a dependency of
cordova-wp8
  - a little awkward, but doable

7. Do nothing
  - realistically wp8 should be deprecated soon, wp8.1 has much more to offer, 
and win10 is on the horizon. We could just let the sun set.









@purplecabbage
risingj.com

Re: [Android] Proposal: Deprecate/No-Op Battery Plugin

[Raymond Camden]

Do you think it fits in the Next Steps doc?

On Thu, Mar 26, 2015 at 1:05 PM, Josh Soref  wrote:
> I'm really hoping someone like Raymond will write something nice and pretty 
> about this.
>
> That isn't my strong suite.
>
> Brian wrote:
>> this! is really good advice and should make it into our guides.
>
> Thanks
>
> Josh Soref  wrote:
>
>> Andrew wrote:
>> > Let's just update the README to state that "the battery plugin is a
>> plugin
>> > that uses your battery" :)
>>
>> I'm +1 on this
>>
>> > Only half joking... probably would be minimal effort and enough to just
>> add
>> > a warning about this and do nothing more.
>>
>> it's not a joke, old battery apis (and probably on other platforms too, i
>> can't remember which) really are harmful.
>>
>> plus, it's rarely the right thing to do.
>>
>> app developers should really be event driven:
>>
>> e.g.:
>> * gaining network connection to their uplink
>> * having sufficient data to justify sending
>> * receiving a notice (e.g. a push) that they have data to fetch
>>
>> and they should use some local storage cache for everything else.
>>
>> * they should be resilient to users reseting their devices (power cycle,
>> os OTA, battery pull, device kernel panic).
>> * they should be resilient to users choosing to go into airplane mode for
>> a 10 hour flight and running out of battery before disembarking.
>>
>> a battery api doesn't help w/ these things. being event driven does.
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>



-- 
===
Raymond Camden, Developer Advocate for MobileFirst at IBM

Email : raymondcam...@gmail.com
Blog : www.raymondcamden.com
Twitter: raymondcamden

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

RE: [Android] Proposal: Deprecate/No-Op Battery Plugin

[Josh Soref]

I'm really hoping someone like Raymond will write something nice and pretty 
about this.

That isn't my strong suite.

Brian wrote:
> this! is really good advice and should make it into our guides.

Thanks

Josh Soref  wrote:

> Andrew wrote:
> > Let's just update the README to state that "the battery plugin is a
> plugin
> > that uses your battery" :)
>
> I'm +1 on this
>
> > Only half joking... probably would be minimal effort and enough to just
> add
> > a warning about this and do nothing more.
>
> it's not a joke, old battery apis (and probably on other platforms too, i
> can't remember which) really are harmful.
>
> plus, it's rarely the right thing to do.
>
> app developers should really be event driven:
>
> e.g.:
> * gaining network connection to their uplink
> * having sufficient data to justify sending
> * receiving a notice (e.g. a push) that they have data to fetch
>
> and they should use some local storage cache for everything else.
>
> * they should be resilient to users reseting their devices (power cycle,
> os OTA, battery pull, device kernel panic).
> * they should be resilient to users choosing to go into airplane mode for
> a 10 hour flight and running out of battery before disembarking.
>
> a battery api doesn't help w/ these things. being event driven does.
-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[DISCUSS] cordova-wp8 + Newtonsoft.JSON

[Jesse]

We have several options, of varying difficulty, legal responsibility, risk,
and technical debt.

1. Redistribute Newtonsoft.JSON (NJ) source code as part of every new
cordova-wp8 project
  - it's a lot of code to add to the project, more that cordova-wp8 itself
  - we completely control our dependencies and will never fall out of sync

2. Redistribute NJ source as part of the library and have every new
cordova-wp8 project link to it.
  - some added complexity, but technically sound, and not as wasteful
seeming as #1
  - we could have issues with dependencies if NJ included source changes
between cordova-wp8 versions

3. Redistribute NJ source, build it when cordova-wp8 is installed on the
users machine, add the .dll to every new cordova-wp8 project.
   - same issues/benefits as #2, some added complexity

4. Redistribute NJ as a pre-built dll and as part of the wp8 template.
  - I like this best, but we have to dig through legal some more.

5. Do some magic with nuget dependencies so VS will download it.
  - lots of unknowns ( to me, others may know more )
  - can only create cordova-wp8 projects when online ( Android already has
this restriction )

6. Redistribute NJ as a cordova-wp8  plugin and make it a dependency of
cordova-wp8
  - a little awkward, but doable

7. Do nothing
  - realistically wp8 should be deprecated soon, wp8.1 has much more to
offer, and win10 is on the horizon. We could just let the sun set.









@purplecabbage
risingj.com

Re: [Android] Proposal: Deprecate/No-Op Battery Plugin

[Brian LeRoux]

this! is really good advice and should make it into our guides.

On Thu, Mar 26, 2015 at 10:42 AM, Josh Soref  wrote:

> Andrew wrote:
> > Let's just update the README to state that "the battery plugin is a
> plugin
> > that uses your battery" :)
>
> I'm +1 on this
>
> > Only half joking... probably would be minimal effort and enough to just
> add
> > a warning about this and do nothing more.
>
> it's not a joke, old battery apis (and probably on other platforms too, i
> can't remember which) really are harmful.
>
> plus, it's rarely the right thing to do.
>
> app developers should really be event driven:
>
> e.g.:
> * gaining network connection to their uplink
> * having sufficient data to justify sending
> * receiving a notice (e.g. a push) that they have data to fetch
>
> and they should use some local storage cache for everything else.
>
> * they should be resilient to users reseting their devices (power cycle,
> os OTA, battery pull, device kernel panic).
> * they should be resilient to users choosing to go into airplane mode for
> a 10 hour flight and running out of battery before disembarking.
>
> a battery api doesn't help w/ these things. being event driven does.
> -
> 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-8717 Write cordova-android@4.0.0 ...

[jsoref]

Github user jsoref commented on the pull request:

https://github.com/apache/cordova-android/pull/167#issuecomment-86647590
  
@jpchase: 
https://github.com/apache/cordova-android/compare/master...jsoref:pr/167?expand=1

Please consider folding in these changes (I can't seem to make a pull 
request against your repo)


---
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] Cordova-WP8 Release 3.8.0

[Jesse]

Starting a new thread for all Newtonsoft.JSON related discussions.

@purplecabbage
risingj.com

On Thu, Mar 26, 2015 at 8:40 AM, Parashuram N (MS OPEN TECH) <
panar...@microsoft.com> wrote:

> About the JSON library, as I understand, only ASF libraries need to be
> included in source form - third party libraries can still be binaries, and
> we would just need to ensure that it does not have IP issues.
>
> http://www.apache.org/legal/resolved.html
>
> Hence, I think we can include the JSON library.
>
> -Original Message-
> From: Steven Gill [mailto:stevengil...@gmail.com]
> Sent: Wednesday, March 25, 2015 1:34 PM
> To: dev@cordova.apache.org
> Subject: Re: [DISCUSS] Cordova-WP8 Release 3.8.0
>
> https://issues.apache.org/jira/browse/CB-8748
>
> On Wed, Mar 25, 2015 at 1:18 PM, Jesse  wrote:
>
> > Yeah, let's push out a 3.8.0 for cordova-wp8 We can do a 4.0.0 after I
> > get the JSON fixes in.
> >
> > @purplecabbage
> > risingj.com
> >
> > On Tue, Mar 24, 2015 at 2:36 PM, Rob Paveza 
> > wrote:
> >
> > > Is it worth breaking out the Newtonsoft.Json additions into a
> > > separate (major 4.0) release and taking these bugfixes into a minor
> > > release until
> > we
> > > get the legal stuff worked out on the JSON side?
> > >
> > > -Original Message-
> > > From: Jesse [mailto:purplecabb...@gmail.com]
> > > Sent: Tuesday, March 24, 2015 11:19 AM
> > > To: dev@cordova.apache.org
> > > Subject: Re: [DISCUSS] Cordova-WP8 Release 3.8.0
> > >
> > > I would like to finish off the Newtonsoft.Json additions, and
> > > release a
> > > 4.0.0
> > > The changes to the JSON namespace in c# potentially break some plugins.
> > > The barcode scanner [1] for one, as it is including the dll already.
> > > There is also possibly some impact on the file-transfer plugin [2]
> > > however, that is not a breaking change.
> > >
> > >
> > >
> > > [1] https://github.com/phonegap-build/PushPlugin
> > > [2]
> > >
> > >
> > https://github.com/apache/cordova-plugin-file-transfer/blob/master/src
> > /wp/FileTransfer.cs#L319
> > >
> > >
> > >
> > > @purplecabbage
> > > risingj.com
> > >
> > > On Tue, Mar 24, 2015 at 10:26 AM, Rob Paveza
> > > 
> > > wrote:
> > >
> > > > It's been three months since the last release of Cordova-WP8.
> > > > There are a number of bugfixes pending, particularly with emulator
> vs.
> > > > deploy-to-device and in scenarios where there are only Phone 8.1
> > > > tools on the machine doing the building.  Also added JSHint,
> > > > improved console
> > > logging, etc.
> > > >
> > > > There is the outstanding issue is that of Newtonsoft.Json (and a
> > > > thread going on about it), but if we can nail that down today
> > > > either way, we can move this along to a vote tomorrow.
> > > >
> > > > Any other outstanding issues to discuss?
> > > >
> > > > -Rob
> > > >
> > >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist Plugins Release

[Ian Clelland]

Yeah :(

Hash changes, code changes, checksums and pgp signatures change... all
necessitates a new vote.
At least we get to abort early.

On Thu, Mar 26, 2015 at 1:28 PM, Parashuram N (MS OPEN TECH) <
panar...@microsoft.com> wrote:

> Should we have to restart the vote thread, now that the tag will change ?
>
> -Original Message-
> From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew
> Grieve
> Sent: Thursday, March 26, 2015 7:41 AM
> To: dev
> Subject: Re: [VOTE] Cordova-Plugin-Whitelist and
> Cordova-Plugin-Legacy-Whitelist Plugins Release
>
> That'd be pretty sad if it were expected :P.
>
> Totally my bad on this one. I've committed a fix.
>
> On Thu, Mar 26, 2015 at 9:40 AM, Alexander Sorokin (Akvelon) <
> v-als...@microsoft.com> wrote:
>
> > Hi guys,
> >
> > I am getting the following error when trying to build a project with
> > legacy-whitelist plugin installed for android@4.0.0-dev:
> >
> >
> C:\Projects\Cordova\mobspec-android\platforms\android\src\org\apache\cordova\whitelist\LegacyWhitelistPlugin.java:44:
> > error: cannot find symbol
> > public void handleStartTag(XmlPullParser xml) {
> >^
> >   symbol: class XmlPullParser
> >
> C:\Projects\Cordova\mobspec-android\platforms\android\src\org\apache\cordova\whitelist\LegacyWhitelistPlugin.java:68:
> > error: cannot find symbol
> > public void handleEndTag(XmlPullParser xml) {
> >  ^
> >   symbol: class XmlPullParser
> >
> >
> > Is this expected?
> >
> > Thanks,
> > Alexander Sorokin
> >
> > -Original Message-
> > From: Steven Gill [mailto:stevengil...@gmail.com]
> > Sent: Wednesday, March 25, 2015 23:23
> > To: dev@cordova.apache.org
> > Subject: [VOTE] Cordova-Plugin-Whitelist and
> > Cordova-Plugin-Legacy-Whitelist Plugins Release
> >
> > Please review and vote on the releases of cordova-plugin-whitelist and
> > cordova-plugin-legacy-whitelist plugins.
> >
> > Release issue: https://issues.apache.org/jira/browse/CB-8739
> >
> > The plugins have been published to
> > dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-8739/
> >
> > The packages were published from their corresponding git tags:
> > cordova-plugin-whitelist: 1.0.0 (38f5a9fa2c)
> > cordova-plugin-legacy-whitelist: 1.0.0 (b4e1b3726a)
> >
> > Upon a successful vote I will upload the archives to dist/ and upload
> > them to npm.
> >
> > Voting guidelines:
> > https://github.com/apache/cordova-coho/blob/master/docs/release-voting
> > .md
> >
> > Voting will go on for a minimum of 48 hours.
> >
> > I vote +1:
> > * Ran coho audit-license-headers over the relevant repos
> > * Ran coho check-license to ensure all dependencies and
> > subdependencies have Apache-compatible licenses
> >
> > -
> > 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: CB-8721 Fixes incorrect...

[purplecabbage]

Github user purplecabbage commented on the pull request:


https://github.com/apache/cordova-plugin-file-transfer/pull/72#issuecomment-86642247
  
I think the DataContractJsonSerializer is gonna choke on some possible 
(valid) json data.
Nested objects are allowed, are they not?


---
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: [Android] Proposal: Deprecate/No-Op Battery Plugin

[Josh Soref]

Andrew wrote:
> Let's just update the README to state that "the battery plugin is a plugin
> that uses your battery" :)

I'm +1 on this

> Only half joking... probably would be minimal effort and enough to just add
> a warning about this and do nothing more.

it's not a joke, old battery apis (and probably on other platforms too, i can't 
remember which) really are harmful.

plus, it's rarely the right thing to do.

app developers should really be event driven:

e.g.:
* gaining network connection to their uplink
* having sufficient data to justify sending
* receiving a notice (e.g. a push) that they have data to fetch

and they should use some local storage cache for everything else.

* they should be resilient to users reseting their devices (power cycle, os 
OTA, battery pull, device kernel panic).
* they should be resilient to users choosing to go into airplane mode for a 10 
hour flight and running out of battery before disembarking.

a battery api doesn't help w/ these things. being event driven does.
-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Cordova WP8: switching to Newtonsoft.Json

[Jesse]

Nikhil, that pull request does not resolve this. Using
DataContractJsonSerializer
will fail for nested objects.
There is no guarantee that jsonHeaders is just a dictionary of
string,string.
In fact, I'm pretty sure this test will fail :
https://github.com/apache/cordova-plugin-file-transfer/blob/master/tests/tests.js#L856





@purplecabbage
risingj.com

On Thu, Mar 26, 2015 at 10:26 AM, Nikhil Khandelwal 
wrote:

> The main use case for Newtonsoft.Json has been resolved through another
> implementation approach in this PR:
> https://github.com/apache/cordova-plugin-file-transfer/pull/72
>
> -Nikhil
>
> -Original Message-
> From: Carlos Santana [mailto:csantan...@gmail.com]
> Sent: Thursday, March 26, 2015 9:47 AM
> To: dev@cordova.apache.org
> Subject: Re: Cordova WP8: switching to Newtonsoft.Json
>
> Jesse dumb question, what else is new 8-]
>
> Can we do that Mark pointed out to add a reference to a location where the
> windows project can get the dependency?
> Like adding a nuget dependency entry, and then when app get's compile,
> visual studio takes care of downloading Newtonsoft.Json from nuget
> repository?
>
>
> On Tue, Mar 24, 2015 at 1:38 PM, Jesse  wrote:
>
> > I am looking into this. We need to include source code, as we cannot
> > distribute a dll.
> > The pull-req is definitely dead except for the fact it contain part of
> > this conversation.
> >
> >
> >
> >
> > > On Mar 24, 2015, at 6:37 AM, Ian Clelland 
> > wrote:
> > >
> > > I'm not sure about whether Cordova has any specific policies --
> > > there's
> > no
> > > hard rule that says we can't use third-party code, and even include
> > > it in our distributions (see Cordova-Android and okhttp, for
> > > instance), but we should probably discuss it on-list first.
> > >
> > > There are definitely rules, policies, and guidelines at the Apache
> > > level
> > --
> > > no distribution of binaries, for instance, and there are probably
> > questions
> > > of license interaction as well between Apache and MIT licenses, if
> > > we're combining the code at all.
> > >
> > >
> > >
> > > On Tue, Mar 24, 2015 at 5:04 AM, Sergey Grebnov (Akvelon) <
> > > v-seg...@microsoft.com> wrote:
> > >
> > >> This[1] PR is being opened for a while so let's make a final
> > >> decision if we switch to Newtonsoft.Json  or reject it.
> > >>
> > >> The idea of adding Newtonsoft.Json (MIT license) [1] looks good to
> > >> me
> > and
> > >> I can quickly add necessary improvements to make sure everything
> > >> looks
> > good
> > >> and works - as per mobile spec tests there are no new issues found.
> > >>
> > >> But I'm not sure about our policies regarding adding new third
> > >> party dependencies. Should it be discussed/voted here before merge?
> > >> Does it documented somewhere?
> > >>
> > >> PS. If we go w/ Newtonsoft.Json   I propose to just add reference to
> > >> compiled dll and not to keep source code due to size(200kb vs 19mb)
> > >> and compile time reasons.
> > >
> > > Distributing the .dll without the source will *definitely* be a
> problem.
> > > Distributing the .dll with the source *might* be a problem. The only
> > > way we've been able to do this in the past (see Gradle and Crosswalk
> > > for two recent examples) is to have a script that the user runs
> > > (even as part of the platform scripts) that downloads the library
> > > from somewhere trusted
> > and
> > > installs it. We can't ship binaries as part of an Apache project.
> > >
> > >
> > >>
> > >> [1] https://github.com/apache/cordova-wp8/pull/62
> > >>
> > >> Thx!
> > >> Sergey
> > >>
> > >>
> > >> ---
> > >> -- 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
> >
> >
>
>
> --
> Carlos Santana
> 
>

RE: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist Plugins Release

[Parashuram N (MS OPEN TECH)]

Should we have to restart the vote thread, now that the tag will change ? 

-Original Message-
From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew Grieve
Sent: Thursday, March 26, 2015 7:41 AM
To: dev
Subject: Re: [VOTE] Cordova-Plugin-Whitelist and 
Cordova-Plugin-Legacy-Whitelist Plugins Release

That'd be pretty sad if it were expected :P.

Totally my bad on this one. I've committed a fix.

On Thu, Mar 26, 2015 at 9:40 AM, Alexander Sorokin (Akvelon) < 
v-als...@microsoft.com> wrote:

> Hi guys,
>
> I am getting the following error when trying to build a project with 
> legacy-whitelist plugin installed for android@4.0.0-dev:
>
> C:\Projects\Cordova\mobspec-android\platforms\android\src\org\apache\cordova\whitelist\LegacyWhitelistPlugin.java:44:
> error: cannot find symbol
> public void handleStartTag(XmlPullParser xml) {
>^
>   symbol: class XmlPullParser
> C:\Projects\Cordova\mobspec-android\platforms\android\src\org\apache\cordova\whitelist\LegacyWhitelistPlugin.java:68:
> error: cannot find symbol
> public void handleEndTag(XmlPullParser xml) {
>  ^
>   symbol: class XmlPullParser
>
>
> Is this expected?
>
> Thanks,
> Alexander Sorokin
>
> -Original Message-
> From: Steven Gill [mailto:stevengil...@gmail.com]
> Sent: Wednesday, March 25, 2015 23:23
> To: dev@cordova.apache.org
> Subject: [VOTE] Cordova-Plugin-Whitelist and 
> Cordova-Plugin-Legacy-Whitelist Plugins Release
>
> Please review and vote on the releases of cordova-plugin-whitelist and 
> cordova-plugin-legacy-whitelist plugins.
>
> Release issue: https://issues.apache.org/jira/browse/CB-8739
>
> The plugins have been published to
> dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-8739/
>
> The packages were published from their corresponding git tags:
> cordova-plugin-whitelist: 1.0.0 (38f5a9fa2c)
> cordova-plugin-legacy-whitelist: 1.0.0 (b4e1b3726a)
>
> Upon a successful vote I will upload the archives to dist/ and upload 
> them to npm.
>
> Voting guidelines:
> https://github.com/apache/cordova-coho/blob/master/docs/release-voting
> .md
>
> Voting will go on for a minimum of 48 hours.
>
> I vote +1:
> * Ran coho audit-license-headers over the relevant repos
> * Ran coho check-license to ensure all dependencies and 
> subdependencies have Apache-compatible licenses
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

RE: Cordova Monthly Hangouts

[Parashuram N (MS OPEN TECH)]

Carlos, you did not miss it, still working on scheduling it :)

Here is the doddle - please respond to this and indicate your availability. 
Since the hangouts usually go to 2 hours, and to keep the number of options 
sane in doddle, I put up 2 hour slots. Let me know if we should make it 1 hour 
slots.

Here is the participation link - http://doodle.com/kydhnyzzwge92hsu 

-Original Message-
From: Carlos Santana [mailto:csantan...@gmail.com] 
Sent: Thursday, March 26, 2015 9:58 AM
To: dev@cordova.apache.org
Subject: Re: Cordova Monthly Hangouts

+1 did I missed the hangout? I would like to attend.

Micha I like the new term "npm-ness" :-)

Yes Android 4.0 is important for us, we are about to start new work and want to 
start with a released one.


On Tue, Mar 24, 2015 at 7:01 PM, tommy-carlos williams 
wrote:

> +1 for package.json discussions
>
> --
> tommy-carlos williams
>
> On 25 March 2015 at 09:18:12, Michal Mocny (mmo...@chromium.org) wrote:
>
> Another topic is discussion of "package.json" based cli workflow, aka 
> leveraging more npm-ness in our tools.
>
> -Michal
>
> On Tue, Mar 24, 2015 at 1:59 PM, Andrew Grieve 
> wrote:
>
> > +1!
> >
> > On Tue, Mar 24, 2015 at 1:23 PM, Jesse  wrote:
> >
> > > +1 asap, thanks Parash!
> > >
> > > We are much more coherent when we meet.
> > >
> > >
> > >
> > > > On Mar 24, 2015, at 10:02 AM, Parashuram N (MS OPEN TECH) <
> > > panar...@microsoft.com> wrote:
> > > >
> > > > Hi,
> > > >
> > > > I was wondering if folks would be interested in doing a hangout 
> > > > to
> > > quickly resolve some of the outstanding issues that we have been
> talking
> > on
> > > the mailing list. I think we could talk about the following
> > > >
> > > >
> > > > * Androind 4.0 release
> > > > * Medic/ParaMedic/Mobile Spec - progress and next steps
> > > > * Finalize Save/Restore discussions
> > > > * ApacheCon ?
> > > >
> > > > I can volunteer to help set this up if we think there are items 
> > > > that
> we
> > > would like to discuss and close on.
> > >
> > > --
> > > --- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > >
> > >
> >
>



--
Carlos Santana

RE: Cordova WP8: switching to Newtonsoft.Json

[Nikhil Khandelwal]

The main use case for Newtonsoft.Json has been resolved through another 
implementation approach in this PR: 
https://github.com/apache/cordova-plugin-file-transfer/pull/72

-Nikhil

-Original Message-
From: Carlos Santana [mailto:csantan...@gmail.com] 
Sent: Thursday, March 26, 2015 9:47 AM
To: dev@cordova.apache.org
Subject: Re: Cordova WP8: switching to Newtonsoft.Json

Jesse dumb question, what else is new 8-]

Can we do that Mark pointed out to add a reference to a location where the 
windows project can get the dependency?
Like adding a nuget dependency entry, and then when app get's compile, visual 
studio takes care of downloading Newtonsoft.Json from nuget repository?


On Tue, Mar 24, 2015 at 1:38 PM, Jesse  wrote:

> I am looking into this. We need to include source code, as we cannot 
> distribute a dll.
> The pull-req is definitely dead except for the fact it contain part of 
> this conversation.
>
>
>
>
> > On Mar 24, 2015, at 6:37 AM, Ian Clelland 
> wrote:
> >
> > I'm not sure about whether Cordova has any specific policies -- 
> > there's
> no
> > hard rule that says we can't use third-party code, and even include 
> > it in our distributions (see Cordova-Android and okhttp, for 
> > instance), but we should probably discuss it on-list first.
> >
> > There are definitely rules, policies, and guidelines at the Apache 
> > level
> --
> > no distribution of binaries, for instance, and there are probably
> questions
> > of license interaction as well between Apache and MIT licenses, if 
> > we're combining the code at all.
> >
> >
> >
> > On Tue, Mar 24, 2015 at 5:04 AM, Sergey Grebnov (Akvelon) < 
> > v-seg...@microsoft.com> wrote:
> >
> >> This[1] PR is being opened for a while so let's make a final 
> >> decision if we switch to Newtonsoft.Json  or reject it.
> >>
> >> The idea of adding Newtonsoft.Json (MIT license) [1] looks good to 
> >> me
> and
> >> I can quickly add necessary improvements to make sure everything 
> >> looks
> good
> >> and works - as per mobile spec tests there are no new issues found.
> >>
> >> But I'm not sure about our policies regarding adding new third 
> >> party dependencies. Should it be discussed/voted here before merge? 
> >> Does it documented somewhere?
> >>
> >> PS. If we go w/ Newtonsoft.Json   I propose to just add reference to
> >> compiled dll and not to keep source code due to size(200kb vs 19mb) 
> >> and compile time reasons.
> >
> > Distributing the .dll without the source will *definitely* be a problem.
> > Distributing the .dll with the source *might* be a problem. The only 
> > way we've been able to do this in the past (see Gradle and Crosswalk 
> > for two recent examples) is to have a script that the user runs 
> > (even as part of the platform scripts) that downloads the library 
> > from somewhere trusted
> and
> > installs it. We can't ship binaries as part of an Apache project.
> >
> >
> >>
> >> [1] https://github.com/apache/cordova-wp8/pull/62
> >>
> >> Thx!
> >> Sergey
> >>
> >>
> >> ---
> >> -- 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
>
>


--
Carlos Santana

Re: Setting config.json values

[Shazron]

The help still says CONFIG is an option:
cordova create  [ID [NAME [CONFIG]]] [options] [PLATFORM...]

and config handling seems to still be there..
https://github.com/apache/cordova-lib/blob/cc596a37d77a92665292a5370d660a898217e0cb/cordova-lib/src/cordova/create.js#L41

.. so I think it's a bug. Two things here:
1. this bug
2. PLATFORM is not defined in the create help (I know it should be
obvious, but...)





On Thu, Mar 26, 2015 at 6:57 AM, John M. Wargo  wrote:
> Earlier this month, there was a conversation on this thread about enabling
> auto saving of plugin information to the project's config.json file
> (.cordova/config.json, right?) by setting auto_save_plugins to true in the
> file.
>
> I responded on that thread suggesting that users would be able to set this
> value by passing the configuration value on the command line to the cordova
> create command like so:
>
> cordova create test com.johnwargo.test Test
> {\"auto_save_plugins\":\"true\"}
>
> Shouldn't this be a viable way to enable users to automagically set this
> value?
>
> The problem is that this CLI feature no longer seems to work. Last fall, I
> was able to set the plugin search path using the following:
>
> cordova create test2 com.johnwargo.test2 Test2
> "{\"plugin_search_path\":\"d:/dev\"}"
>
> But I just tested it (for a second time on a different system) and that
> capability, passing config.json values on the command line to create, no
> longer seems to be working. Did I miss something? Was this feature removed?
> Or should I submit a ticket on this issue?
>
> Currently the SAP Mobile Platform Hybrid SDK ships as a local installer, the
> plugins aren't in the plugin registry or even github. The plugins have local
> dependencies (the AppUpdate plugin relies upon capabilities exposed by the
> Logon plugin) and the Cordova CLI isn't able to resolve them locally without
> the plugin_search_path being set. We've instructed users to use this
> feature, but now it seems it's not working. Can someone confirm?
>
> Since plugin_search_path is valuable for SAP customers and auto_save_plugins
> is important for this new save/restore capability, is it time to design a
> simpler approach to allow developers to easily set these properties as
> needed for their projects?  It seems that having a create command parameter
> that points to a configuration file containing default settings for the
> project would be a useful thing to have.
>
> What says the group?
> --
> John M. Wargo
> @johnwargo 
> www.johnwargo.com 
> --

-
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-8757 Make paths with --link relative ...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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: Cordova Monthly Hangouts

[Carlos Santana]

+1 did I missed the hangout? I would like to attend.

Micha I like the new term "npm-ness" :-)

Yes Android 4.0 is important for us, we are about to start new work and
want to start with a released one.


On Tue, Mar 24, 2015 at 7:01 PM, tommy-carlos williams 
wrote:

> +1 for package.json discussions
>
> --
> tommy-carlos williams
>
> On 25 March 2015 at 09:18:12, Michal Mocny (mmo...@chromium.org) wrote:
>
> Another topic is discussion of "package.json" based cli workflow, aka
> leveraging more npm-ness in our tools.
>
> -Michal
>
> On Tue, Mar 24, 2015 at 1:59 PM, Andrew Grieve 
> wrote:
>
> > +1!
> >
> > On Tue, Mar 24, 2015 at 1:23 PM, Jesse  wrote:
> >
> > > +1 asap, thanks Parash!
> > >
> > > We are much more coherent when we meet.
> > >
> > >
> > >
> > > > On Mar 24, 2015, at 10:02 AM, Parashuram N (MS OPEN TECH) <
> > > panar...@microsoft.com> wrote:
> > > >
> > > > Hi,
> > > >
> > > > I was wondering if folks would be interested in doing a hangout to
> > > quickly resolve some of the outstanding issues that we have been
> talking
> > on
> > > the mailing list. I think we could talk about the following
> > > >
> > > >
> > > > * Androind 4.0 release
> > > > * Medic/ParaMedic/Mobile Spec - progress and next steps
> > > > * Finalize Save/Restore discussions
> > > > * ApacheCon ?
> > > >
> > > > I can volunteer to help set this up if we think there are items that
> we
> > > would like to discuss and close on.
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > >
> > >
> >
>



-- 
Carlos Santana

Re: Introduction

[Carlos Santana]

Welcome Alex, that's the right attitude we want to see more !!

On Thu, Mar 26, 2015 at 12:51 PM, Jesse  wrote:

> Welcome Alex!
>
>
>
> > On Mar 26, 2015, at 6:57 AM, Andrew Grieve  wrote:
> >
> > Welcome Alex! Thanks for wanting to make Cordova better for everyone! :)
> >
> >
> >
> > On Wed, Mar 25, 2015 at 11:33 PM, Alex Talis
> 
> > wrote:
> >
> >> Hi guys,
> >>
> >> I’m planning to submit a pull request and so following the instructions
> in
> >> the “Process of Contributing” and introducing myself!
> >>
> >> My name is Alex Talis. I’ve been using Cordova to develop apps for iOS
> and
> >> Android since version 0.9, so for quite a while now. On occasion I’ve
> had
> >> to make some quick hacks to Cordova-generated code to make it do what I
> >> needed it to do, but the problem with those is that they usually break
> when
> >> updating Cordova. Now I have a large enough enhancement that I would
> like
> >> to contribute and I hope will be useful to others, so here I am!
> >>
> >>
> >> -
> >> 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
>
>


-- 
Carlos Santana

Re: Introduction

[Jesse]

Welcome Alex!



> On Mar 26, 2015, at 6:57 AM, Andrew Grieve  wrote:
> 
> Welcome Alex! Thanks for wanting to make Cordova better for everyone! :)
> 
> 
> 
> On Wed, Mar 25, 2015 at 11:33 PM, Alex Talis 
> wrote:
> 
>> Hi guys,
>> 
>> I’m planning to submit a pull request and so following the instructions in
>> the “Process of Contributing” and introducing myself!
>> 
>> My name is Alex Talis. I’ve been using Cordova to develop apps for iOS and
>> Android since version 0.9, so for quite a while now. On occasion I’ve had
>> to make some quick hacks to Cordova-generated code to make it do what I
>> needed it to do, but the problem with those is that they usually break when
>> updating Cordova. Now I have a large enough enhancement that I would like
>> to contribute and I hope will be useful to others, so here I am!
>> 
>> 
>> -
>> 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

Re: Cordova WP8: switching to Newtonsoft.Json

[Carlos Santana]

Jesse dumb question, what else is new 8-]

Can we do that Mark pointed out to add a reference to a location where the
windows project can get the dependency?
Like adding a nuget dependency entry, and then when app get's compile,
visual studio takes care of downloading Newtonsoft.Json from nuget
repository?


On Tue, Mar 24, 2015 at 1:38 PM, Jesse  wrote:

> I am looking into this. We need to include source code, as we cannot
> distribute a dll.
> The pull-req is definitely dead except for the fact it contain part of
> this conversation.
>
>
>
>
> > On Mar 24, 2015, at 6:37 AM, Ian Clelland 
> wrote:
> >
> > I'm not sure about whether Cordova has any specific policies -- there's
> no
> > hard rule that says we can't use third-party code, and even include it in
> > our distributions (see Cordova-Android and okhttp, for instance), but we
> > should probably discuss it on-list first.
> >
> > There are definitely rules, policies, and guidelines at the Apache level
> --
> > no distribution of binaries, for instance, and there are probably
> questions
> > of license interaction as well between Apache and MIT licenses, if we're
> > combining the code at all.
> >
> >
> >
> > On Tue, Mar 24, 2015 at 5:04 AM, Sergey Grebnov (Akvelon) <
> > v-seg...@microsoft.com> wrote:
> >
> >> This[1] PR is being opened for a while so let's make a final decision if
> >> we switch to Newtonsoft.Json  or reject it.
> >>
> >> The idea of adding Newtonsoft.Json (MIT license) [1] looks good to me
> and
> >> I can quickly add necessary improvements to make sure everything looks
> good
> >> and works - as per mobile spec tests there are no new issues found.
> >>
> >> But I'm not sure about our policies regarding adding new third party
> >> dependencies. Should it be discussed/voted here before merge? Does it
> >> documented somewhere?
> >>
> >> PS. If we go w/ Newtonsoft.Json   I propose to just add reference to
> >> compiled dll and not to keep source code due to size(200kb vs 19mb) and
> >> compile time reasons.
> >
> > Distributing the .dll without the source will *definitely* be a problem.
> > Distributing the .dll with the source *might* be a problem. The only way
> > we've been able to do this in the past (see Gradle and Crosswalk for two
> > recent examples) is to have a script that the user runs (even as part of
> > the platform scripts) that downloads the library from somewhere trusted
> and
> > installs it. We can't ship binaries as part of an Apache project.
> >
> >
> >>
> >> [1] https://github.com/apache/cordova-wp8/pull/62
> >>
> >> Thx!
> >> Sergey
> >>
> >>
> >> -
> >> 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
>
>


-- 
Carlos Santana

[GitHub] cordova-plugin-file-transfer pull request: CB-8721 Fixes incorrect...

[vladimir-kotikov]

Github user vladimir-kotikov commented on the pull request:


https://github.com/apache/cordova-plugin-file-transfer/pull/72#issuecomment-86594703
  
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-network-information pull request: CB-8185 Use `navi...

[vladimir-kotikov]

Github user vladimir-kotikov commented on the pull request:


https://github.com/apache/cordova-plugin-network-information/pull/25#issuecomment-86594471
  
My bad :dizzy_face: Fixed in 
https://github.com/apache/cordova-plugin-network-information/commit/481bdd93b023f808c301943ac6c541e3633aeee4


---
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-file-transfer pull request: CB-8721 Fixes incorrect...

[mowcixo]

Github user mowcixo commented on the pull request:


https://github.com/apache/cordova-plugin-file-transfer/pull/72#issuecomment-86591690
  
Sure. Done.


---
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-wp8 pull request: JsonHelper testing, and use of Newtonsof...

[mowcixo]

Github user mowcixo commented on the pull request:

https://github.com/apache/cordova-wp8/pull/62#issuecomment-86590836
  
I close this pull request in favor of apache/cordova-plugin-file-transfer#72


---
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-file-transfer pull request: Better header parse wit...

[mowcixo]

Github user mowcixo commented on the pull request:


https://github.com/apache/cordova-plugin-file-transfer/pull/54#issuecomment-86590240
  
I close this pull request in favor of 
apache/cordova-plugin-file-transfer#72.


---
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-file-transfer pull request: Better header parse wit...

[mowcixo]

Github user mowcixo closed the pull request at:

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


---
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-wp8 pull request: JsonHelper testing, and use of Newtonsof...

[mowcixo]

Github user mowcixo closed the pull request at:

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


---
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-file-transfer pull request: CB-8721 Fixes incorrect...

[vladimir-kotikov]

Github user vladimir-kotikov commented on the pull request:


https://github.com/apache/cordova-plugin-file-transfer/pull/72#issuecomment-86588650
  
@mowcixo, if you're ok with this approach, could you please close  
apache/cordova-wp8#62 and the apache/cordova-plugin-file-transfer#54


---
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-8757 Make paths with --link relative ...

[mbektchiev]

GitHub user mbektchiev opened a pull request:

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

CB-8757 Make paths with --link relative to the real project path

Fixes https://issues.apache.org/jira/browse/CB-8757

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

$ git pull https://github.com/Icenium/cordova-lib bektchiev/CB-8757

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

https://github.com/apache/cordova-lib/pull/192.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 #192


commit cb7f38c554cb98644509b7fdca49dd476f95ecd0
Author: Martin Bektchiev 
Date:   2015-03-26T15:09:06Z

CB-8757 Make paths with --link relative to the real project path




---
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] Cordova-WP8 Release 3.8.0

[Parashuram N (MS OPEN TECH)]

About the JSON library, as I understand, only ASF libraries need to be included 
in source form - third party libraries can still be binaries, and we would just 
need to ensure that it does not have IP issues. 

http://www.apache.org/legal/resolved.html

Hence, I think we can include the JSON library. 

-Original Message-
From: Steven Gill [mailto:stevengil...@gmail.com] 
Sent: Wednesday, March 25, 2015 1:34 PM
To: dev@cordova.apache.org
Subject: Re: [DISCUSS] Cordova-WP8 Release 3.8.0

https://issues.apache.org/jira/browse/CB-8748

On Wed, Mar 25, 2015 at 1:18 PM, Jesse  wrote:

> Yeah, let's push out a 3.8.0 for cordova-wp8 We can do a 4.0.0 after I 
> get the JSON fixes in.
>
> @purplecabbage
> risingj.com
>
> On Tue, Mar 24, 2015 at 2:36 PM, Rob Paveza 
> wrote:
>
> > Is it worth breaking out the Newtonsoft.Json additions into a 
> > separate (major 4.0) release and taking these bugfixes into a minor 
> > release until
> we
> > get the legal stuff worked out on the JSON side?
> >
> > -Original Message-
> > From: Jesse [mailto:purplecabb...@gmail.com]
> > Sent: Tuesday, March 24, 2015 11:19 AM
> > To: dev@cordova.apache.org
> > Subject: Re: [DISCUSS] Cordova-WP8 Release 3.8.0
> >
> > I would like to finish off the Newtonsoft.Json additions, and 
> > release a
> > 4.0.0
> > The changes to the JSON namespace in c# potentially break some plugins.
> > The barcode scanner [1] for one, as it is including the dll already.
> > There is also possibly some impact on the file-transfer plugin [2] 
> > however, that is not a breaking change.
> >
> >
> >
> > [1] https://github.com/phonegap-build/PushPlugin
> > [2]
> >
> >
> https://github.com/apache/cordova-plugin-file-transfer/blob/master/src
> /wp/FileTransfer.cs#L319
> >
> >
> >
> > @purplecabbage
> > risingj.com
> >
> > On Tue, Mar 24, 2015 at 10:26 AM, Rob Paveza 
> > 
> > wrote:
> >
> > > It's been three months since the last release of Cordova-WP8.  
> > > There are a number of bugfixes pending, particularly with emulator vs.
> > > deploy-to-device and in scenarios where there are only Phone 8.1 
> > > tools on the machine doing the building.  Also added JSHint, 
> > > improved console
> > logging, etc.
> > >
> > > There is the outstanding issue is that of Newtonsoft.Json (and a 
> > > thread going on about it), but if we can nail that down today 
> > > either way, we can move this along to a vote tomorrow.
> > >
> > > Any other outstanding issues to discuss?
> > >
> > > -Rob
> > >
> >
>

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

[GitHub] cordova-plugin-network-information pull request: CB-8185 Use `navi...

[deadbird1980]

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


https://github.com/apache/cordova-plugin-network-information/pull/25#discussion_r27221938
  
--- Diff: www/network.js ---
@@ -26,7 +26,9 @@ var exec = require('cordova/exec'),
 // Link the onLine property with the Cordova-supplied network info.
 // This works because we clobber the navigator object with our own
 // object in bootstrap.js.
-if (typeof navigator != 'undefined') {
+// Browser platform do not need to define this property, because
+// it is already supported by modern browsers
+if (cordova.platforId !== 'browser' && typeof navigator != 'undefined') {
--- End diff --

I think it should be cordova.platformId here, just found this problem when 
testing latest code on browser.


---
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: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist Plugins Release

[Andrew Grieve]

That'd be pretty sad if it were expected :P.

Totally my bad on this one. I've committed a fix.

On Thu, Mar 26, 2015 at 9:40 AM, Alexander Sorokin (Akvelon) <
v-als...@microsoft.com> wrote:

> Hi guys,
>
> I am getting the following error when trying to build a project with
> legacy-whitelist plugin installed for android@4.0.0-dev:
>
> C:\Projects\Cordova\mobspec-android\platforms\android\src\org\apache\cordova\whitelist\LegacyWhitelistPlugin.java:44:
> error: cannot find symbol
> public void handleStartTag(XmlPullParser xml) {
>^
>   symbol: class XmlPullParser
> C:\Projects\Cordova\mobspec-android\platforms\android\src\org\apache\cordova\whitelist\LegacyWhitelistPlugin.java:68:
> error: cannot find symbol
> public void handleEndTag(XmlPullParser xml) {
>  ^
>   symbol: class XmlPullParser
>
>
> Is this expected?
>
> Thanks,
> Alexander Sorokin
>
> -Original Message-
> From: Steven Gill [mailto:stevengil...@gmail.com]
> Sent: Wednesday, March 25, 2015 23:23
> To: dev@cordova.apache.org
> Subject: [VOTE] Cordova-Plugin-Whitelist and
> Cordova-Plugin-Legacy-Whitelist Plugins Release
>
> Please review and vote on the releases of cordova-plugin-whitelist and
> cordova-plugin-legacy-whitelist plugins.
>
> Release issue: https://issues.apache.org/jira/browse/CB-8739
>
> The plugins have been published to
> dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-8739/
>
> The packages were published from their corresponding git tags:
> cordova-plugin-whitelist: 1.0.0 (38f5a9fa2c)
> cordova-plugin-legacy-whitelist: 1.0.0 (b4e1b3726a)
>
> Upon a successful vote I will upload the archives to dist/ and upload them
> to npm.
>
> Voting guidelines:
> https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
>
> Voting will go on for a minimum of 48 hours.
>
> I vote +1:
> * Ran coho audit-license-headers over the relevant repos
> * Ran coho check-license to ensure all dependencies and subdependencies
> have Apache-compatible licenses
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

[GitHub] cordova-medic pull request: CB-8734 add support for firefoxos

[marti1125]

Github user marti1125 commented on the pull request:

https://github.com/apache/cordova-medic/pull/39#issuecomment-86543253
  
the unique error is about path of mobilespec

G:\cordova-medic (CB-8734)
λ node build_firefoxos.js
G:\cordova-medic\.git G:\cordova-medic
G:\cordova-medic
G:\cordova-medic\bin G:\cordova-medic
G:\cordova-medic
G:\cordova-medic\buildbot-conf G:\cordova-medic
G:\cordova-medic
G:\cordova-medic\node_modules G:\cordova-medic
G:\cordova-medic
G:\cordova-medic\runner G:\cordova-medic
G:\cordova-medic
G:\cordova-medic\src G:\cordova-medic
G:\cordova-medic
[FIREFOXOS ERROR]: (sha: Firefox)
Exception thrown modifying FirefoxOS mobile spec application.
create must have failed as output path does not exist.path  
G:\cordova-medic\mobilespec\platforms\firefoxos
FirefoxOS test prepare failed


---
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: Introduction

[Andrew Grieve]

Welcome Alex! Thanks for wanting to make Cordova better for everyone! :)



On Wed, Mar 25, 2015 at 11:33 PM, Alex Talis 
wrote:

> Hi guys,
>
> I’m planning to submit a pull request and so following the instructions in
> the “Process of Contributing” and introducing myself!
>
> My name is Alex Talis. I’ve been using Cordova to develop apps for iOS and
> Android since version 0.9, so for quite a while now. On occasion I’ve had
> to make some quick hacks to Cordova-generated code to make it do what I
> needed it to do, but the problem with those is that they usually break when
> updating Cordova. Now I have a large enough enhancement that I would like
> to contribute and I hope will be useful to others, so here I am!
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Setting config.json values

[John M. Wargo]

Earlier this month, there was a conversation on this thread about enabling auto 
saving of plugin information to the project's config.json file 
(.cordova/config.json, right?) by setting auto_save_plugins to true in the file.

I responded on that thread suggesting that users would be able to set this 
value by passing the configuration value on the command line to the cordova 
create command like so:

cordova create test com.johnwargo.test Test {\"auto_save_plugins\":\"true\"}

Shouldn't this be a viable way to enable users to automagically set this value?

The problem is that this CLI feature no longer seems to work. Last fall, I was 
able to set the plugin search path using the following:

cordova create test2 com.johnwargo.test2 Test2 
"{\"plugin_search_path\":\"d:/dev\"}"

But I just tested it (for a second time on a different system) and that 
capability, passing config.json values on the command line to create, no longer 
seems to be working. Did I miss something? Was this feature removed?  Or should 
I submit a ticket on this issue?

Currently the SAP Mobile Platform Hybrid SDK ships as a local installer, the 
plugins aren't in the plugin registry or even github. The plugins have local 
dependencies (the AppUpdate plugin relies upon capabilities exposed by the 
Logon plugin) and the Cordova CLI isn't able to resolve them locally without 
the plugin_search_path being set. We've instructed users to use this feature, 
but now it seems it's not working. Can someone confirm?

Since plugin_search_path is valuable for SAP customers and auto_save_plugins is 
important for this new save/restore capability, is it time to design a simpler 
approach to allow developers to easily set these properties as needed for their 
projects?  It seems that having a create command parameter that points to a 
configuration file containing default settings for the project would be a 
useful thing to have.

What says the group?
--
John M. Wargo
@johnwargo 
www.johnwargo.com 
--

[GitHub] cordova-android pull request: CB-8753 Maintain splash screen aspec...

[agrieve]

Github user agrieve commented on the pull request:

https://github.com/apache/cordova-android/pull/168#issuecomment-86521912
  
Great questions.

The statics are meant to prevent multiple splash screens from showing if 
there is more than one CordovaWebView within a project.

`CordovaPreferences.copyIntoIntentExtras(Activity)` - it's legacy.

keep getting preferences from CordovaPreferences - because embedders can 
change these preferences during app start-up, and we want those changes to take 
effect.

New Prefs android only - yes. that's fine. Splash screen already has mostly 
platform-specific prefs :(

Overall comments:
- Randomly, an `onConfigurationChange` hook was just recently added to 
master, so you should just use that instead.
- We aren't planning on doing another release of 3.x branch, so you should 
make these changes to cordova-plugin-splashscreen, which is what will work with 
cordova-android@4.0.x (and with master branch of cordova-android)
- I don't see why anyone would want reloadOnOrientationChange=false, so 
maybe don't make that a preference?
- Might be better to get rid of the LinearLayout, and instead switch to an 
ImageView in both cases


---
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: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist Plugins Release

[Alexander Sorokin (Akvelon)]

Hi guys,

I am getting the following error when trying to build a project with 
legacy-whitelist plugin installed for android@4.0.0-dev:

C:\Projects\Cordova\mobspec-android\platforms\android\src\org\apache\cordova\whitelist\LegacyWhitelistPlugin.java:44:
 error: cannot find symbol
public void handleStartTag(XmlPullParser xml) {
   ^
  symbol: class XmlPullParser
C:\Projects\Cordova\mobspec-android\platforms\android\src\org\apache\cordova\whitelist\LegacyWhitelistPlugin.java:68:
 error: cannot find symbol
public void handleEndTag(XmlPullParser xml) {
 ^
  symbol: class XmlPullParser


Is this expected?

Thanks,
Alexander Sorokin

-Original Message-
From: Steven Gill [mailto:stevengil...@gmail.com] 
Sent: Wednesday, March 25, 2015 23:23
To: dev@cordova.apache.org
Subject: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist 
Plugins Release

Please review and vote on the releases of cordova-plugin-whitelist and 
cordova-plugin-legacy-whitelist plugins.

Release issue: https://issues.apache.org/jira/browse/CB-8739

The plugins have been published to
dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-8739/

The packages were published from their corresponding git tags:
cordova-plugin-whitelist: 1.0.0 (38f5a9fa2c)
cordova-plugin-legacy-whitelist: 1.0.0 (b4e1b3726a)

Upon a successful vote I will upload the archives to dist/ and upload them to 
npm.

Voting guidelines:
https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md

Voting will go on for a minimum of 48 hours.

I vote +1:
* Ran coho audit-license-headers over the relevant repos
* Ran coho check-license to ensure all dependencies and subdependencies have 
Apache-compatible licenses

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

Introduction

[Alex Talis]

Hi guys,

I’m planning to submit a pull request and so following the instructions in the 
“Process of Contributing” and introducing myself!

My name is Alex Talis. I’ve been using Cordova to develop apps for iOS and 
Android since version 0.9, so for quite a while now. On occasion I’ve had to 
make some quick hacks to Cordova-generated code to make it do what I needed it 
to do, but the problem with those is that they usually break when updating 
Cordova. Now I have a large enough enhancement that I would like to contribute 
and I hope will be useful to others, so here I am!


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

[GitHub] cordova-docs pull request: Storage.md link to file plugin readme

[flurdy]

GitHub user flurdy opened a pull request:

https://github.com/apache/cordova-docs/pull/273

Storage.md link to file plugin readme

Storage.md file plugin link changed to point to the projects readme and not 
the doc index as it no longer exists on master.

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

$ git pull https://github.com/flurdy/cordova-docs storage-fileplugin-link

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

https://github.com/apache/cordova-docs/pull/273.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 #273


commit 400c601041b27e98175f973d6972ef0214023b1c
Author: Ivar Abrahamsen 
Date:   2015-03-24T18:45:59Z

Storage.md file plugin link to readme

Storage.md file plugin link changed to point to the projects readme and not 
the doc index as it no longer exists on master.




---
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-file-transfer pull request: CB-8721 Fixes incorrect...

[mowcixo]

Github user mowcixo commented on the pull request:


https://github.com/apache/cordova-plugin-file-transfer/pull/72#issuecomment-86503166
  
I think it's correct. It does not solve the root of the problem, but 
customizing each plugin that uses headers, will be a good solution.

As you say, it will solve the apache/cordova-wp8#62 and the 
apache/cordova-plugin-file-transfer#54 too.


---
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-vibration pull request: CB-7970 Add cordova-plugin-...

[sgrebnov]

Github user sgrebnov commented on the pull request:


https://github.com/apache/cordova-plugin-vibration/pull/25#issuecomment-86446195
  
Rebased, tested, merged


---
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-vibration pull request: CB-7970 Add cordova-plugin-...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-plugin-vibration/pull/25


---
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-inappbrowser pull request: inAppBrowser custom appl...

[jcesarmobile]

Github user jcesarmobile commented on the pull request:


https://github.com/apache/cordova-plugin-inappbrowser/pull/99#issuecomment-86389973
  
I can't understand what this changes try to achieve. Looking at the code it 
launchs an intent to open an external app if the url is defined on the 
config.xml. But that can be done right now using the _system option



---
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-inappbrowser pull request: inAppBrowser custom appl...

[osvso]

GitHub user osvso opened a pull request:

https://github.com/apache/cordova-plugin-inappbrowser/pull/99

inAppBrowser custom application scheme handling on android 

Currently the inAppBrowser doesn't handle custom application scheme making 
it impossible to redirect back to the nativeCode from the embedded webView. The 
system browser handles such redirects without a problem, but due to security 
reasons in some cases usage of embedded view is more advisable.  


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

$ git pull https://github.com/osvso/cordova-plugin-inappbrowser master

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

https://github.com/apache/cordova-plugin-inappbrowser/pull/99.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 #99


commit c21943fa3e48e0e26d26ae31b595ca64d886a46f
Author: Pawel Lewandowski 
Date:   2015-03-26T07:39:03Z

inAppBrowser will allow back-to-the-app-redirections using application's 
custom scheme

scheme can be configured in config.xml using "CustomAppScheme" proererty




---
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-mobile-spec pull request: CB-8742 fixed XMLHttpRequest.spe...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-mobile-spec/pull/125


---
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-inappbrowser pull request: CB-8635 Improves UX on w...

[vladimir-kotikov]

GitHub user vladimir-kotikov opened a pull request:

https://github.com/apache/cordova-plugin-inappbrowser/pull/98

CB-8635 Improves UX on windows platform

This implements some improvements for IAB on window from CB-8635

- Adds `fullscreen` option which allows to open IAB window without gray 
border around it
- Adds ability to apply custom styles to IAB window via `inAppBrowserWrap` 
CSS class (similar to Friefox OS)
- Moves styles for IAB container to separate CSS file

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

$ git pull https://github.com/MSOpenTech/cordova-plugin-inappbrowser CB-8635

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

https://github.com/apache/cordova-plugin-inappbrowser/pull/98.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 #98


commit c541fcf642a47a3ac235cfd26024b73db82c6358
Author: Vladimir Kotikov 
Date:   2015-03-25T12:03:30Z

CB-8635 Improves UX on windows platform

* Adds `fullscreen` option
* Adds ability to apply custom styles to IAB window




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