On Tue, Jun 24, 2014 at 6:52 PM, Martin Gonzalez < martin.c.glez.g...@gmail.com> wrote:
> We've been discussing here in IBM, about add a flag to the CLI to pull the > tests from the plugin, add them to each platform, prepare, build and > deploy. > It would be something like 'cordova run/emulate [platform] --tests' > The workflow has been discussed and I think that are great ideas. > Proposal: > - 'cordova plugin add' it would remain as is. > -Add the tests to the master branch, and those would be added to the > project. > -The plugin framework may be installed manually or can be part of the > 'cordova run/emulate --tests' workflow. > > Workflow: > - 'cordova prepare' has to change, only if the --tests flag is present it > would copy the test files. > - 'cordova build' it would save a copy of config.xml or modify the file to > replace the content tag: '<content src="index.html" />' by <content > src="cdvtests/index.html" />, as well as modify plugin.xml of each > installed plugin to add this tag: '<js-module src="test/tests.js" > name="tests"></js-module>' > Options with this one: create a backup of config.xml, modify the file > adding/replacing the information, save the previous values from the files > or restore the default config.xml content tag to index.html, it might be > possible however, not always index.html is the default file in a project. > > This behavior it would work only in a temporal way, the idea is not corrupt > the project at all, meaning that this workflow it will be followed if the > --tests flag is present in the CLI, it would prepare, build, deploy/emulate > and at the end it should restore to the previous configuration, meaning > that config.xml should be restored, as well as each plugin.xml file of each > installed plugin. > > In order to work on this, decisions are required. We have to define how > it's gonna be: > > -The tests on each plugin, where are going to live? on master or cdvtest > (This branch it may became outdated as Jesse mentioned), I can't find any > reason to not add them to master. > Definitely. cdvtest was never meant to be more than temporary. > -Backup the plugin.xml and config.xml and then restore them or modify them > and undo the modifications after run/emulate the app? any thoughts? > We can add logic to the tools to do what you want, but we should *not* be modifying any files on disk to accomplish it. Config.xml is easy to modify in a one-off since it's a generated file within platforms/ and is generated on each prepare. Test files are not though, and to have them not stick around after the --test run would be pretty tricky to implement robustly. I think the pitched idea where each plugin repo has a second plugin within it that contains the tests would be more robust and easier to reason about. E.g. if you want to add a --test flag to CLI, then have the logic be: for each installed plugin ID, install $PLUGIN_ID.test (or something along those lines) Really, as long as the createmobilespec.js knows to install the test plugins, I think that would be fine. > -The flag should work to prepare the project only? and then allow to the > user/dev to run or emulate or both, emulator/device? > -'cordova run/emulate --tests cdvtests/index.html' or 'cordova run/emulate > --tests' ? there is any other useful arguments to improve the workflow? > -plugin-test-framework, installed manually or automatically? > > Also Andrew points are good, improve it to make tests fast, avoid timers, > identify if its running on the simulator/emulator or not. > > Any input, ideas, suggestions about this, it would be great. > > > > 2014-06-21 10:22 GMT-05:00 Andrew Grieve <agri...@chromium.org>: > > > Just occurred to me it might be a good idea to point out what's > > not-so-great about our current auto-tests since you guys will be looking > to > > refactor them quite a bit. Big things that've come to bug me: > > > > - Tests should fail fast instead of timing out when failure callbacks are > > called. FileTransfer is one case where tests generally fail fast rather > > than timeout. All this entails is making fail callbacks call the done() > > callback. > > - Tests have a lot of copy & paste. Some is okay, but helper functions > > would go a *long* way for some tests > > - Tests that don't work on the simulator often time out. Would be better > if > > they were skipped when simulator is detected. > > > > Thanks again for taking this on, and feel free not to address anything > I've > > said. Just wanted to point it out as something that you don't need to go > > out of your way to keep the same. :) > > > > > > On Fri, Jun 20, 2014 at 12:40 AM, Piotr Zalewa <pzal...@mozilla.com> > > wrote: > > > > > testing is good, no need to hide it, > > > it would be good though to not copy it with the rendered app > > > > > > Dnia Thu Jun 19 19:11:25 2014 purplecabbage pisze: > > > > > > I think we just lead by example. > > >> > > >> Sent from my iPhone > > >> > > >> On Jun 19, 2014, at 6:18 PM, Michal Mocny <mmo...@chromium.org> > wrote: > > >>> > > >>> +1 I agree, this would be awesome. > > >>> > > >>> New question, should this merely be the "standard" we adhere to for > > core > > >>> plugins, or should we actively make it difficult for plugin devs to > not > > >>> ship tests directly with plugins? (Not sure how we could accomplish > > that, > > >>> so I hope its just a convention that applies to our work). > > >>> > > >>> -Michal > > >>> > > >>> > > >>> On Thu, Jun 19, 2014 at 7:48 PM, Jesse <purplecabb...@gmail.com> > > wrote: > > >>>> > > >>>> My ultimate would be this: > > >>>> > > >>>> cordova create TestFilePlugin > > >>>> cd TestFilePlugin > > >>>> cordova platform add android > > >>>> cordova plugin add > > >>>> > > >>>> http://git-wip-us.apache.org/repos/asf/cordova-labs.git# > > >>>> cdvtest:cordova-plugin-test-framework > > >>>> cordova plugin add ../cordova-plugin-file/ > > >>>> cordova plugin add ../cordova-plugin-file/test/ > > >>>> cordova run android --start cdvtests/index.html > > >>>> > > >>>> Then do this for each plugin, and for each platform > > >>>> Then do this for all combinations of plugins > > >>>> ... > > >>>> > > >>>> Note the run --start does not yet exist, but this would be awesome! > > >>>> > > >>>> > > >>>> @purplecabbage > > >>>> risingj.com > > >>>> > > >>>> > > >>>> On Thu, Jun 19, 2014 at 4:15 PM, Jesse <purplecabb...@gmail.com> > > >>>>> wrote: > > >>>>> > > >>>>> Option a) was what I suggested a ways back, and I still stand by > it. > > >>>>> I think it provides the greatest transparency, and simplicity, yet > it > > >>>>> is > > >>>>> still very flexible. > > >>>>> I don't think it would be hard to accomplish either. This is the > > small > > >>>>> re-org I was hinting at, you've already done the hard part. > > >>>>> > > >>>>> > > >>>>> @purplecabbage > > >>>>> risingj.com > > >>>>> > > >>>>> > > >>>>> On Thu, Jun 19, 2014 at 3:45 PM, Michal Mocny < > mmo...@chromium.org> > > >>>>>> > > >>>>> wrote: > > >>>>> > > >>>>> Andrew has raised that concern as well. My gut says that the > > bundling > > >>>>>> > > >>>>> of > > >>>> > > >>>>> a > > >>>>>> few shorts scripts that get parsed but not run as long as they > don't > > >>>>>> get > > >>>>>> require() will not affect applications negatively (there are > > probably > > >>>>>> > > >>>>> many > > >>>> > > >>>>> more significant overheads we live with today in cordova) -- but I > > >>>>>> understand why that may not be useful default. > > >>>>>> > > >>>>>> In that case, some ideas: (I recall these were proposed previously > > but > > >>>>>> > > >>>>> not > > >>>> > > >>>>> sure by whom) > > >>>>>> (a) Bundle tests as a plugin-within-the-plugin as such: > > >>>>>> myplugin/ > > >>>>>> - plugin.xml > > >>>>>> - src/... > > >>>>>> - www/... > > >>>>>> - tests/ > > >>>>>> - plugin.xml > > >>>>>> - www/... > > >>>>>> > > >>>>>> Which basically means the plugin tests live in the same > repo/branch, > > >>>>>> and > > >>>>>> are fetched as part of "plugin add", but are not moved into > > platforms/ > > >>>>>> > > >>>>> on > > >>>> > > >>>>> cordova prepare by default, thus don't end up in your application > > (disk > > >>>>>> and > > >>>>>> network are cheap, application startup and size costs are not, > > >>>>>> right?). > > >>>>>> Then, to run tests, we basically need to iterate all plugins > looking > > >>>>>> > > >>>>> for a > > >>>> > > >>>>> nested tests/plugin.xml, and install those. This can be added to > > >>>>>> CLI/Plugman, or just be a CLI hook even. > > >>>>>> > > >>>>>> (b) add a <js-test-module> or <js-module type="test"> that is only > > >>>>>> used > > >>>>>> > > >>>>> if > > >>>> > > >>>>> you run prepare with --test. Similar to the above, but I think > > >>>>>> requires > > >>>>>> more CLI/config file changes, which I'm not a fan of. > > >>>>>> (c) Just ship tests as a second plugin in a second repo, and > > document > > >>>>>> > > >>>>> how > > >>>> > > >>>>> to install tests. Can then perhaps have a <dependency type=tests>. > > I > > >>>>>> don't like this as much since its basically back to mobile-spec. > > >>>>>> > > >>>>>> WDYT? > > >>>>>> > > >>>>>> -Michal > > >>>>>> > > >>>>>> > > >>>>>> On Thu, Jun 19, 2014 at 4:53 PM, Jesse <purplecabb...@gmail.com> > > >>>>>>> wrote: > > >>>>>>> > > >>>>>>> re: > > >>>>>>> > > >>>>>>> Q: What do I do if my plugin tests must have very large > assets? > > >>>>>>> - A: Don't bundle those assets with your plugin. If you can, > > have > > >>>>>>> > > >>>>>> your > > >>>>>> > > >>>>>>> ... > > >>>>>>> > > >>>>>>> > > >>>>>>> My concern is I do not want to see tests added to every project > > that > > >>>>>>> > > >>>>>> uses a > > >>>>>> > > >>>>>>> plugin, even if the assets are not large, there are implications > to > > >>>>>>> including the test framework + all the tests because they get > > loaded > > >>>>>>> > > >>>>>> and > > >>>> > > >>>>> processed with all of the plugins and will impact load time even if > > >>>>>>> > > >>>>>> never > > >>>>>> > > >>>>>>> run. > > >>>>>>> > > >>>>>>> 99.9% of the time the plugin tests will be used by us the plugin > > >>>>>>> developers, and not the people who use the plugin in there apps. > > >>>>>>> > > >>>>>>> I agree, having the tester install the test harness plugin > > dependency > > >>>>>>> themselves is probably a better option, as I see you have wrapped > > all > > >>>>>>> > > >>>>>> tests > > >>>>>> > > >>>>>>> inside a exports.defineAutoTests so we don't have to worry about > > >>>>>>> describe/it/expects not being defined. > > >>>>>>> > > >>>>>>> > > >>>>>>> @purplecabbage > > >>>>>>> risingj.com > > >>>>>>> > > >>>>>>> > > >>>>>>> On Thu, Jun 19, 2014 at 1:27 PM, Michal Mocny < > > mmo...@chromium.org> > > >>>>>>>> > > >>>>>>> wrote: > > >>>>>>> > > >>>>>>> Jesee, the branch is NOT a requirement (I don't think I > documented > > >>>>>>>> > > >>>>>>> it > > >>>> > > >>>>> as > > >>>>>> > > >>>>>>> such, except in the examples for installing plugins for initial > > >>>>>>>> > > >>>>>>> look). > > >>>> > > >>>>> Actually, we should delete those stale branches now that we are > > >>>>>>>> > > >>>>>>> moving > > >>>>>> > > >>>>>>> up-to-date tests into master. It was just for early > > experimentation > > >>>>>>>> > > >>>>>>> on > > >>>>>> > > >>>>>>> the > > >>>>>>> > > >>>>>>>> feature. > > >>>>>>>> > > >>>>>>>> Jesse, I'm not seeing the benefit of using plugins-tests.xml or > > the > > >>>>>>>> dependency on the test plugin yet, may you elaborate your > > thoughts? > > >>>>>>>> > > >>>>>>>> My hope was that tests are just always installed alongside > > plugins. > > >>>>>>>> > > >>>>>>> If > > >>>>>> > > >>>>>>> that is not a good idea for some particular plugin, say because > it > > >>>>>>>> > > >>>>>>> uses > > >>>>>> > > >>>>>>> huge assets, I elaborated my answer in the plugin FAQ ( > > >>>>>>>> > > >>>>>>> https://github.com/apache/cordova-labs/blob/cdvtest/ > > >>>> cordova-plugin-test-framework/README.md#faq > > >>>> > > >>>>> ): > > >>>>>>>> FAQ > > >>>>>>>> > > >>>>>>>> - > > >>>>>>>> > > >>>>>>>> Q: Should I add org.apache.cordova.test-harness as a > > >>>>>>>> <dependancy> > > >>>>>>>> > > >>>>>>> of > > >>>>>> > > >>>>>>> my > > >>>>>>> > > >>>>>>>> plugin? > > >>>>>>>> - A: No. The end-user should decide if they want to install > the > > >>>>>>>> > > >>>>>>> test > > >>>>>> > > >>>>>>> harness, not your plugin (most users won't). > > >>>>>>>> - > > >>>>>>>> > > >>>>>>>> Q: What do I do if my plugin tests must have very large > assets? > > >>>>>>>> - A: Don't bundle those assets with your plugin. If you can, > > have > > >>>>>>>> > > >>>>>>> your > > >>>>>> > > >>>>>>> tests fail gracefully if those assets don't don't exist > > >>>>>>>> > > >>>>>>> (perhaps > > >>>> > > >>>>> log > > >>>>>>> > > >>>>>>>> a > > >>>>>>>> warning, perhaps fail a single asset-checking test, and > skip > > >>>>>>>> > > >>>>>>> the > > >>>> > > >>>>> rest). > > >>>>>>>> Then, ideally download those assets automatically into > local > > >>>>>>>> > > >>>>>>> storage > > >>>>>>> > > >>>>>>>> the > > >>>>>>>> first time tests run. Or create a manual test step to > > download > > >>>>>>>> and install > > >>>>>>>> assets. As a final alternative, split those test assets > > into a > > >>>>>>>> separate > > >>>>>>>> plugin, and instruct users to install that plugin to run > > your > > >>>>>>>> > > >>>>>>> full > > >>>>>> > > >>>>>>> test > > >>>>>>>> suite. > > >>>>>>>> - > > >>>>>>>> > > >>>>>>>> Q: Should I ship my app with the test harness plugin > installed? > > >>>>>>>> - A: Not likely. If you want, you can. Then your app could > even > > >>>>>>>> > > >>>>>>> embed > > >>>>>> > > >>>>>>> a > > >>>>>>> > > >>>>>>>> link to the test page (cdvtests/index.html) from a help > > >>>>>>>> > > >>>>>>> section > > >>>> > > >>>>> of > > >>>>>> > > >>>>>>> your app, to give end users a way to run your test suite > out > > >>>>>>>> > > >>>>>>> in > > >>>> > > >>>>> the feild. > > >>>>>>>> That may help diagnose causes of issues within your app. > > >>>>>>>> > > >>>>>>> Maybe. > > >>>> > > >>>>> > > >>>>>>>> > > >>>>>>>> ============= > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> Feel free the debate those answers -- now is certainly the time > -- > > >>>>>>>> > > >>>>>>> but I > > >>>>>> > > >>>>>>> put a lot of effort to make it super flexible and to not require > > >>>>>>>> > > >>>>>>> depending > > >>>>>>> > > >>>>>>>> on changes to CLI :P > > >>>>>>>> > > >>>>>>>> -Michal > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> On Thu, Jun 19, 2014 at 3:11 PM, Jesse <purplecabb...@gmail.com > > > > >>>>>>>> > > >>>>>>> wrote: > > >>>>>> > > >>>>>>> > > >>>>>>>> Sorry I missed providing feedback on this earlier ... > > >>>>>>>>> Having a deeper look at this, I am not feeling great about the > > >>>>>>>>> > > >>>>>>>> extra > > >>>> > > >>>>> requirement that every plugin have an additional branch. > > >>>>>>>>> > > >>>>>>>>> Several concerns arise : > > >>>>>>>>> - test branch can be out of sync with master > > >>>>>>>>> - how do we test a specific version? > > >>>>>>>>> - tests are not immediately visible when looking at master > > >>>>>>>>> - differing versions of plugin.xml depending on the branch > > >>>>>>>>> > > >>>>>>>>> The majority of the work has been done (thanks Michal!), and > > >>>>>>>>> > > >>>>>>>> mostly > > >>>> > > >>>>> any > > >>>>>> > > >>>>>>> suggestions I make will just require moving code and changing a > > >>>>>>>>> > > >>>>>>>> few > > >>>> > > >>>>> conventions. > > >>>>>>>>> > > >>>>>>>>> What if we? : > > >>>>>>>>> 1. add a plugin-test.xml file which has the exact format of > > >>>>>>>>> > > >>>>>>>> plugin.xml > > >>>>>> > > >>>>>>> 2. keep tests/ and plugin-test.xml file in master branch > > >>>>>>>>> 3. have plugman/cli support an additional flag --test so we can > > >>>>>>>>> > > >>>>>>>> install > > >>>>>> > > >>>>>>> like this: > > >>>>>>>>> cordova plugin add > > >>>>>>>>> > http://git-wip-us.apache.org/repos/asf/cordova-plugin-device.git > > >>>>>>>>> > > >>>>>>>> --test > > >>>>>>> > > >>>>>>>> This would mean that in addition to processing the plugin.xml of > > >>>>>>>>> > > >>>>>>>> the > > >>>> > > >>>>> plugin, we would also process the plugin-test.xml file ( identical > > >>>>>>>>> processing logic ) > > >>>>>>>>> 4. have all plugin-test.xml files declare a dependency on > > >>>>>>>>> cordova-plugin-test-framework > > >>>>>>>>> > > >>>>>>>>> The above suggestions could also be used in conjuction with the > > >>>>>>>>> > > >>>>>>>> cordova > > >>>>>> > > >>>>>>> run > > >>>>>>>> > > >>>>>>>>> --tests platform mentioned by Michal, but without the need to > > >>>>>>>>> > > >>>>>>>> manage > > >>>> > > >>>>> the > > >>>>>>> > > >>>>>>>> switching of branches. > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> @purplecabbage > > >>>>>>>>> risingj.com > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> On Tue, Jun 17, 2014 at 2:16 PM, Michal Mocny < > > >>>>>>>>> > > >>>>>>>> mmo...@chromium.org> > > >>>> > > >>>>> wrote: > > >>>>>>>> > > >>>>>>>>> > > >>>>>>>>> Piotr: Actually I'm not sure how running tests in the harness > > >>>>>>>>>> > > >>>>>>>>> would > > >>>>>> > > >>>>>>> work, > > >>>>>>>> > > >>>>>>>>> since the path to the resource may be different. However, in > > >>>>>>>>>> > > >>>>>>>>> general, > > >>>>>>> > > >>>>>>>> with > > >>>>>>>>> > > >>>>>>>>>> development using the harness you aren't making any changes to > > >>>>>>>>>> > > >>>>>>>>> plugins. > > >>>>>>> > > >>>>>>>> The whole point is for app developers who want to modify only > > >>>>>>>>>> > > >>>>>>>>> web > > >>>> > > >>>>> application bits and not deal with native compiles. > > >>>>>>>>>> > > >>>>>>>>>> In theory the app harness could support working on the > > >>>>>>>>>> > > >>>>>>>>> js-modules > > >>>> > > >>>>> of > > >>>>>> > > >>>>>>> plugins, but that sounds like a really niche idea. I'd not be > > >>>>>>>>>> > > >>>>>>>>> opposed > > >>>>>>> > > >>>>>>>> to > > >>>>>>>> > > >>>>>>>>> someone working on it but I'm not sure you'll have luck finding > > >>>>>>>>>> > > >>>>>>>>> volunteers. > > >>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> -Michal > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> On Tue, Jun 17, 2014 at 5:13 PM, Michal Mocny < > > >>>>>>>>>> > > >>>>>>>>> mmo...@chromium.org> > > >>>>>> > > >>>>>>> wrote: > > >>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> At the time I went through my design iterations I just didn't > > >>>>>>>>>>> > > >>>>>>>>>> want > > >>>>>> > > >>>>>>> to > > >>>>>>> > > >>>>>>>> necessarily depend on cordova tooling changes / documentation. > > >>>>>>>>>>> > > >>>>>>>>>> In > > >>>>>> > > >>>>>>> other > > >>>>>>>>> > > >>>>>>>>>> words, someone else may have a different strategy for > > >>>>>>>>>>> > > >>>>>>>>>> testing.. > > >>>> > > >>>>> > > >>>>>>>>>>> My personal opinion would be have the test plugin ship with a > > >>>>>>>>>>> > > >>>>>>>>>> plugin > > >>>>>>> > > >>>>>>>> hook > > >>>>>>>>> > > >>>>>>>>>> (those are in, right? or at least on their way), that will > > >>>>>>>>>>> > > >>>>>>>>>> automatically > > >>>>>>>>> > > >>>>>>>>>> update the start page if you pass a flag to run command. Ie, > > >>>>>>>>>>> > > >>>>>>>>>> in an > > >>>>>> > > >>>>>>> ideal > > >>>>>>>>> > > >>>>>>>>>> world: `cordova run --tests` runs a plugin hook passing in > > >>>>>>>>>>> > > >>>>>>>>>> --tests > > >>>>>> > > >>>>>>> flag > > >>>>>>>>> > > >>>>>>>>>> which changes the start page, in a way that isn't overwritten > > >>>>>>>>>>> > > >>>>>>>>>> by > > >>>> > > >>>>> the > > >>>>>>> > > >>>>>>>> top-level config.xml. > > >>>>>>>>>>> > > >>>>>>>>>>> My 2 cents, since I don't want "our way" of testing mobile > > >>>>>>>>>>> > > >>>>>>>>>> spec > > >>>> > > >>>>> to > > >>>>>> > > >>>>>>> be > > >>>>>>> > > >>>>>>>> "the > > >>>>>>>>>> > > >>>>>>>>>>> only way" to test. Frameworks and opinions on testing > > >>>>>>>>>>> > > >>>>>>>>>> change. > > >>>> > > >>>>> > > >>>>>>>>>>> -Michal > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> On Tue, Jun 17, 2014 at 4:33 PM, Piotr Zalewa < > > >>>>>>>>>>> > > >>>>>>>>>> pzal...@mozilla.com > > >>>>>> > > >>>>>>> > > >>>>>>>> wrote: > > >>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> One thing more - it would be great if user could create a > > >>>>>>>>>>>> > > >>>>>>>>>>> test > > >>>> > > >>>>> using > > >>>>>>> > > >>>>>>>> test > > >>>>>>>>>> > > >>>>>>>>>>> harness app as well. Is it also considered? > > >>>>>>>>>>>> > > >>>>>>>>>>>> Dnia Tue Jun 17 13:27:22 2014 Martin Gonzalez pisze: > > >>>>>>>>>>>> > > >>>>>>>>>>>> It would be a nice to have in the cli, aimed to just setup > > >>>>>>>>>>>> > > >>>>>>>>>>> the > > >>>> > > >>>>> right > > >>>>>>>> > > >>>>>>>>> path > > >>>>>>>>>> > > >>>>>>>>>>> in the config.xml, maybe along with an another argument to > > >>>>>>>>>>>>> > > >>>>>>>>>>>> build, > > >>>>>> > > >>>>>>> run/emulate as well. > > >>>>>>>>>>>>> It sounds great. > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> 2014-06-17 15:21 GMT-05:00 Piotr Zalewa < > > >>>>>>>>>>>>> > > >>>>>>>>>>>> pzal...@mozilla.com > > >>>> > > >>>>> : > > >>>>>>> > > >>>>>>>> > > >>>>>>>>>>>>> Thanks Martin, > > >>>>>>>>>>>>> > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> Has it been considered to create a separate command > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>> "testrun" or > > >>>>>> > > >>>>>>> similar > > >>>>>>>>>> > > >>>>>>>>>>> which would remove the need to edit the config.xml? > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> Dnia Tue Jun 17 11:58:33 2014 Michal Mocny pisze: > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> Martin, thanks for posting those links. > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> And I'll look into the INFRA tickets I need to file to > set > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>> up a > > >>>>>> > > >>>>>>> repo > > >>>>>>>>> > > >>>>>>>>>> for > > >>>>>>>>>>>>>>> that plugin, since its ready to come out of labs. > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> On Tue, Jun 17, 2014 at 2:06 PM, Martin Gonzalez < > > >>>>>>>>>>>>>>> martin.c.glez.g...@gmail.com> wrote: > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> This is the Cordova Plugin Test Framework readme.md, > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>> you > > >>>> > > >>>>> can > > >>>>>> > > >>>>>>> catch > > >>>>>>>>> > > >>>>>>>>>> up > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> with > > >>>>>>>>>>>>>>>> the functionality by reading some of the content: > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> Repository: > > >>>>>>>>>>>>>>>> https://github.com/apache/cordova-labs > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> Docs: > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> > > https://github.com/apache/cordova-labs/blob/master/README.md > > >>>>>> > > >>>>>>> > > >>>>>>>>>>>>>>>> https://github.com/apache/cordova-labs/blob/cdvtest/ > > >>>>>>>>>>>>>>>> cordova-plugin-test-framework/README.md > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> 2014-06-17 12:56 GMT-05:00 Piotr Zalewa < > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> pzal...@mozilla.com > > >>>>>> > > >>>>>>> : > > >>>>>>>> > > >>>>>>>>> > > >>>>>>>>>>>>>>>> a documentation explaining how it's gonna work > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> Dnia Tue Jun 17 10:51:58 2014 Michal Mocny pisze: > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> What do you mean? > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> On Tue, Jun 17, 2014 at 1:50 PM, Piotr Zalewa < > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> pzal...@mozilla.com> > > >>>>>>>>>> > > >>>>>>>>>>> wrote: > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> Is there any predev document? > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> Dnia Mon Jun 16 18:30:46 2014 Andrew Grieve pisze: > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> Yeah, really exciting. Thanks for taking this on. > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> On Mon, Jun 16, 2014 at 3:42 PM, Michal Mocny < > > >>>>>>>>>>>>>>>>>>>> mmo...@chromium.org> > > >>>>>>>>>>>>>>>>>>>> wrote: > > >>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>> Fantastic! > > >>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>> I'll try to keep an eye out on the PR's, and please > > >>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> ping > > >>>>>> > > >>>>>>> me > > >>>>>>> > > >>>>>>>> if > > >>>>>>>>> > > >>>>>>>>>> you > > >>>>>>>>>>>>>>>>>>>>> would > > >>>>>>>>>>>>>>>>>>>>> like any help. > > >>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>> -Michal > > >>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>> On Mon, Jun 16, 2014 at 3:25 PM, Marcel Kinard < > > >>>>>>>>>>>>>>>>>>>>> cmarc...@gmail.com> > > >>>>>>>>>>>>>>>>>>>>> wrote: > > >>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>> Hi, after some discussions here with IBM > > >>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>> management, > > >>>>>> > > >>>>>>> we’re > > >>>>>>>>> > > >>>>>>>>>> going > > >>>>>>>>>>>>>>>>>>>>> to > > >>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>> bring > > >>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>> in a couple extra interns for a week to jumpstart > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>> the > > >>>> > > >>>>> migration > > >>>>>>>>>> > > >>>>>>>>>>> of > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> the > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>> tests out of mobile-spec into the new plugin test > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> framework. > > >>>>>> > > >>>>>>> Staci > > >>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>>>>>>>>> Cooper > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> will be leading this effort, and Martin Gonzalez > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>> will > > >>>> > > >>>>> be a > > >>>>>>> > > >>>>>>>> part > > >>>>>>>>>> > > >>>>>>>>>>> of > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> it. > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> So if you see a bunch of pull requests, this is what it > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> is > > >>>>>> > > >>>>>>> for. > > >>>>>>>> > > >>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> We’ll > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>> get > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> the interns to submit an ICLA asap. > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> -- > > >>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>> Piotr Zalewa > > >>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> Mozilla > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> -- > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> Piotr Zalewa > > >>>>>>>>>>>>>>>>> Mozilla > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> -- > > >>>>>>>>>>>>>>>> Regards, > > >>>>>>>>>>>>>>>> Martin Gonzalez > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> -- > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>> Piotr Zalewa > > >>>>>>>>>>>>>> Mozilla > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>> -- > > >>>>>>>>>>>> Piotr Zalewa > > >>>>>>>>>>>> Mozilla > > >>>>>>>>>>>> > > >>>>>>>>>>> > > >>>> > > > -- > > > Piotr Zalewa > > > Mozilla > > > > > > > > > -- > Regards, > Martin Gonzalez >
