Re: Medic status and plans
It would not be a clean merge, there are considerable differences. I started with medic, but many parts have been replaced. My repo contains many elements and structure from the original though. Because the overall project structure changed a great deal with 3.0, it was going to be a lot of work to rebuild and fix the git monitor, web view and build administration that was in Medic. Since that was available out of the box elsewhere, it made more sense to use an existing opensource tool for those elements. All of the deployment pieces of medic are still used, just as command line elements instead of being called directly. On Thu, Oct 10, 2013 at 6:09 PM, Lorin Beer lorin.beer@gmail.comwrote: and I do not believe there is any common history between the apache medic repo and David's bb-test repo On Thu, Oct 10, 2013 at 3:07 PM, Anis KADRI anis.ka...@gmail.com wrote: You can't force push to apache :-/ On Thu, Oct 10, 2013 at 1:40 PM, Brian LeRoux b...@brian.io wrote: Kind of a chicken/egg problem. Will this cleanly merge or should we just force push it in? On Thu, Oct 10, 2013 at 7:42 AM, David Kemp drk...@google.com wrote: I'm happy to put the bb-test code into the official repo. I was hoping to do that soon but I do not think I am an official committer yet. As for USB hubs, the 2.1A one that I picked up has recently stopped working on the 2.1A port. I need to get it returned and replaced, but probably cannot recommend it right now since the first one stopped working right after only about 3 weeks. When it was working it was awesome. Keeping iPads and tablets charged is definitely the hard part. Pretty much all the phones happily stay charged on a 500mA USB port. On Thu, Oct 10, 2013 at 10:07 AM, Mike Billau mike.bil...@gmail.com wrote: Hi Sergey, We have been using David's Medic++ over here without too many issues. (Moving the master to a linux box was key.) The setup was pretty easy once you get Buildbot installed. I'm not sure how much effort it would take to add Windows platforms support, but it doesn't seem like that much. I think that you pretty much just need to follow the examples of the other two platforms and write BuildBot commands (in Python) to shell out to the lower level dev tools to create the project and deploy on your devices: https://github.com/drkemp/bb-test/blob/master/master.cfg#L132 I think the next steps should be something like: 1. Set up a centralized couchDB where we can aggregate data from all of the CI instances. A few months ago I requested a VM for this purpose and it looks like we will get it soon: https://issues.apache.org/jira/browse/INFRA-6422 2. Need a dashboard to view all of the results 3. Set up reporting so that the CI actually gets used (email devs who break builds, possibly IRC bot, would be nice to have a TravisCI style badge on the github pages, etc.) 4. Documentation - there should at least be instructions to help others quickly set up a CI and feed data back to the community (David's readme.md ?) There should also be docs about setting up the device wall, which USB hubs are the best to buy*, etc After those three immediate issues get resolved, I think the CI will start to really provide a lot of value to the community and the project. After that happens, we can talk about more long term goals and feature enhancements. The biggest enhancement I can think of would be the ability to run personal builds against the test devices and get feedback before checking in code. I'm sure there are a lot of other things we can do too, like adding in the rest of the platforms, exercising the native tests, making the system more robust, etc. David, what do you think about pushing your bb-test branch into the cordova-medic repo? We can put Fil's old stuff into a branch for safe keeping, but it seems like we should all be concentrating on the same version of medic, and your buildbot branch is clearly the most complete and working version. Having it in the official repo would make it easier for people to find and contribute to. Mike Billau *For USB hubs, we have been daisy chaining these hubs and have only had charging issues with Samsung tablets: http://www.amazon.com/Plugable-Charger-Adapter-Charges-Kindle/dp/B005P2BY5I David has been using these ones that have a 2.1A port for iPad charging (we haven't yet seen the iPads discharge ): http://www.amazon.ca/Release-Charging-Adapter-3-5-foot-Included/dp/B00B7FLPBU/ref=cm_cr_pr_product_top I think part of the medic documentation should definitely have a discussion about USB hubs because this is a difficult and potentially very
Re: Medic status and plans
Although it is not how I got to where the product is, I can fairly easily make a buildbot branch from the exising medic repo. I will re-create a clean branch of the existing repo with my work. That will then show the common history, David Kemp On Fri, Oct 11, 2013 at 8:12 AM, David Kemp drk...@google.com wrote: It would not be a clean merge, there are considerable differences. I started with medic, but many parts have been replaced. My repo contains many elements and structure from the original though. Because the overall project structure changed a great deal with 3.0, it was going to be a lot of work to rebuild and fix the git monitor, web view and build administration that was in Medic. Since that was available out of the box elsewhere, it made more sense to use an existing opensource tool for those elements. All of the deployment pieces of medic are still used, just as command line elements instead of being called directly. On Thu, Oct 10, 2013 at 6:09 PM, Lorin Beer lorin.beer@gmail.comwrote: and I do not believe there is any common history between the apache medic repo and David's bb-test repo On Thu, Oct 10, 2013 at 3:07 PM, Anis KADRI anis.ka...@gmail.com wrote: You can't force push to apache :-/ On Thu, Oct 10, 2013 at 1:40 PM, Brian LeRoux b...@brian.io wrote: Kind of a chicken/egg problem. Will this cleanly merge or should we just force push it in? On Thu, Oct 10, 2013 at 7:42 AM, David Kemp drk...@google.com wrote: I'm happy to put the bb-test code into the official repo. I was hoping to do that soon but I do not think I am an official committer yet. As for USB hubs, the 2.1A one that I picked up has recently stopped working on the 2.1A port. I need to get it returned and replaced, but probably cannot recommend it right now since the first one stopped working right after only about 3 weeks. When it was working it was awesome. Keeping iPads and tablets charged is definitely the hard part. Pretty much all the phones happily stay charged on a 500mA USB port. On Thu, Oct 10, 2013 at 10:07 AM, Mike Billau mike.bil...@gmail.com wrote: Hi Sergey, We have been using David's Medic++ over here without too many issues. (Moving the master to a linux box was key.) The setup was pretty easy once you get Buildbot installed. I'm not sure how much effort it would take to add Windows platforms support, but it doesn't seem like that much. I think that you pretty much just need to follow the examples of the other two platforms and write BuildBot commands (in Python) to shell out to the lower level dev tools to create the project and deploy on your devices: https://github.com/drkemp/bb-test/blob/master/master.cfg#L132 I think the next steps should be something like: 1. Set up a centralized couchDB where we can aggregate data from all of the CI instances. A few months ago I requested a VM for this purpose and it looks like we will get it soon: https://issues.apache.org/jira/browse/INFRA-6422 2. Need a dashboard to view all of the results 3. Set up reporting so that the CI actually gets used (email devs who break builds, possibly IRC bot, would be nice to have a TravisCI style badge on the github pages, etc.) 4. Documentation - there should at least be instructions to help others quickly set up a CI and feed data back to the community (David's readme.md ?) There should also be docs about setting up the device wall, which USB hubs are the best to buy*, etc After those three immediate issues get resolved, I think the CI will start to really provide a lot of value to the community and the project. After that happens, we can talk about more long term goals and feature enhancements. The biggest enhancement I can think of would be the ability to run personal builds against the test devices and get feedback before checking in code. I'm sure there are a lot of other things we can do too, like adding in the rest of the platforms, exercising the native tests, making the system more robust, etc. David, what do you think about pushing your bb-test branch into the cordova-medic repo? We can put Fil's old stuff into a branch for safe keeping, but it seems like we should all be concentrating on the same version of medic, and your buildbot branch is clearly the most complete and working version. Having it in the official repo would make it easier for people to find and contribute to. Mike Billau *For USB hubs, we have been daisy chaining these hubs and have only had charging issues with Samsung tablets: http://www.amazon.com/Plugable-Charger-Adapter-Charges-Kindle/dp/B005P2BY5I David has been using these ones that have a 2.1A port for
no such file: ~/.cordova\lib\android\cordova\3.1.0\framework\assets\www\cordova.js
Hi, I moved to a new developement machine and installed the latest phonegap using npm -g install phonegap. Then I checked out a phonegap project (3.0) from our git repo. Now I want to build the Android part but get the message below. Is this happening because I never did a phonegap platform add android here? Yes we are checking in the platforms/android directory (which might not be the pure phonegap CLI way to do things) How can I fix this? cheers Axel $ phonegap local build android [phonegap] compiling Android... fs.js:427 return binding.open(pathModule._makeLong(path), stringToFlags(flags), mode); ^ Error: ENOENT, no such file or directory 'C:\Users\ignisvulpis\.cordova\lib\andr oid\cordova\3.1.0\framework\assets\www\cordova.js' at Object.fs.openSync (fs.js:427:18) at Object.fs.readFileSync (fs.js:284:15) at Object.module.exports.update_www (c:\Users\ignisvulpis\AppData\Roaming\np m\node_modules\phonegap\node_modules\cordova\src\metadata\android_parser.js:183: 70) at Object.module.exports.update_project (c:\Users\ignisvulpis\AppData\Roamin g\npm\node_modules\phonegap\node_modules\cordova\src\metadata\android_parser.js: 213:14) at c:\Users\ignisvulpis\AppData\Roaming\npm\node_modules\phonegap\node_modul es\cordova\src\prepare.js:88:32 at c:\Users\ignisvulpis\AppData\Roaming\npm\node_modules\phonegap\node_modul es\cordova\src\lazy_load.js:48:31 at Object.module.exports.custom (c:\Users\ignisvulpis\AppData\Roaming\npm\no de_modules\phonegap\node_modules\cordova\src\lazy_load.js:57:34) at Object.lazy_load [as cordova] (c:\Users\ignisvulpis\AppData\Roaming\npm\n ode_modules\phonegap\node_modules\cordova\src\lazy_load.js:43:24) at Object.module.exports.based_on_config (c:\Users\ignisvulpis\AppData\Roami ng\npm\node_modules\phonegap\node_modules\cordova\src\lazy_load.js:134:28) at c:\Users\ignisvulpis\AppData\Roaming\npm\node_modules\phonegap\node_modul es\cordova\src\prepare.js:81:27 ignisvulpis@NAMENLOS ~/git/phonegap (master)
Re: no such file: ~/.cordova\lib\android\cordova\3.1.0\framework\assets\www\cordova.js
I think that likely is the case. See if creating a dummy project on the same machine fixes it. Clearly a poor design choice. Filed an issue for it: https://issues.apache.org/jira/browse/CB-5063 On Fri, Oct 11, 2013 at 9:32 AM, Axel Nennker ignisvul...@gmail.com wrote: Hi, I moved to a new developement machine and installed the latest phonegap using npm -g install phonegap. Then I checked out a phonegap project (3.0) from our git repo. Now I want to build the Android part but get the message below. Is this happening because I never did a phonegap platform add android here? Yes we are checking in the platforms/android directory (which might not be the pure phonegap CLI way to do things) How can I fix this? cheers Axel $ phonegap local build android [phonegap] compiling Android... fs.js:427 return binding.open(pathModule._makeLong(path), stringToFlags(flags), mode); ^ Error: ENOENT, no such file or directory 'C:\Users\ignisvulpis\.cordova\lib\andr oid\cordova\3.1.0\framework\assets\www\cordova.js' at Object.fs.openSync (fs.js:427:18) at Object.fs.readFileSync (fs.js:284:15) at Object.module.exports.update_www (c:\Users\ignisvulpis\AppData\Roaming\np m\node_modules\phonegap\node_modules\cordova\src\metadata\android_parser.js:183: 70) at Object.module.exports.update_project (c:\Users\ignisvulpis\AppData\Roamin g\npm\node_modules\phonegap\node_modules\cordova\src\metadata\android_parser.js: 213:14) at c:\Users\ignisvulpis\AppData\Roaming\npm\node_modules\phonegap\node_modul es\cordova\src\prepare.js:88:32 at c:\Users\ignisvulpis\AppData\Roaming\npm\node_modules\phonegap\node_modul es\cordova\src\lazy_load.js:48:31 at Object.module.exports.custom (c:\Users\ignisvulpis\AppData\Roaming\npm\no de_modules\phonegap\node_modules\cordova\src\lazy_load.js:57:34) at Object.lazy_load [as cordova] (c:\Users\ignisvulpis\AppData\Roaming\npm\n ode_modules\phonegap\node_modules\cordova\src\lazy_load.js:43:24) at Object.module.exports.based_on_config (c:\Users\ignisvulpis\AppData\Roami ng\npm\node_modules\phonegap\node_modules\cordova\src\lazy_load.js:134:28) at c:\Users\ignisvulpis\AppData\Roaming\npm\node_modules\phonegap\node_modul es\cordova\src\prepare.js:81:27 ignisvulpis@NAMENLOS ~/git/phonegap (master)
Re: [CB-3747] - We need a test video
I might be able to create something new here. What sizes and formats are needed? Would something short in duration work best, or does it need to be longer than ~15 seconds? On Oct 10, 2013, at 9:06 PM, Shazron shaz...@gmail.com wrote: Added https://issues.apache.org/jira/browse/CB-5053
Re: Medic status and plans
That works. Or even just tag and wipe it out, add the new bits. Either way: you should be able to commit directly very soon. =) On Fri, Oct 11, 2013 at 6:15 AM, David Kemp drk...@google.com wrote: Although it is not how I got to where the product is, I can fairly easily make a buildbot branch from the exising medic repo. I will re-create a clean branch of the existing repo with my work. That will then show the common history, David Kemp On Fri, Oct 11, 2013 at 8:12 AM, David Kemp drk...@google.com wrote: It would not be a clean merge, there are considerable differences. I started with medic, but many parts have been replaced. My repo contains many elements and structure from the original though. Because the overall project structure changed a great deal with 3.0, it was going to be a lot of work to rebuild and fix the git monitor, web view and build administration that was in Medic. Since that was available out of the box elsewhere, it made more sense to use an existing opensource tool for those elements. All of the deployment pieces of medic are still used, just as command line elements instead of being called directly. On Thu, Oct 10, 2013 at 6:09 PM, Lorin Beer lorin.beer@gmail.com wrote: and I do not believe there is any common history between the apache medic repo and David's bb-test repo On Thu, Oct 10, 2013 at 3:07 PM, Anis KADRI anis.ka...@gmail.com wrote: You can't force push to apache :-/ On Thu, Oct 10, 2013 at 1:40 PM, Brian LeRoux b...@brian.io wrote: Kind of a chicken/egg problem. Will this cleanly merge or should we just force push it in? On Thu, Oct 10, 2013 at 7:42 AM, David Kemp drk...@google.com wrote: I'm happy to put the bb-test code into the official repo. I was hoping to do that soon but I do not think I am an official committer yet. As for USB hubs, the 2.1A one that I picked up has recently stopped working on the 2.1A port. I need to get it returned and replaced, but probably cannot recommend it right now since the first one stopped working right after only about 3 weeks. When it was working it was awesome. Keeping iPads and tablets charged is definitely the hard part. Pretty much all the phones happily stay charged on a 500mA USB port. On Thu, Oct 10, 2013 at 10:07 AM, Mike Billau mike.bil...@gmail.com wrote: Hi Sergey, We have been using David's Medic++ over here without too many issues. (Moving the master to a linux box was key.) The setup was pretty easy once you get Buildbot installed. I'm not sure how much effort it would take to add Windows platforms support, but it doesn't seem like that much. I think that you pretty much just need to follow the examples of the other two platforms and write BuildBot commands (in Python) to shell out to the lower level dev tools to create the project and deploy on your devices: https://github.com/drkemp/bb-test/blob/master/master.cfg#L132 I think the next steps should be something like: 1. Set up a centralized couchDB where we can aggregate data from all of the CI instances. A few months ago I requested a VM for this purpose and it looks like we will get it soon: https://issues.apache.org/jira/browse/INFRA-6422 2. Need a dashboard to view all of the results 3. Set up reporting so that the CI actually gets used (email devs who break builds, possibly IRC bot, would be nice to have a TravisCI style badge on the github pages, etc.) 4. Documentation - there should at least be instructions to help others quickly set up a CI and feed data back to the community (David's readme.md ?) There should also be docs about setting up the device wall, which USB hubs are the best to buy*, etc After those three immediate issues get resolved, I think the CI will start to really provide a lot of value to the community and the project. After that happens, we can talk about more long term goals and feature enhancements. The biggest enhancement I can think of would be the ability to run personal builds against the test devices and get feedback before checking in code. I'm sure there are a lot of other things we can do too, like adding in the rest of the platforms, exercising the native tests, making the system more robust, etc. David, what do you think about pushing your bb-test branch into the cordova-medic repo? We can put Fil's old stuff into a branch for safe keeping, but it seems like we should all be concentrating on the same version of medic, and your buildbot branch is clearly the most complete and working version. Having it in the official repo would make
Re: mobile-spec and releases: How do we test?
Sorry keep meaning to respond. I like Michal's first step but growing to a
full suite of tools. Are you currently tackling this Braden? I feel like it
is related to the Medic stuff and maybe we should throw one of our guys on
the problem fully.
On Sep 27, 2013 5:10 PM, Braden Shepherdson bra...@chromium.org wrote:
Which one?
On Fri, Sep 27, 2013 at 10:09 AM, Brian LeRoux b...@brian.io wrote:
I really like your proposal as a starting point. Very simple but would
allow for in-app testing as well as on the cmd line if we so wish.
On Fri, Sep 27, 2013 at 3:28 PM, Michal Mocny mmo...@chromium.org
wrote:
I was looking over some old emails from this list on plugin testing,
and
an
idea that was proposed way back was to ship plugin tests as a second
plugin. That way, you can chose to install tests, or not, and know
explicitly if they are being copied into your final project.
An alternative would be to support build targets a la release/debug
and
have target-specific plugin.xml tags (assets, js-modules,
source-file..).
-Michal
On Fri, Sep 27, 2013 at 4:52 AM, Brian LeRoux b...@brian.io wrote:
I think this is basically what we've been proposing for a while now.
On Thu, Sep 26, 2013 at 8:29 PM, Michal Mocny mmo...@chromium.org
wrote:
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(...) ).
- Will need a common way to describe/report results (others have
mentioned TAP).
- Any app is free to run those plugin tests in any which way, but
we
ship a
mobile-spec app which is one opinionated way to do so.
- It attempts to require the test module for each installed
plugin,
runs
them, and aggregates results.
- It could report results to some shared server, allow toggling
of
tests,
etc, but no plugin should know or care about those features.
Using that as a generic base:
- We ship a CDVTests (or whatever) plugin which has a bunch of
library
code for creating tests, and plugins can use it to register their
tests.
- This makes it easier to register manual tests in a common format
for
core
plugins, and prevents code duplication for core auto tests.
- External plugins can chose to use our testing library, or not.
-Michal
On Thu, Sep 26, 2013 at 10:34 AM, Braden Shepherdson
bra...@chromium.org
wrote:
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 prepare-test), that:
- Ignores the top-level www.
- Instead copies in a basic testing index.html similar to the
current
mobile-spec's
- That index reads a file akin to cordova_plugins.js
(cordova_tests.js,
maybe?) generated by the CLI, containing the info from the test
tags.
- It has navigation similar to the current mobile-spec, with
buttons
for the automatic and manual sections. Auto has All and then
each
module,
manual just has the list of modules.
Thoughts?
Braden
On Thu, Sep 26, 2013 at 6:33 AM, Carlos Santana
csantan...@gmail.com
wrote:
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
to
include
information about testing (i.e. Directory containing tests
files,
test
command, etc..)
--Carlos
On Thursday, September 26, 2013, Anis KADRI wrote:
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
javascript:;
wrote:
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
javascript:;
wrote:
Yeah, I have
Re: mobile-spec and releases: How do we test?
I'm throwing something together right now, actually. I'll post my current
progress today so you can take a look.
On Fri, Oct 11, 2013 at 12:41 PM, Brian LeRoux b...@brian.io wrote:
Sorry keep meaning to respond. I like Michal's first step but growing to a
full suite of tools. Are you currently tackling this Braden? I feel like it
is related to the Medic stuff and maybe we should throw one of our guys on
the problem fully.
On Sep 27, 2013 5:10 PM, Braden Shepherdson bra...@chromium.org wrote:
Which one?
On Fri, Sep 27, 2013 at 10:09 AM, Brian LeRoux b...@brian.io wrote:
I really like your proposal as a starting point. Very simple but would
allow for in-app testing as well as on the cmd line if we so wish.
On Fri, Sep 27, 2013 at 3:28 PM, Michal Mocny mmo...@chromium.org
wrote:
I was looking over some old emails from this list on plugin testing,
and
an
idea that was proposed way back was to ship plugin tests as a second
plugin. That way, you can chose to install tests, or not, and know
explicitly if they are being copied into your final project.
An alternative would be to support build targets a la release/debug
and
have target-specific plugin.xml tags (assets, js-modules,
source-file..).
-Michal
On Fri, Sep 27, 2013 at 4:52 AM, Brian LeRoux b...@brian.io wrote:
I think this is basically what we've been proposing for a while
now.
On Thu, Sep 26, 2013 at 8:29 PM, Michal Mocny mmo...@chromium.org
wrote:
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(...) ).
- Will need a common way to describe/report results (others
have
mentioned TAP).
- Any app is free to run those plugin tests in any which way, but
we
ship a
mobile-spec app which is one opinionated way to do so.
- It attempts to require the test module for each installed
plugin,
runs
them, and aggregates results.
- It could report results to some shared server, allow toggling
of
tests,
etc, but no plugin should know or care about those features.
Using that as a generic base:
- We ship a CDVTests (or whatever) plugin which has a bunch of
library
code for creating tests, and plugins can use it to register their
tests.
- This makes it easier to register manual tests in a common
format
for
core
plugins, and prevents code duplication for core auto tests.
- External plugins can chose to use our testing library, or not.
-Michal
On Thu, Sep 26, 2013 at 10:34 AM, Braden Shepherdson
bra...@chromium.org
wrote:
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 prepare-test), that:
- Ignores the top-level www.
- Instead copies in a basic testing index.html similar to
the
current
mobile-spec's
- That index reads a file akin to cordova_plugins.js
(cordova_tests.js,
maybe?) generated by the CLI, containing the info from the
test
tags.
- It has navigation similar to the current mobile-spec,
with
buttons
for the automatic and manual sections. Auto has All and then
each
module,
manual just has the list of modules.
Thoughts?
Braden
On Thu, Sep 26, 2013 at 6:33 AM, Carlos Santana
csantan...@gmail.com
wrote:
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
to
include
information about testing (i.e. Directory containing tests
files,
test
command, etc..)
--Carlos
On Thursday, September 26, 2013, Anis KADRI wrote:
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
javascript:;
wrote:
Currently, the automated test system that we have running
(derived
from
Re: Platforms Meet-up @ Waterloo
+1 would like to come, Red Hat is interested to contribute on platforms as well. -- Gorkem On Wed, Oct 9, 2013 at 10:10 AM, Andrew Grieve agri...@chromium.org wrote: Working via email is fun, but seeing each other in person is fun too! I'd like to invite committers / active contributors who are able to join the Google team for a couple days of work and fun at the Google Waterloo office! When: Oct 29th, 30th (Tuesday, Wednesday) Where: Google Waterloo (http://goo.gl/jI99Fr) Full Address: 151 Charles Street West, Kitchener, Ontario What: Working together + dinner and a social activity evening of the 29th More details: A lot of focus recently has been on CLI/Plugman, so I wanted this meet-up to instead focus on *platforms*. Specifically: - iOS Android Roadmaps (other platforms too depending on who's attending) - Storage locations (CB-285) (oldie but a goldie!) - Accessibility (both IBM and Adobe have mentioned this recently, not sure if there's anything to share / report yet) If you're able to come, please respond to this thread so I can get an idea of numbers. We'll provide food and a work space, but you'll have to figure out how to get here. As always, we'll be sure to not make any decisions without going through the ML. Andrew
Re: mobile-spec and releases: How do we test?
TLDR; I've implemented a plugin testing strategy that requires 0 new
tooling features, can support non-core plugins, and hopefully even support
a variety of methods for running/reporting the test results. Super alpha
preview, but take a look if you like the direction!
NEW: CDVTest Plugin: https://github.com/mmocny/CDVTest
NEW: CordovaTest App: https://github.com/mmocny/CordovaTests
UPDATED: Converted three existing plugins to this new style. Code is on
feature branches of respective repos (cdvtest branch):
org.apache.cordova.device
org.apache.cordova.device-motion
org.chromium.storage
(must clone locally, switch to branch, and plugin add from local path)
Now, any plugin that wants to join in on the fun needs to provide a js-module
src=... name=test / and use this template:
exports.init = function() {
eval(require('org.apache.cordova.test.test').injectJasmineInterface(this,
'this'));
// TESTS GO HERE
describe(..., function() {
it(...);
});
};
(The eval is optional but super useful; it will inject the jasmine
interface into your scope, so you don't have to type jasmine.describe,
jasmine.it, etc. Not sure of any cleaner way to do this.)
STEPS:
1. create a new cordova project
2. import the CordovaTest app into your www
3. add any or all of the above plugins
4. give it a run, and try out the auto tests (all pass on ipad, some still
fail on android)
Lots of work left to do, but hopefully good enough to whet your appetite.
One thing to note, I've attempted to make CDVTest and plugin tests unaware
of the specific jasmine version the app is hosting (so that it can be
swapped without changing all plugins), but it must support the new style
interface for async tests (ie, accept a done callback). This is the style
that node-jasmine uses, mocha uses, and jasmine-2.0 is going to use (I'm
using jasmine 2.0 rc3). This means that core plugin tests require some
code transformations, but the net effect is cleaner tests and more common
style with our node tools' tests.
Manual tests are not implemented yet.
-Michal
On Fri, Oct 11, 2013 at 12:54 PM, Michal Mocny mmo...@chromium.org wrote:
I'm throwing something together right now, actually. I'll post my current
progress today so you can take a look.
On Fri, Oct 11, 2013 at 12:41 PM, Brian LeRoux b...@brian.io wrote:
Sorry keep meaning to respond. I like Michal's first step but growing to a
full suite of tools. Are you currently tackling this Braden? I feel like
it
is related to the Medic stuff and maybe we should throw one of our guys on
the problem fully.
On Sep 27, 2013 5:10 PM, Braden Shepherdson bra...@chromium.org
wrote:
Which one?
On Fri, Sep 27, 2013 at 10:09 AM, Brian LeRoux b...@brian.io wrote:
I really like your proposal as a starting point. Very simple but would
allow for in-app testing as well as on the cmd line if we so wish.
On Fri, Sep 27, 2013 at 3:28 PM, Michal Mocny mmo...@chromium.org
wrote:
I was looking over some old emails from this list on plugin testing,
and
an
idea that was proposed way back was to ship plugin tests as a second
plugin. That way, you can chose to install tests, or not, and know
explicitly if they are being copied into your final project.
An alternative would be to support build targets a la
release/debug
and
have target-specific plugin.xml tags (assets, js-modules,
source-file..).
-Michal
On Fri, Sep 27, 2013 at 4:52 AM, Brian LeRoux b...@brian.io wrote:
I think this is basically what we've been proposing for a while
now.
On Thu, Sep 26, 2013 at 8:29 PM, Michal Mocny
mmo...@chromium.org
wrote:
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(...) ).
- Will need a common way to describe/report results (others
have
mentioned TAP).
- Any app is free to run those plugin tests in any which way,
but
we
ship a
mobile-spec app which is one opinionated way to do so.
- It attempts to require the test module for each installed
plugin,
runs
them, and aggregates results.
- It could report results to some shared server, allow
toggling
of
tests,
etc, but no plugin should know or care about those features.
Using that as a generic base:
- We ship a CDVTests (or whatever) plugin which has a bunch of
library
code for creating tests, and plugins can use it to register
their
tests.
- This makes it easier to register manual tests in a common
format
for
core
plugins, and prevents code duplication for core auto tests.
- External plugins can chose to use our testing
Re: [jira] [Resolved] (CB-4786) Add `owner` command
can you 'pwn' me too? @purplecabbage risingj.com On Fri, Oct 11, 2013 at 4:15 PM, Anis KADRI anis.ka...@gmail.com wrote: done On Thu, Oct 10, 2013 at 7:44 PM, Andrew Grieve agri...@chromium.org wrote: Awesome! Could you add me as an owner for the plugins? On Thu, Oct 10, 2013 at 6:34 PM, Anis Kadri (JIRA) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/CB-4786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anis Kadri resolved CB-4786. Resolution: Fixed [~stevegill] was able to publish all plugins today. The issue is resolved. Add `owner` command --- Key: CB-4786 URL: https://issues.apache.org/jira/browse/CB-4786 Project: Apache Cordova Issue Type: Bug Components: Plugman Affects Versions: 3.0.0 Reporter: Anis Kadri Assignee: Anis Kadri Fix For: 3.1.0 similar to [npm owner|https://npmjs.org/doc/owner.html] -- This message was sent by Atlassian JIRA (v6.1#6144)
Re: [jira] [Resolved] (CB-4786) Add `owner` command
I don't see your user account. You need to create one with `plugman adduser` On Fri, Oct 11, 2013 at 4:21 PM, Jesse purplecabb...@gmail.com wrote: can you 'pwn' me too? @purplecabbage risingj.com On Fri, Oct 11, 2013 at 4:15 PM, Anis KADRI anis.ka...@gmail.com wrote: done On Thu, Oct 10, 2013 at 7:44 PM, Andrew Grieve agri...@chromium.org wrote: Awesome! Could you add me as an owner for the plugins? On Thu, Oct 10, 2013 at 6:34 PM, Anis Kadri (JIRA) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/CB-4786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anis Kadri resolved CB-4786. Resolution: Fixed [~stevegill] was able to publish all plugins today. The issue is resolved. Add `owner` command --- Key: CB-4786 URL: https://issues.apache.org/jira/browse/CB-4786 Project: Apache Cordova Issue Type: Bug Components: Plugman Affects Versions: 3.0.0 Reporter: Anis Kadri Assignee: Anis Kadri Fix For: 3.1.0 similar to [npm owner|https://npmjs.org/doc/owner.html] -- This message was sent by Atlassian JIRA (v6.1#6144)
Re: [jira] [Resolved] (CB-4786) Add `owner` command
done: purplecabbage @purplecabbage risingj.com On Fri, Oct 11, 2013 at 4:23 PM, Anis KADRI anis.ka...@gmail.com wrote: I don't see your user account. You need to create one with `plugman adduser` On Fri, Oct 11, 2013 at 4:21 PM, Jesse purplecabb...@gmail.com wrote: can you 'pwn' me too? @purplecabbage risingj.com On Fri, Oct 11, 2013 at 4:15 PM, Anis KADRI anis.ka...@gmail.com wrote: done On Thu, Oct 10, 2013 at 7:44 PM, Andrew Grieve agri...@chromium.org wrote: Awesome! Could you add me as an owner for the plugins? On Thu, Oct 10, 2013 at 6:34 PM, Anis Kadri (JIRA) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/CB-4786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anis Kadri resolved CB-4786. Resolution: Fixed [~stevegill] was able to publish all plugins today. The issue is resolved. Add `owner` command --- Key: CB-4786 URL: https://issues.apache.org/jira/browse/CB-4786 Project: Apache Cordova Issue Type: Bug Components: Plugman Affects Versions: 3.0.0 Reporter: Anis Kadri Assignee: Anis Kadri Fix For: 3.1.0 similar to [npm owner|https://npmjs.org/doc/owner.html] -- This message was sent by Atlassian JIRA (v6.1#6144)
Re: [jira] [Resolved] (CB-4786) Add `owner` command
done. On Fri, Oct 11, 2013 at 4:29 PM, Jesse purplecabb...@gmail.com wrote: done: purplecabbage @purplecabbage risingj.com On Fri, Oct 11, 2013 at 4:23 PM, Anis KADRI anis.ka...@gmail.com wrote: I don't see your user account. You need to create one with `plugman adduser` On Fri, Oct 11, 2013 at 4:21 PM, Jesse purplecabb...@gmail.com wrote: can you 'pwn' me too? @purplecabbage risingj.com On Fri, Oct 11, 2013 at 4:15 PM, Anis KADRI anis.ka...@gmail.com wrote: done On Thu, Oct 10, 2013 at 7:44 PM, Andrew Grieve agri...@chromium.org wrote: Awesome! Could you add me as an owner for the plugins? On Thu, Oct 10, 2013 at 6:34 PM, Anis Kadri (JIRA) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/CB-4786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anis Kadri resolved CB-4786. Resolution: Fixed [~stevegill] was able to publish all plugins today. The issue is resolved. Add `owner` command --- Key: CB-4786 URL: https://issues.apache.org/jira/browse/CB-4786 Project: Apache Cordova Issue Type: Bug Components: Plugman Affects Versions: 3.0.0 Reporter: Anis Kadri Assignee: Anis Kadri Fix For: 3.1.0 similar to [npm owner|https://npmjs.org/doc/owner.html] -- This message was sent by Atlassian JIRA (v6.1#6144)
third-party cordova plugin registry
Saw this from a comment on one of my blog posts: http://www.plugreg.com/
Re: third-party cordova plugin registry
I welcome the initiative. However, If I am not mistaken it only references git URLs. There is no notion of version so you'd have to pull from master. It definitely looks better than plugins.cordova.io though xD! On Fri, Oct 11, 2013 at 4:40 PM, Shazron shaz...@gmail.com wrote: Saw this from a comment on one of my blog posts: http://www.plugreg.com/
Re: third-party cordova plugin registry
herm wong has 3 plugins up there! wtf? @purplecabbage risingj.com On Fri, Oct 11, 2013 at 4:46 PM, Anis KADRI anis.ka...@gmail.com wrote: I welcome the initiative. However, If I am not mistaken it only references git URLs. There is no notion of version so you'd have to pull from master. It definitely looks better than plugins.cordova.io though xD! On Fri, Oct 11, 2013 at 4:40 PM, Shazron shaz...@gmail.com wrote: Saw this from a comment on one of my blog posts: http://www.plugreg.com/
Re: third-party cordova plugin registry
Definitely looks better and it reports engine versions! ;) hint hint https://issues.apache.org/jira/browse/CB-4896 On Fri, Oct 11, 2013 at 4:46 PM, Anis KADRI anis.ka...@gmail.com wrote: I welcome the initiative. However, If I am not mistaken it only references git URLs. There is no notion of version so you'd have to pull from master. It definitely looks better than plugins.cordova.io though xD! On Fri, Oct 11, 2013 at 4:40 PM, Shazron shaz...@gmail.com wrote: Saw this from a comment on one of my blog posts: http://www.plugreg.com/
Re: third-party cordova plugin registry
and apparently I have 2 ... this is going to confuse people, since most of them are just different forks of the same repos. @purplecabbage risingj.com On Fri, Oct 11, 2013 at 4:52 PM, Jesse purplecabb...@gmail.com wrote: herm wong has 3 plugins up there! wtf? @purplecabbage risingj.com On Fri, Oct 11, 2013 at 4:46 PM, Anis KADRI anis.ka...@gmail.com wrote: I welcome the initiative. However, If I am not mistaken it only references git URLs. There is no notion of version so you'd have to pull from master. It definitely looks better than plugins.cordova.io though xD! On Fri, Oct 11, 2013 at 4:40 PM, Shazron shaz...@gmail.com wrote: Saw this from a comment on one of my blog posts: http://www.plugreg.com/
Re: third-party cordova plugin registry
It's probably the Firefox OS plugin stuff On Fri, Oct 11, 2013 at 4:52 PM, Jesse purplecabb...@gmail.com wrote: herm wong has 3 plugins up there! wtf? @purplecabbage risingj.com On Fri, Oct 11, 2013 at 4:46 PM, Anis KADRI anis.ka...@gmail.com wrote: I welcome the initiative. However, If I am not mistaken it only references git URLs. There is no notion of version so you'd have to pull from master. It definitely looks better than plugins.cordova.io though xD! On Fri, Oct 11, 2013 at 4:40 PM, Shazron shaz...@gmail.com wrote: Saw this from a comment on one of my blog posts: http://www.plugreg.com/
Re: third-party cordova plugin registry
Yeah especially since I'm sure none of us submitted anything he's just seeding stuff more like On Fri, Oct 11, 2013 at 4:54 PM, Jesse purplecabb...@gmail.com wrote: and apparently I have 2 ... this is going to confuse people, since most of them are just different forks of the same repos. @purplecabbage risingj.com On Fri, Oct 11, 2013 at 4:52 PM, Jesse purplecabb...@gmail.com wrote: herm wong has 3 plugins up there! wtf? @purplecabbage risingj.com On Fri, Oct 11, 2013 at 4:46 PM, Anis KADRI anis.ka...@gmail.com wrote: I welcome the initiative. However, If I am not mistaken it only references git URLs. There is no notion of version so you'd have to pull from master. It definitely looks better than plugins.cordova.io though xD! On Fri, Oct 11, 2013 at 4:40 PM, Shazron shaz...@gmail.com wrote: Saw this from a comment on one of my blog posts: http://www.plugreg.com/
Re: third-party cordova plugin registry
There are 4021 xml files on github with the namespace : http://cordova.apache.org/ns/plugins/1.0 https://github.com/search?l=xmlq=http%3A%2F%2Fcordova.apache.org%2Fns%2Fplugins%2F1.0ref=advsearchtype=Code @purplecabbage risingj.com On Fri, Oct 11, 2013 at 4:55 PM, Shazron shaz...@gmail.com wrote: Yeah especially since I'm sure none of us submitted anything he's just seeding stuff more like On Fri, Oct 11, 2013 at 4:54 PM, Jesse purplecabb...@gmail.com wrote: and apparently I have 2 ... this is going to confuse people, since most of them are just different forks of the same repos. @purplecabbage risingj.com On Fri, Oct 11, 2013 at 4:52 PM, Jesse purplecabb...@gmail.com wrote: herm wong has 3 plugins up there! wtf? @purplecabbage risingj.com On Fri, Oct 11, 2013 at 4:46 PM, Anis KADRI anis.ka...@gmail.com wrote: I welcome the initiative. However, If I am not mistaken it only references git URLs. There is no notion of version so you'd have to pull from master. It definitely looks better than plugins.cordova.io though xD! On Fri, Oct 11, 2013 at 4:40 PM, Shazron shaz...@gmail.com wrote: Saw this from a comment on one of my blog posts: http://www.plugreg.com/
Re: third-party cordova plugin registry
Maybe we should contact him to help out with our official registry! We could use some UX On Fri, Oct 11, 2013 at 4:55 PM, Shazron shaz...@gmail.com wrote: Yeah especially since I'm sure none of us submitted anything he's just seeding stuff more like On Fri, Oct 11, 2013 at 4:54 PM, Jesse purplecabb...@gmail.com wrote: and apparently I have 2 ... this is going to confuse people, since most of them are just different forks of the same repos. @purplecabbage risingj.com On Fri, Oct 11, 2013 at 4:52 PM, Jesse purplecabb...@gmail.com wrote: herm wong has 3 plugins up there! wtf? @purplecabbage risingj.com On Fri, Oct 11, 2013 at 4:46 PM, Anis KADRI anis.ka...@gmail.com wrote: I welcome the initiative. However, If I am not mistaken it only references git URLs. There is no notion of version so you'd have to pull from master. It definitely looks better than plugins.cordova.io though xD! On Fri, Oct 11, 2013 at 4:40 PM, Shazron shaz...@gmail.com wrote: Saw this from a comment on one of my blog posts: http://www.plugreg.com/
Re: mobile-spec and releases: How do we test?
The eval of the jasmine interface deserves mention. Is the motivation there
that tests can choose to use another testing framework? That's why you
don't just make jasmine functions globals?
One nit pick just from reading your email is that this will cause the test
js-modules to be injected into apps that use the plugins. I think probably
we will want to update the tools to recognize a js-test-module. We
*could* work around it by adding the tests to new plugins that depend on
the thing they are testing, but I think changing the tools would be nicer.
Another nit is that it would be nice if the CordovaTests app didn't depend
on any plugins. e.g., don't have it depend on device plugin.
Overall, really like the approach!
On Fri, Oct 11, 2013 at 5:17 PM, Michal Mocny mmo...@chromium.org wrote:
TLDR; I've implemented a plugin testing strategy that requires 0 new
tooling features, can support non-core plugins, and hopefully even support
a variety of methods for running/reporting the test results. Super alpha
preview, but take a look if you like the direction!
NEW: CDVTest Plugin: https://github.com/mmocny/CDVTest
NEW: CordovaTest App: https://github.com/mmocny/CordovaTests
UPDATED: Converted three existing plugins to this new style. Code is on
feature branches of respective repos (cdvtest branch):
org.apache.cordova.device
org.apache.cordova.device-motion
org.chromium.storage
(must clone locally, switch to branch, and plugin add from local path)
Now, any plugin that wants to join in on the fun needs to provide a
js-module
src=... name=test / and use this template:
exports.init = function() {
eval(require('org.apache.cordova.test.test').injectJasmineInterface(this,
'this'));
// TESTS GO HERE
describe(..., function() {
it(...);
});
};
(The eval is optional but super useful; it will inject the jasmine
interface into your scope, so you don't have to type jasmine.describe,
jasmine.it, etc. Not sure of any cleaner way to do this.)
STEPS:
1. create a new cordova project
2. import the CordovaTest app into your www
3. add any or all of the above plugins
4. give it a run, and try out the auto tests (all pass on ipad, some still
fail on android)
Lots of work left to do, but hopefully good enough to whet your appetite.
One thing to note, I've attempted to make CDVTest and plugin tests unaware
of the specific jasmine version the app is hosting (so that it can be
swapped without changing all plugins), but it must support the new style
interface for async tests (ie, accept a done callback). This is the style
that node-jasmine uses, mocha uses, and jasmine-2.0 is going to use (I'm
using jasmine 2.0 rc3). This means that core plugin tests require some
code transformations, but the net effect is cleaner tests and more common
style with our node tools' tests.
Manual tests are not implemented yet.
-Michal
On Fri, Oct 11, 2013 at 12:54 PM, Michal Mocny mmo...@chromium.org
wrote:
I'm throwing something together right now, actually. I'll post my
current
progress today so you can take a look.
On Fri, Oct 11, 2013 at 12:41 PM, Brian LeRoux b...@brian.io wrote:
Sorry keep meaning to respond. I like Michal's first step but growing
to a
full suite of tools. Are you currently tackling this Braden? I feel like
it
is related to the Medic stuff and maybe we should throw one of our guys
on
the problem fully.
On Sep 27, 2013 5:10 PM, Braden Shepherdson bra...@chromium.org
wrote:
Which one?
On Fri, Sep 27, 2013 at 10:09 AM, Brian LeRoux b...@brian.io wrote:
I really like your proposal as a starting point. Very simple but
would
allow for in-app testing as well as on the cmd line if we so wish.
On Fri, Sep 27, 2013 at 3:28 PM, Michal Mocny mmo...@chromium.org
wrote:
I was looking over some old emails from this list on plugin
testing,
and
an
idea that was proposed way back was to ship plugin tests as a
second
plugin. That way, you can chose to install tests, or not, and
know
explicitly if they are being copied into your final project.
An alternative would be to support build targets a la
release/debug
and
have target-specific plugin.xml tags (assets, js-modules,
source-file..).
-Michal
On Fri, Sep 27, 2013 at 4:52 AM, Brian LeRoux b...@brian.io wrote:
I think this is basically what we've been proposing for a while
now.
On Thu, Sep 26, 2013 at 8:29 PM, Michal Mocny
mmo...@chromium.org
wrote:
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(...) ).
- Will need a common
Re: third-party cordova plugin registry
Wowzers! That's a lot of xml files! On Fri, Oct 11, 2013 at 8:04 PM, Jesse purplecabb...@gmail.com wrote: There are 4021 xml files on github with the namespace : http://cordova.apache.org/ns/plugins/1.0 https://github.com/search?l=xmlq=http%3A%2F%2Fcordova.apache.org%2Fns%2Fplugins%2F1.0ref=advsearchtype=Code @purplecabbage risingj.com On Fri, Oct 11, 2013 at 4:55 PM, Shazron shaz...@gmail.com wrote: Yeah especially since I'm sure none of us submitted anything he's just seeding stuff more like On Fri, Oct 11, 2013 at 4:54 PM, Jesse purplecabb...@gmail.com wrote: and apparently I have 2 ... this is going to confuse people, since most of them are just different forks of the same repos. @purplecabbage risingj.com On Fri, Oct 11, 2013 at 4:52 PM, Jesse purplecabb...@gmail.com wrote: herm wong has 3 plugins up there! wtf? @purplecabbage risingj.com On Fri, Oct 11, 2013 at 4:46 PM, Anis KADRI anis.ka...@gmail.com wrote: I welcome the initiative. However, If I am not mistaken it only references git URLs. There is no notion of version so you'd have to pull from master. It definitely looks better than plugins.cordova.io though xD! On Fri, Oct 11, 2013 at 4:40 PM, Shazron shaz...@gmail.com wrote: Saw this from a comment on one of my blog posts: http://www.plugreg.com/
Re: third-party cordova plugin registry
Seems quite useful actually. He could support versions via git tags (if he added that in, plugman already supports it)... Probably the main difference (besides he's scraped github), is that he's not hosting tgz files. On Fri, Oct 11, 2013 at 9:10 PM, Andrew Grieve agri...@chromium.org wrote: Wowzers! That's a lot of xml files! On Fri, Oct 11, 2013 at 8:04 PM, Jesse purplecabb...@gmail.com wrote: There are 4021 xml files on github with the namespace : http://cordova.apache.org/ns/plugins/1.0 https://github.com/search?l=xmlq=http%3A%2F%2Fcordova.apache.org%2Fns%2Fplugins%2F1.0ref=advsearchtype=Code @purplecabbage risingj.com On Fri, Oct 11, 2013 at 4:55 PM, Shazron shaz...@gmail.com wrote: Yeah especially since I'm sure none of us submitted anything he's just seeding stuff more like On Fri, Oct 11, 2013 at 4:54 PM, Jesse purplecabb...@gmail.com wrote: and apparently I have 2 ... this is going to confuse people, since most of them are just different forks of the same repos. @purplecabbage risingj.com On Fri, Oct 11, 2013 at 4:52 PM, Jesse purplecabb...@gmail.com wrote: herm wong has 3 plugins up there! wtf? @purplecabbage risingj.com On Fri, Oct 11, 2013 at 4:46 PM, Anis KADRI anis.ka...@gmail.com wrote: I welcome the initiative. However, If I am not mistaken it only references git URLs. There is no notion of version so you'd have to pull from master. It definitely looks better than plugins.cordova.io though xD! On Fri, Oct 11, 2013 at 4:40 PM, Shazron shaz...@gmail.com wrote: Saw this from a comment on one of my blog posts: http://www.plugreg.com/
Re: mobile-spec and releases: How do we test?
On Fri, Oct 11, 2013 at 9:08 PM, Andrew Grieve agri...@chromium.org wrote:
The eval of the jasmine interface deserves mention. Is the motivation
there that tests can choose to use another testing framework? That's why
you don't just make jasmine functions globals?
I was hoping the plugins would need to depend on anything but CDVTest, and
not expect any globals. I guess, though, that CDVTest still expects the
app to provide to a test framework and some other stuff, so in the end its
no different. I was hedging on being able to update CDVTest in the future
for whatever we need, and all 3rdparty plugins would not need updating.
eval() could be used to do all sorts of clever things if we needed..
One nit pick just from reading your email is that this will cause the test
js-modules to be injected into apps that use the plugins. I think probably
we will want to update the tools to recognize a js-test-module. We
*could* work around it by adding the tests to new plugins that depend on
the thing they are testing, but I think changing the tools would be nicer.
I also mentioned splitting tests into second plugin but thats overkill
except in extreme circumstances. Note that the tests aren't actually
loaded unless you require them, so its just a matter of larger binaries
which could be filtered out manually.
My person preference would be to support conditional build types, which
have come up before. ie, cordova prepare debug, cordova prepare release,
cordova prepare test -- and plugin.xml could specify a different set of
js-module for either.
A specific js-test-module would be fine, but isnt 0 new tooling.
Also, I forgot to mention, but we do need to add support for getting the
full list of plugins installed, which should be trivial to add to
modulemapper (maybe there is already a way to reach in, but I don't think
we have a documented api for it).
Another nit is that it would be nice if the CordovaTests app didn't depend
on any plugins. e.g., don't have it depend on device plugin.
CordovaTests doesn't explicitly depend on device plugin, except that at the
moment I have it printing the same info that MobileSpec does at startup.
This could be wrapped in a try{}catch in case the require fails, but its
good info to have in the common case.
Overall, really like the approach!
Thanks!
On Fri, Oct 11, 2013 at 5:17 PM, Michal Mocny mmo...@chromium.org wrote:
TLDR; I've implemented a plugin testing strategy that requires 0 new
tooling features, can support non-core plugins, and hopefully even support
a variety of methods for running/reporting the test results. Super alpha
preview, but take a look if you like the direction!
NEW: CDVTest Plugin: https://github.com/mmocny/CDVTest
NEW: CordovaTest App: https://github.com/mmocny/CordovaTests
UPDATED: Converted three existing plugins to this new style. Code is on
feature branches of respective repos (cdvtest branch):
org.apache.cordova.device
org.apache.cordova.device-motion
org.chromium.storage
(must clone locally, switch to branch, and plugin add from local path)
Now, any plugin that wants to join in on the fun needs to provide a
js-module
src=... name=test / and use this template:
exports.init = function() {
eval(require('org.apache.cordova.test.test').injectJasmineInterface(this,
'this'));
// TESTS GO HERE
describe(..., function() {
it(...);
});
};
(The eval is optional but super useful; it will inject the jasmine
interface into your scope, so you don't have to type jasmine.describe,
jasmine.it, etc. Not sure of any cleaner way to do this.)
STEPS:
1. create a new cordova project
2. import the CordovaTest app into your www
3. add any or all of the above plugins
4. give it a run, and try out the auto tests (all pass on ipad, some still
fail on android)
Lots of work left to do, but hopefully good enough to whet your appetite.
One thing to note, I've attempted to make CDVTest and plugin tests unaware
of the specific jasmine version the app is hosting (so that it can be
swapped without changing all plugins), but it must support the new style
interface for async tests (ie, accept a done callback). This is the style
that node-jasmine uses, mocha uses, and jasmine-2.0 is going to use (I'm
using jasmine 2.0 rc3). This means that core plugin tests require some
code transformations, but the net effect is cleaner tests and more common
style with our node tools' tests.
Manual tests are not implemented yet.
-Michal
On Fri, Oct 11, 2013 at 12:54 PM, Michal Mocny mmo...@chromium.org
wrote:
I'm throwing something together right now, actually. I'll post my
current
progress today so you can take a look.
On Fri, Oct 11, 2013 at 12:41 PM, Brian LeRoux b...@brian.io wrote:
Sorry keep meaning to respond. I like Michal's first step but growing
to a
full suite of tools. Are you currently tackling this Braden? I feel
like
it
is related to the Medic stuff and
Re: config.xml as a build artifact for less suffering and easier upgrades
On Tue, Oct 8, 2013 at 10:27 AM, Jeffrey Heifetz jheif...@blackberry.comwrote: So I'm not sure if we ever came to a true consensus about this, but the code has been up for a while now [1]. If there are no complaints in say 24hrs I think its reasonable to merge it in. Hooray for lazy consensus! :) Seriously, though, this is great -- I looked at the code in reviewboard a couple of times, and it looked good. I wasn't confident enough to hit the Ship it button, I guess. I've hit a snag running CLI today, though. It looks like the new prepare method always: 1) runs plugman prepare for each installed plugin, which copies the plugin js modules into the platform www dir, and then 2) calls parser.update_project(), which deletes the platform www dir, and recreates it. The end result is that plugin native code is installed, but JS code is not. I've sent up a small change to reviewboard[1]; it's working for me now for Android and iOS -- let me know if you think it's going to introduce any new problems, though. Ian [1] https://reviews.apache.org/r/14621/ Cheers, Jeff 1. https://reviews.apache.org/r/14376/ On 13-09-16 5:06 PM, Michal Mocny mmo...@chromium.org wrote: I've emailed github about that in the past. Hopefully they can address it, since their review system is far superior for all other reasons. On Mon, Sep 16, 2013 at 1:16 PM, Andrew Grieve agri...@chromium.org wrote: We do get emails for some pull requests, but some repos aren't set up to email and looks like CLI is one of them. Think you need to file an INFRA ticket to fix it :(. I'm liking reviewboard more than github for reviews since it lets you review your comments without sending an email for each and every one of them. I'm fine with using github as well though since that's what most people tend to use. On Mon, Sep 16, 2013 at 4:06 PM, Michal Mocny mmo...@chromium.org wrote: We don't get email notified (or, at least I don't) of github pull requests, but we do get emails for review-board (or at least the assignee does?). Either way, if you post a link you'll likely get better luck with a review quicker next time, sorry that we missed it. I can't peek until tomorrow/wed, so if no one gets to it, I'll do it then. -Michal On Mon, Sep 16, 2013 at 11:16 AM, Jeffrey Heifetz jheif...@blackberry.comwrote: So I believe this pull request is ready to go, however I have yet to get any feedback on the request itself. Can anyone familiar with the other platforms volunteer to test this with them? Is this a question of presentation, should I close the github pull request in favour of the cordova review board ? On 13-09-12 2:13 PM, Michal Mocny mmo...@chromium.org wrote: Thats awesome, looking forward to it! On Thu, Sep 12, 2013 at 10:22 AM, Jeffrey Heifetz jheif...@blackberry.comwrote: Yup I'm on the same page with you Michal, and I believe Braden as well. I'm sorry I should have said so earlier, we resolved this on irc. I have a basic implementation here https://github.com/apache/cordova-cli/pull/39 but I'm still testing it. On 13-09-12 12:36 PM, Michal Mocny mmo...@chromium.org wrote: Trying to clarify the misunderstanding... Jeffrey, if I understand your email, your understanding of point (4) of bradens flow is that the app.xml is *being* munged, whereas we meant that its the app.xml config that is *doing* the munging to the platform config. I think that means we both agree that app.xml should never be modified, and it was just a miscommunication. Am I right with that understanding? Also, in your proposal you have plugins munging/preparing *after* app.xml does its munging. I assume you did not do intentionally, that you had just not considered the order important. If it was intentional, why? We were thinking app.xml should be last and thus have the most importance. On Wed, Sep 11, 2013 at 11:38 AM, Braden Shepherdson bra...@chromium.orgwrote: I think we've gotten a bit confused. Let me try to describe again the way I was envisioning things. 1. If defaults.xml exists, replace platform config.xml with it. 2. Use plugman to add each plugin's config-file changes onto the platform config.xml. 3. Add in the values from the app config.xml: name, author etc., which it currently does, plus the proposed new config-file tags. 4. Somewhere in there, call plugman prepare to update the JS modules. This doesn't change or depend on config.xml at all. NB: I don't suggest anywhere that we edit the user's top-level, app config.xml. This is just a process for building the platform config.xml, and making it a pure
Review Request 14621: Fix plugin JS installation during cordova prepare
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14621/ --- Review request for cordova and Jeffrey Heifetz. Bugs: CB-4774 https://issues.apache.org/jira/browse/CB-4774 Repository: cordova-cli Description --- Changes order of operations in `cordova prepare` so that the app www directory is clobbered before plugins are prepared. Without this, the platforms' www directories do not have end up with plugins installed after a `cordova prepare` execution. Diffs - src/metadata/android_parser.js 2df37e6 src/metadata/blackberry10_parser.js 5ad4f0b src/metadata/firefoxos_parser.js 51f6e1a src/metadata/ios_parser.js 15854e8 src/metadata/wp7_parser.js 5bda771 src/metadata/wp8_parser.js ad914b6 src/prepare.js 62dbf65 Diff: https://reviews.apache.org/r/14621/diff/ Testing --- Created new mobile spec project: cordova-cli/bin/cordova create mobilespec com.example.mobilespec mobilespec cd mobilespec ../cordova-cli/bin/cordova platform add android ../cordova-cli/bin/cordova platform add ios ../cordova-cli/bin/cordova plugin add ../cordova-mobile-spec/dependencies-plugin rm -r www ln -s ../cordova-mobile-spec/ www ../cordova-cli/bin/cordova prepare Checked for existence of platforms/android/assets/www/plugins and platforms/ios/www/plugins. Ran mobile spec tests on android and ios to verify that plugins were loading correctly. Other platform parsers are changed to match ios and android, but I don't have hardware to verify the changes. Thanks, Ian Clelland
Re: Review Request 14621: Fix plugin JS installation during cordova prepare
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14621/#review26955 --- Haven't tested it but it looks right to me. I'll try and test over the weekend. - Jeffrey Heifetz On Oct. 12, 2013, 2:45 a.m., Ian Clelland wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14621/ --- (Updated Oct. 12, 2013, 2:45 a.m.) Review request for cordova and Jeffrey Heifetz. Bugs: CB-4774 https://issues.apache.org/jira/browse/CB-4774 Repository: cordova-cli Description --- Changes order of operations in `cordova prepare` so that the app www directory is clobbered before plugins are prepared. Without this, the platforms' www directories do not have end up with plugins installed after a `cordova prepare` execution. Diffs - src/metadata/android_parser.js 2df37e6 src/metadata/blackberry10_parser.js 5ad4f0b src/metadata/firefoxos_parser.js 51f6e1a src/metadata/ios_parser.js 15854e8 src/metadata/wp7_parser.js 5bda771 src/metadata/wp8_parser.js ad914b6 src/prepare.js 62dbf65 Diff: https://reviews.apache.org/r/14621/diff/ Testing --- Created new mobile spec project: cordova-cli/bin/cordova create mobilespec com.example.mobilespec mobilespec cd mobilespec ../cordova-cli/bin/cordova platform add android ../cordova-cli/bin/cordova platform add ios ../cordova-cli/bin/cordova plugin add ../cordova-mobile-spec/dependencies-plugin rm -r www ln -s ../cordova-mobile-spec/ www ../cordova-cli/bin/cordova prepare Checked for existence of platforms/android/assets/www/plugins and platforms/ios/www/plugins. Ran mobile spec tests on android and ios to verify that plugins were loading correctly. Other platform parsers are changed to match ios and android, but I don't have hardware to verify the changes. Thanks, Ian Clelland
