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,
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
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:
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
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
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,
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 agri...@chromium.org wrote:
+1!
On Tue, Mar 24, 2015 at 1:23 PM, Jesse purplecabb...@gmail.com wrote:
+1 asap, thanks Parash!
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
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,
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
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 available
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
Ah yes. Looks like it.
Thanks,
Edna Morales
From: Raymond Camden raymondcam...@gmail.com
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 7:48 PM, Gorkem Ercan gorkem.er...@gmail.com
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
Agreed - everything looks good there.
On Tue, Mar 24, 2015 at 8:43 PM, Andrew Grieve agri...@chromium.org wrote:
that grep looks fine to me.
On Tue, Mar 24, 2015 at 5:13 PM, Steven Gill stevengil...@gmail.com
wrote:
Leo, the whitelist plugin will only start being used after the next tools
On Tue, Mar 24, 2015 at 11:46 AM, Joe Bowser bows...@gmail.com 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
On Tue, Mar 24, 2015 at 7:26 PM Raymond Camden raymondcam...@gmail.com
wrote:
On Tue, Mar 24, 2015 at 11:46 AM, Joe Bowser bows...@gmail.com 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
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
..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 agri...@chromium.org wrote:
On Tue, Mar 24, 2015 at 7:48 PM, Gorkem Ercan gorkem.er...@gmail.com
wrote:
On 24 Mar 2015, at
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 raymondcam...@gmail.com
wrote:
On Tue, Mar 24, 2015 at 9:37 PM, Joe Bowser bows...@gmail.com wrote:
If you use the Battery
that grep looks fine to me.
On Tue, Mar 24, 2015 at 5:13 PM, Steven Gill stevengil...@gmail.com 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
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
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
..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 mmo...@chromium.org
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
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
https://github.com/apache/cordova-plugin-battery-status/commit/16740d612db8dec22fd34ca26a9302abb6d63b1b
@purplecabbage
risingj.com
On Tue, Mar 24, 2015 at 9:03 PM, Michal Mocny mmo...@chromium.org wrote:
..and regarding the release process, thats not the reason this wasn't done.
We release
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
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.
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
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
+1!
On Tue, Mar 24, 2015 at 1:23 PM, Jesse purplecabb...@gmail.com 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
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
+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
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
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
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.
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 bows...@gmail.com wrote:
Hey
So, right
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
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:
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
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
+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 gorkem.er...@gmail.com wrote:
I think the
Dropping support for Android was my initial proposal, but I'm fine with
either.
On Tue, Mar 24, 2015, 12:44 PM Dmitry Blotsky dblot...@microsoft.com
wrote:
Do you mean dropping support only for Android, or dropping the plugin
altogether? On some platforms it may still be relevant.
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
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
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 eymor...@us.ibm.com 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
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
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
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
Welcome!
On Fri, Mar 20, 2015 at 3:20 PM, Shazron shaz...@gmail.com wrote:
Welcome Karen! Glad to have you on board.
On Fri, Mar 20, 2015 at 12:12 PM, Karen Tran ktop...@gmail.com wrote:
Hello,
My name is Karen. I am a new addition to the Cordova team at IBM and will
be focusing on
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
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,
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
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 iclell...@chromium.org wrote:
I'm not sure about whether Cordova
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
Welcome aboard!!
2015-03-24 11:47 GMT-06:00 Andrew Grieve agri...@chromium.org:
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
+1! Excited to have some npm-only plugins!
On Tue, Mar 24, 2015 at 9:42 AM, Ian Clelland iclell...@chromium.org
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
Could this be fixed on plugman's side with git clone --depth 1?
On Tue, Mar 24, 2015 at 9:02 AM, Ian Clelland iclell...@chromium.org
wrote:
On Tue, Mar 24, 2015 at 6:15 AM, Hu, Ningxin ningxin...@intel.com wrote:
Crosswalk engine plugin is expected to work with upcoming Cordova Android
On Tue, Mar 24, 2015 at 11:49 AM, Gorkem Ercan gorkem.er...@gmail.com
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.
Definitely agree with alignment with npm's save! :D
On Tue, Mar 24, 2015 at 1:46 PM, Nikhil Khandelwal nikhi...@microsoft.com
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
63 matches
Mail list logo
