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 sp
Crosswalk engine plugin is expected to work with upcoming Cordova Android 4.0.0
release.
As I investigate, there are some issues need to be fixed:
1. Update the README.md of cordova-crosswalk-engine. E.g no fetch_libs.sh
anymore. I managed to create a PR for this:
https://github.com/MobileChro
Github user eymorale closed the pull request at:
https://github.com/apache/cordova-plugin-legacy-whitelist/pull/1
---
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,
On Tue, Mar 24, 2015 at 6:15 AM, Hu, Ningxin wrote:
> Crosswalk engine plugin is expected to work with upcoming Cordova Android
> 4.0.0 release.
>
> As I investigate, there are some issues need to be fixed:
> 1. Update the README.md of cordova-crosswalk-engine. E.g no fetch_libs.sh
> anymore. I
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, polici
We should definitely do that -- and I think we should release them
simultaneously with cordova-app-hello-world, since it now references
cordova-plugin-whitelist by that name (I had to install it from local git
repo, but it still wasn't a perfectly smooth experience).
On Mon, Mar 23, 2015 at 7:18 P
Currently, version info is not saved for plugins in the fetch.json. That
needs to be added so that plugin version can be saved in the config.xml. It
should follow what 'cordova platform save' does. I created a jira item for
this: https://issues.apache.org/jira/browse/CB-8733 and opened a pull
req
Is that a dupe of https://issues.apache.org/jira/browse/CB-8594?
On Tue, Mar 24, 2015 at 10:19 AM, Edna Y Morales wrote:
>
>
> Currently, version info is not saved for plugins in the fetch.json. That
> needs to be added so that plugin version can be saved in the config.xml. It
> should follow wha
Ah yes. Looks like it.
Thanks,
Edna Morales
From: Raymond Camden
To: dev@cordova.apache.org
Date: 03/24/2015 11:30 AM
Subject:Re: 'cordova plugin save' should also save plugin versions
Is that a dupe of https://issues.apache.org/jira/browse/CB-8594?
On Tue, Mar 24, 2015 at
GitHub user tlancina opened a pull request:
https://github.com/apache/cordova-android/pull/165
CB-7085 add onConfigurationChanged hook for plugins
Hey @agrieve if you don't mind taking a look at this when you get a chance,
I just copied the format of onResume, minus sending a JS eve
They are related but not same.
CB-8594 asks to save the plugin version information during "cordova plugin
add --save". Right now we do not save version unless the command is
"cordova plugin add --save --shrinkwrap". This behaviour allows plugins to
be restored to the latest possible version availa
Hey
So, right now our current Battery Plugin on Android is actually considered
harmful to devices and shouldn't be used. It seems that the Chrome team
has implemented the Battery Spec in Chromium 38. This can be tested with
this simple JSBin here:
http://jsbin.com/battery-status-test
The probl
Github user axemclion commented on the pull request:
https://github.com/apache/cordova-browser/pull/9#issuecomment-85595175
@purplecabbage @jsoref Ping. Wanted your opinions on the question above. I
was thinking about the relevance of Cordova serve, given that we have cordova
browser
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
+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)
> 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
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.
Ther
Can we drop our support for the battery plugin entirely? Let the community take
over if they want it?
I would rank it very low in use among our supported plugins, but it does
probably still need to exist.
> On Mar 24, 2015, at 9:46 AM, Joe Bowser wrote:
>
> Hey
>
> So, right now our curren
Github user asfgit closed the pull request at:
https://github.com/apache/cordova-android/pull/165
---
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 featur
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 polic
Welcome!
On Fri, Mar 20, 2015 at 3:20 PM, Shazron wrote:
> Welcome Karen! Glad to have you on board.
>
> On Fri, Mar 20, 2015 at 12:12 PM, Karen Tran wrote:
> > Hello,
> >
> > My name is Karen. I am a new addition to the Cordova team at IBM and will
> > be focusing on android. I spent the last
Github user robpaveza commented on the pull request:
https://github.com/apache/cordova-lib/pull/187#issuecomment-85617372
@purplecabbage Can we set aside the issue of the Windows 8 deprecation for
this PR? There are still reasons we'll want to target package.appxmanifest
with semver
Woohoo! Glad to hear more are coming!
On Sat, Mar 21, 2015 at 11:51 AM, Ross Gardler (MS OPEN TECH) <
ross.gard...@microsoft.com> wrote:
> Some of my day job colleagues have signed up to organize both a BoF and a
> hack season (not me, although I will be there). The focus will be rolling
> and ge
Welcome aboard!!
2015-03-24 11:47 GMT-06:00 Andrew Grieve :
> Woohoo! Glad to hear more are coming!
>
> On Sat, Mar 21, 2015 at 11:51 AM, Ross Gardler (MS OPEN TECH) <
> ross.gard...@microsoft.com> wrote:
>
> > Some of my day job colleagues have signed up to organize both a BoF and a
> > hack sea
Totally agree with your concern, and on Android master / tools master this
is already fixed. When Android 4.0.0 ships (and is the case with master
right now), Android Studio will work out-of-the-box without the need for a
command-line build.
On Mon, Mar 23, 2015 at 1:37 PM, Nell Gawor wrote:
> I
Welcome aboard!! (as usual, I'm messing things here lol)
2015-03-24 11:45 GMT-06:00 Andrew Grieve :
> Welcome!
>
> On Fri, Mar 20, 2015 at 3:20 PM, Shazron wrote:
>
> > Welcome Karen! Glad to have you on board.
> >
> > On Fri, Mar 20, 2015 at 12:12 PM, Karen Tran wrote:
> > > Hello,
> > >
> > >
Github user agrieve commented on the pull request:
https://github.com/apache/cordova-plugin-network-information/pull/26#issuecomment-85620698
I'd prefer not to open up the internals of the plugin, as that would
increase the maintenance burden by broadening its API. It's not very big,
+1! Excited to have some npm-only plugins!
On Tue, Mar 24, 2015 at 9:42 AM, Ian Clelland
wrote:
> We should definitely do that -- and I think we should release them
> simultaneously with cordova-app-hello-world, since it now references
> cordova-plugin-whitelist by that name (I had to install it
Could this be fixed on plugman's side with git clone --depth 1?
On Tue, Mar 24, 2015 at 9:02 AM, Ian Clelland
wrote:
> On Tue, Mar 24, 2015 at 6:15 AM, Hu, Ningxin wrote:
>
> > Crosswalk engine plugin is expected to work with upcoming Cordova Android
> > 4.0.0 release.
> >
> > As I investigate,
+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
On Tue, Mar 24, 2015 at 11:49 AM, Gorkem Ercan
wrote:
> They are related but not same.
>
> CB-8594 asks to save the plugin version information during "cordova plugin
> add --save". Right now we do not save version unless the command is
> "cordova plugin add --save --shrinkwrap". This behaviour al
Github user purplecabbage commented on the pull request:
https://github.com/apache/cordova-lib/pull/187#issuecomment-85626756
I am okay with setting aside the deprecation discussion.
Does the renaming of target->deviceTarget have any impact outside this pull
request?
---
If your
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 there a timing issue here? How can a plugin be published to npm when there
is no tools release that will fetch from npm?
Leo
-Original Message-
From: iclell...@google.com [mailto:iclell...@google.com] On Behalf Of Ian
Clelland
Sent: Tuesday, March 24, 2015 6:42 AM
To: dev@cordova.ap
I think the problem here is shrinkwrap behaviour is the expected because
platforms behave that way. I guess we could just make shrinkwrap default
and change the flag to --noshrinkwrap.
--
Gorkem
On 24 Mar 2015, at 13:58, Andrew Grieve wrote:
On Tue, Mar 24, 2015 at 11:49 AM, Gorkem Ercan
wro
Github user agrieve commented on the pull request:
https://github.com/apache/cordova-plugin-splashscreen/pull/40#issuecomment-85662478
The next version of the plugin will be installable by this name, it's just
not working yet.
---
If your project is set up for it, you can reply to t
+1 for making the shrinkwrap as the default for the ‹save.
This makes sure the users will restore the same version they saved before.
Byoungro So
SSG / DPD / Mobile Computing and Compilers
Intel Corporation
On 3/24/15, 12:31 PM, "Gorkem Ercan" wrote:
>
>I think the problem here is shrinkwr
Github user dblotsky commented on the pull request:
https://github.com/apache/cordova-medic/pull/39#issuecomment-85664065
Yep, that is expected. Unfortunately the new medic code still has some
baggage from the old design that has not yet been refactored. Specifically,
there is a [conf
Do you mean dropping support only for Android, or dropping the plugin
altogether? On some platforms it may still be relevant.
-Original Message-
From: Jesse [mailto:purplecabb...@gmail.com]
Sent: Tuesday, March 24, 2015 10:31 AM
To: dev@cordova.apache.org
Subject: Re: [Android] Proposal:
Dropping support for Android was my initial proposal, but I'm fine with
either.
On Tue, Mar 24, 2015, 12:44 PM Dmitry Blotsky
wrote:
> Do you mean dropping support only for Android, or dropping the plugin
> altogether? On some platforms it may still be relevant.
>
> -Original Message-
>
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 hang
Thank you Tim for the brief explanation! ;)
I agree with all your summary points.
Some more 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
I am suggesting we drop support completely, letting the community take it
over, and we just quietly step back.
Yes it may be relevant on other platforms, but how relevant/important is
it?, and how much is it likely to change?
@purplecabbage
risingj.com
On Tue, Mar 24, 2015 at 12:45 PM, Joe Bowse
I'm in favor of alignment of 'plugin save' behavior with npm's as we expect
developers to already familiar with that and in future, we plan to move to npm.
I liked Andrew's idea of adding a specific version with allowing minor version
upgrades to be automatic.
As for shrink wrapping, for npm th
Leo, the whitelist plugin will only start being used after the next tools
release. So timing should be fine.
Andrew, I did a quick grep search for org.apache.cordova for both whitelist
plugins. Do any of these values need to be updated before releasing?
cordova-plugin-whitelist
grep -R "org.apach
Definitely agree with alignment with npm's save! :D
On Tue, Mar 24, 2015 at 1:46 PM, Nikhil Khandelwal
wrote:
> I'm in favor of alignment of 'plugin save' behavior with npm's as we
> expect developers to already familiar with that and in future, we plan to
> move to npm.
>
> I liked Andrew's ide
Github user purplecabbage commented on the pull request:
https://github.com/apache/cordova-browser/pull/9#issuecomment-85704380
Yeah, I think it best to merge this now, and refactor out to a common
module later.
Please rebase.
---
If your project is set up for it, you can reply t
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, 20
Github user robpaveza commented on the pull request:
https://github.com/apache/cordova-lib/pull/187#issuecomment-85706497
Re: target->deviceTarget: No, all the tests pass, etc. Since I already did
the merge/rebase, I can't really back out the change, but I'll definitely keep
things l
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 whe
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 ha
Another +1 to do-as-npm-does. Both because of existing developer
expectations, and because the trend is to move towards npm-isms and it
would be a disservice down the road to change the behaviour. Any fork from
what npm does should have a strong reason, and not just a
prefer-it-this-way, imho.
-
+1 from me too (always save version, and allow automatic minor version
upgrades).
Gorkem - I'm currently doing some work in this area - I'm happy to make this
change while I'm there.
From: Steven Gill [stevengil...@gmail.com]
Sent: Wednesday, March 25, 2
Github user TimBarham commented on the pull request:
https://github.com/apache/cordova-browser/pull/9#issuecomment-85727710
I'll take care of rebasing. 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 proje
+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 G
On 24 Mar 2015, at 18:38, Tim Barham wrote:
+1 from me too (always save version, and allow automatic minor version
upgrades).
I like Andrew's idea, my only concern is implementing only a portion of
the semver syntax. I personally would assume full semver support after
seeing "^1.2.3" notat
Let's just update the README to state that "the battery plugin is a plugin
that uses your battery" :)
Only half joking... probably would be minimal effort and enough to just add
a warning about this and do nothing more.
On Tue, Mar 24, 2015 at 3:59 PM, Jesse wrote:
> I am suggesting we drop sup
that grep looks fine to me.
On Tue, Mar 24, 2015 at 5:13 PM, Steven Gill wrote:
> Leo, the whitelist plugin will only start being used after the next tools
> release. So timing should be fine.
>
> Andrew, I did a quick grep search for org.apache.cordova for both whitelist
> plugins. Do any of th
On Tue, Mar 24, 2015 at 7:48 PM, Gorkem Ercan
wrote:
>
>
> On 24 Mar 2015, at 18:38, Tim Barham wrote:
>
> +1 from me too (always save version, and allow automatic minor version
>> upgrades).
>>
>> I like Andrew's idea, my only concern is implementing only a portion of
> the semver syntax. I pe
GitHub user TimBarham opened a pull request:
https://github.com/apache/cordova-lib/pull/190
CB-8737 Available platforms list includes extraneous values.
Using the latest sources, if you list available platforms the output
includes two extraneous values (`getPlatformProject` and
`Pl
Github user TimBarham commented on the pull request:
https://github.com/apache/cordova-lib/pull/190#issuecomment-85786656
@kamrik would you be able to take a look at this? Thanks!
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as
Agreed - everything looks good there.
On Tue, Mar 24, 2015 at 8:43 PM, Andrew Grieve wrote:
> that grep looks fine to me.
>
> On Tue, Mar 24, 2015 at 5:13 PM, Steven Gill
> wrote:
>
> > Leo, the whitelist plugin will only start being used after the next tools
> > release. So timing should be fi
On Tue, Mar 24, 2015 at 11:46 AM, Joe Bowser wrote:
> Hey
>
> So, right now our current Battery Plugin on Android is actually considered
> harmful to devices and shouldn't be used. It seems that the Chrome team
Um, really? I've never heard this. There's nothing on the plugin doc
page about it be
On Tue, Mar 24, 2015 at 7:26 PM Raymond Camden
wrote:
> On Tue, Mar 24, 2015 at 11:46 AM, Joe Bowser wrote:
> > Hey
> >
> > So, right now our current Battery Plugin on Android is actually
> considered
> > harmful to devices and shouldn't be used. It seems that the Chrome team
>
> Um, really? I'
Github user TimBarham commented on the pull request:
https://github.com/apache/cordova-browser/pull/9#issuecomment-85797578
Grrr... I merged instead of rebasing. Are we ok with that?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub
On Tue, Mar 24, 2015 at 9:37 PM, Joe Bowser wrote:
> If you use the Battery plugin on Android, it will drain your battery. It's
> been a known issue for almost a year, and there's been this issue in JIRA:
>
> https://issues.apache.org/jira/browse/CB-6838
I'd like to think I'm a pretty involved u
GitHub user jpchase opened a pull request:
https://github.com/apache/cordova-docs/pull/272
CB-8715 Update docs for whitelist changes
- Update Whitelist guide for changes in cordova-android 4.0.0 and
cordova-ios 4.0.0
- Link guide to cordova-plugin-whitelist for detailed document
GitHub user jpchase opened a pull request:
https://github.com/apache/cordova-android/pull/166
CB-8715 Update comments to match whitelist code
- Comments on various methods were confusing and out of sync with current
implementation
You can merge this pull request into a Git reposito
..Also with the move to put plugins in npm, I think we would be directly
using npm's resolution of the version?
On Tue, Mar 24, 2015 at 8:48 PM, Andrew Grieve wrote:
> On Tue, Mar 24, 2015 at 7:48 PM, Gorkem Ercan
> wrote:
>
> >
> >
> > On 24 Mar 2015, at 18:38, Tim Barham wrote:
> >
> > +1 fr
Raymond, I think that was Joe's point in the original email. He is saying
we should finally do something about it :P
On Tue, Mar 24, 2015 at 10:47 PM, Raymond Camden
wrote:
> On Tue, Mar 24, 2015 at 9:37 PM, Joe Bowser wrote:
> > If you use the Battery plugin on Android, it will drain your bat
..and regarding the release process, thats not the reason this wasn't done.
We release plugins in a bulk process and its not much work to add an update
to this one. Just no one made the documentation updates to master yet.
On Wed, Mar 25, 2015 at 12:02 AM, Michal Mocny wrote:
> Raymond, I thin
GitHub user TimBarham opened a pull request:
https://github.com/apache/cordova-lib/pull/191
CB-8596 Expose APIs to retrieve platforms and plugins from config.xml
Provides third parties access to platform and plugin information stored in
`config.xml` without having to go through Conf
Github user TimBarham commented on the pull request:
https://github.com/apache/cordova-browser/pull/9#issuecomment-85841367
Ok, I've cleaned it up. It's ready to merge now.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well.
https://github.com/apache/cordova-plugin-battery-status/commit/16740d612db8dec22fd34ca26a9302abb6d63b1b
@purplecabbage
risingj.com
On Tue, Mar 24, 2015 at 9:03 PM, Michal Mocny wrote:
> ..and regarding the release process, thats not the reason this wasn't done.
>
> We release plugins in a bulk
>
> Could this be fixed on plugman's side with git clone --depth 1?
It still downloads 63MB.
In my experiment, I delete all unused branches, tags, and remove related git
objects. It can shrink the repo to 340KB with full history of master branch.
There is a good reference for git repo shrinkin
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
75 matches
Mail list logo
