Currently, the automated test system that we have running (derived from
Medic) uses only the mobilespec tests. It does not yet use tests collected
from the plugins. Its been talked about, but not gone anywhere.
David Kemp
On Wed, Sep 25, 2013 at 7:58 PM, Jesse purplecabb...@gmail.com wrote:
I have merged the dev branches into master on my machine and tagged all of
the plugins. I am planning on merging this into master tomorrow if no one
has any issues.
I will also send a review request for the plugin release blog once I finish
it tomorrow.
Tracking everything at
Sweet! Thanks Steve! Hopefully I didn't break anything :-S
On Thu, Sep 26, 2013 at 8:24 AM, Steven Gill stevengil...@gmail.com wrote:
I have merged the dev branches into master on my machine and tagged all of
the plugins. I am planning on merging this into master tomorrow if no one
has any
What's the challenge of having us use the tests that come with the
individual plugins ?
On Thu, Sep 26, 2013 at 8:13 AM, David Kemp drk...@google.com wrote:
Currently, the automated test system that we have running (derived from
Medic) uses only the mobilespec tests. It does not yet use tests
No I didn't mean implement `plugman --watch`. I don't think plugman
needs a `watch` command.
I was indeed talking about `cordova watch` which should watch for
changes in plugins/ (and maybe in merges/ and www/ as well) and update
the platform projects (prepare?) on every change. I am happy to
TL;DR:
You decided it was easier to ask for forgiveness than permission ;)
On 25 Sep 2013 04:49, Braden Shepherdson bra...@chromium.org wrote:
I get the impression that talking about it internally came out wrong.
Here's what actually happened:
- I started out to fix some bugs, including
I like the idea can we call mobilespec now cordova-voltron and be DRY and
use the tests form the plugins.
Voltron by itself creates an App that tests only core, but as you
use plugman to add plugins to voltron it has more test cases.
It would not be a bad idea to enhance plugin.xml in the future
I am strongly opposed to splitting into one file per platform. We want to
support platform tags in config.xml, which will allow platform-specific
content within the single config.xml.
There are good reasons why the CLI moves the config.xml on some platforms.
On Android, it's really easy to load
If the proposal above is temporary, what's permanent? cordova watch? I want
to make sure we're on the same page.
Braden
On Thu, Sep 26, 2013 at 6:08 AM, Anis KADRI anis.ka...@gmail.com wrote:
No I didn't mean implement `plugman --watch`. I don't think plugman
needs a `watch` command.
I was
FYI, the w3c Device API's Working Group is discussing the idea of adding
strength to the vibration command. more information can be found here:
http://www.w3.org/2009/dap/track/issues/146
Does anyone here have any opinion one way or another on this change and
how it might affect our cordova
Here's an off-the-top-of-my-head sketch of how we might do Voltron tests:
- Add a tag to plugin.xml that names each test file:
test type=automatic src=spec/foo.js name=Foo Automated /
test type=manual src=spec/bar.js name=Foo Manual /
- Add a new command, cordova test (maybe
Forgot about the existence of --link for a second. I think this is a
good solution (not temporary). watch can be an enhancement to this
solution. This might get people like Joe Bowser and other people who
do native dev to give cordova-cli a try (only maybe though).
On Thu, Sep 26, 2013 at 4:25
On Thu, Sep 26, 2013 at 7:18 AM, Braden Shepherdson bra...@chromium.org wrote:
I am strongly opposed to splitting into one file per platform. We want to
support platform tags in config.xml, which will allow platform-specific
content within the single config.xml.
Agreed. I'm not sure if
On Thu, Sep 26, 2013 at 11:03 AM, Joe Bowser bows...@gmail.com wrote:
On Thu, Sep 26, 2013 at 7:18 AM, Braden Shepherdson bra...@chromium.org
wrote:
I am strongly opposed to splitting into one file per platform. We want to
support platform tags in config.xml, which will allow
Branden,
On Android, it's really easy to load XML files from res/xml/foo.xml,
so that's where we put it.
Easy for who?
I think is difficult for web developer to not find it in www/config.xml and
start searching for it
I don't know much about Android so maybe I'm putting my foot in my mouth
I too am opposed to splitting up into multiple files.
The existing config.xml should already be usable cross device without
change.
feature name=Device
param name=android-package value=org.apache.cordova.device.Device /
param name=ios-package value=CDVDevice /
param name=wp-package
On Thu, Sep 26, 2013 at 8:32 AM, Carlos Santana csantan...@gmail.comwrote:
Branden,
On Android, it's really easy to load XML files from res/xml/foo.xml,
so that's where we put it.
Easy for who?
I think is difficult for web developer to not find it in www/config.xml and
start searching
On Thu, Sep 26, 2013 at 8:53 AM, Lindsey Simon els...@gmail.com wrote:
When you say www are you referring to project/www or
project/platform/android/assets/www?
That's the kicker, isn't it? If you're using the CLI, we're talking
project/www, but not everyone uses the CLI, or should use the
Personally, when I refer to the www folder I am referring to the folder as
part of the app package at runtime, which is usually the same as the device
specific project layout.
iOS: AppRoot/www
wp7: AppRoot/www
wp8: AppRoot/www
windows8: AppRoot/www
Android: AppRoot/assets/www ?
The fact that
On Thu, Sep 26, 2013 at 8:32 AM, Carlos Santana csantan...@gmail.com wrote:
Branden,
On Android, it's really easy to load XML files from res/xml/foo.xml,
so that's where we put it.
Easy for who?
Easy for anyone who has to actually maintain this. We have to do this
on startup, and adding
I agree 100% with you Joe enabling developers to make apps that don't suck
And can slow down the PluginManager and make Cordova slower
Just saying because is really easy is sounded a little bit odd to be the
ONLY reason.
But a performance hit is a very good reason to not include the file at
I agree with Jesse proposal.
1. Clean up ghost copies of config.xml
2. Document a single Table in docs/config_ref_index.md.html
Two columns CLI, Not CLI location of config.xml to be edit by user
--Carlos
On Thu, Sep 26, 2013 at 12:03 PM, Jesse purplecabb...@gmail.com wrote:
Personally, when
Would be great to get our plugins aligned with the latest specs. (And now
that we have independent revisiting we can!)
On Thu, Sep 26, 2013 at 4:26 PM, Lisa Seacat DeLuca ldel...@us.ibm.comwrote:
FYI, the w3c Device API's Working Group is discussing the idea of adding
strength to the
I love the idea of a watch command.
On Thu, Sep 26, 2013 at 4:48 PM, Anis KADRI anis.ka...@gmail.com wrote:
Forgot about the existence of --link for a second. I think this is a
good solution (not temporary). watch can be an enhancement to this
solution. This might get people like Joe Bowser
It would be even nicer if any of the platforms we support had APIs to
change the 'volume' of the vibration. :(
@purplecabbage
risingj.com
On Thu, Sep 26, 2013 at 9:58 AM, Brian LeRoux b...@brian.io wrote:
Would be great to get our plugins aligned with the latest specs. (And now
that we have
On Thu Sep 26 10:18 AM, Braden Shepherdson wrote:
I am strongly opposed to splitting into one file per platform. We want to
support
platform tags in config.xml, which will allow platform-specific content
within
the single config.xml.
+1, a single configuration file not in the www/ folder
I also agree to keep a single config.xml and the content as it is today
(not to have platform sections)
just document which one to edit and where is located for the two scenarios
(CLI and not-CLI)
On Thu, Sep 26, 2013 at 1:28 PM, Jonathan Bond-Caron
jbo...@gdesolutions.com wrote:
On Thu Sep
On Thu Sep 26 11:32 AM, Carlos Santana wrote:
Branden,
On Android, it's really easy to load XML files from res/xml/foo.xml, so
that's
where we put it.
Easy for who?
I think is difficult for web developer to not find it in www/config.xml and
start
searching for it
But config.xml
What does a watch mean?
- if I reboot, is it still watched?
I think it would be best to consider separating development from packaging
in your use-case for workflow.
If I am going to develop featureX as a plugin I would :
1. create a project for a single cordova platform, and develop the feature
This discussion is getting a little tangled, with CLI and not-CLI and so
on. I'm trying to bring together the current situation:
In CLI: there is a top level myproject/www/config.xml. This file is
*accidentally* copied into www/config.xml in each platform.
A **totally different file** with the
Just one comment: if I understand this feature correctly, it watches the
top-level www folder and will copy any updated files into the platform files.
My issue with this is that I typically create the project, add the platform
(iOS in my case) and then load the Xcode project. And what is shown
maybe a new file cordova.xml for CLI scenario?
On Thu, Sep 26, 2013 at 1:40 PM, Braden Shepherdson bra...@chromium.orgwrote:
This discussion is getting a little tangled, with CLI and not-CLI and so
on. I'm trying to bring together the current situation:
In CLI: there is a top level
I'm not sure which file you're suggesting that we rename. We have talked in
the past about moving the top-level one out of www and calling it app.xml
or similar. I don't think there are any plans to rename the
platform-specific ones.
Braden
On Thu, Sep 26, 2013 at 1:59 PM, Carlos Santana
I think we can do something outside cordova in grunt using the
grunt-contrib-watch plugin in user land.
If after a while there is a compelling reason to add some portion or
lessons learned to cordova then it can be expose to users.
Also there is the possibility of star experimenting just for
we have one config.xml today lets keep it but lets not add a different file
with same name config.xml in a different location.
maybe I got completely lost in your explanation, sorry :-(
On Thu, Sep 26, 2013 at 2:01 PM, Braden Shepherdson bra...@chromium.orgwrote:
I'm not sure which file
Can someone review this proposed fix?
https://github.com/apache/cordova-plugin-inappbrowser/pull/4
https://issues.apache.org/jira/browse/CB-4926
--
Carlos Santana
csantan...@gmail.com
I don't understand at all what you're suggesting. Nobody is proposing
adding any new files.
We have a bug filed to remove the unused accidental duplicates, other than
that I don't think much is going to change here. At least we'd need a
compelling reason to be moving and renaming files. In the
Branden
Yes I agree with you, I think we are on the same page.
Maybe I got confuse about defaults.xml and A **totally different file**
with the same name is also generated by the
CLI
my bad
On Thu, Sep 26, 2013 at 2:12 PM, Braden Shepherdson bra...@chromium.orgwrote:
I don't understand at
pushed!
@purplecabbage
risingj.com
On Thu, Sep 26, 2013 at 11:07 AM, Carlos Santana csantan...@gmail.comwrote:
Can someone review this proposed fix?
https://github.com/apache/cordova-plugin-inappbrowser/pull/4
https://issues.apache.org/jira/browse/CB-4926
--
Carlos Santana
i have the ZTE Open, i might be able to take a look at that issue
On Sep 25, 2013, at 9:39 AM, Carlos Santana csantan...@gmail.com wrote:
I worked with Jesse on Windows8 with exec.js because it was causing a
memory leak.
Can someone with a firefoxos phone double check that the problem is
I would suggest perhaps a simpler approach, which doesn't add anything new
to cordova-cli/plugman:
- Each plugin ships with a tests js-module, and we document a convention
of where they should live, and what signature it should have (i.e.,
cordova.require('plugin.name.Tests').forEach(...) ).
-
Thank you Lucas
On Thu, Sep 26, 2013 at 2:26 PM, Lucas Holmquist lholm...@redhat.comwrote:
i have the ZTE Open, i might be able to take a look at that issue
On Sep 25, 2013, at 9:39 AM, Carlos Santana csantan...@gmail.com wrote:
I worked with Jesse on Windows8 with exec.js because it was
thank you
On Thu, Sep 26, 2013 at 2:18 PM, Jesse purplecabb...@gmail.com wrote:
pushed!
@purplecabbage
risingj.com
On Thu, Sep 26, 2013 at 11:07 AM, Carlos Santana csantan...@gmail.com
wrote:
Can someone review this proposed fix?
On Thu, Sep 26, 2013 at 2:03 PM, Carlos Santana csantan...@gmail.comwrote:
I think we can do something outside cordova in grunt using the
grunt-contrib-watch plugin in user land.
Agreed. I think watch command should leverage grunt, and is just a future
value-add on top of cordova-cli base
Not sure how Android button labels work, but for Cordova iOS InAppBrowser I
got away with unicode arrows:
https://github.com/apache/cordova-plugin-inappbrowser/blob/b4059a2c683c486f1fb48b182ceb9a48fbc59f6e/src/ios/CDVInAppBrowser.m#L477-L485
On Tue, Sep 24, 2013 at 9:41 AM, Joe Bowser
On Thu, Sep 26, 2013 at 1:39 PM, Jesse purplecabb...@gmail.com wrote:
What does a watch mean?
- if I reboot, is it still watched?
No, this would start a process that lives until you CTRL+C. You could have
it run it in the background, or set it to start of startup, but that would
be using
Can someone review this proposed fix for CB-4928?
https://issues.apache.org/jira/browse/CB-4928
https://github.com/apache/cordova-plugin-media/pull/3
--
Carlos Santana
csantan...@gmail.com
Hey
What did we agree to for supporting the old 2.9.x branch? I'm just
wondering, since we're still getting tons of bugs filed against that.
While most of them are valid in 3.0.x, we probably should be
backporting to 2.9.
Have people been doing this. I've been doing this a bit, but I have
to
I'm about to try to better clarify current behavior in the doc. I understand
when using the CLI to build, the `platforms/*/www/config.xml` files come from
passively copying the web-assets source directory. (Excpetion: Android's ends
up in `platforms/android/assets/www/config.xml`.) If you
Can someone review this?
https://github.com/apache/cordova-plugin-splashscreen/pull/4
https://issues.apache.org/jira/browse/CB-4929
--
Carlos Santana
csantan...@gmail.com
Sounds less than ideal to have to backport, given that we still support the
old workflow with 3.0.
However, I think we did discuss keeping 2.9 maintained while we iron out
3.0 issues. I think we should drop 2.9 as soon as users run out of *valid*
reasons for not upgrading to 3.0, right?
What do
Makes sense to me if taking it out is feasible code-wise. Would encourage
people to fork / fiddle with it themselves as well I think.
Now that we have a registry, we don't need to create new repos for them
(yay!). Maybe just put the plugins within cordova-ios/plugins?
I think we'll need to wait
Hi,
I opened this issue a couple of days ago:
https://issues.apache.org/jira/browse/CB-4902
The issue was the plugin identifiers were changed and the code wasn't
updated with the new identifiers. I opened two pull requests to fix the
issue but I can't figure out how to add them the to the
You mean put it within cordova-labs/plugins? I agree it should start life
there. I don't think plugins should live in the platform repos, even if
they are currently platform specific.
On Thu, Sep 26, 2013 at 4:11 PM, Andrew Grieve agri...@chromium.org wrote:
Makes sense to me if taking it
Wow, this sounds like the problem I just ran into yesterday, so thanks for
fixing it. I'm heading out for today so cannot reviewpull your patches,
but to get the ball rolling for tomorrow, make sure you have signed the
ICLA (http://www.apache.org/licenses/#clas) since It looks like you have
not.
Michal,
Awesome. I've sent in a signed copy of the CLA.
Cheers,
Mike
On 2013-09-26 18:02, Michal Mocny wrote:
Wow, this sounds like the problem I just ran into yesterday, so thanks for
fixing it. I'm heading out for today so cannot reviewpull your patches,
but to get the ball rolling for
Can someone review this code?
[CB-4934] plugin-splashscreen should not show by default on Windows8
https://issues.apache.org/jira/browse/CB-4934
https://github.com/apache/cordova-plugin-splashscreen/pull/5
--
Carlos Santana
csantan...@gmail.com
Hey Michael,
I am not sure how that code got on master, but it shouldn't have been.
We have already taken care of this problem on the dev branch and I am in
the process of merging it today. Issue is at
https://issues.apache.org/jira/browse/CB-4889
Thanks for taking the time and sending pull
@purplecabbage: I have the same workflow but I think the proposed
solution is a step in the right direction. It would allow us to easily
develop platform plugins without having to delete project/create
project/install plugin/uninstall plugin constantly. The plugin would
be packaged (plugin.xml)
merged, thanks
@purplecabbage
risingj.com
On Thu, Sep 26, 2013 at 2:59 PM, Carlos Santana csantan...@gmail.comwrote:
Can someone review this code?
[CB-4934] plugin-splashscreen should not show by default on Windows8
https://issues.apache.org/jira/browse/CB-4934
Can you guys review it at https://reviews.apache.org/r/14356/
I don't think post-review was working properly for me...
Does everyone have access to this? I get:
You don't have access to this review request.
This review request is private. You must be a requested reviewer, either
directly or on a requested group, and have permission to access the
repository in order to view this review request.
On Thu, Sep 26,
I've added https://issues.apache.org/jira/browse/CB-4935
Scheduled this for 3.2.0 - I've already got this working in a branch on
cordova-ios actually (will publish to the branch EOD). I suppose it could
go to cordova-labs?
On Thu, Sep 26, 2013 at 1:56 PM, Michal Mocny mmo...@chromium.org wrote:
You don't have access to this review request.
This review request is private. You must be a requested reviewer, either
directly or on a requested group, and have permission to access the
repository in order to view this review request.
Ya, same here
On 26 September 2013 16:37, Shazron
Re: IDEs: if it is the case that the CLI should not be used along with an IDE,
perhaps the documentation - including Getting Started Guides, etc. - ought to
be much clearer about this. Perhaps a big warning that Xcode project files are
created by the CLI, but they should not be opened and used
Back when we adopted 2.9.0 we were a bit apprehensive about early
adoption of 3.x, so were quite encouraged to read:
We understand and respect that there is a huge community of projects
built on PhoneGap 2.0 series and we will continue to support 2.x in a
long lived branch.
I have no idea how this review stuff works. I will post the blog here
On Sep 26, 2013 4:59 PM, Tim Kim timki...@gmail.com wrote:
You don't have access to this review request.
This review request is private. You must be a requested reviewer, either
directly or on a requested group, and
Today we are doing a big plugin release in preperation for Apache Cordova
3.1.0 which is scheduled to come out next week.
The main change for this release is removing core from all of the plugin ID
fields. This was done to make installing plugins easier in 3.1.0. We are
switching over to using
And one more data point I think worth mentioning: I just went to the main
Cordova site, clicked the top Download button, it took me to the Download
Archive section, and I downloaded the source.zip. I opened it up and it is just
a folder full of zip files, including the zips for each plugin.
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/14356/
---
Review request for cordova.
Repository: cordova-site
Description
---
I
Published the branch on apache/cordova-ios/CB-4935 (see the issue for the
specific branch commit)
Decided to make the settings dynamic, although HideKeyboardFormAccessoryBar
can't be unhidden currently - so that setting is readonly (there's a
TODO: in there)
On Thu, Sep 26, 2013 at 4:48 PM,
Looks like I forgot to click publish on the review page. I also found a
bunch of spelling mistakes I made in my rush to create this. I just fixed
them and uploaded a new diff. The review site should be available for all
now to leave feedback.
On Thu, Sep 26, 2013 at 5:42 PM, Steven Gill
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/14356/
---
(Updated Sept. 27, 2013, 1:09 a.m.)
Review request for cordova.
Changes
We should be supporting 2.9 -- I'm pretty sure we've committed to at least
fixing bugs as they come up.
We never discussed whether we would *only* be fixing things that were
reported on the 2.9 branch, or whether we were going to test the issues
that were reported on 3.x and backport the fixes. I
We should continue to do this for defects for the time being.
On Sep 26, 2013 9:17 PM, Joe Bowser bows...@gmail.com wrote:
Hey
What did we agree to for supporting the old 2.9.x branch? I'm just
wondering, since we're still getting tons of bugs filed against that.
While most of them are valid
You can help!
On Sep 27, 2013 2:37 AM, Smith, Peter pet...@fast.au.fujitsu.com wrote:
Back when we adopted 2.9.0 we were a bit apprehensive about early
adoption of 3.x, so were quite encouraged to read:
We understand and respect that there is a huge community of projects
built on PhoneGap
+1
On Sep 26, 2013 11:04 PM, Michal Mocny mmo...@chromium.org wrote:
You mean put it within cordova-labs/plugins? I agree it should start life
there. I don't think plugins should live in the platform repos, even if
they are currently platform specific.
On Thu, Sep 26, 2013 at 4:11 PM,
On Fri, Sep 27, 2013 at 12:11 AM, Anis KADRI anis.ka...@gmail.com wrote:
As far as IDEs, the answer is simple. You should not use IDEs and
cordova-cli at the same time. Until IDEs are aware of cordova-cli
there is no point in creating projects with cordova-cli because
everything gets blown on
Plugins are ready to be published. I did plugman adduser. Can't publish
plugins yet. Guessing Anis has to give me permission.
On Tue, Sep 17, 2013 at 6:10 PM, Andrew Grieve agri...@chromium.org wrote:
The ability to clone from a branch/tag already exists. It didn't for 3.0,
but was added
Alright I'll add it to the
https://github.com/apache/cordova-labs/tree/plugins branch
On Thu, Sep 26, 2013 at 7:30 PM, Brian LeRoux b...@brian.io wrote:
+1
On Sep 26, 2013 11:04 PM, Michal Mocny mmo...@chromium.org wrote:
You mean put it within cordova-labs/plugins? I agree it should
80 matches
Mail list logo
