Cordova things

[David Kemp]

Hi all,
I will be moving on to a different team and will likely not contribute much
to Cordova. Its been a slice, but other exciting things await.

Max will be handling Medic/CI stuff and helping to keep ci.cordova.io green.

Maybe I can get my next team to build apps with Cordova...

Happy bug hunting,
David Kemp

Re: Proposal: remove platform versions from platfroms.js

[David Kemp]

It seems to me that:
1) to make our users happy and get them to consider using newer versions,
we need to have the perception of stability. Nice clean, well tested,
co-ordinated releases are a good way to get that. For that reason, I think
a method of providing a 'pinned' release set for the end user is a good way
to deliver that.
2) to make it easy and fast for the various platform contributors to
release new stuff, we need independent platform versioning. That would
allow platforms to move ahead separately - as long as all tooling is
backward compatible.

We should be able to do both.



On Thu, Jul 24, 2014 at 1:38 PM, Brian LeRoux  wrote:

> I am against this change. I am in favor of adding platforms via
> package.json, however.
>
> We need to version lock our dependencies in the CLI. Testing and bug
> resolution will be impossible otherwise. (We did this for that reason.)
> However, the Platforms don't need to be synchronized. Platforms can release
> as they want and the CLI can pick them up as needs be BUT the versioning of
> dependencies needs to be explicit.
>
> The only way 'always grab latest' works is when master is pristine and all
> development happens on topic branches only to be merged in when everything
> works. That is not a capability we currently have.
>
> "This makes it impossible to release new versions of platforms that would
> be
> usable with the same version of CLI." <--- this is a feature, not a bug!
> When we want to bump the platforms we *should* have to bump the CLI as it
> is a dependency.
>
>
>
> On Thu, Jul 24, 2014 at 9:19 AM, Andrew Grieve 
> wrote:
>
> > On Thu, Jul 24, 2014 at 10:40 AM, Chuck Lantz 
> > wrote:
> >
> > > To me it sounds like we're talking about something bigger than pinning:
> > > What does a Cordova version actually mean?
> > >
> > > When new macro-level "Cordova" features like splash screens and icons
> > > support or perhaps coming up with a way to manage code signing and
> > > packaging without going into native projects are released, we'll need
> to
> > be
> > > able to coordinate a release across a number of different platforms.
>  So,
> > > the way I've always thought about this from and end user perspective
> is:
> >
> >
> > Certainly having platforms at different versions will be a change from
> what
> > we've had historically. Still, I think it will be for the better.
> >
> >
> > >
> > > -Updating the first digit is done for major Cordova level features that
> > > affect everyone - and force everyone to change
> > >
> > But what if only one platform has a change that requires action? Do we
> not
> > bump the major then?, Or do we bump the major and users of other
> platforms
> > discover it doesn't actually affect them.
> >
> >
> > > -Updating the second digit is about incremental improvements that still
> > > constitute new Cordova level features but may only support certain
> > platforms
> >
> > -Updating the last digit ties to bug fixes, perf improvements, and other
> > > things that do not have a direct effect on end users
> >
> >
> > > Two questions:
> > > -How will documentation work if platforms go to versions independent of
> > > one another?  For example, consider this:
> > >
> > > Android goes to Cordova 3.7.0 one week
> > > iOS goes to Cordova 3.7.0 two weeks later
> >
> >
> > > Does the documentation for the same version update?
> > >
> >
> > I think the easiest way is to just not version the docs. Just have them
> > always be up-to-date for all released platforms.
> >
> >
> >
> > >
> > > -Are we saying that there will never be shared infrastructure across
> > > platforms that the CLI needs?  Otherwise you could get in a situation
> > where
> > > the CLI revs and only one or two platforms are actually supported.
>  Given
> > > Cordova really is about cross-platform/multi-device development, is
> that
> > a
> > > message we want to send to end users?  What about plugins?
> > >
> >
> > The latest version of CLI must always support all plugins (even old
> ones),
> > and all platform versions (even old ones). This (I believe), is already
> the
> > case today, and is not too hard to maintain.
> >
> >
> >
> > >
> > > I also think this commits the community to testing the CLI across a
> > number
> > > of different versions over time. The CLI would need to be validated
> > across
> > > a number of different major and minor versions which increases the test
> > > burden.
> > >
> >
> > I believe this to already be the case. The current workflow is:
> >
> > 1. Install a platform (say, android 3.2)
> > 2. Update CLI to 3.5.0
> > 3. CLI now expected to work with version of platform you have installed.
> > 4. Decide you want to update your platform via "cordova platform update
> > android"
> > 5. Now, your project is at android 3.5.0
> >
> >
> >
> > >
> > > I would argue that plugins are a potential problem right now - the
> moment
> > > a core plugin drops support for a Cordova version that people are using
> > > widely, I think w

Re: Pointing docs to edge

[David Kemp]

I would prefer to have the 'coming soon' stuff more visible.
I like the idea that when looking for how to do something, its easy to see
improvements that have already landed - and I can possibly get just by
grabbing a bleeding edge plugin/tool.



On Mon, Jul 14, 2014 at 1:25 PM, Max Woghiren  wrote:

> I agree.  I think 3 is my preferred option; I think it lends itself best to
> a sustainable and straightforward workflow.
>
> Docs fixes relevant to the current release of the CLI and each platform can
> be committed directly to master.  Unreleased changes can be committed to
> the appropriate branch, and we can add the merging of the branch as a step
> in the release process.
>
>
> On Mon, Jul 14, 2014 at 1:06 PM, Ray Camden  wrote:
>
> > Personally I'd rather not have any "coming soon" paragraphs in the doc
> > text. As a user, if I'm at the docs, I don't care what is coming next.
> I'm
> > trying to solve a problem I have *now*, or trying to build now. Anything
> > that is coming soon is a distractor.
> >
> > Do I feel strongly about it? No, but I'd vote against it being in the
> docs
> > at all. Stuff like that should definitely be communicated to users - via
> > the Cordova blog perhaps - but not in the mainline docs.
> >
> > 
> > From: m...@google.com  on behalf of Max Woghiren <
> > m...@chromium.org>
> > Sent: Monday, July 14, 2014 10:27 AM
> > To: dev
> > Subject: Re: Pointing docs to edge
> >
> > Okay, so here are the current proposals for handling Ray's issue (thanks
> > Ray!):
> >
> > 1. Update docs at commit-time and release-time.  At commit-time,
> > documentation changes can be marked with "coming soon", or "removed in
> next
> > release", or whatever the relevant message is.  At release-time, docs are
> > further updated to remove these sub-messages.
> >
> > 2. Use CSS to do the manual marking in proposal 1.  We could also use it
> to
> >
>

Re: Monthly Cordova hangouts

[David Kemp]

The call is scheduled for tomorrow evening.
On 14 Jul 2014 11:44, "Parashuram Narasimhan (MS OPEN TECH)" <
panar...@microsoft.com> wrote:

> Just wondering if we already had the Monthly hangouts for this month. We
> usually have it on 15th every month, right ?
> Also, I remember that from the last hangout, we had trouble getting more
> than 10 people into the hangout. Do we want to try alternate solutions
> (Webex, Lync, or a conference bridge) that can let more people participate?
>

Re: For review: Blog Post for Contacts and Network Information plugin release

[David Kemp]

readding => re-adding



On Tue, Jul 8, 2014 at 11:56 AM, Ian Clelland 
wrote:

> I have this draft ready to go out for the two contacts updated recently,
> and need someone to take a look and review it before I do that.
>
> Thanks,
> Ian
>
> ---
>
> ---
> layout: post
> author:
> name: Ian Clelland
> url: https://twitter.com/iclelland
> title:  "Plugins Release: July 8, 2014"
> categories: news
> tags: release plugins
> ---
> The following plugins have just been updated:
>
> * cordova-plugin-contacts: 0.2.11
> * cordova-plugin-network-information: 0.2.10
>
> Notable changes include:
> * The network-information plugin no longer crashes immediately if no
> network is available
> * navigator.contacts.pickContact API has been added for **Android**,
> **iOS**, **Windows Phone 8** and **Windows 8 platforms**
> * Contacts on **Firefox OS** no longer requires manual change of the
> application permissions
>
> The plugins have been updated on our registry at [plugins.cordova.io](
> http://plugins.cordova.io/).
>
> 
> You can update any plugin by removing it, and then readding it. E.g. To
> update your contacts plugin:
>
> cordova plugin rm org.apache.cordova.contacts
> cordova plugin add org.apache.cordova.contacts
>
> Other changes include:
> 
>
> `org.apache.cordova.contacts@0.2.11`
>
> * [CB-6127](https://issues.apache.org/jira/browse/CB-6127) Spanish and
> French Translations added.
> * [CB-6797](https://issues.apache.org/jira/browse/CB-6797) Add license
> * [CB-5416](https://issues.apache.org/jira/browse/CB-5416) Adding support
> for auto-managing permissions
> * [CB-6682](https://issues.apache.org/jira/browse/CB-6682) Move **Windows
> 8** command proxy into it's missing platform tag.
> * [CB-6491](https://issues.apache.org/jira/browse/CB-6491) Add
> CONTRIBUTING.md
> * [CB-5698](https://issues.apache.org/jira/browse/CB-5698) **iOS**: Check
> to see if photoData exists before using
> * [CB-7003](https://issues.apache.org/jira/browse/CB-7003) **Android**:
> Make pickContact pick correct contact on Android 4.3 and 4.4.3
> * Remove deprecated symbols for **iOS** < 6
> * **Windows Phone 8** now populates contact photos
> * Update license headers format
> * Add pickContact functionality to cordova contacts plugin
> * Add ContactError codes to index.md doc
> * Docs typo: navigator.contacts.length -> contacts.length
>
> `org.apache.cordova.network-information@0.2.10`
>
> * [CB-6907](https://issues.apache.org/jira/browse/CB-6907): **Android**:
> Don't crash on startup if no networks available
>

Re: [VOTE] Contacts plugin release

[David Kemp]

+1

   - verified signature and hashes using `coho verify-archive`

cordova-plugin-contacts-r0.2.11-rc3.zip signature and hashes verified.


   - verified that the contents of the zip match the contents of the repo
   at 104c565615 using `diff -r`

Only in [the contacts repo]: .git



On Wed, Jul 2, 2014 at 12:28 PM, Max Woghiren  wrote:

> +1
>
>- verified signature and hashes using `coho verify-archive`
>
> cordova-plugin-contacts-r0.2.11-rc3.zip signature and hashes verified.
>
>
>- verified that the contents of the zip match the contents of the repo
>at 104c565615 using `diff -r`
>
> Only in [the contacts repo]: .git
>
>
>
> On Wed, Jul 2, 2014 at 11:47 AM, Ian Clelland 
> wrote:
>
> > Please review and vote on the release of this plugins release.
> >
> > Release issue: https://issues.apache.org/jira/browse/CB-7040
> >
> > The plugins have been published to dist/dev:
> > https://dist.apache.org/repos/dist/dev/cordova/CB-7040/
> >
> > The packages were published from their corresponding git tags:
> > cordova-plugin-contacts: 0.2.11-rc3 (104c565615)
> >
> > Upon a successful vote I will upload the archives to dist/, upload them
> to
> > the Plugins Registry, and post the corresponding blog post.
> >
> > Voting guidelines:
> >
> https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
> >
> > Voting will go on for a minimum of 48 hours.
> >
> > I vote +1:
> > * Ran coho audit-license-headers over the relevant repos
> > * Ensured that mobile spec tests for contacts were all passing on android
> > and ios
> >
>

Medic/CI - Holiday!

[David Kemp]

Just in case anyone is checking...
The CI system will not have any test slaves this long weekend so all tests
will stop.
We will be back online Tuesday morning.

Current State: All cordova tests are GREEN

Related news: the CI deletes any shinkwrap file found, but doesn't fail if
there isn't one. It had been deleting it, but failing if it wasn't present.
Now it just doesn't care :)

CI failure in CLI

[David Kemp]

It appears that the plugman commit 57a5eaa1357f1f70d85437b9bb2d8f322bc39bc2
from April 8 broke the build for iOS. Android is OK.

If this requires a change to the test procedure, let me know - otherwise it
should be fixed/rolled back.

Details below..

TypeError: Cannot read property 'parents' of undefined
at PlatformMunger_apply_file_munge [as apply_file_munge]
(/Users/medic/buildbot/slave_ios/IOS_Release/build/cordova-cli/node_modules/plugman/src/util/config-changes.js:156:35)
at PlatformMunger.reapply_global_munge
(/Users/medic/buildbot/slave_ios/IOS_Release/build/cordova-cli/node_modules/plugman/src/util/config-changes.js:283:14)
at 
/Users/medic/buildbot/slave_ios/IOS_Release/build/cordova-cli/src/prepare.js:105:24
at _fulfilled
(/Users/medic/buildbot/slave_ios/IOS_Release/build/cordova-cli/node_modules/q/q.js:798:54)
at self.promiseDispatch.done
(/Users/medic/buildbot/slave_ios/IOS_Release/build/cordova-cli/node_modules/q/q.js:827:30)
at Promise.promise.promiseDispatch
(/Users/medic/buildbot/slave_ios/IOS_Release/build/cordova-cli/node_modules/q/q.js:760:13)
at 
/Users/medic/buildbot/slave_ios/IOS_Release/build/cordova-cli/node_modules/q/q.js:821:14
at flush 
(/Users/medic/buildbot/slave_ios/IOS_Release/build/cordova-cli/node_modules/q/q.js:108:17)
at process._tickCallback (node.js:415:13)
at Function.Module.runMain (module.js:499:11)program finished with
exit code 1
elapsedTime=1.089107

Re: Ship stage.plugins.cordova.io

[David Kemp]

Love the fact that its usable on my phone!

LGTM


On Fri, Apr 4, 2014 at 1:12 PM, Andrew Grieve  wrote:

> Just did some clicking through. It's night & day better than what's on
> plugins.cordova.io. Ship it!
>
>
> On Fri, Apr 4, 2014 at 1:11 AM, Steven Gill 
> wrote:
>
> > Hey All,
> >
> > I am wanting to switch over stage.plugins.cordova.io to
> plugins.cordova.io
> > .
> > Feature wise it is on par with the existing site. We are still working on
> > polish + a few additional features, but I believe we could work on them
> > while the site is live.
> >
> > You can view our progress at
> https://issues.apache.org/jira/browse/CB-5130
> > .
> > The source code + getting started instructions are available at
> > https://github.com/apache/cordova-registry-web/tree/refactor
> >
> > Please let me know if you have any concerns or feedback before I move
> > forward with this. I would like to ship it this weekend so it would be
> > ready for ApacheCon.
> >
> > Hopefully having it live would drive a more people to contribute + report
> > issues! :)
> >
> > Thanks!
> > -Steve
> >
>

Re: [VOTE] cordoav-cli@3.4.1-0.1.0, cordova-plugman@0.21.0 and cordova-ios@3.4.1

[David Kemp]

If we make the proposed change to the CLI package.json (change the plugman
dependency to ">=0.21.0-rc"),
then all that is required for testing is to delete the shrinkwrap file.

That means a little less hackery to test the package that is being voted on.

We have currently made those changes on the fly in the CI to get it working
again.



On Fri, Apr 4, 2014 at 12:57 PM, Bryan Higgins wrote:

> The other problem we face is the actual repo being unusable for a period of
> time unless you know how to fiddle with package.json / npm-shrinkwrap.json.
>
> At the very least this should be pointed out on the README, but even that
> doesn't seem friendly to potential contributors.
>
> I'm in favour of bumping the version number in CLI after the vote for cases
> like this where we're releasing tools together. Those testing the CLI for
> release can bump up the plugman version locally.
>
> Otherwise we should vote on plugman first, then update CLI and vote on
> that...
>
>
> On Fri, Apr 4, 2014 at 12:33 PM, Parashuram Narasimhan (MS OPEN TECH) <
> panar...@microsoft.com> wrote:
>
> > Can we also include the Windows Phone and Windows Platform, specifically
> > for the following bugs/pull requests
> >
> > 1.  Windows 8 - https://github.com/apache/cordova-windows/pull/20 -
> > This is more of a regression in case VS2013 is installed. With the build
> > announcement yesterday, this could be higher priority. Note that this is
> > not yet merged in.
> > 2.  Windows Phone 8 - https://github.com/apache/cordova-wp8/pull/28-
> > This could affect the users using the emulator.
> >
> > -Original Message-
> > From: Axel Nennker [mailto:ignisvul...@gmail.com]
> > Sent: Friday, April 4, 2014 9:21 AM
> > To: dev
> > Subject: Re: [VOTE] cordoav-cli@3.4.1-0.1.0, cordova-plugman@0.21.0 and
> > cordova-ios@3.4.1
> >
> > Is there a chance to get the cb-2606 patch for launcer icon support into
> a
> > release some time no too far?
> >
> > Axel
> > Am 04.04.2014 10:01 schrieb "Steven Gill" :
> >
> > > Please review and vote on the release of this cordova-cli,
> > > cordova-plugman and cordova-ios release.
> > >
> > > cordova-cli@3.4.1-0.1.0, cordova-plugman@0.21.0 and cordova-ios@3.4.1
> > > have been published here:
> > > *https://dist.apache.org/repos/dist/dev/cordova/CB-6245/
> > > *
> > >
> > >
> > > The packages were published from their corresponding git tags:
> > > cordova-cli: 3.4.1-0.1.0 (b769a304be)
> > > cordova-plugman: 0.21.0 (b2f3a130d3)
> > > cordova-ios: 3.4.1 (a96d2360fa)
> > >
> > > Upon a successful vote I will upload the cli & plugman archives to
> > > dist/ and publish them to npm. Cordova-ios will be uploaded to
> > > dist/platforms. I will then post the corresponding blog post.
> > >
> > > Voting will go on for a minimum of 24 hours.
> > >
> > > I vote +1.
> > >
> > > If people want individual vote threads for each item, let me know and
> > > I will create them instead of this thread.
> > >
> >
>

Re: Looking at the new File API pragmatically

[David Kemp]

So in summary
 make toURL() return the same thing that toNativeURL() does now.
 do nothing to toNativeURL()
 maybe later add a toCdvURL()

If thats correct, then +1




On Tue, Apr 1, 2014 at 4:50 AM, Anis KADRI  wrote:

> On Tue, Apr 1, 2014 at 3:28 AM, Ian Clelland 
> wrote:
>
> > On Mon, Mar 31, 2014 at 4:33 PM, Ian Clelland  > >wrote:
> >
> > > On Mon, Mar 31, 2014 at 4:20 PM, Michal Mocny 
> > wrote:
> > >
> > >> On Mon, Mar 31, 2014 at 3:39 PM, Ian Clelland  > >> >wrote:
> > >> > This is ugly, though, and is going to get worse over time, and
> become
> > a
> > >> > division between Cordova and any platforms which actually implement
> > the
> > >> > File API correctly. I'd like to propose switching the behaviour of
> > >> > .toURL(), to match .toNativeURL -- returning a webview-usable URL by
> > >> > default -- and implementing some other method or property to get the
> > CDV
> > >> > URL when it's necessary.
> > >> >
> > >>
> > >> Everything you've said sounds like its all upside to make the switch.
> >  So
> > >> I'm curious, when would CDV URL be necessary/useful over file/content
> > >> urls?
> > >>
> > >
> > > cdvfile:// URLs would still be necessary when dealing with files that
> > just
> > > don't *have* an alternate representation. There currently aren't any of
> > > those, but we could implement virtual file systems entirely inside of a
> > > plugin, and those would require a cdvfile:// URL to be read.
> > >
> > > I think we'd recommend them when saving URLs to persistent storage, if
> > > there is any chance that the actual files could be moved / migrated,
> and
> > we
> > > could hide that from the user by giving them a more abstract identifier
> > > than one which specifies a physical location.
> > > cdvfile://localhost/persistent/my/file.txt might be more durable over
> > time
> > > than file:///data/data/com.company.package/files/my/file.txt, perhaps
> > > across OS upgrades.
> > >
> >
> > Actually, forget all of that.
> >
> > Your question had me looking for reasons to advocate users using
> cdvfile://
> > URLs, when perhaps none exist. The truth of the matter is this: The
> cdvfile
> > URL has two parts: the filesystem name, and the full path. Those two
> parts
> > form a consistent internal representation for all of the types of file
> that
> > the plugin can handle, and so all of the internal / native bits of the
> file
> > plugin use them almost exclusively. We make sure that every FileEntry and
> > DirectoryEntry has those parts, and we only need to turn them into a URL
> > for passing them across the bridge.
> >
> > One day someone may discover a great reason to use deliberately use
> cdvfile
> > URLs at the application level; until then, they're available, and we can
> > continue to use them internally to simplify the plugin code, enforce the
> > sandboxing, and make everything generally more consistent and efficient,
> > and users shouldn't need to know or care what the URLs in use actually
> are.
> >
>
> I agree with this as long as the URLs are useable in the WebView (as src
> attributes for example). If they're not, I also suggest that we return URLs
> that are useable (file:///, content:/// or whatever) by default.
>
> As for filesystems (temp or persistent), I think most developers will use
> whatever the default is. BUT they should be able to specify where they want
> to store their data if they feel like it without using a third-party
> plugin.
>
>
> >
> > Ian
> >
>

Re: Many CLI tests failing

[David Kemp]

I have just verified the plugman state and on my machine I get the same 7
errors that Medic gets.
All of them are related to version comparisions.




On Thu, Mar 27, 2014 at 6:17 PM, Steven Gill  wrote:

> All tests seem to be passing now.
>
> Medic is showing plugman tests failing after the tizen commits, but they
> are passing fine for me.
>
>
> On Wed, Mar 26, 2014 at 10:05 AM, Andrew Grieve  >wrote:
>
> > On Wed, Mar 26, 2014 at 9:05 AM, Josh Soref 
> wrote:
> >
> > > https://github.com/blackberry/cordova-cli/tree/cb_6337
> > >
> > > Should cover both of my breaks.
> > >
> > > I¹m waiting for our CI tooling to confirm it¹s happy before I submit a
> > > pull request for it.
> > >
> > > Maybe sometime in the near future I¹ll try to rework the tests to use
> an
> > > in-memory-psuedo-filesystem so that we can stop having to add all these
> > > stupid lies.
> > >
> > > Tests shouldn¹t be so brittle that changing code which has no relation
> to
> > > a test results in a broken test. If we¹re lying and pretending that
> > > there¹s e.g. a "lib/dir", then that directory needs to sufficiently
> exist
> > > ‹ adding code which makes a perfectly reasonable assumption ³this
> > > directory which someone claimed exists exists² shouldn¹t break a test
> > > which pretended the directory existed.
> > >
> >
> > Agree 100% with your sentiments here, and also agree that an in-memory
> > filesystem is the best way to make our tests decent.
> >
> > >
> > > The CordovaError bit is different (and entirely my fault), I think I
> must
> > > have failed to commit the requires update, because I remember doing the
> > > greps for it...
> > >
> > >
> >
>

Re: ios-deploy issues

[David Kemp]

Thanks!
I have updated Medic and at the moment ios-deploy is working correctly.



On Thu, Mar 27, 2014 at 6:29 PM, Shazron  wrote:

> ios-deploy 1.0.6 published to npm.
> https://github.com/phonegap/ios-deploy/releases/tag/1.0.6
>
> Added non-interactive, port flags. Removed python wrapper.
>
> - Two flags added:
> (-p/--port) flag (port used for device debugging, default is 12345)
> (-I/--noninteractive) flag (start in non interactive mode - quit when app
> crashes or exits)
>
> - Python wrapper shell removed.
> - App does not hang when being called from a shell script now
>
>
> On Tue, Mar 25, 2014 at 10:13 AM, David Kemp  wrote:
>
> > Awesome! We will check it out again.
> > Our success with ios-deploy in the automated test environment has been
> very
> > poor. It correctly deploys & launches somewhat less than 5% of the time.
> > Generally the deploy will work, then it fails to launch for one reason or
> > another.
> >
> > Hoping for better success!
> >
> >
> > On Fri, Mar 21, 2014 at 4:19 PM, Shazron  wrote:
> >
> > > The problem with ios-deploy that I have right now is, it works on its
> own
> > > on the command line, but now hangs if I call it through cordova/run (it
> > > deploys to device, runs it, but hangs at the splash screen) -- weird
> > >
> > >
> > > On Fri, Mar 21, 2014 at 4:06 PM, Shazron  wrote:
> > >
> > > > ios-deploy 1.0.5 published.
> > > > Fixes the problem where you only get to a usable state after over a
> > > > minute. Now it does so after 5s.
> > > >
> > > >
> > > > On Fri, Dec 13, 2013 at 1:04 PM, Shazron  wrote:
> > > >
> > > >> Yup I've been looking at the issues today - how coincidental.
> > > >> There's been new code that I've been testing, but I'm having
> problems:
> > > >> https://github.com/phonegap/ios-deploy/pull/12
> > > >>
> > > >>
> > > >>
> > > >> On Fri, Dec 13, 2013 at 1:02 PM, David Kemp 
> > > wrote:
> > > >>
> > > >>> Hi all,
> > > >>> I am having pretty regular problems with phonegap/ios-deploy. It
> > seems
> > > >>> generally unreliable, failing about 30-40% of the time. A very
> common
> > > >>> failure mode is:
> > > >>>
> > > >>> Assertion failed: (AMDeviceStartService(device,
> > > >>> CFSTR("com.apple.debugserver"), &gdbfd, NULL) == 0), function
> > > >>> start_remote_debug_server, file ios-deploy.c, line 524.
> > > >>>
> > > >>> I seem to have the newest published version, is anyone looking at
> > this?
> > > >>>
> > > >>> I note that this has been reported by someone else as well:
> > > >>>
> > > >>> https://github.com/phonegap/ios-deploy/issues/11
> > > >>>
> > > >>
> > > >>
> > > >
> > >
> >
>

Re: Get your test results here! Medic/CI viewing available

[David Kemp]

Hi folks,
We thought this was fixed, but we continue to have trouble with the
automated iOS deployment. It works fine for a while and then starts failing
to run the app. It always deploys the app, just often fails to then start
it and run the test. As a result, the iOS tests are often incorrectly in a
fail state - you can tell with a little inspection that the test did not
deploy (as opposed to failed).

On a more positive note, for any mobile tests that run (Android or iOS),
the shell output in the last step contains a link to the couchdb results
page for that test. If there are errors, you can see the details there.



On Wed, Mar 26, 2014 at 2:53 PM, Mike Billau  wrote:

> This is awesome!
>
> We have had to push back our medic update do to resources but this is a lot
> of encouragement to get our buildbot up and running again.
>
> I guess the next step would be setting up a dashboard for the CouchDB so
> that we can easily aggregate data from other teams running medic in
> different labs?
>
>
> On Wed, Mar 26, 2014 at 2:41 PM, Steven Gill 
> wrote:
>
> > I just set up ci.cordova.io to point there!
> >
> > I'm guessing Adobe/Blackberry Net block it due to the port.
> >
> >
> >
> >
> > On Wed, Mar 26, 2014 at 11:39 AM, Marcel Kinard 
> > wrote:
> >
> > > I'm able to see it from the IBM corporate network.
> > >
> > > Looks nice. Great work, David!
> > >
> > > On Mar 25, 2014, at 11:05 PM, Brian LeRoux  wrote:
> > >
> > > > we should get the dns pointing there ci.cordova.io ??
> > >
> > > If it is ready for that, sounds like a great next step.
> > >
> >
>

Re: [DISCUSS] Serial API

[David Kemp]

I have been looking at a serial plugin for a personal project.
In my case I am looking at a chrome
apicompatible version, which
is specifically for chatting with an Arduino
using USB. The Arduino incorporates the the FTDI or prolific usb-serial
interface, so its a bit like solution 2 in the link Marcel sent:
https://code.google.com/p/android-serialport-api/wiki/android_to_rs232_guideline

Not strictly related, but yet another standard...



On Thu, Mar 20, 2014 at 7:54 PM, Brian LeRoux  wrote:

> http://whatwg.github.io/serial/
>

Re: Many CLI tests failing

[David Kemp]

We will have to look into why some people can't get to the machine. It's
not that the server is down or slow, its being blocked for some people.
 On Mar 25, 2014 9:37 PM, "Max Woghiren"  wrote:

> Josh is having trouble accessing the buildbot page, so here is the relevant
> information.
>
> Lorin's relevant commit:
>
>
> https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=commit;h=79e571953c2d3459b459c02eb50e753308fd453d
>
> Josh's relevant commits:
>
>
> https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=commit;h=07181e4ee3e358b7af7674a4ae68fe06552b2655(platform
> parsers)
>
> https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=commit;h=edecaf9193e8b23c6b7e209c6893491497021082(create.js)
>
> Lorin's commit led to errors 2-5.  The remainder are the result of Josh's
> commits.
>
> The text of the failed tests:
>
> 1) hooker should throw if provided directory is not a cordova project
>Message:
>   [31mExpected function to throw Not a Cordova project, can't use
> hooks. , but it threw Not a Cordova project
> ("/var/folders/p5/b_w_jqzj2jd64nz22dnv7xzcgn/T/e2e-test/hooks_test"),
> can't use hooks. [0m
>Stacktrace:
>  Error: Expected function to throw Not a Cordova project, can't
> use hooks. , but it threw Not a Cordova project
> ("/var/folders/p5/b_w_jqzj2jd64nz22dnv7xzcgn/T/e2e-test/hooks_test"),
> can't use hooks.
> at null.
>
> (/Users/medic/buildbot/slave_common/Tools_CLI/build/cordova-cli/e2e/hooker.spec.js:53:12)
>
>   2) create command callback should return null if a callback parameter is
> used
>Message:
>   [31mReferenceError: foobar is not defined [0m
>Stacktrace:
>  ReferenceError: foobar is not defined
> at null.
>
> (/Users/medic/buildbot/slave_common/Tools_CLI/build/cordova-cli/spec/create.spec.js:79:66)
>
>   3) create command callback should return null if a callback parameter is
> used
>Message:
>   [31mtimeout: timed out after 1 msec waiting for something to
> happen [0m
>Stacktrace:
>  undefined
>
>   4) create command callback should call the callback function if
> callback parameter is used
>Message:
>   [31mReferenceError: foobar is not defined [0m
>Stacktrace:
>  ReferenceError: foobar is not defined
> at null.
>
> (/Users/medic/buildbot/slave_common/Tools_CLI/build/cordova-cli/spec/create.spec.js:79:66)
>
>   5) create command callback should call the callback function if
> callback parameter is used
>Message:
>   [31mtimeout: timed out after 1 msec waiting for something to
> happen [0m
>Stacktrace:
>  undefined
>
>   6) create command success should create top-level directory
> structure appropriate for a cordova-cli project
>Message:
>   [31mtimeout: timed out after 1 msec waiting for spec to complete
> [0m
>Stacktrace:
>  undefined
>
>   7) create command success should create hooks directory
>Message:
>   [31mtimeout: timed out after 1 msec waiting for spec to complete
> [0m
>Stacktrace:
>  undefined
>
>   8) create command success should by default use
> cordova-app-hello-world as www assets
>Message:
>   [31mtimeout: timed out after 1 msec waiting for spec to complete
> [0m
>Stacktrace:
>  undefined
>
>   9) create command success should try to lazy load custom www
> location if specified
>Message:
>   [31mtimeout: timed out after 1 msec waiting for spec to complete
> [0m
>Stacktrace:
>  undefined
>
>   10) create command success should add a missing www/config.xml
>Message:
>   [31mtimeout: timed out after 1 msec waiting for spec to complete
> [0m
>Stacktrace:
>  undefined
>
>   11) create command success should not replace an existing www/config.xml
>Message:
>   [31mtimeout: timed out after 1 msec waiting for spec to complete
> [0m
>Stacktrace:
>  undefined
>
>   12) android project parser constructions should throw if provided
> directory does not contain an AndroidManifest.xml
>Message:
>   [31mExpected function to throw The provided path "some/path" is
> not an Android project. , but it threw CordovaError is not defined [0m
>Stacktrace:
>  Error: Expected function to throw The provided path "some/path"
> is not an Android project. , but it threw CordovaError is not defined
> at null.
>
> (/Users/medic/buildbot/slave_common/Tools_CLI/build/cordova-cli/spec/metadata/android_parser.spec.js:71:16)
>
>   13) blackberry10 project parser constructions should throw an
> exception with a path that is not a native blackberry project
>Message:
>   [31mExpected function to throw The provided path "/some/path" is
> not a Cordova BlackBerry10 project. , but it threw CordovaError is not
> defined [0m
>Stacktrace:
>  Error: Expected function to throw The provided path "/some/path"
> is not a Cordova BlackBerry10 project. , but it threw CordovaError is
> not defined
> at null.
>
> (/Users/medic/buildbot

Re: Get your test results here! Medic/CI viewing available

[David Kemp]

It is not down currently. I haven't had any downtime except a few minutes
about 4 hours ago when we re-configured it.



On Tue, Mar 25, 2014 at 4:23 PM, Steven Gill  wrote:

> Either Adobe NET is blocking me or it is down.
>
>
> On Tue, Mar 25, 2014 at 1:50 PM, David Kemp  wrote:
>
> > Hi all,
> > After many months of delays, we now have our Buildbot master available
> for
> > the community to view. You can see the status of the tests for Android,
> > iOS, CLI and Plugman,
> >
> > You can see/view the build display at:
> >
> > http://108.170.217.131:8010/waterfall or http://goo.gl/UNijok
> >
> > For those not familiar with Buildbot, each phase of the test has a
> 'stdio'
> > link that allows you to see any command output from that step. If a step
> > fails (stopping the build) you can generally just click the link and see
> > the error messages.
> > Test results are saved in a couchDB for posterity, but there is no pretty
> > dashboard for that.
> >
> > *Currently Configuration:*
> > Android Master : master platform, dev plugins, master CLI, master Plugman
> > Android Release : 3.4.x platform, master plugins, master CLI, master
> > Plugman
> > iOS Master : master platform, dev plugins, master CLI, master Plugman
> > iOS Release : 3.4.x platform, master plugins, master CLI, master Plugman
> > Tools CLI Master : master CLI, master Plugman
> > Tools Plugman : master plugman
> > Chrome Desktop : Chrome API tests on release Chrome
> > Chrome Mobile : Chrome API tests on cca - android
> >
> > Note that the last two tests are for our Chrome Apps on Mobile toolchain
> > (not part of Cordova).
> >
> > Android and iOS tests currently run on only one device:  iPad mini v7.0
> >  and Nexus 7 v4.3
> >
>

Get your test results here! Medic/CI viewing available

[David Kemp]

Hi all,
After many months of delays, we now have our Buildbot master available for
the community to view. You can see the status of the tests for Android,
iOS, CLI and Plugman,

You can see/view the build display at:

http://108.170.217.131:8010/waterfall or http://goo.gl/UNijok

For those not familiar with Buildbot, each phase of the test has a 'stdio'
link that allows you to see any command output from that step. If a step
fails (stopping the build) you can generally just click the link and see
the error messages.
Test results are saved in a couchDB for posterity, but there is no pretty
dashboard for that.

*Currently Configuration:*
Android Master : master platform, dev plugins, master CLI, master Plugman
Android Release : 3.4.x platform, master plugins, master CLI, master Plugman
iOS Master : master platform, dev plugins, master CLI, master Plugman
iOS Release : 3.4.x platform, master plugins, master CLI, master Plugman
Tools CLI Master : master CLI, master Plugman
Tools Plugman : master plugman
Chrome Desktop : Chrome API tests on release Chrome
Chrome Mobile : Chrome API tests on cca - android

Note that the last two tests are for our Chrome Apps on Mobile toolchain
(not part of Cordova).

Android and iOS tests currently run on only one device:  iPad mini v7.0
 and Nexus 7 v4.3

Re: ios-deploy issues

[David Kemp]

Awesome! We will check it out again.
Our success with ios-deploy in the automated test environment has been very
poor. It correctly deploys & launches somewhat less than 5% of the time.
Generally the deploy will work, then it fails to launch for one reason or
another.

Hoping for better success!


On Fri, Mar 21, 2014 at 4:19 PM, Shazron  wrote:

> The problem with ios-deploy that I have right now is, it works on its own
> on the command line, but now hangs if I call it through cordova/run (it
> deploys to device, runs it, but hangs at the splash screen) -- weird
>
>
> On Fri, Mar 21, 2014 at 4:06 PM, Shazron  wrote:
>
> > ios-deploy 1.0.5 published.
> > Fixes the problem where you only get to a usable state after over a
> > minute. Now it does so after 5s.
> >
> >
> > On Fri, Dec 13, 2013 at 1:04 PM, Shazron  wrote:
> >
> >> Yup I've been looking at the issues today - how coincidental.
> >> There's been new code that I've been testing, but I'm having problems:
> >> https://github.com/phonegap/ios-deploy/pull/12
> >>
> >>
> >>
> >> On Fri, Dec 13, 2013 at 1:02 PM, David Kemp 
> wrote:
> >>
> >>> Hi all,
> >>> I am having pretty regular problems with phonegap/ios-deploy. It seems
> >>> generally unreliable, failing about 30-40% of the time. A very common
> >>> failure mode is:
> >>>
> >>> Assertion failed: (AMDeviceStartService(device,
> >>> CFSTR("com.apple.debugserver"), &gdbfd, NULL) == 0), function
> >>> start_remote_debug_server, file ios-deploy.c, line 524.
> >>>
> >>> I seem to have the newest published version, is anyone looking at this?
> >>>
> >>> I note that this has been reported by someone else as well:
> >>>
> >>> https://github.com/phonegap/ios-deploy/issues/11
> >>>
> >>
> >>
> >
>

Re: Platform specific preferences

[David Kemp]

Currently preferences can be specified inside a  tag in the
plugin XML. This provides the functionality you describe for a plugin.
I would suggest if we need to add the same functionality at the app level,
then we do it the same way (put preferences inside a Platform tag)




On Sat, Mar 15, 2014 at 7:33 AM, Sergei Grebnov Home <
sergei.greb...@gmail.com> wrote:

> Hi,
>
>
>
> Propose to add optional 'platform' attribute to 'preference' element
> (config.xml) so that we can specify different preferences for different
> platforms. For example, right now there is a  name="SplashScreen"
> /> (I'm looking on Android code) but I'm not sure single splash screen
> image
> can fit all different platforms (size, image format, etc).
>
>
>
>  <-
> wp8 only
>
>   <-- by
> default applied to all platforms
>
>  value="assets\SplashScreenImage.screen-WVGA.jpg." platform="wp8" /> <- wp8
> will use this image; if remove this preference, wp8 will use preference
> above
>
>
>
> Thoughts?
>
>
>
> Thx!
>
> Sergey
>
>

Re: Consolidating the Distribution of Platforms & Plugins

[David Kemp]

+1 to handling both the same way and not using git for distribution.

I'm interested in the pros and cons of using the plugin registry vs npm.



On Thu, Mar 13, 2014 at 10:14 PM, Gorkem Ercan wrote:

> Great idea..  I especially don't like the git archive download. It does not
> really allow us to track some sort of statistics reliably. I think its
> replacement should allow collection of download statistics. The plugins
> stats from plugman seems OK. I am not sure if npm would allow such stats.
>
> Not that important to this discussion but I think plugman has a cache in
> .plugman/cache
>
> --
> Gorkem
>
>
> On Thu, Mar 13, 2014 at 11:25 AM, Andrew Grieve  >wrote:
>
> > Right now, CLI downloads & caches platforms & plugins using two different
> > mechanisms, with totally independent code paths.
> >
> > plugman uses the request library, with proxy settings in .plugman/config.
> > It downloads the tars directly from registry.cordova.io. It does not
> cache
> > them.
> >
> > CLI uses the request library as well, with proxy settings from .npmrc. It
> > downloads tars directly from our git server's archive endpoint. It caches
> > them in ~/.cordova.
> >
> >
> > I'd like to propose that we unify them. Specifically:
> >
> > 1. Store platforms on registry.cordova.io
> >   - This would allow CLI to easily see what versions of platforms are
> > available, and be able to choose between them.
> >   - This (I'm sure), INFRA would be much happier about than our current
> > fetch-from-git approach
> >
> > 2. Unify CLI & Plugman's downloading logic
> >   - Use the same code-path for both.
> >   - Have them use the same caching logic.
> >
> > 3. Use npm's cache logic instead of our own:
> >   - Just type npm help cache to see what it does
> >   - Would allow for: "cordova cache clean"
> >
> > I would *not* want to lose our support for --searchpath, as I think it's
> > really handy. I don't see a problem with this though.
> >
> > This would also enable CLI to answer queries like "what platform versions
> > are available", and make it trivial to do "install cordova-android@3.0.0
> "
> >
> > This isn't something I have time to work on in the near future, but
> wanted
> > to see if everyone would be onboard with the change. I'll end up just
> > filing bugs for the changes if it sounds good... but if anyone else wants
> > to work on it... :)
> >
>

Re: [Vote] Plugins Release

[David Kemp]

+1


On Sun, Mar 2, 2014 at 12:23 AM, Shazron  wrote:

> +1
>
>
> On Sat, Mar 1, 2014 at 7:06 PM, Ian Clelland 
> wrote:
>
> > +1
> >
> >
> >
> > On Fri, Feb 28, 2014 at 10:00 PM, Andrew Grieve  > >wrote:
> >
> > > Please review and vote on the release of this plugins release.
> > >
> > > Release issue: https://issues.apache.org/jira/browse/CB-6114
> > >
> > > The plugins have been published to dist/dev:
> > > https://dist.apache.org/repos/dist/dev/cordova/CB-6114/
> > >
> > > The packages were published from their corresponding git tags:
> > > cordova-plugin-camera: 0.2.8 (552b806347)
> > > cordova-plugin-contacts: 0.2.9 (431eeea9f5)
> > > cordova-plugin-file-transfer: 0.4.2 (c0c91d0245)
> > > cordova-plugin-inappbrowser: 0.3.2 (4d3c7b17d2)
> > > cordova-plugin-media: 0.2.9 (ea7b96bcca)
> > > cordova-plugin-media-capture: 0.2.8 (f516d31b79)
> > > cordova-plugin-file: 1.0.1 (21e119692a)
> > >
> > > Upon a successful vote I will upload the archives to dist/, upload them
> > to
> > > the Plugins Registry, and post the corresponding blog post.
> > >
> > > Voting will go on for 48 hours.
> > >
> >
>

Re: Introduction

[David Kemp]

Welcome aboard!
Please share the good and the bad.

If you haven't already, check out the Wiki for workflow, and background.

Also remember that if you submit patches you need to sign the CLA.

Thanks!




On Mon, Feb 24, 2014 at 8:02 AM, Andrey Kurdumov wrote:

> Hello Cordova Devs,
>
> I currently working on  application, which will work on Android and iOS,
> and willing to share solutions which I will found on my way.
>
> Also I work on Windows, and could help to test with issues which arise on
> that platform.
> I'm interested mostly in improvements in plugin development and tooling
> processes for Cordova for now. My customer is very picky about native look
> and feel, so I maybe hit some corner cases.
>
> Best regards
> Andrey Kurdyumov
>

Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

[David Kemp]

My concern with any automated fix is that we have no idea what files belong
to an app.
The default is to just toss everything in the root.
Files may be user data that is shared between apps, config files or temp
files. The developer probably knows what to migrate - we don't.\


On Wed, Feb 5, 2014 at 9:05 AM, sebb  wrote:

> On 5 February 2014 13:20, David Kemp  wrote:
> > -1 to merging reads. That just sounds like a horrible thing to debug.
>
> Seems to me that developers using the plugin will have to implement
> something similar in order to make it easier for their users.
>
> Would it not be better to spend the time getting it right once, for
> the benfit of all developers, rather than hoping they each get it
> right?
>
> I don't know what is involved here, so this is theoretical.
> But I believe that compatibility should only be broken if necessary.
> Also that fixing a problem at source is usually a lot cheaper than
> requiring downstream developers/users to do so.
> There are lots more of them, so any extra effort they have to expend
> is multiplied many times.
> In other words, the cost-benefit should not just look at the immediate
> cost to the project.
>
> > +1 to 'go big or go home'. Break it now. Break it obviously.
>
> But I agree that breakage - if decided on - should be obvious.
>
> >
> > On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref 
> wrote:
> >
> >> Is it impossible to have reads merged from both locations, but writes go
> >> to the new location, and when a write completes in the new location,
> delete
> >> the old one?
>

Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)

[David Kemp]

-1 to merging reads. That just sounds like a horrible thing to debug.
+1 to 'go big or go home'. Break it now. Break it obviously.


On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref  wrote:

> Is it impossible to have reads merged from both locations, but writes go
> to the new location, and when a write completes in the new location, delete
> the old one?

Re: Blog post review for tools release (plz review)

[David Kemp]

lgtm


On Fri, Jan 31, 2014 at 4:15 PM, Andrew Grieve  wrote:

> Mostly the same as my failed blog post last time, but with updated release
> notes
>
> ---
> layout: post
> author:
> name: Andrew Grieve
> url: https://twitter.com/GrieveAndrew
> title:  "Tools Release: Jan 31, 2014"
> categories: news
> tags: release tools
> ---
> It's been a long time since our last tools release, but that's certainly no
> sign of stagnation. Today's release is action packed!
>
> * plugman@0.19.0
> * cordova@3.3.1-0.3.1
>
> To update your tools:
>
> npm update -g cordova
> npm update -g plugman
>
> This release brings with it a plethora of bug fixes as well as some new
> features! Notably:
>
> * `config.xml` now lives at the project root by default (instead of within
> www/)
> * `hooks` now lives at the project root by default (instead of within
> .cordova)
>
> Full list of release notes:
> 
>
> ## cordova
>
> * [CB-5006](https://issues.apache.org/jira/browse/CB-5006) Add
> --searchpath
> to `cordova plugin add` so that installing by ID will search local paths
> before hitting the registry.
> * [CB-4153](https://issues.apache.org/jira/browse/CB-4153) Add --copy-from
> & --link-to to `cordova create`.
> * [CB-5687](https://issues.apache.org/jira/browse/CB-5687) Make cordova
> commands work when CWD is inside of a symlink'ed `www/`
> * [CB-4910](https://issues.apache.org/jira/browse/CB-4910) Default
> `config.xml` to the root instead of within `www/`
> * [CB-5764](https://issues.apache.org/jira/browse/CB-5764) Move `hooks/`
> to
> top-level instead of under `.cordova`
> * [CB-5763](https://issues.apache.org/jira/browse/CB-5763) Don't create
> `.cordova/` by default
> * [CB-4871](https://issues.apache.org/jira/browse/CB-4871) Reduced package
> size significantly.
> * [CB-4976](https://issues.apache.org/jira/browse/CB-4976) Don't add cache
> entries for local platforms.
> * [CB-5777](https://issues.apache.org/jira/browse/CB-5777) Fix `cordova
> platform update` not updating `cordova.js`.
> * [CB-5728](https://issues.apache.org/jira/browse/CB-5728) Files in merges
> must remain intact when removing platform.
> * [CB-5493](https://issues.apache.org/jira/browse/CB-5493) lazy_load now
> downloads to a temp dir and then moves.
> * [CB-5782](https://issues.apache.org/jira/browse/CB-5782) Hide stack
> trace
> for explicitly handled error conditions
> * [CB-5590](https://issues.apache.org/jira/browse/CB-5590) Have config.xml
> version map to CFBundleShortVersionString instead of CFBundleVersion
> * [CB-5913](https://issues.apache.org/jira/browse/CB-5913) Fail more
> gracefully on Windows when symlinks fail.
> * Fix isWindows check in util.js to support win64
> * [CB-5907](https://issues.apache.org/jira/browse/CB-5907) Make `cordova
> update` get version from platform's version script
> * [CB-3612](https://issues.apache.org/jira/browse/CB-3612) Don't pass
> --device to "run" command by default.
> * [CB-5299](https://issues.apache.org/jira/browse/CB-5299) Cache pbxproj
> to
> avoid re-parsing it for each plugin.
> * [CB-5813](https://issues.apache.org/jira/browse/CB-5813) Fix missing
> quotes on update and ls commands
> * [CB-5808](https://issues.apache.org/jira/browse/CB-5808) Fix lazy_load
> stripping off windows drive letters
> * Expose util.isCordova as cordova.findProjectRoot()
> * Allow lazy_load libs to work without an id and version for local paths.
>
> ## plugman
>
> * [CB-5770](https://issues.apache.org/jira/browse/CB-5770) Plugman prepare
> script content wrapping no longer allows ending parens/braces to be
> commented out from end of line comment
> * [CB-4871](https://issues.apache.org/jira/browse/CB-4871) Reduced package
> size significantly
> * [CB-5720](https://issues.apache.org/jira/browse/CB-5720) Allow
> `` on Android
> * [CB-5006](https://issues.apache.org/jira/browse/CB-5006) Add
> --searchpath
> option for local plugin search path
> * [CB-5701](https://issues.apache.org/jira/browse/CB-5701) Reference
> custom
> frameworks using relative paths
> * [CB-5495](https://issues.apache.org/jira/browse/CB-5495), [CB-5568](
> https://issues.apache.org/jira/browse/CB-5568) Fix config.xml path for iOS
> * [CB-5804](https://issues.apache.org/jira/browse/CB-5804) Added repo &
> issue information into `plugman publish`
>

Re: Introducing myself

[David Kemp]

Welcome aboard!




On Sun, Jan 26, 2014 at 9:08 AM, Bas Bosman  wrote:

> Hi,
>
> My name is Bas Bosman.
>
> I've been using Cordova to build some personal projects on iOS and Android
> for some time. I've gotten so much value out of it that I want to
> contribute back.
>
> I don't have that much experience yet with hacking the Corodva core
> itself, but my plan is to get my feet wet by taking on some low hanging
> fruit from existing JIRA issues.
>
> Regards,
> Bas Bosman
>
>

Medic/CI

[David Kemp]

To those running Medic/CI ...

There have been a couple changes lately that required changes to the medic
master.cfg and some of the android & ios build scripts. I have committed
the changes to the repo, but you will probably need to manually update the
master.cfg if you care about those platforms. Changes to file other than
master.cfg will be picked up automatically.

details:
- changes to iOS build script mean it no longer builds for device by
default. This required a change for Master that is not backward compatible
to current release. I am ignoring that since the problem will go away in a
few days (with 3.4 release)
- changes to the mobilespec plugins dependency file mean that if you do not
specify the --searchpath, you always get released plugins from the
registry, causing Master builds to potentially fail (should use dev
plugins). This is changed and is backward compatible.
- changes to the android build.xml that move the output apk and cause ant
debug to fail. Moved to using cordova/build and handling the new location.

Re: Configuring the File plugin

[David Kemp]

+1 to configurable

The main reason would be to make changing (default) locations easier. As
described the upgrade to move to new (more sensible) locations is easy to
manage and supports people with legacy apps that don't want to change.



On Mon, Jan 13, 2014 at 1:37 PM, Brian LeRoux  wrote:

> I am apprehensive about making this surface configurable. (I can live w/
> our own protocol cdvfile:// personally).
>
> The main use case is being able to add custom storage providers in the
> future?
>
> (Might be good to add this to the 'lets talk configuration' backlog /
> meeting.)
>
>
> On Mon, Jan 13, 2014 at 7:32 AM, Ian Clelland  >wrote:
>
> > The new File plugin is essentially ready, for iOS and Android (with,
> > hopefully, no breaking changes for those or other platforms)
> >
> > I had to move away from the "filesystem://" URL scheme -- on Android 4.4,
> > that scheme appears to be special, and doesn't defer to
> > WebView.shouldInterceptRequest(). (I filed
> > https://code.google.com/p/chromium/issues/detail?id=95 on Friday
> once
> > I
> > had isolated the problem.) For now, I've settled on "cdvfile://", but the
> > issue is open to bikeshedding, I suppose.
> >
> > What I'd really like to open for discussion though, is the idea of making
> > the whole plugin configuration, er, configurable.
> >
> > The URL scheme is one driving force behind this; the historical locations
> > of the TEMPORARY and PERSISTENT filesystems is another; the new ability
> to
> > open up completely new filesystems is a third.
> >
> > I'm thinking of implementing a section in config.xml that would define
> the
> > names of the installed filesystems available to a Cordova app, along with
> > their type, the URL prefix to use, and any other required details (like
> > *where the files live*). Something like this:
> >
> > 
> >   
> >  > prefix="cdvfile://localhost/temporary" src="cache" />
> >  > prefix="cdvfile://localhost/persistent" src="Documents" />
> >  > prefix="content://" />
> >   
> > 
> >
> > or
> >
> > 
> >   
> > 
> >> prefix="cdvfile://localhost/temporary" src="cache" />
> >> prefix="cdvfile://localhost/persistent" src="Documents" />
> >> prefix="content://" />
> > 
> >   
> > 
> >
> > (The platform's defaults.xml, or whatever we're calling it these days,
> > could specify the default mapping, so that devs could write
> cross-platform
> > apps without having to add this for every platform, or even at all, if
> they
> > don't care to change it)
> >
> > I think that being this explicit will let us change the url scheme as
> > needed (hopefully cdvfile won't need to change, but it would have if it
> was
> > still "filesystem"). It could eventually allow new FS plugins to be added
> > to an app with this mechanism. And it would mean that we could roll out a
> > default configuration that left the iOS files in their current locations:
> >
> >  > type="local-filesystem"
> > prefix="cdvfile://localhost/temporary"
> > src="Temporary" />
> >  > type="local-filesystem"
> > prefix="cdvfile://localhost/persistent"
> > src="Documents" />
> >
> > and then, in a later version, we could change the default for new
> projects
> > to
> >
> >  > type="local-filesystem"
> > prefix="cdvfile://localhost/temporary"
> > src="Temporary" />
> >  > type="local-filesystem"
> > prefix="cdvfile://localhost/persistent"
> > src="Library" />
> >  > type="local-filesystem"
> > prefix="cdvfile://localhost/documents"
> > src="Documents" />
> >
> > and existing projects shouldn't see any change. And in the meantime, any
> > dev who wanted to use the more sensible filesystem locations could just
> > change their own config.xml.
> >
> > I'm going to take a stab at implementing this as described, but
> discussion
> > is certainly welcome before it goes out to the world. As multiple people
> > have said, we need to get this right, and not hurt all of our existing
> > devs.
> >
> > Ian
> >
>

Re: Moving .cordova/config.json -> cordova.json

[David Kemp]

Config.json is a strange beast. Its not a build artifact because you
optionally create it to configure your project. Its used by Medic to force
the use of the locally available platfrom libs, and Medic has to create it.
It has always seemed strange to hide a configuration file in a hidden
directlory. Now its one step worse because the hidden directory might not
even be there.
Could we just get his thing out into the open?



On Fri, Jan 10, 2014 at 10:19 PM, Michal Mocny  wrote:

> On Fri, Jan 10, 2014 at 8:58 PM, Andrew Grieve 
> wrote:
>
> > I've finished working on this for now and have marked the bug as
> > fixed. The commits are all attached to
> > https://issues.apache.org/jira/browse/CB-4910.
> >
> > What I've done is:
> > 1. config.xml:
> >  - defaults to the root instead of within www/.
> >  - We still read www/config.xml if the file doesn't exist at the root.
> >  - The template will put in at the root now though.
> > 2. hooks/ now live in a directory in the root instead of within .cordova
> >  - The code will run all hooks found in .cordova/hooks as well as hooks/
> >  - The create template now creates the directory in the root.
> >
>
> Are hooks something popular enough that we should be creating by default?
>  I do like that its self documenting and discoverable this way, but its
> also adding some cognitive load for those just starting out with their
> first project.  I'm not opposed at all, just asking.
>
>  - The create template no longer creates an empty directory for each
> > hook type and instead adds a README.md to the hooks/
> >- Reason for this is that git doesn't commit empty dirs, so the
> > empty subdirs are lost when committing to git anyways.
> > 3. The .cordova/config.json:
> >  - Has not moved.
> >  - No longer contains the id and name used when creating the project
> > (they weren't used anyways)
> >  - Will not be written if it doesn't contain anything (which is the
> > default)
> >  - This means the .cordova/ directory now does not exist by default.
> >
>
> ..but if I wanted a config.json for some reason, I would need to create a
> .cordova, or can it exist inside the root as well?
>
>
> > 4. Updated the README.md to reflect the new project structure
> >
> > In terms of promoting the change, I think it'll be enough to mention
> > the change in the next tools release blog post.
> >
> > On Mon, Jan 6, 2014 at 12:07 PM, Brian LeRoux  wrote:
> > > ya agreed, we should aim to do something early Feb once everyone is
> back
> > > into the the flow
> > >
> > >
> > > On Mon, Jan 6, 2014 at 11:59 AM, Michal Mocny 
> > wrote:
> > >
> > >> If we don't add a config.json by default, we need a new strategy for
> > >> looking up paths for the root.
> > >>
> > >> I don't like naming the top-level config "config.xml", but after some
> > >> thoughts on it, I don't think we should rename it just right now.
>  There
> > >> are a lot of changes that would need to go along with that rename for
> > it to
> > >> make any sense.  I also agree with Brian that what we really need is
> to
> > >> step back and consider an entirely better solution rather than
> something
> > >> incremental.  Perhaps this is good subject matter for the next
> hangout /
> > >> meet-up.
> > >>
> > >> -Michal
> > >>
> > >>
> > >> On Fri, Jan 3, 2014 at 2:43 PM, Brian LeRoux  wrote:
> > >>
> > >> > probably a good idea for the moment / at some we will have a config
> > file
> > >> > reckoning!
> > >> >
> > >> >
> > >> > On Fri, Jan 3, 2014 at 11:34 AM, Andrew Grieve <
> agri...@chromium.org>
> > >> > wrote:
> > >> >
> > >> > > Okay, yeah, reading that back to myself and it seems like a bad
> idea
> > >> > > (config.xml->app.xml). Probably would just add to confusion.
> > >> > >
> > >> > > So, top-level config.xml and top-level cordova.json.
> > >> > >
> > >> > > Maybe I could add to this that we don't create a cordova.json by
> > >> default,
> > >> > > since 99% most people shouldn't need it.
> > >> > >
> > >> > >
> > >> > > On Fri, Jan 3, 2014 at 2:31 PM, Brian LeRoux  wrote:
> > >> > >
> > >> > > > actually, let me put this another way: I support
> > .cordova/config.json
> > >> > ->
> > >> > > > cordova.json but I am not really interested in changing the name
> > of
> > >> > > > ./www/config.xml to ./www/app.xml
> > >> > > >
> > >> > > > ...feels to me we could consolidate this entire sitation with a
> > >> single
> > >> > > well
> > >> > > > crafted configuration file (at the top level). ideally we have
> > more
> > >> > > > convention than configuration. feels like we have too many
> > footguns
> > >> to
> > >> > > ease
> > >> > > > our personal dev workflows as is than consideration for people
> > >> actually
> > >> > > > building apps.
> > >> > > >
> > >> > > >
> > >> > > > On Fri, Jan 3, 2014 at 11:25 AM, Brian LeRoux 
> wrote:
> > >> > > >
> > >> > > > > Sorry, I completely do not understand this at all. The
> proposal
> > is
> > >> to
> > >> > > > > change the name of config.xml to ease confusions and add a new
> 

Re: IC: current state of IOS master

[David Kemp]

+1 to removing them.
Soon we will need to replace them all with the ones from mobilespec (sort
of) anyway.



On Wed, Jan 8, 2014 at 3:53 PM, Andrew Grieve  wrote:

> Anyone object to me going through and deleting the stale copy of tests
> within plugins?
>
>
> On Wed, Jan 8, 2014 at 12:40 PM, Ian Clelland  >wrote:
>
> > They are out of sync, for sure. The mobile-spec tests should be
> considered
> > canonical, I think -- that's what is actually being run by the CI server,
> > and by everyone who is doing manual testing, as far as I know. (Anyone
> who
> > knows different: now is the time to chime in :) )
> >
> > We're very close to being able to split all of the tests out of mobile
> > spec; we have a test runner which is close to being ready that will pull
> in
> > tests from individual plugins. Once that's ready, we'll be able to move
> the
> > tests from MS back into plugins.
> >
> > Most plugins right now have a set of tests that was copied in circa
> Cordova
> > 2.9/3.0, and so they'll mostly need to be refreshed when we finally move
> to
> > plugin-hosted-tests.
> >
> > (And I think the tests are back to passing now, from the look of the CI
> > dashboard -- thanks for doing that! :) )
> >
> > Ian
> >
> >
> >
> >
> > On Wed, Jan 8, 2014 at 3:23 PM, Jesse  wrote:
> >
> > > I reverted the merge and pushed to master.
> > >
> > > So should the mobile-spec tests, or the tests in each plugin repo be
> > > considered the root?  I fear they are out of sync.
> > >
> > > @purplecabbage
> > > risingj.com
> > >
> > >
> > > On Wed, Jan 8, 2014 at 10:54 AM, Jesse 
> wrote:
> > >
> > > > I did the premature merge for CB-5602, I'll revert it.
> > > >
> > > > @purplecabbage
> > > > risingj.com
> > > >
> > > >
> > > > On Wed, Jan 8, 2014 at 8:47 AM, Ian Clelland  > > >wrote:
> > > >
> > > >> I think that this has to do with CB-5602. It looks like the file api
> > > tests
> > > >> were overwritten with a version from the cordova-plugin-file repo,
> > which
> > > >> would have been rather stale, and the merge caused the whole suite
> to
> > > >> contain errors.
> > > >>
> > > >> We appear to have a completely different issue in the CI server,
> > because
> > > >> the tests should have failed on all platforms, not just iOS/release.
> > > >>
> > > >> [I've replied to CB-5602 as well; not sure which is the better place
> > for
> > > >> discussion]
> > > >>
> > > >> Ian
> > > >>
> > > >>
> > > >>
> > > >> On Wed, Jan 8, 2014 at 11:08 AM, David Kemp 
> > > wrote:
> > > >>
> > > >> > Unfortunately, our iOS deploy has been broken for a while. I just
> > > spent
> > > >> > some time getting it back on its feet and find that master does
> not
> > > pass
> > > >> > tests. I do not have a simple 'blame list' because many commits
> have
> > > >> passed
> > > >> > since the test deployed correctly.
> > > >> >
> > > >> > All tests pass on iOS 3.3.x
> > > >> >
> > > >> > All tests pass on Android Master and 3.3.x
> > > >> >
> > > >> > On iOS master 7 file tests are failing on iOS 6.1.3 and 7.04
> > > >> >
> > > >> >
> > > >> >"*spec*": "File API DirectoryEntry file.spec.25
> > > >> > DirectoryEntry.getDirectory: create new dir with space
> > > >> resolveFileSystemURI
> > > >> > with encoded URI.",
> > > >> >
> > > >> >"*exception*": "timeout: timed out after
> 7500
> > > >> msec
> > > >> > waiting for win never called",
> > > >> >
> > > >> >"*spec*": "File API File file.spec.40 should be
> > define
> > > >> File
> > > >> > attributes.",
> > > >> >
> > > >> >"*exception*": "Expected undefined to be
> > > >> defined.",
> > > >> >

Re: IC: current state of IOS master

[David Kemp]

To follow up: yes all tests are now passing again on android and ios master
and 3.3.x


On Wed, Jan 8, 2014 at 3:40 PM, Ian Clelland  wrote:

> They are out of sync, for sure. The mobile-spec tests should be considered
> canonical, I think -- that's what is actually being run by the CI server,
> and by everyone who is doing manual testing, as far as I know. (Anyone who
> knows different: now is the time to chime in :) )
>
> We're very close to being able to split all of the tests out of mobile
> spec; we have a test runner which is close to being ready that will pull in
> tests from individual plugins. Once that's ready, we'll be able to move the
> tests from MS back into plugins.
>
> Most plugins right now have a set of tests that was copied in circa Cordova
> 2.9/3.0, and so they'll mostly need to be refreshed when we finally move to
> plugin-hosted-tests.
>
> (And I think the tests are back to passing now, from the look of the CI
> dashboard -- thanks for doing that! :) )
>
> Ian
>
>
>
>
> On Wed, Jan 8, 2014 at 3:23 PM, Jesse  wrote:
>
> > I reverted the merge and pushed to master.
> >
> > So should the mobile-spec tests, or the tests in each plugin repo be
> > considered the root?  I fear they are out of sync.
> >
> > @purplecabbage
> > risingj.com
> >
> >
> > On Wed, Jan 8, 2014 at 10:54 AM, Jesse  wrote:
> >
> > > I did the premature merge for CB-5602, I'll revert it.
> > >
> > > @purplecabbage
> > > risingj.com
> > >
> > >
> > > On Wed, Jan 8, 2014 at 8:47 AM, Ian Clelland  > >wrote:
> > >
> > >> I think that this has to do with CB-5602. It looks like the file api
> > tests
> > >> were overwritten with a version from the cordova-plugin-file repo,
> which
> > >> would have been rather stale, and the merge caused the whole suite to
> > >> contain errors.
> > >>
> > >> We appear to have a completely different issue in the CI server,
> because
> > >> the tests should have failed on all platforms, not just iOS/release.
> > >>
> > >> [I've replied to CB-5602 as well; not sure which is the better place
> for
> > >> discussion]
> > >>
> > >> Ian
> > >>
> > >>
> > >>
> > >> On Wed, Jan 8, 2014 at 11:08 AM, David Kemp 
> > wrote:
> > >>
> > >> > Unfortunately, our iOS deploy has been broken for a while. I just
> > spent
> > >> > some time getting it back on its feet and find that master does not
> > pass
> > >> > tests. I do not have a simple 'blame list' because many commits have
> > >> passed
> > >> > since the test deployed correctly.
> > >> >
> > >> > All tests pass on iOS 3.3.x
> > >> >
> > >> > All tests pass on Android Master and 3.3.x
> > >> >
> > >> > On iOS master 7 file tests are failing on iOS 6.1.3 and 7.04
> > >> >
> > >> >
> > >> >"*spec*": "File API DirectoryEntry file.spec.25
> > >> > DirectoryEntry.getDirectory: create new dir with space
> > >> resolveFileSystemURI
> > >> > with encoded URI.",
> > >> >
> > >> >"*exception*": "timeout: timed out after 7500
> > >> msec
> > >> > waiting for win never called",
> > >> >
> > >> >"*spec*": "File API File file.spec.40 should be
> define
> > >> File
> > >> > attributes.",
> > >> >
> > >> >"*exception*": "Expected undefined to be
> > >> defined.",
> > >> >
> > >> >"*spec*": "File API Entry file.spec.63 copyTo:
> > directory
> > >> > that does not exist.",
> > >> >
> > >> >"*exception*": "TypeError: 'null' is not an
> > >> object
> > >> > (evaluating 'parent.filesystem.__format__') in
> > >> >
> > >> >
> > >>
> >
> file:///var/mobile/Applications/836872AD-CFED-4BE7-A316-45353151C586/mobilespec.app/www/plugins/org.apache.cordova.file/www/Entry.js
> > >> > (line 165)",
> > >> >
> > >> >

Re: Medic/CI

[David Kemp]

So I am also giving the CI system a little attention because I ignored it
for a month. There is currently a problem with the recorded results in the
couchdb, but I should get that cleared up shortly.
Then maybe step one is to just get the data replicated and not even worry
about moving master there. That can be done separately/later if at all.

We will still need to set up a proper ssl method for our local couchdb
instances to replicate to the apache one.



On Wed, Jan 8, 2014 at 2:48 PM, Mike Billau  wrote:

> (Sorry, I dropped the ball on this and checked out pretty hard over the
> holidays.)
>
> We have a test lab with ~15 Android devices and ~10 iOS devices, all with
> varying OS levels and availability (sometimes testers need to borrow a
> device for a few days.) We also have some Windows phone, Windows 8, and
> Blackberry devices but I have not added these to the system yet. FYI, my
> "Plugable USB 2.0 4-port Hub"s are working great (except for Samsung
> devices, boo!. I know David has checked out a few different USB hub models
> too - eventually we should consolidate this data to help anyone else set up
> a test lab.)
>
> +1 for setting up a buildbot master. We are still working on getting a
> private network set up that wont be able to access the corporate intranet
> though, so until that happens I don't think we can use the Apache machine.
> We can probably replicate our couchdb though.
>
> +1 for consolidating test results on a central couchdb hosted on the Apache
> machine. It will be great to finally see our full device/os coverage across
> the community.
>
>
>
> On Wed, Jan 8, 2014 at 10:08 AM, David Kemp  wrote:
>
> > I think we can set the slaves up to ssh to the host, and we would have to
> > set up a local couchdb for the devices to write to, then replicate it
> over
> > ssh to the central one. This would require that the infra guys give us
> some
> > accounts for the slave systems (in addition to developers).
> >
> >
> >
> > On Wed, Jan 8, 2014 at 9:56 AM, Andrew Grieve 
> > wrote:
> >
> > > I believe the machine does not have external (public) access, but all
> > devs
> > > can get SSH access to it.
> > >
> > >
> > > On Tue, Jan 7, 2014 at 9:11 PM, Sergey Grebnov (Akvelon) <
> > > v-seg...@microsoft.com> wrote:
> > >
> > > > Hi David,
> > > >
> > > > Does it mean we can use that Apache machine to consolidate test
> results
> > > > (couchdb with external access)?
> > > >
> > > > PS. I'm running CI for WP8 and Windows8 (master branches)
> > > >
> > http://sgrebnov.blogspot.com/2013/12/apache-cordova-ci-for-windows.html
> > > >
> > > > -Sergey
> > > > -Original Message-
> > > > From: drk...@google.com [mailto:drk...@google.com] On Behalf Of
> David
> > > Kemp
> > > > Sent: Tuesday, January 7, 2014 7:31 PM
> > > > To: dev@cordova.apache.org
> > > > Subject: Medic/CI
> > > >
> > > > Hi all,
> > > > Just wondering how many people are running the buildbot CI system.
> > > > We have an Apache machine we can use as a buildmaster if there are
> > slaves
> > > > out there that people are interested in tying to it.
> > > >
> > > > David Kemp
> > > >
> > >
> >
>

IC: current state of IOS master

[David Kemp]

Unfortunately, our iOS deploy has been broken for a while. I just spent
some time getting it back on its feet and find that master does not pass
tests. I do not have a simple 'blame list' because many commits have passed
since the test deployed correctly.

All tests pass on iOS 3.3.x

All tests pass on Android Master and 3.3.x

On iOS master 7 file tests are failing on iOS 6.1.3 and 7.04


   "*spec*": "File API DirectoryEntry file.spec.25
DirectoryEntry.getDirectory: create new dir with space resolveFileSystemURI
with encoded URI.",

   "*exception*": "timeout: timed out after 7500 msec
waiting for win never called",

   "*spec*": "File API File file.spec.40 should be define File
attributes.",

   "*exception*": "Expected undefined to be defined.",

   "*spec*": "File API Entry file.spec.63 copyTo: directory
that does not exist.",

   "*exception*": "TypeError: 'null' is not an object
(evaluating 'parent.filesystem.__format__') in
file:///var/mobile/Applications/836872AD-CFED-4BE7-A316-45353151C586/mobilespec.app/www/plugins/org.apache.cordova.file/www/Entry.js
(line 165)",

   "*exception*": "timeout: timed out after 7500 msec
waiting for itCopy never called",

   "*spec*": "File API Entry file.spec.79 moveTo: directory
that does not exist.",

   "*exception*": "timeout: timed out after 7500 msec
waiting for itMove never called",

   "*spec*": "File API read method file.spec.82 should error
out on non-existent file.",

   "*exception*": "timeout: timed out after 7500 msec
waiting for verifier never called",

   "*spec*": "File API FileWriter file.spec.97 should be able
to write and append to file, File object.",

   "*exception*": "timeout: timed out after 7500 msec
waiting for verifier",

   "*spec*": "File API Backwards compatibility file.spec.109
should be able to resolve a file:/// URL.",

   "*exception*": "ReferenceError: Can't find variable:
joinURL in
file:///var/mobile/Applications/836872AD-CFED-4BE7-A316-45353151C586/mobilespec.app/www/autotest/tests/file.tests.js
(line 3599)",

Re: Medic/CI

[David Kemp]

I think we can set the slaves up to ssh to the host, and we would have to
set up a local couchdb for the devices to write to, then replicate it over
ssh to the central one. This would require that the infra guys give us some
accounts for the slave systems (in addition to developers).



On Wed, Jan 8, 2014 at 9:56 AM, Andrew Grieve  wrote:

> I believe the machine does not have external (public) access, but all devs
> can get SSH access to it.
>
>
> On Tue, Jan 7, 2014 at 9:11 PM, Sergey Grebnov (Akvelon) <
> v-seg...@microsoft.com> wrote:
>
> > Hi David,
> >
> > Does it mean we can use that Apache machine to consolidate test results
> > (couchdb with external access)?
> >
> > PS. I'm running CI for WP8 and Windows8 (master branches)
> > http://sgrebnov.blogspot.com/2013/12/apache-cordova-ci-for-windows.html
> >
> > -Sergey
> > -----Original Message-
> > From: drk...@google.com [mailto:drk...@google.com] On Behalf Of David
> Kemp
> > Sent: Tuesday, January 7, 2014 7:31 PM
> > To: dev@cordova.apache.org
> > Subject: Medic/CI
> >
> > Hi all,
> > Just wondering how many people are running the buildbot CI system.
> > We have an Apache machine we can use as a buildmaster if there are slaves
> > out there that people are interested in tying to it.
> >
> > David Kemp
> >
>

Medic/CI

[David Kemp]

Hi all,
Just wondering how many people are running the buildbot CI system.
We have an Apache machine we can use as a buildmaster if there are slaves
out there that people are interested in tying to it.

David Kemp

Re: Introductory Developer Email

[David Kemp]

Welcome Aboard Josh!



On Mon, Jan 6, 2014 at 12:20 PM, Josh Bavari  wrote:

> Hello fellow Cordova Devs,
>
> I have been using PhoneGap / Cordova for about the last few years and love
> that the project is ever evolving. I would like to help contribute to the
> Cordova project as well to help give back some of what was freely given to
> myself.
>
> Some of my hobbies include mobile development (im guessing you already knew
> hybrid apps), coding in Ruby and Javascript, process automation, and
> speaking / mentoring others.
>
> I hope to be chatting with many of you and contributing on issues that I
> myself find or that others may have an urgent priority for.
>
> Thanks, and may we build a better future.
>
>
> --
> "Clear thoughts produce clear results."
> Josh Bavari
> Application Developer
> Phone: 405-509-9448
> Cell: 405-812-0496
> Email: jbav...@gmail.com
>

ios-deploy issues

[David Kemp]

Hi all,
I am having pretty regular problems with phonegap/ios-deploy. It seems
generally unreliable, failing about 30-40% of the time. A very common
failure mode is:

Assertion failed: (AMDeviceStartService(device,
CFSTR("com.apple.debugserver"), &gdbfd, NULL) == 0), function
start_remote_debug_server, file ios-deploy.c, line 524.

I seem to have the newest published version, is anyone looking at this?

I note that this has been reported by someone else as well:

https://github.com/phonegap/ios-deploy/issues/11

plugman config file problem - CB-5495 & CB-5568

[David Kemp]

There is a problem with the iOS platform only when running build multiple
times.
The problem appear to be with the last function in
plugman/src/util/config-changes.js where it locates the config.xml file.
This function does a global find in the project tree for config.xml and
takes the first one - for anything except android and ubuntu.
In the case of iOS, this works the first time - locating the one in the
project dir, but on subsequent prepares it chooses the config files in the
build/device/... directory.

Is there a reason for this global search instead of specifying the
location? It clearly doesnt work right in iOS, and I suspect other
platforms might experience the same issue.

Re: Medic CI failures

[David Kemp]

Seems like it. I am seeing some passes now. I will check into the details
in a bit.
 On Dec 12, 2013 5:52 PM, "Steven Gill"  wrote:

> I have removed btests from running for now. We can add them back in once we
> get them to a working state. This should fix the CI issues you are seeing
> David.
>
>
> On Thu, Dec 12, 2013 at 1:51 PM, Brian LeRoux  wrote:
>
> > The tests aren't new. They just run now instead of silent failure.
> >
> > I'll have a look at restoring old behavior and kick up a thread about
> > testing. Current/old solution tested nothing.
> > On Dec 13, 2013 8:02 AM, "David Kemp"  wrote:
> >
> > > Brian,
> > > The new tests also appear to open a tab on my chrome browser to display
> > the
> > > jasmine results after every test. This results in a rather unmanageable
> > > number of tabs on the slave machine after a while.
> > >
> > > I still have all master tests failing.
> > >
> > >
> > >
> > >
> > > On Thu, Dec 12, 2013 at 10:42 AM, David Kemp 
> wrote:
> > >
> > > > From the perspective of the js tests, medic (testing master) does:
> > > > - rm -rf ~/.cordova/lib/ios (this ensures no cached crap)
> > > > - use coho to checkout the sources into a clean directory
> > > > - cd into cordova-js
> > > > - git checkout master (for the release branch this currently checks
> out
> > > > 3.2.x)
> > > > - npm install
> > > > - grunt
> > > >
> > > > running on Mavericks, Xcode 5.01
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Thu, Dec 12, 2013 at 10:29 AM, Brian LeRoux  wrote:
> > > >
> > > >> Still? How do I reproduce?
> > > >> On Dec 13, 2013 2:28 AM, "David Kemp"  wrote:
> > > >>
> > > >> > Sorry - I did sort of forget to say which test..
> > > >> >
> > > >> > Yes the failure is in cordova-js.
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> > On Thu, Dec 12, 2013 at 10:15 AM, Brian LeRoux 
> wrote:
> > > >> >
> > > >> > > cordova-js ?? (Should be passing now but gruntfile was
> > refactored.)
> > > >> > > On Dec 13, 2013 12:06 AM, "David Kemp" 
> wrote:
> > > >> > >
> > > >> > > > last night a commit to change tests seems to have created a
> > > problem
> > > >> > with
> > > >> > > > the iOS and android testing. The grunt test for iOS failed
> with:
> > > >> > > >
> > > >> > > > deviceready has not fired after 5 seconds.
> > > >> > > >
> > > >> > > > Channel not fired: onNativeReady
> > > >> > > > Channel not fired: onCordovaReady
> > > >> > > > command timed out: 1200 seconds without output, attempting to
> > kill
> > > >> > > >
> > > >> > > > The Android test didn't get that far because it tried to start
> > the
> > > >> test
> > > >> > > > concurrently with the iOS test and :
> > > >> > > >
> > > >> > > > starting browser-based tests
> > > >> > > > Test Server running on:
> > > >> > > > http://127.0.0.1:3000
> > > >> > > >
> > > >> > > >  [31mFatal error: listen EADDRINUSE
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
>

Re: Medic CI failures

[David Kemp]

Brian,
The new tests also appear to open a tab on my chrome browser to display the
jasmine results after every test. This results in a rather unmanageable
number of tabs on the slave machine after a while.

I still have all master tests failing.




On Thu, Dec 12, 2013 at 10:42 AM, David Kemp  wrote:

> From the perspective of the js tests, medic (testing master) does:
> - rm -rf ~/.cordova/lib/ios (this ensures no cached crap)
> - use coho to checkout the sources into a clean directory
> - cd into cordova-js
> - git checkout master (for the release branch this currently checks out
> 3.2.x)
> - npm install
> - grunt
>
> running on Mavericks, Xcode 5.01
>
>
>
>
>
>
> On Thu, Dec 12, 2013 at 10:29 AM, Brian LeRoux  wrote:
>
>> Still? How do I reproduce?
>> On Dec 13, 2013 2:28 AM, "David Kemp"  wrote:
>>
>> > Sorry - I did sort of forget to say which test..
>> >
>> > Yes the failure is in cordova-js.
>> >
>> >
>> >
>> >
>> > On Thu, Dec 12, 2013 at 10:15 AM, Brian LeRoux  wrote:
>> >
>> > > cordova-js ?? (Should be passing now but gruntfile was refactored.)
>> > > On Dec 13, 2013 12:06 AM, "David Kemp"  wrote:
>> > >
>> > > > last night a commit to change tests seems to have created a problem
>> > with
>> > > > the iOS and android testing. The grunt test for iOS failed with:
>> > > >
>> > > > deviceready has not fired after 5 seconds.
>> > > >
>> > > > Channel not fired: onNativeReady
>> > > > Channel not fired: onCordovaReady
>> > > > command timed out: 1200 seconds without output, attempting to kill
>> > > >
>> > > > The Android test didn't get that far because it tried to start the
>> test
>> > > > concurrently with the iOS test and :
>> > > >
>> > > > starting browser-based tests
>> > > > Test Server running on:
>> > > > http://127.0.0.1:3000
>> > > >
>> > > >  [31mFatal error: listen EADDRINUSE
>> > > >
>> > >
>> >
>>
>
>

Re: Medic CI failures

[David Kemp]

>From the perspective of the js tests, medic (testing master) does:
- rm -rf ~/.cordova/lib/ios (this ensures no cached crap)
- use coho to checkout the sources into a clean directory
- cd into cordova-js
- git checkout master (for the release branch this currently checks out
3.2.x)
- npm install
- grunt

running on Mavericks, Xcode 5.01






On Thu, Dec 12, 2013 at 10:29 AM, Brian LeRoux  wrote:

> Still? How do I reproduce?
> On Dec 13, 2013 2:28 AM, "David Kemp"  wrote:
>
> > Sorry - I did sort of forget to say which test..
> >
> > Yes the failure is in cordova-js.
> >
> >
> >
> >
> > On Thu, Dec 12, 2013 at 10:15 AM, Brian LeRoux  wrote:
> >
> > > cordova-js ?? (Should be passing now but gruntfile was refactored.)
> > > On Dec 13, 2013 12:06 AM, "David Kemp"  wrote:
> > >
> > > > last night a commit to change tests seems to have created a problem
> > with
> > > > the iOS and android testing. The grunt test for iOS failed with:
> > > >
> > > > deviceready has not fired after 5 seconds.
> > > >
> > > > Channel not fired: onNativeReady
> > > > Channel not fired: onCordovaReady
> > > > command timed out: 1200 seconds without output, attempting to kill
> > > >
> > > > The Android test didn't get that far because it tried to start the
> test
> > > > concurrently with the iOS test and :
> > > >
> > > > starting browser-based tests
> > > > Test Server running on:
> > > > http://127.0.0.1:3000
> > > >
> > > >  [31mFatal error: listen EADDRINUSE
> > > >
> > >
> >
>

Re: Medic CI failures

[David Kemp]

Sorry - I did sort of forget to say which test..

Yes the failure is in cordova-js.




On Thu, Dec 12, 2013 at 10:15 AM, Brian LeRoux  wrote:

> cordova-js ?? (Should be passing now but gruntfile was refactored.)
> On Dec 13, 2013 12:06 AM, "David Kemp"  wrote:
>
> > last night a commit to change tests seems to have created a problem with
> > the iOS and android testing. The grunt test for iOS failed with:
> >
> > deviceready has not fired after 5 seconds.
> >
> > Channel not fired: onNativeReady
> > Channel not fired: onCordovaReady
> > command timed out: 1200 seconds without output, attempting to kill
> >
> > The Android test didn't get that far because it tried to start the test
> > concurrently with the iOS test and :
> >
> > starting browser-based tests
> > Test Server running on:
> > http://127.0.0.1:3000
> >
> >  [31mFatal error: listen EADDRINUSE
> >
>

Medic CI failures

[David Kemp]

last night a commit to change tests seems to have created a problem with
the iOS and android testing. The grunt test for iOS failed with:

deviceready has not fired after 5 seconds.

Channel not fired: onNativeReady
Channel not fired: onCordovaReady
command timed out: 1200 seconds without output, attempting to kill

The Android test didn't get that far because it tried to start the test
concurrently with the iOS test and :

starting browser-based tests
Test Server running on:
http://127.0.0.1:3000

Fatal error: listen EADDRINUSE

Debugging on Android 4.4 with multiple users

[David Kemp]

Just a cautionary note for anyone using multiple accounts on an Android
device.

If you have a secondary user set up that has the ability to install apps,
you can deploy apps to either the primary or secondary user (whichever is
logged in). The primary user works as expected, but when deploying to the
secondary user adb does not correctly start the app. In my testing it
usually brings the battery monitor to the front instead of the app.

This has nothing to do with Cordova, I have replicated it with the sample
accelerometerplay android application.
The step that starts the app in the android tools is:

adb -s  shell am start -W -a android.intent.action.MAIN -n


It works OK if you remove the -W (but returns immediately instead of
waiting)

Reported as a bug in adb.

Re: Plugins Release today

[David Kemp]

You can definitely do an automated build on demand, but the interesting
part is specifying exactly what to build.
Currently a build is made up of a bunch of repos at one tag, and some other
repos at another tag.
We would need to have a well defined way to specify which tag for each repo.

example:
I want to build cordova-android from the 'fancy-pants' branch, because I am
ready to push it to master

I presumably need:
  cordova-android - fancy-pants branch
  cli,plugman,coho,mobilespec, js from master branch
  all plugins from master branch

If we can ALWAYS say that a demand build is the same as a master build, but
with one repo at a different branch that might be pretty easy...




On Wed, Dec 4, 2013 at 2:44 PM, Ian Clelland  wrote:

> On Tue, Dec 3, 2013 at 3:29 PM, Steven Gill 
> wrote:
>
> > On Tue, Dec 3, 2013 at 12:14 PM, Ian Clelland 
> > wrote:> Dev becomes a staging branch, essentially; and all actual dev
> work
> > happens
> >  > on branches. That sounds like a more sane way to do it. The only
> reason
> > I
> > > had it on dev in the first place was to be able to test with buildbot
> --
> > > I'd love to have a way to run those branches through the CI server
> before
> > > merging them into dev/staging/master.
> >
> >
> > Good point. Maybe we standardize a third branch (ducks for cover) that
> the
> > CI server also tests and can be used for breaking dev work. This way dev
> is
> > used for staging and only has code that can be released. I'm afraid that
> > this just adds more complexity to plugins though and I am not a fan of
> > adding more complexity.
> >
>
> I was thinking that it would be cool to be able to force a buildbot build
> of a specific branch (though maybe a set of branches would be required) --
> it wouldn't have to happen with every commit, but you could say "I'm ready
> to merge my feature into dev, let's get buildbot to run all of the tests on
> that branch first, to see if the merge will break anything".
>
> That would avoid the need for a third special branch, but would let anybody
> with access to buildbot (which we hope is everybody, soon) the ability to
> test a branch before merging.
>
> I don't know if it's possible to get buildbot to do that or not; I'll defer
> to David on that subject :)
>
> Ian
>
>
> >
> > >
> >  Ian
> > >
> > >
> > >
> > > > Still confusing at times. It will be
> > > > nice once we can get away from this dev-master setup we have. I'm
> sure
> > > many
> > > > of us have pushed code to dev that isn't in a sate to be released.
> > Maybe
> > > > this point/process should get added to our wiki? Not sure where the
> > best
> > > > place for it would be.
> > > >
> > > >
> > > >
> > > >
> > > > On Tue, Dec 3, 2013 at 11:34 AM, Ian Clelland 
> > > > wrote:
> > > >
> > > > > Hey Steven,
> > > > >
> > > > > File is close to being ready, but I haven't merged in my Android
> code
> > > > yet,
> > > > > and I want to add some more tests, given how critical the plugin
> is.
> > > I'm
> > > > > not comfortable with it going to master yet. If you want, I can
> pull
> > it
> > > > out
> > > > > of dev and put it on another branch. (There have been some other
> > > commits,
> > > > > so we could also create a new branch without those commits, and
> merge
> > > > > *that* into master instead)
> > > > >
> > > > > Let me know how you want to handle it, I'll help out any way I can.
> > > > >
> > > > > Ian
> > > > >
> > > > >
> > > > > On Tue, Dec 3, 2013 at 2:20 PM, Steven Gill <
> stevengil...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Any plugin issues I should know about before releasing today?
> > > > > >
> > > > > > Last I heard file and file-transfer dev branches aren't ready to
> be
> > > > > merged
> > > > > > into master. Has this changed? Ian?
> > > > > >
> > > > > > Plugin issues that are still being reviewed/worked on:
> > > > > > https://issues.apache.org/jira/browse/CB-5525
> > > > > > https://issues.apache.org/jira/browse/CB-5531
> > > > > > https://issues.apache.org/jira/browse/CB-5532
> > > > > > https://issues.apache.org/jira/browse/CB-5430
> > > > > > https://issues.apache.org/jira/browse/CB-5504
> > > > > > https://issues.apache.org/jira/browse/CB-5505
> > > > > >
> > > > > > I can wait until later in the day to release if some of these are
> > > > getting
> > > > > > resolve today. I know Jesse is looking at the windows ones.
> > > > > >
> > > > > > We can also just do another plugin release next week (or post
> > > holidays)
> > > > > > once some of these land.
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [jira] [Resolved] (INFRA-6422) request linux virtual machine for Apache Cordova project

[David Kemp]

Given that I still do not have an internal machine designated for
buildmaster( maybe soon...) , is there any interest in putting a shared
buildbot master on this too?




On Tue, Dec 3, 2013 at 8:22 AM, Mike Billau  wrote:

> Awesome, looks like JIRA has given us a VM to use to collect all of the CI
> data.
>
> Reply if you want/need access and I can email INFRA with all of our names
> at once.
>
> I can also work on setting up the db this week if nobody else wants to.
>
>
>
> -- Forwarded message --
> From: jan iversen (JIRA) 
> Date: Wed, Nov 27, 2013 at 12:20 PM
> Subject: [jira] [Resolved] (INFRA-6422) request linux virtual machine for
> Apache Cordova project
> To: mike.bil...@gmail.com
>
>
>
>  [
>
> https://issues.apache.org/jira/browse/INFRA-6422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
>
> jan iversen resolved INFRA-6422.
> 
>
> Resolution: Fixed
>
> Vm is created and secured (ldap puppet etc).
>
> dns: cordova-vm.a.o
>
> At the moment root@ and I have access. Please catch a root@ person on
> #asfnfra, or mail root@a.o o with apacheid to get access.
>
> The project is expected to maintain the vm and keep it updated with
> patches. If needed infra can help with this task.
>
> In case of questions/problems do not hesitate to contact us.
>
> Have fun
> rgds
> jan I.
>
> > request linux virtual machine for Apache Cordova project
> > 
> >
> > Key: INFRA-6422
> > URL: https://issues.apache.org/jira/browse/INFRA-6422
> > Project: Infrastructure
> >  Issue Type: Task
> >  Security Level: public(Regular issues)
> >  Components: VMWare
> >Reporter: Mike Billau
> >Assignee: jan iversen
> >
> > Hello, the Apache Cordova project would like to use a VM running Linux to
> set up an instance of Apache CouchDB. This CouchDB will collect the results
> of our continuous automated testing framework, Medic. We may end up using
> the VM to host other infrastructure related tools in the future, like our
> NPM registry.
> > I do not really have any requirements for the VM, so any suggestions or
> recommendations for a Linux VM with CouchDB are welcome and appreciated.
> I've read that some distributions of Linux come prebuilt with CouchDB, so
> maybe if we could get one of those that would make things easier. For the
> VM specs, I'd think 1GB RAM and 50GB disk space should be enough.
> > Thanks!
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.1#6144)
>

CLI testing

[David Kemp]

a recent set of commits landed about 1/2 hour ago has broken the CLI tests

343 tests, 572 assertions, 59 failures


looks like most are : Error: ENOENT, no such file or directory

Re: 3.2.0 blog review

[David Kemp]

+1 to removing stuff from the logs
also not that:
CB-4527: This was an easy fix, since the script deletes batch files

isn't descriptive - maybe:
'When a new Android project is created, only the OS-specific the
platform-scripts (my-project/cordova/) are copied over.'



On Fri, Nov 22, 2013 at 9:10 AM, Braden Shepherdson wrote:

> Looks good to me except for the change logs. They're too spammy. I think it
> would be better to remove banal things like bumping the version and fixing
> the tests, leaving only relevant changes. Also there's at least one pair of
> making a change and reverting it, that should probably be dropped.
>
> Braden
> On Nov 21, 2013 6:53 PM, "Carlos Santana"  wrote:
>
> > +1 on blog post and this time including plugin versions
> >
> >
> >
> >
> > On Thu, Nov 21, 2013 at 6:37 PM, Steven Gill 
> > wrote:
> >
> > > posted below in markdown:
> > >
> > > The [Apache Cordova](http://cordova.apache.org/) team has just
> released
> > > Cordova 3.2.0. Woo Hoo! This release has various bug fixes and
> > enhancements
> > > for all of the platforms.
> > >
> > > To upgrade a 3.2 project (replace `android` with the platform you want
> to
> > > update):
> > >
> > > npm install -g cordova
> > > cd my_project
> > > cordova platform update android
> > >
> > > For non-CLI projects or for pre-3.0 projects, refer to the [upgrade
> > > guides](
> > > http://cordova.apache.org/docs/en/3.2.0/guide_platforms_index.md.html
> ).
> > >
> > > Please report any bugs on our [issue tracker](
> > > https://issues.apache.org/jira/browse/CB).
> > >
> > > 
> > >
> > > ## What's new in Android
> > >
> > > * Set VERSION to 3.2.0 (via coho)
> > > * Update JS snapshot to version 3.2.0 (via coho)
> > > * CB-5301 add missing license headers
> > > * CB-5349: fixed regression in update script
> > > * Set VERSION to 3.2.0-rc1 (via coho)
> > > * Update JS snapshot to version 3.2.0-rc1 (via coho)
> > > * CB-5193 Fix Android WebSQL sometime throwing SECURITY_ERR.
> > > * CB-5191 Deprecate 
> > > * Updating shelljs to 0.2.6. Copy now preserves mode bits.
> > > * CB-4872 - moved version script to promise model
> > > * CB-4872 - make sure to copy over version scripts to project
> > > * [CB-4872] - added android version scripts
> > > * CB-5117: Output confirmation message if check_reqs passes.
> > > * Refactoring Android project-level and platform scripts to use Q.js
> > > * Updating to latest shelljs, old version doesn't preserve +x bits
> > > * Remove cordova.xml fallback from Config.java (it was removed from
> > > PluginManager for 3.0)
> > > * CB-5080 Find resources in a way that works with aapt's
> > > --rename-manifest-package
> > > * Update JS snapshot to version 3.2.0-dev (via coho)
> > > * Remove a couple incorrect lines from RELEASENOTES.md
> > > * CB-4961: shell.js returns the full path on ls, rebuilding the full
> path
> > > isn't really needed
> > > * Updating README.md to have latest Android SDK
> > > * CB-4527: This was an easy fix, since the script deletes batch files
> > > * [CB-4892] Fix create script only escaping the first space instead of
> > all
> > > spaces.
> > > * Fix update script to clobber cordova.js file (missing -f)
> > > * Add missing copyright header for Whitelist.java.
> > > * [CB-4832] Add 3.1.0 RELEASENOTES.md
> > > * Update JS snapshot to version 3.2.0-dev (via coho)
> > > * Set VERSION to 3.2.0-dev (via coho)
> > >
> > >
> > > ## What's new in iOS
> > >
> > > * CB-5124 - Remove splashscreen config.xml values from iOS
> Configuration
> > > Docs, move to plugin docs
> > > * CB-5229 - cordova/emulate important improvements (stderr, check
> ios-sim
> > > before build)
> > > * CB-5058 - CordovaLib xcode project gets assigned problematic Build
> > Active
> > > Architecture Only settings.
> > > * CB-5217 - cordova emulate ios doesn't exit
> > > * CB-4805 - Update cordova/run and cordova/lib/install-device to use
> > latest
> > > ios-deploy for iOS 7
> > > * CB-5103 - Fix cordova/run: --emulate should be --emulator (fix CLI
> > usage)
> > > * CB-4872 - added iOS sdk version scripts
> > > * CB-5099 - Add missing icons especially iOS 7 120x120 icon to default
> > > template
> > > * CB-5037 - Fix bridge sometimes not resetting properly during page
> > > transitions
> > > * CB-4990 - Can't run emulator from cordova cli
> > > * CB-4978 - iOS - Remove HideKeyboardFormAccessoryBar and
> > > KeyboardShrinksView preferences in config.xml
> > > * CB-4935 - iOS - Remove Keyboard preferences code into its own plugin
> > > * Make CDVWebViewDelegate able to load pages after a failed load.
> > > * Prevented automatic logging of whitelist failures.
> > >
> > > ## What's new in Windows Phone 7 & 8
> > >
> > > * CB-5418 BrowserMouseHelper fails on WP8 for WP7 apps
> > > * Update to 3.2.0
> > > * CB-5437 Inconsistent default new project names for wp7 and wp8 visual
> > > studio templates
> > > * update js and template defs for 3.2.0-rc1
> > > * Fixes the invalid pattern used to test msbuild availability
> > > * Fix

Medic/CI

[David Kemp]

After a little turmoil, the medic repo is now up to date with the Windows
support added, and still working on mac/ios/android.

Thanks for the additions Sergey!

** and everything except CLI is green **

CI failures - CLI & WP8

[David Kemp]

last error output from npm test of CLI:


Failures:

  1) platform command success `add` should shell out to specified
platform's bin/create, using the version that is specified in
platforms manifest
   Message:
 Expected '"lib/wp/cordova/3.1.0/wp8/wp8/bin/create"
"some/path/platforms/wp8" "ca.filmaj.id" "magical mystery tour"' to
match /lib.wp.cordova.\d.\d.\d[\d\w\-]*.wp8.bin.create/gi.
   Stacktrace:
 Error: Expected '"lib/wp/cordova/3.1.0/wp8/wp8/bin/create"
"some/path/platforms/wp8" "ca.filmaj.id" "magical mystery tour"' to
match /lib.wp.cordova.\d.\d.\d[\d\w\-]*.wp8.bin.create/gi.
at new jasmine.ExpectationResult
(/Users/drkemp/buildbot/slave_common/Tools_CLI/build/cordova-cli/node_modules/jasmine-node/lib/jasmine-node/jasmine-1.3.1.js:114:32)
at null.toMatch
(/Users/drkemp/buildbot/slave_common/Tools_CLI/build/cordova-cli/node_modules/jasmine-node/lib/jasmine-node/jasmine-1.3.1.js:1235:29)
at 
/Users/drkemp/buildbot/slave_common/Tools_CLI/build/cordova-cli/spec/platform.spec.js:150:57
at _fulfilled
(/Users/drkemp/buildbot/slave_common/Tools_CLI/build/cordova-cli/node_modules/q/q.js:798:54)
at self.promiseDispatch.done
(/Users/drkemp/buildbot/slave_common/Tools_CLI/build/cordova-cli/node_modules/q/q.js:827:30)
at Promise.promise.promiseDispatch
(/Users/drkemp/buildbot/slave_common/Tools_CLI/build/cordova-cli/node_modules/q/q.js:760:13)
at 
/Users/drkemp/buildbot/slave_common/Tools_CLI/build/cordova-cli/node_modules/q/q.js:574:44
at flush 
(/Users/drkemp/buildbot/slave_common/Tools_CLI/build/cordova-cli/node_modules/q/q.js:108:17)
at process._tickCallback (node.js:415:13)

  2) platform command success `add` should shell out to specified
platform's bin/create, using the version that is specified in
platforms manifest
   Message:
 Expected
'"lib/windows8/cordova/3.1.0/windows8/windows8/bin/create"
"some/path/platforms/windows8" "ca.filmaj.id" "magical mystery tour"'
to match /lib.windows8.cordova.\d.\d.\d[\d\w\-]*.windows8.bin.create/gi.
   Stacktrace:
 Error: Expected
'"lib/windows8/cordova/3.1.0/windows8/windows8/bin/create"
"some/path/platforms/windows8" "ca.filmaj.id" "magical mystery tour"'
to match /lib.windows8.cordova.\d.\d.\d[\d\w\-]*.windows8.bin.create/gi.
at new jasmine.ExpectationResult
(/Users/drkemp/buildbot/slave_common/Tools_CLI/build/cordova-cli/node_modules/jasmine-node/lib/jasmine-node/jasmine-1.3.1.js:114:32)
at null.toMatch
(/Users/drkemp/buildbot/slave_common/Tools_CLI/build/cordova-cli/node_modules/jasmine-node/lib/jasmine-node/jasmine-1.3.1.js:1235:29)
at 
/Users/drkemp/buildbot/slave_common/Tools_CLI/build/cordova-cli/spec/platform.spec.js:155:57
at _fulfilled
(/Users/drkemp/buildbot/slave_common/Tools_CLI/build/cordova-cli/node_modules/q/q.js:798:54)
at self.promiseDispatch.done
(/Users/drkemp/buildbot/slave_common/Tools_CLI/build/cordova-cli/node_modules/q/q.js:827:30)
at Promise.promise.promiseDispatch
(/Users/drkemp/buildbot/slave_common/Tools_CLI/build/cordova-cli/node_modules/q/q.js:760:13)
at 
/Users/drkemp/buildbot/slave_common/Tools_CLI/build/cordova-cli/node_modules/q/q.js:574:44
at flush 
(/Users/drkemp/buildbot/slave_common/Tools_CLI/build/cordova-cli/node_modules/q/q.js:108:17)
at process._tickCallback (node.js:415:13)

  3) platform command success `add` should call into lazy_load.custom
if there is a user-specified configruation for consuming custom
libraries
   Message:
 Expected '"lib/wp/phonegap/bleeding edge/wp8/wp8/bin/create"
 "some/path/platforms/wp8" "ca.filmaj.id" "magical mystery tour"' to
match /lib.wp.phonegap.bleeding edge.wp8.bin.create/gi.
   Stacktrace:
 Error: Expected '"lib/wp/phonegap/bleeding
edge/wp8/wp8/bin/create"  "some/path/platforms/wp8" "ca.filmaj.id"
"magical mystery tour"' to match /lib.wp.phonegap.bleeding
edge.wp8.bin.create/gi.
at new jasmine.ExpectationResult
(/Users/drkemp/buildbot/slave_common/Tools_CLI/build/cordova-cli/node_modules/jasmine-node/lib/jasmine-node/jasmine-1.3.1.js:114:32)
at null.toMatch
(/Users/drkemp/buildbot/slave_common/Tools_CLI/build/cordova-cli/node_modules/jasmine-node/lib/jasmine-node/jasmine-1.3.1.js:1235:29)
at 
/Users/drkemp/buildbot/slave_common/Tools_CLI/build/cordova-cli/spec/platform.spec.js:173:57
at _fulfilled
(/Users/drkemp/buildbot/slave_common/Tools_CLI/build/cordova-cli/node_modules/q/q.js:798:54)
at self.promiseDispatch.done
(/Users/drkemp/buildbot/slave_common/Tools_CLI/build/cordova-cli/node_modules/q/q.js:827:30)
at Promise.promise.promiseDispatch
(/Users/drkemp/buildbot/slave_common/Tools_CLI/build/cordova-cli/node_modules/q/q.js:760:13)
at 
/Users/drkemp/buildbot/slave_common/Tools_CLI/build/cordova-cli/node_modules/q/q.js:574:44
at flush 
(/Users/drkemp/buildbot/slave_common/Tools_CLI/build/cordova-cli/node_modules/q/q.js:108:17)
at process._tickCallback (node.js:415:13)

Re: Medic. Windows support for review

[David Kemp]

Hi Medic users,
I reviewed these and did some testing (not enough) and pushed the commits.
Unfortunately, now that its live, I have found a serious problem.

working on it...

David Kemp



On Thu, Nov 7, 2013 at 9:29 AM, Carlos Santana  wrote:

> Thanks Sergey !
>
> Testing and CI contributions I consider big improvements!
>
>
> On Thu, Nov 7, 2013 at 8:40 AM, Sergey Grebnov (Akvelon) <
> v-seg...@microsoft.com> wrote:
>
> > I've added wp8 and windows8 support for Medic. Could someone review and
> > merge? David?
> >
> > CB-5152 Medic. Add Windows Phone8 support
> > CB-5153 Medic. Add Windows related info to home page
> > https://github.com/apache/cordova-medic/pull/1
> >
> > CB-5289 Medic. Can't be installed on Windows due to ios-deploy dependency
> > https://github.com/apache/cordova-medic/pull/2
> >
> > CB-5292 Medic. Add Windows8 support
> > https://github.com/apache/cordova-medic/pull/3
> >
> > Notes
> > 1. Changes were tested on Mac 10.8 and Windows8.
> > 2. Windows related config is presented as config.json.sample-windows.
> > 3. WP8: testing is performed on connected device.
> > 4. Windows8: testing is performed on local machine. Looking for options
> to
> > automate installation on connected device.
> >
> > Thx!!
> > Sergey
> >
>
>
>
> --
> Carlos Santana
> 
>

Re: Build Failures: Master - please review

[David Kemp]

Oops!
You are correct Bryan. The last build only has the other failure (plugin
add).

thanks for the fix!

David


On Mon, Nov 4, 2013 at 2:06 PM, Bryan Higgins wrote:

> Hi David,
>
> Are you still seeing the lint errors on master? I put a commit in yesterday
> which resolved them on my machine.
>
>
> On Mon, Nov 4, 2013 at 1:09 PM, David Kemp  wrote:
>
> > Still having a failure in cordova-js
> > Probably from a commit by Bryan Higgins
> > ...
> >
> > [4mRunning "jshint:src" (jshint) task [24m
> > Linting lib/blackberry10/platform.js ... [31mERROR [39m
> >  [31m[ [39m [33mL148 [39m [31m: [39m [33mC13 [39m [31m] [39m
> >  [33mW020 [39m [31m: [39m  [33mRead only. [39m
> >  [31m [7mb [27m [39mlackberry = {};
> >
> >  [33mWarning: Task "jshint:src" failed.  Use --force to continue. [39m
> >
> >  [31mAborted due to warnings. [39m
> >
> >
> > And today - a new failure in 'cordova plugin add ...'
> > after some commits by Joe Bowser
> >
> >
> > Starting installation of "org.apache.cordova.inappbrowser" for
> > android[Error: Plugin doesn't support this project's cordova version.
> > cordova: 2.10.0, failed version requirement: >=3.1.0]
> >
>

Build Failures: Master - please review

[David Kemp]

Still having a failure in cordova-js
Probably from a commit by Bryan Higgins
...

[4mRunning "jshint:src" (jshint) task
Linting lib/blackberry10/platform.js ...ERROR
[L148:C13]
W020: Read only.
blackberry = {};

Warning: Task "jshint:src" failed. Use --force to continue.

Aborted due to warnings.


And today - a new failure in 'cordova plugin add ...'
after some commits by Joe Bowser


Starting installation of "org.apache.cordova.inappbrowser" for
android[Error: Plugin doesn't support this project's cordova version.
cordova: 2.10.0, failed version requirement: >=3.1.0]

Medic / CI build problems

[David Kemp]

I believe this was triggered by a commit from Bryan Higgins, but I am not
sure.

It results in a fail due to lint in the vents

Linting lib/blackberry10/platform.js ...ERROR
[L148:C13]
W020: Read only.
blackberry = {};

Warning: Task "jshint:src" failed. Use --force to continue.

Re: Medic / fruitstrap /xcode 5

[David Kemp]

I agree that it would be better to just run the tools that are part of the
development toolchain. I have been trying to remove all of the special
tooling and only kept that last step of running it on multiple devices (see
reasons below). There are other issues with the ios-deploy that I have not
yet resolved. It has an enormous delay in the middle of it and I have found
that deploys are significantly less reliable since I switched to it. About
30% of the time it just hangs near the run command and the deploy fails.

If you want to add the dependency script as a short-term measure, thats
fine. In the long term I think we need to fix the command line tools to
support the automated deploy properly on all platforms.

-- notes --
It may be possible to use the ios run command line components, but when I
first looked at it there were some issues. The easy solution seemed to keep
the little bit of special code from Medic.
As I recall:
* no support for obtaining a list of devices attached
* no support for deploy only (dont build) - all of the commands want to
prepare/build and that causes problems
* Medic needs to wrap each deploy in a timer to kill it if it doesnt
complete.





On Fri, Nov 1, 2013 at 8:46 AM, Sergey Grebnov (Akvelon) <
v-seg...@microsoft.com> wrote:

> Hi David,
>
> Do we really need 'ios-deploy' module since 'cordova-cli' should support
> installing and listing connected devices, isn't it? I think it is better to
> use cordova-cli for such tasks since we also test this functionality as
> part of the tests preparation process.
>
> Due to 'ios-deploy' reference I can't install Medic on Windows platform;
> as a quick temporary solution we can move 'ios-deploy' dependency to
> devDependency so I can run 'npm install --production' and it will be
> skipped, but the better option seems to be adding additional
> install_dependency.js script like suggested at [1].
>
> David, what do you think the best option to have Medic run on both Mac and
> Windows platform?
>
> [1]http://stackoverflow.com/a/15670089/255654
>
> Thx!
> Sergey
> -Original Message-
> From: drk...@google.com [mailto:drk...@google.com] On Behalf Of David Kemp
> Sent: Monday, October 28, 2013 6:53 PM
> To: dev@cordova.apache.org
> Subject: Re: Medic / fruitstrap /xcode 5
>
> The cordova-medic project has been updated to use the npm version of
> ios-deploy.
>
> Also, separate tests for CLI and plugman have been added.
>
>
> On Mon, Oct 28, 2013 at 10:20 AM, David Kemp  wrote:
>
> > When I run this tool like:
> >
> > ios-deploy --id  --bundle xxx --debug
> >
> > it works, but there is a ~45 second pause after run/success before the
> > mobilespec application actually starts running the test. During that
> > time the cordova bot image is on the device (so something has started).
> >
> > There is no debug output for this time, but at the end of the delay
> > everything moves along as expected.
> >
> > Any idea whats up with that?
> >
> >
> >
> > On Fri, Oct 25, 2013 at 6:28 PM, Shazron  wrote:
> >
> >> related: xcode 5 command line tools however, have a way to deploy to
> >> a device directly but *only* for running XCTest based tests
> >> (xcodebuild -destination [destination-specifier])
> >>
> >>
> >> On Fri, Oct 25, 2013 at 3:23 PM, Shazron  wrote:
> >>
> >> > http://github.com/phonegap/ios-deploy
> >> > or from npm install -g ios-deploy
> >> >
> >> > This is used in cordova-ios
> >> >
> >> >
> >> >
> >> >
> >> > On Fri, Oct 25, 2013 at 1:58 PM, David Kemp 
> >> wrote:
> >> >
> >> >> Hi all,
> >> >> It seems that xcode 5 no longer supports gdb, resulting in
> >> >> fruitstrap
> >> not
> >> >> being able to deploy iOS apps. fruitstrap seems to have a
> >> >> hard-coded
> >> path
> >> >> to where the appropriate gdb bits are.
> >> >> Our test system is currently not running iOS tests for that reason
> >> because
> >> >> xcode conveniently upgraded.
> >> >>
> >> >> I am looking into solutions, but thought someone out there might
> >> >> know a fix.
> >> >>
> >> >> Thoughts?
> >> >>
> >> >> David Kemp
> >> >>
> >> >
> >> >
> >>
> >
> >
>

Re: mobile-spec and releases: How do we test?

[David Kemp]

gt;> >>>will
> >>> >>> timeout even though done was called.
> >>> >>>
> >>> >>
> >>> >> We could file a bug (I ran into it during setup once too), but
> really,
> >>> >> what is the worth of a test if there are no expect clauses?
> >>> >>
> >>> >>
> >>> >>> - I did not remove the manual test page [2]. It would be great if
> we
> >>> >>>had a
> >>> >>> convention for importing these. (ie test harness looks for a page
> at
> >>> >>> www/test/plugin-id.html and adds a link to it if it exists)
> >>> >>>
> >>> >>
> >>> >> I'm going to work on a solution for this today.  The thought is that
> >>> the
> >>> >> plugin has a single module that can define all auto/manual tests,
> and
> >>> >>the
> >>> >> test-harness choses which to display where.
> >>> >>
> >>> >>
> >>> >>>
> >>> >>> [1]
> >>> >>>
> >>> >>>
> >>> >>>
> >>>
> https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-geolocation.git
> >>> >>>;a=commit;h=075850a460d8171a04809cf6317fb4c4ef998603
> >>> >>> [2]
> >>> >>>
> >>> >>>
> >>> >>>
> >>>
> https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-geolocation.git
> >>>
> >>>
> >>>;a=blob;f=test/manual.html;h=6ec2eed03e18c2efaa8710094d60930bb32227ba;hb
> >>> >>>=459a01c01e8dfa2a688d25483bb48c46d8e2
> >>> >>>
> >>> >>>
> >>> >>> On Tue, Oct 15, 2013 at 12:50 PM, David Kemp 
> >>> >>>wrote:
> >>> >>>
> >>> >>> > In spite of that fact that it needs a tooling change, I like the
> >>> >>>added
> >>> >>> >  tag / prepare steps.
> >>> >>> > The tooling change should be small and it means no runtime
> impact on
> >>> >>> apps.
> >>> >>> >
> >>> >>> > I love the approach - a very positive step to cleaning up
> testing.
> >>> >>> >
> >>> >>> > David Kemp
> >>> >>> >
> >>> >>> >
> >>> >>> >
> >>> >>> > On Tue, Oct 15, 2013 at 12:18 PM, Michal Mocny <
> mmo...@chromium.org
> >>> >
> >>> >>> > wrote:
> >>> >>> >
> >>> >>> > > Braden, you're right, good catch.
> >>> >>> > >
> >>> >>> > > Discussing locally how we could support "prepare --mode=..." in
> >>> the
> >>> >>> most
> >>> >>> > > generalized form, we remembered an old suggestion to just
> support
> >>> >>> 
> >>> >>> > > tags.
> >>> >>> > >
> >>> >>> > > The benefits seem to be:
> >>> >>> > > - No need to add custom tag-prefix/attributes for the
> combinations
> >>> >>>of
> >>> >>> > > js-module mode=, asset mode=, etc etc
> >>> >>> > > - More visually apparent when reading a plugin.xml file, akin
> to
> >>> >>> > >  tag
> >>> >>> > >
> >>> >>> > > The drawbacks seem to be:
> >>> >>> > > - Not all descendant tags are easy to support for a given mode
> >>> (ie,
> >>> >>> > > )
> >>> >>> > >
> >>> >>> > >
> >>> >>> > > Summarizing the options currently discussed in this thread:
> >>> >>> > >
> >>> >>> > > - new  tag.  Not general enough solution to
> >>> support
> >>> >>> tests
> >>> >>> > > bundling , so -1 from me for this reason.
> >>> >>> > > - mode="..." attribute for a set of whitelisted tags
> (,
> >>> >>> > ,
> >>> >>> > > ...)
> >>> >>> > > -  tag for a set of whitelisted descendant
> >

Re: CLI build failure

[David Kemp]

There is an interesting issue with detecting change though.
The failure is detected easily because a commit to CLI triggered a build.
The only reason I knew it was fixed was because a commit to JS caused a
rebuild on the Master branches (which worked).

Ideally, updating the plugman NPM module would have been detected an
triggered a build. I am not sure I can track that...


On Tue, Oct 29, 2013 at 7:56 AM, David Kemp  wrote:

>
> The CI always uses master cli and master plugman using this procedure:
>
> git clone CLI
> npm install (installs the 'wrong' plugman)
> delete the node-modules/plugman directory
> git clone plugman (into node-modules/plugman)
> npm install (plugman)
>
> When CLI refers to a plugman that does not exist, the first 'npm install'
> fails and aborts the test.
> If plugman was the last reference, I suppose that the error could possibly
> be ignored and move on anyway, but I am not sure that the npm install would
> really be complete even then (post install tasks?).
>
> If there is a better way to override the npm install behaviour, I would be
> happy to give it a try.
>
> The commit that fixed the problem was about midnight, about an hour before
> Michal checked it.
>
> David
>
>
> On Tue, Oct 29, 2013 at 1:10 AM, Michal Mocny  wrote:
>
>> Just pulled latest cli/plugman to check that the version numbers & deps,
>> and seems that they are.  So im guessing its a tooling version mismatch on
>> the CI machine (using dev cli with released plugman).
>>
>> -Michal
>>
>>
>> On Tue, Oct 29, 2013 at 12:57 AM, Michal Mocny 
>> wrote:
>>
>> > If you are using both versions off master, why are you getting that
>> error
>> > message?
>> >
>> > Seems it may happen if using master CLI and running npm install without
>> > linking plugman first?
>> >
>> >
>> > On Mon, Oct 28, 2013 at 9:52 PM, Steven Gill > >wrote:
>> >
>> >> That is because I pushed plugman + cli to master but not to npm yet.
>> That
>> >> will go away right when they get published to npm. After some more
>> views
>> >> on
>> >> the review of the blog post I will publish them.
>> >>
>> >>
>> >>
>> >> On Monday, October 28, 2013, David Kemp wrote:
>> >>
>> >> > Our CI is failing with the message:
>> >> >
>> >> > Error: No compatible version found: plugman@'>=0.14.0- <0.15.0-'
>> >> > npm ERR!
>> >> >
>> >>
>> >
>> >
>>
>
>

Re: CLI build failure

[David Kemp]

The CI always uses master cli and master plugman using this procedure:

git clone CLI
npm install (installs the 'wrong' plugman)
delete the node-modules/plugman directory
git clone plugman (into node-modules/plugman)
npm install (plugman)

When CLI refers to a plugman that does not exist, the first 'npm install'
fails and aborts the test.
If plugman was the last reference, I suppose that the error could possibly
be ignored and move on anyway, but I am not sure that the npm install would
really be complete even then (post install tasks?).

If there is a better way to override the npm install behaviour, I would be
happy to give it a try.

The commit that fixed the problem was about midnight, about an hour before
Michal checked it.

David


On Tue, Oct 29, 2013 at 1:10 AM, Michal Mocny  wrote:

> Just pulled latest cli/plugman to check that the version numbers & deps,
> and seems that they are.  So im guessing its a tooling version mismatch on
> the CI machine (using dev cli with released plugman).
>
> -Michal
>
>
> On Tue, Oct 29, 2013 at 12:57 AM, Michal Mocny 
> wrote:
>
> > If you are using both versions off master, why are you getting that error
> > message?
> >
> > Seems it may happen if using master CLI and running npm install without
> > linking plugman first?
> >
> >
> > On Mon, Oct 28, 2013 at 9:52 PM, Steven Gill  >wrote:
> >
> >> That is because I pushed plugman + cli to master but not to npm yet.
> That
> >> will go away right when they get published to npm. After some more views
> >> on
> >> the review of the blog post I will publish them.
> >>
> >>
> >>
> >> On Monday, October 28, 2013, David Kemp wrote:
> >>
> >> > Our CI is failing with the message:
> >> >
> >> > Error: No compatible version found: plugman@'>=0.14.0- <0.15.0-'
> >> > npm ERR!
> >> >
> >>
> >
> >
>

CLI build failure

[David Kemp]

Our CI is failing with the message:

Error: No compatible version found: plugman@'>=0.14.0- <0.15.0-'
npm ERR!

Re: Mobile spec tests and exclusion list

[David Kemp]

Specifically I am thinking of  a test that passes on one platform/device
but will not pass on another one.
so maybe 'take them out' was poor language.

If at all possible, the test should be coded in some way to skip it or
change the expectation for that platform/device, rather than 'just knowing'
that test 46 always fails on platform xx.

This could be done in the test itself (inspect cordova-device or something)
or by some external file that describes expected results.
I would generally rather see it done explicitly in the test.




On Mon, Oct 28, 2013 at 10:10 AM, Michal Mocny  wrote:

> Some test frameworks just have an "expectFailure", so a failed test
> actually lets the test suite pass, and a passed test makes it fail.
>
> -Michal
>
>
> On Mon, Oct 28, 2013 at 8:17 AM, David Kemp  wrote:
>
> > -1 for known failing tests. You need to have them all pass for a clean
> run.
> > If the tests don't work, take them out.
> >
> > I would support some additional functionality to the test runner to allow
> > marking tests.
> > We definitely have tests that are know to not work on a platform, OS
> > version or device.
> > Being able to embody that info in the test system would be great.
> >
> > Until we get more stuff cleaned up we also have tests that are flakey and
> > probably should just trigger a rerun if they fail.
> > My preference is to just fix those though.
> >
> >
> >
> >
> >
> > On Sat, Oct 26, 2013 at 11:02 PM, purplecabbage  > >wrote:
> >
> > > Having a known failure in the tests on wp7 is no biggie, it has always
> > > been there. Just move on ...
> > >
> > > Sent from my iPhone
> > >
> > > > On Oct 26, 2013, at 3:24 PM, Michal Mocny 
> wrote:
> > > >
> > > > We have a proposal and prototype on the table right now for
> re-working
> > > > tests to ship with plugins, defined according to auto and manual
> tests.
> > > >
> > > > To accomplish what you ask for would require a specialized testing
> app
> > > that
> > > > simply runs both at the same time. (this wouldn't be the default, but
> > > would
> > > > be easy to make).
> > > >
> > > > Thus, I think the tests shouldn't be modified (its hard to state at
> > test
> > > > definition time in which fashion they should be used), the test
> runner
> > > > should.  This wont solve the problem today, but perhaps in about a
> > month
> > > it
> > > > could.
> > > >
> > > > -Micha
> > > >
> > > >
> > > > On Sat, Oct 26, 2013 at 6:41 AM, Sergey Grebnov (Akvelon) <
> > > > v-seg...@microsoft.com> wrote:
> > > >
> > > >> Hi Michael,
> > > >>
> > > >> Agree. But taking into account having a way to run all the tests
> > > >> (including ones w/ user interaction) is very useful for Windows
> Phone
> > I
> > > >> propose the following
> > > >> 1. No changes for non-WP platforms
> > > >> 2. For WP
> > > >>  a) Use the following condition for the tests which require user
> > > >> interaction
> > > >>define(..., function(...) {
> > > >>  if (isWP8 && !runAll) return;
> > > >>  expect(...);
> > > >>  ...
> > > >>})
> > > >>  b) Current autotests will run w/o runAll option so won't require
> user
> > > >> interaction
> > > >>  c) Add 'Run All Tests (Extended)' option specifically for WP8 where
> > we
> > > >> will have runAll == true
> > > >>
> > > >> Motivation:
> > > >> 1. I don't think we should move such tests to manual tests for WP
> only
> > > to
> > > >> be consistent with other platforms - we actually test api call and
> > check
> > > >> result
> > > >> 2. By default all tests will run w/o any user interaction
> > > >> 3. We will have an option to quickly check all api before release
> via
> > > Run
> > > >> All Tests (Extended). In other case we should have special
> information
> > > how
> > > >> to check all the api and not to forget to run such special tests.
> > > >>
> > > >> Thx!
> > > >> Sergey
> > > >> -Original Message-
> > > >&g

Re: Medic / fruitstrap /xcode 5

[David Kemp]

The cordova-medic project has been updated to use the npm version of
ios-deploy.

Also, separate tests for CLI and plugman have been added.


On Mon, Oct 28, 2013 at 10:20 AM, David Kemp  wrote:

> When I run this tool like:
>
> ios-deploy --id  --bundle xxx --debug
>
> it works, but there is a ~45 second pause after run/success before the
> mobilespec application actually starts running the test. During that time
> the cordova bot image is on the device (so something has started).
>
> There is no debug output for this time, but at the end of the delay
> everything moves along as expected.
>
> Any idea whats up with that?
>
>
>
> On Fri, Oct 25, 2013 at 6:28 PM, Shazron  wrote:
>
>> related: xcode 5 command line tools however, have a way to deploy to a
>> device directly but *only* for running XCTest based tests (xcodebuild
>> -destination [destination-specifier])
>>
>>
>> On Fri, Oct 25, 2013 at 3:23 PM, Shazron  wrote:
>>
>> > http://github.com/phonegap/ios-deploy
>> > or from npm install -g ios-deploy
>> >
>> > This is used in cordova-ios
>> >
>> >
>> >
>> >
>> > On Fri, Oct 25, 2013 at 1:58 PM, David Kemp 
>> wrote:
>> >
>> >> Hi all,
>> >> It seems that xcode 5 no longer supports gdb, resulting in fruitstrap
>> not
>> >> being able to deploy iOS apps. fruitstrap seems to have a hard-coded
>> path
>> >> to where the appropriate gdb bits are.
>> >> Our test system is currently not running iOS tests for that reason
>> because
>> >> xcode conveniently upgraded.
>> >>
>> >> I am looking into solutions, but thought someone out there might know a
>> >> fix.
>> >>
>> >> Thoughts?
>> >>
>> >> David Kemp
>> >>
>> >
>> >
>>
>
>

Re: Medic / fruitstrap /xcode 5

[David Kemp]

When I run this tool like:

ios-deploy --id  --bundle xxx --debug

it works, but there is a ~45 second pause after run/success before the
mobilespec application actually starts running the test. During that time
the cordova bot image is on the device (so something has started).

There is no debug output for this time, but at the end of the delay
everything moves along as expected.

Any idea whats up with that?



On Fri, Oct 25, 2013 at 6:28 PM, Shazron  wrote:

> related: xcode 5 command line tools however, have a way to deploy to a
> device directly but *only* for running XCTest based tests (xcodebuild
> -destination [destination-specifier])
>
>
> On Fri, Oct 25, 2013 at 3:23 PM, Shazron  wrote:
>
> > http://github.com/phonegap/ios-deploy
> > or from npm install -g ios-deploy
> >
> > This is used in cordova-ios
> >
> >
> >
> >
> > On Fri, Oct 25, 2013 at 1:58 PM, David Kemp  wrote:
> >
> >> Hi all,
> >> It seems that xcode 5 no longer supports gdb, resulting in fruitstrap
> not
> >> being able to deploy iOS apps. fruitstrap seems to have a hard-coded
> path
> >> to where the appropriate gdb bits are.
> >> Our test system is currently not running iOS tests for that reason
> because
> >> xcode conveniently upgraded.
> >>
> >> I am looking into solutions, but thought someone out there might know a
> >> fix.
> >>
> >> Thoughts?
> >>
> >> David Kemp
> >>
> >
> >
>

Re: Medic / fruitstrap /xcode 5

[David Kemp]

Awesome!

Thanks!


On Fri, Oct 25, 2013 at 6:28 PM, Shazron  wrote:

> related: xcode 5 command line tools however, have a way to deploy to a
> device directly but *only* for running XCTest based tests (xcodebuild
> -destination [destination-specifier])
>
>
> On Fri, Oct 25, 2013 at 3:23 PM, Shazron  wrote:
>
> > http://github.com/phonegap/ios-deploy
> > or from npm install -g ios-deploy
> >
> > This is used in cordova-ios
> >
> >
> >
> >
> > On Fri, Oct 25, 2013 at 1:58 PM, David Kemp  wrote:
> >
> >> Hi all,
> >> It seems that xcode 5 no longer supports gdb, resulting in fruitstrap
> not
> >> being able to deploy iOS apps. fruitstrap seems to have a hard-coded
> path
> >> to where the appropriate gdb bits are.
> >> Our test system is currently not running iOS tests for that reason
> because
> >> xcode conveniently upgraded.
> >>
> >> I am looking into solutions, but thought someone out there might know a
> >> fix.
> >>
> >> Thoughts?
> >>
> >> David Kemp
> >>
> >
> >
>

Re: Mobile spec tests and exclusion list

[David Kemp]

-1 for known failing tests. You need to have them all pass for a clean run.
If the tests don't work, take them out.

I would support some additional functionality to the test runner to allow
marking tests.
We definitely have tests that are know to not work on a platform, OS
version or device.
Being able to embody that info in the test system would be great.

Until we get more stuff cleaned up we also have tests that are flakey and
probably should just trigger a rerun if they fail.
My preference is to just fix those though.





On Sat, Oct 26, 2013 at 11:02 PM, purplecabbage wrote:

> Having a known failure in the tests on wp7 is no biggie, it has always
> been there. Just move on ...
>
> Sent from my iPhone
>
> > On Oct 26, 2013, at 3:24 PM, Michal Mocny  wrote:
> >
> > We have a proposal and prototype on the table right now for re-working
> > tests to ship with plugins, defined according to auto and manual tests.
> >
> > To accomplish what you ask for would require a specialized testing app
> that
> > simply runs both at the same time. (this wouldn't be the default, but
> would
> > be easy to make).
> >
> > Thus, I think the tests shouldn't be modified (its hard to state at test
> > definition time in which fashion they should be used), the test runner
> > should.  This wont solve the problem today, but perhaps in about a month
> it
> > could.
> >
> > -Micha
> >
> >
> > On Sat, Oct 26, 2013 at 6:41 AM, Sergey Grebnov (Akvelon) <
> > v-seg...@microsoft.com> wrote:
> >
> >> Hi Michael,
> >>
> >> Agree. But taking into account having a way to run all the tests
> >> (including ones w/ user interaction) is very useful for Windows Phone I
> >> propose the following
> >> 1. No changes for non-WP platforms
> >> 2. For WP
> >>  a) Use the following condition for the tests which require user
> >> interaction
> >>define(..., function(...) {
> >>  if (isWP8 && !runAll) return;
> >>  expect(...);
> >>  ...
> >>})
> >>  b) Current autotests will run w/o runAll option so won't require user
> >> interaction
> >>  c) Add 'Run All Tests (Extended)' option specifically for WP8 where we
> >> will have runAll == true
> >>
> >> Motivation:
> >> 1. I don't think we should move such tests to manual tests for WP only
> to
> >> be consistent with other platforms - we actually test api call and check
> >> result
> >> 2. By default all tests will run w/o any user interaction
> >> 3. We will have an option to quickly check all api before release via
> Run
> >> All Tests (Extended). In other case we should have special information
> how
> >> to check all the api and not to forget to run such special tests.
> >>
> >> Thx!
> >> Sergey
> >> -Original Message-
> >> From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal
> >> Mocny
> >> Sent: Saturday, October 26, 2013 4:12 AM
> >> To: dev
> >> Subject: Re: Mobile spec tests and exclusion list
> >>
> >> Auto tests should run automatically without intervention.  If user
> actions
> >> is needed for test to pass, we should call that something different
> (manual
> >> tests have been used).
> >>
> >> I think some varient of #3 is fine, this isn't a common problem.  I
> >> wouldn't even test for Medic specifically, since I want my auto tests to
> >> run automatically even when testing by hand.
> >>
> >> define(..., function(...) {
> >>  if (isWP8) return;
> >>  expect(...);
> >>  ...
> >> })
> >>
> >> -Michal
> >>
> >>
> >> On Fri, Oct 25, 2013 at 4:37 PM, Sergey Grebnov (Akvelon) <
> >> v-seg...@microsoft.com> wrote:
> >>
> >>> Mobile spec autotests include tests which on some platforms require
> >>> user interaction to complete. For example, contact save api on Windows
> >>> Phone requires user to manually click on save  button. This prevents
> >>> the tests to be run as part of Medic test automation since test  app
> >>> just hangs on such api calls.
> >>>
> >>> Is Windows Phone special or there are similar problem on other
> platforms?
> >>>
> >>> I'm thinking about the following possible approaches:
> >>> #1 Ad-hoc solution to Medic - replacing some test files as part of
> >>> Medic functionality (some additional wp specific build step).
> >>> #2 Extending mobile spec functionality- adding something like tests
> >>> exclusion config where you can define test ids (or even the whole api)
> >>> to be skipped. Such exclusion list could be generated on the fly and
> >>> put to the app before starting tests.
> >>> #3 If there are only few such tests we can probably add check for the
> >>> current platform to determine whether to include the test. For example:
> >>> if(!(window.MedicTestRunner && isWP8)) {testDefinition}  Or the same
> >>> way but inside the test to fail gracefully.
> >>>
> >>> Thoughts?
> >>>
> >>> Thx!
> >>> Sergey
> >>
>

Re: Medic tests results consolidation

[David Kemp]

There was an apache request out as well for a machine to run couch and
other things on.
It does not seem to be moving much.

Currently we are just storing it locally and waiting to share...


On Fri, Oct 25, 2013 at 4:40 PM, Sergey Grebnov (Akvelon) <
v-seg...@microsoft.com> wrote:

> Thank you for the info Lorin! Looking forward...
>
> -Sergey
> -Original Message-
> From: Lorin Beer [mailto:lorin.beer@gmail.com]
> Sent: Saturday, October 26, 2013 12:37 AM
> To: dev
> Subject: Re: Medic tests results consolidation
>
> Currently, we are setting up Adobe's Device Wall, as it was dismantled and
> shipped down to SF from the Vancouver office. After we have working setup
> in SF, plans are to address federation of the CI systems each organization
> has setup, and aggregate the results in a single place.
>
> This should be happening over the next two weeks.
>
> - Lorin
>
>
> On Fri, Oct 25, 2013 at 12:40 PM, Sergey Grebnov (Akvelon) <
> v-seg...@microsoft.com> wrote:
>
> > Hi,
> > There were plans to set up a dedicated vm to consolidate test results
> > from different platforms. Could someone let me know where we are? Is
> > there couchdb endpoint available so that I can join with my test
> > results and also compare to other platforms?
> >
> > Thx!
> > Sergey
> >
>

Medic / fruitstrap /xcode 5

[David Kemp]

Hi all,
It seems that xcode 5 no longer supports gdb, resulting in fruitstrap not
being able to deploy iOS apps. fruitstrap seems to have a hard-coded path
to where the appropriate gdb bits are.
Our test system is currently not running iOS tests for that reason because
xcode conveniently upgraded.

I am looking into solutions, but thought someone out there might know a fix.

Thoughts?

David Kemp

github mirror for cordova-registry, cordova-registry-web

[David Kemp]

mirrors are now operational

some code exists in cordova-registry-web

Re: build failure

[David Kemp]

Looks like it fixed it!
On Oct 21, 2013 4:40 PM, "Tim Kim"  wrote:

> Hey David,
>
> I just uploaded a patch that should hopefully things for ya. Let me know if
> there are any more problems.
>
>
> On 18 October 2013 18:51, Tim Kim  wrote:
>
> > Hrmmm. Shoot. Funny how a '.0' can paint you into a corner.
> >
> > I'm not sure if there are any easy solutions to this one since the code
> > always pulls the latest. I think what I'll do is add some logic such that
> > the new version-compare in plugman can handle differing version strings.
> > Unfortunately it's pretty much end of the day for me here, but I'll
> attempt
> > for a fix this weekend.
> >
> >
> >
> > On 18 October 2013 18:27, David Kemp  wrote:
> >
> >> Hi Tim,
> >> That has indeed fixed the master branch, but the 3.1 release branch
> still
> >> has the problem. I currently always build with the latest tool chain
> >> (plugman) so a non backward-compatible change to plugman will be an
> issue.
> >>
> >> That would require that the fix to mobilespec be back-patched to 3.1 as
> >> well. Not sure if that has any other side-effects.
> >>
> >>
> >>
> >>
> >> On Fri, Oct 18, 2013 at 8:59 PM, Tim Kim  wrote:
> >>
> >> > Hey there David,
> >> >
> >> > I just committed a fix for mobile spec. I believe the problem was that
> >> the
> >> > engine tag in cordova-mobile-spec/dependencies-plugin/plugin.xml
> needed
> >> to
> >> > have a patch portion to the version.
> >> >
> >> >
> >> > On 18 October 2013 17:48, David Kemp  wrote:
> >> >
> >> > > Builds are failing due to an inability to add plugins.
> >> > >
> >> > > This started about 8:2pm with three plugman commits by Tim Kim
> >> > >
> >> > > error text:
> >> > >
> >> > > Fetching plugin from "../cordova-mobile-spec/dependencies-plugin"...
> >> > > Starting installation of "org.cordova.mobile-spec-dependencies" for
> >> > > ios[Error: Different version string format detected. Unable to
> compare
> >> > > to versions. Please check the output from your version script and
> the
> >> > > engine tag in your plugin.xml.
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> > Timothy Kim
> >> >
> >>
> >
> >
> >
> > --
> > Timothy Kim
> >
> >
>
>
> --
> Timothy Kim
>

Re: build failure

[David Kemp]

Hi Tim,
That has indeed fixed the master branch, but the 3.1 release branch still
has the problem. I currently always build with the latest tool chain
(plugman) so a non backward-compatible change to plugman will be an issue.

That would require that the fix to mobilespec be back-patched to 3.1 as
well. Not sure if that has any other side-effects.




On Fri, Oct 18, 2013 at 8:59 PM, Tim Kim  wrote:

> Hey there David,
>
> I just committed a fix for mobile spec. I believe the problem was that the
> engine tag in cordova-mobile-spec/dependencies-plugin/plugin.xml needed to
> have a patch portion to the version.
>
>
> On 18 October 2013 17:48, David Kemp  wrote:
>
> > Builds are failing due to an inability to add plugins.
> >
> > This started about 8:2pm with three plugman commits by Tim Kim
> >
> > error text:
> >
> > Fetching plugin from "../cordova-mobile-spec/dependencies-plugin"...
> > Starting installation of "org.cordova.mobile-spec-dependencies" for
> > ios[Error: Different version string format detected. Unable to compare
> > to versions. Please check the output from your version script and the
> > engine tag in your plugin.xml.
> >
>
>
>
> --
> Timothy Kim
>

build failure

[David Kemp]

Builds are failing due to an inability to add plugins.

This started about 8:2pm with three plugman commits by Tim Kim

error text:

Fetching plugin from "../cordova-mobile-spec/dependencies-plugin"...
Starting installation of "org.cordova.mobile-spec-dependencies" for
ios[Error: Different version string format detected. Unable to compare
to versions. Please check the output from your version script and the
engine tag in your plugin.xml.

Re: iOS only cordova-labs plugins (keyboard and statusbar, in plugins branch) - move to cordova-ios repo

[David Kemp]

I would hate to see plugins that are currently ios only get put there, and
then later have another platform supported. That would be ugly.

Can we at least insist that any plugin that goes in the ios platform have a
name like ios-* (likewise for other platforms)


On Fri, Oct 18, 2013 at 1:07 PM, Michal Mocny  wrote:

> +1 to metadata for repo location.
>
> However, I'm still not 100% why these plugins should live in the platform
> repo?  Its just an arbitrary container, right?  I think the fact thats its
> a plugin is more relevant than the fact that they only support ios.  If
> cordova-labs doesn't feel right, then why not make a single cordova-plugins
> repo?  I know we used to have a phonegap-plugins repo and we didn't like
> that, but thats because it had external contributions and unsupported stale
> code.
>
> It doesn't really matter I guess, but I just don't see the point of having
> seperated out all of the plugins into separate repos and now we shove some
> back alongside platforms.
>
> -Michal
>
>
> On Thu, Oct 17, 2013 at 7:32 PM, Shazron  wrote:
>
> > Also, to avoid any "git entanglements" with trying to keep history
> between
> > the two repos (it's possible but I'm not at level of git black-belt yet),
> > I'm just going to copy the folders in, and add them.
> >
> >
> > On Thu, Oct 17, 2013 at 4:11 PM, Shazron  wrote:
> >
> > > I propose moving these iOS only plugins to the cordova-ios repo, and
> > > adding the corresponding components in JIRA (ios-statusbar,
> ios-keyboard)
> > > for issue tracking.
> > > With https://issues.apache.org/jira/browse/CB-5026 - plus these two
> > > plugins, that would make a total of three plugins in cordova-ios
> > (probably
> > > in a plugins subfolder)
> > >
> > > Also, would be great to add the extra meta-data (new tags?) to
> > plugins.xml
> > > to show which repo this comes from, where issues are supposed to go. I
> > > believe we discussed this in the hangout.
> > >
> > >
> >
>

Re: Github mirrors

[David Kemp]

The repos exist on apache, but are empty.

Unless someone can clearly state that the repos ought to go away, I will
leave the INFRA ticket open.

If they are not going to be used, we should file a different ticket...



On Fri, Oct 18, 2013 at 8:57 AM, Braden Shepherdson wrote:

> Chiming in late here, but I thought Cordova-registry was a temporary repo
> Anis had set up during development of the registry, but that it's now
> folded into Cordova-plugman, and can be retired.
>
> Does it hold the website?
>
> Braden
> On Oct 18, 2013 7:55 AM, "David Kemp"  wrote:
>
> > Issue INFRA-6894 - add github mirror for cordova-registry,
> > cordova-registry-web <https://issues.apache.org/jira/browse/INFRA-6894>
> > has
> > been successfully created.
> >
> >
> >
> > On Thu, Oct 17, 2013 at 7:32 PM, Brian LeRoux  wrote:
> >
> > > ya we want everything possible to be mirrored
> > >
> > >
> > > On Thu, Oct 17, 2013 at 8:20 AM, Shazron  wrote:
> > >
> > > > I believe they should be as well.
> > > >
> > > >
> > > > On Thu, Oct 17, 2013 at 7:46 AM, David Kemp 
> > wrote:
> > > >
> > > > > When I went to add to the cordova-medic repo, I found that is was
> not
> > > > > mirrored to github. I have filed a INFRA ticket to fix that.
> > > > >
> > > > > It appears that at least the following repos are also not mirrored:
> > > > >
> > > > > should they be?
> > > > >
> > > > > https://git-wip-us.apache.org/repos/asf/cordova-registry.git
> > > > > https://git-wip-us.apache.org/repos/asf/cordova-registry-web.git
> > > > >
> > > >
> > >
> >
>

Re: Github mirrors

[David Kemp]

Issue INFRA-6894 - add github mirror for cordova-registry,
cordova-registry-web <https://issues.apache.org/jira/browse/INFRA-6894> has
been successfully created.



On Thu, Oct 17, 2013 at 7:32 PM, Brian LeRoux  wrote:

> ya we want everything possible to be mirrored
>
>
> On Thu, Oct 17, 2013 at 8:20 AM, Shazron  wrote:
>
> > I believe they should be as well.
> >
> >
> > On Thu, Oct 17, 2013 at 7:46 AM, David Kemp  wrote:
> >
> > > When I went to add to the cordova-medic repo, I found that is was not
> > > mirrored to github. I have filed a INFRA ticket to fix that.
> > >
> > > It appears that at least the following repos are also not mirrored:
> > >
> > > should they be?
> > >
> > > https://git-wip-us.apache.org/repos/asf/cordova-registry.git
> > > https://git-wip-us.apache.org/repos/asf/cordova-registry-web.git
> > >
> >
>

Re: Tag 2.9.1

[David Kemp]

When the dust settles about what to backport to 2.9, does that mean that
all of that gets pushed back to 3.0 as well?
Plus more?



On Thu, Oct 17, 2013 at 2:52 PM, Shazron  wrote:

> To reiterate (before updating the wiki page)
>
> - Backporting ends with the 3.5 release (or six months, whichever comes
> first)
> - Only backport fixes to 2.9 for serious platform breakages and "easy"
> plugin changes, not new features (iOS 7 changes are new features)
> - No re-organizing of plugins to backport code to (for example in 3.0
> the Notification
> plugin diverged into the Notification and Vibration  plugins, so for 2.9 we
> won't re-organize it also)
>
>
>
>
> On Thu, Oct 17, 2013 at 11:42 AM, Shazron  wrote:
>
> > Thanks Dan,
> > All feedback appreciated! It's one way to contribute, among others. I
> > kicked off a Wiki page under "How to Contribute" -- called 2.9.x support,
> > right now it's empty -- I'll populate it with what we discussed.
> >
> > https://wiki.apache.org/cordova/2.9.x%20Support
> >
> >
> > On Wed, Oct 16, 2013 at 9:36 AM, Dan Moore  wrote:
> >
> >> Hi folks,
> >>
> >> I know this is a dev list, so please let me know if I'm out of line
> >> posting (since I am a user and not a dev), but I couldn't restrain
> myself
> >> from chiming in on this issue.
> >>
> >> First, thanks for supporting 2.9.x for a while.  As a user developing on
> >> top of Cordova, chasing Cordova versions can be tough.  I really felt
> good
> >> about committing to 2.9, especially since 3.x was such a big (good, but
> >> big) change.
> >>
> >> As a user, I would advocate for:
> >> * having a clear end of life date for 2.9.x (3.5 or 6 months or
> whichever
> >> comes first).  The blog is a fine place to put this, but I'd also add
> it to
> >> the 2.9 docs, announce it on the phonegap google group, etc.
> >> * porting as much as possible back (including iOS 7 support)
> >> * documenting what you can't or won't backport in the blog and in the
> >> 2.9.x docs, so users can make an informed choice.
> >>
> >> From this thread, seems like you aren't interested in porting new device
> >> support back to 2.9.x.  That is a bummer.  Is that because of the
> effort?
> >>
> >> When I read that 2.9.x was going to be supported for a 'long time':
> >> http://www.infil00p.org/introducing-cordova-2-8-1-on-android/  I wasn't
> >> sure what that meant, but I hoped it meant support for major new
> versions
> >> of devices (especially on the two marquee platforms).
> >>
> >> As far as no one moving to 3.x, I would say that when you specify the
> end
> >> of life of 2.9.x, that will be a clear signal it is time to move.
> >>
> >> Anyway, I'm sure I can live with whatever is decided, but please do
> >> communicate this as clearly and loudly as you can to us users.
> >>
> >> Thanks!
> >>
> >>
> >> --
> >> Dan Moore
> >> Developing with Cordova CLI
> >> https://leanpub.com/developingwithcordovacli
> >>
> >>
> >> 
> >>  From: Brian LeRoux 
> >> To: "dev@cordova.apache.org" 
> >> Sent: Wednesday, October 16, 2013 9:02 AM
> >> Subject: Re: Tag 2.9.1
> >>
> >>
> >> yes and yes!
> >>
> >>
> >> On Wed, Oct 16, 2013 at 9:49 AM, Marcel Kinard 
> >> wrote:
> >>
> >> > So my intepretation of these comments is:
> >> > - backport fixes to 2.9 for serious platform breakages and "easy"
> plugin
> >> > changes, not new features (new device OS capability such as iOS 7 is
> >> > considered a new feature)
> >> > - stop backporting anything to 2.9 when 3.5 comes out
> >> >
> >> > If so, should this be spelled out somwhere, such as
> >> > cordova.apache.org/blog?
> >> >
> >> > On Oct 15, 2013, at 8:24 PM, Brian LeRoux  wrote:
> >> >
> >> > > 3.5
> >> > >
> >> > > (Or six months.)
> >> > >
> >> > > But ya, what Jesse said.
> >> > >
> >> > > On Tuesday, October 15, 2013, Jesse wrote:
> >> > >
> >> > >> I would not add iOS7 support.
> >> > >> I would consider adding any plugin changes if it is not too
> difficult
> >> > to do
> >> > >> so.
> >> > >>
> >> > >> @purplecabbage
> >> > >> risingj.com
> >> > >>
> >> > >>
> >> > >> On Tue, Oct 15, 2013 at 4:56 PM, Shazron  >> >
> >> > >> wrote:
> >> > >>
> >> > >>> Nothing is "completely" broken in iOS 7, although with iOS 7
> issues
> >> > that
> >> > >> is
> >> > >>> debatable. If we keep patching 2.9.x no one will move on to 3.x...
> >> (at
> >> > >>> least for iOS). There has to be an ending...
> >> > >>>
> >> > >>>
> >> > >>> On Tue, Oct 15, 2013 at 4:53 PM, Jesse  >> > >
> >> > >> wrote:
> >> > >>>
> >> >  Decide what is completely broken in your platform, that is
> >> reasonable
> >> > >> to
> >> >  fix, and fix it.
> >> >  No promises ... just fix what we can, and document that it is
> >> fixed. I
> >> >  think...
> >> > 
> >> >  @purplecabbage
> >> >  risingj.com
> >> > 
> >> > 
> >> >  On Tue, Oct 15, 2013 at 3:10 PM, Shazron  >> > >
> >> > >> wrote:
> >> > 
> >> > > One question about this that was not answered. When does
> >> back-port

Github mirrors

[David Kemp]

When I went to add to the cordova-medic repo, I found that is was not
mirrored to github. I have filed a INFRA ticket to fix that.

It appears that at least the following repos are also not mirrored:

should they be?

https://git-wip-us.apache.org/repos/asf/cordova-registry.git
https://git-wip-us.apache.org/repos/asf/cordova-registry-web.git

Re: Medic/Buildbot - building release versions

[David Kemp]

FYI the commit that updated the plugin names (and would need to be
cherrypicked into 3.1) is:

https://github.com/apache/cordova-mobile-spec/commit/06262fa18baa625003a7e0dc25c740c82ef8baaa




On Thu, Oct 17, 2013 at 10:31 AM, Michal Mocny  wrote:

> I think using MS at master with released platform/cli was a powder keg
> waiting to explode.
>
> We shipped a broken 3.1 mobile spec, and so +1 to your suggestion of fixing
> it and moving CI back to test testing cadence releases with the matching
> MobileSpec.
>
> Side note: part of the problem seems to be that mobile spec is both an app
> and a set of plugins, and those plugins (namely the dependency plugin)
> weren't being updated on the plugin update schedule (weekly).  We should
> make a note to do so in the future (or even move MS plugins out to another
> repo and add to registry?)
>
> -Michal
>
>
> On Thu, Oct 17, 2013 at 8:40 AM, David Kemp  wrote:
>
> > TL;DR : Android release 3.1 is hard to test again due to added tests (to
> > master) that fail. patching 3.1 mobile-spec would be a good thing.
> >
> > Our plan here was to continuously build iOS and Android, both current
> > release and master (4 builds). To do this we build:
> > IOS_Master : iOS (master), plugins(dev), mobile-spec(master)
> > IOS_Release : iOS (3.1), plugins(master), mobile-spec(master)
> > Android_Master : iOS (master), plugins(dev), mobile-spec(master)
> > Android_Release : iOS (3.1), plugins(master, mobile-spec(master)
> >
> > The reason that mobile-spec master is used for release branches is
> because
> > the plugins were renamed just before 3.1, but the dependencies listed in
> > mobile-spec were not updated.
> > (cordova-mobile-spec/dependencies-plugin/plugin.xml)
> >
> > To avoid that problem, we switched to testing 3.1 with master
> mobile-spec.
> > Until last night that worked.
> >
> > However, now mobile-spec (master) has new tests added that will always
> fail
> > for 3.1.
> >
> > SO, I would like to patch 3.1 mobilespec with the plugin dependencies
> from
> > master.
> >
> > Any concerns?
> >
>

Medic/Buildbot - building release versions

[David Kemp]

TL;DR : Android release 3.1 is hard to test again due to added tests (to
master) that fail. patching 3.1 mobile-spec would be a good thing.

Our plan here was to continuously build iOS and Android, both current
release and master (4 builds). To do this we build:
IOS_Master : iOS (master), plugins(dev), mobile-spec(master)
IOS_Release : iOS (3.1), plugins(master), mobile-spec(master)
Android_Master : iOS (master), plugins(dev), mobile-spec(master)
Android_Release : iOS (3.1), plugins(master, mobile-spec(master)

The reason that mobile-spec master is used for release branches is because
the plugins were renamed just before 3.1, but the dependencies listed in
mobile-spec were not updated.
(cordova-mobile-spec/dependencies-plugin/plugin.xml)

To avoid that problem, we switched to testing 3.1 with master mobile-spec.
Until last night that worked.

However, now mobile-spec (master) has new tests added that will always fail
for 3.1.

SO, I would like to patch 3.1 mobilespec with the plugin dependencies from
master.

Any concerns?

Medic / Buildbot / cordova-medic

[David Kemp]

I have pushed the current state of the buildbot CI to the cordova-medic
repo.

The history generally makes sense and provides flow from the medic state in
April to the current state.

Those of you using the Buildbot/medic version - if you want to use this
repo you would need to either update your repos.json or grab the new one
from cordova-medic.

David Kemp

Re: mobile-spec and releases: How do we test?

[David Kemp]

In spite of that fact that it needs a tooling change, I like the added
 tag / prepare steps.
The tooling change should be small and it means no runtime impact on apps.

I love the approach - a very positive step to cleaning up testing.

David Kemp



On Tue, Oct 15, 2013 at 12:18 PM, Michal Mocny  wrote:

> Braden, you're right, good catch.
>
> Discussing locally how we could support "prepare --mode=..." in the most
> generalized form, we remembered an old suggestion to just support 
> tags.
>
> The benefits seem to be:
> - No need to add custom tag-prefix/attributes for the combinations of
> js-module mode=, asset mode=, etc etc
> - More visually apparent when reading a plugin.xml file, akin to
>  tag
>
> The drawbacks seem to be:
> - Not all descendant tags are easy to support for a given mode (ie,
> )
>
>
> Summarizing the options currently discussed in this thread:
>
> - new  tag.  Not general enough solution to support tests
> bundling , so -1 from me for this reason.
> - mode="..." attribute for a set of whitelisted tags (, ,
> ...)
> -  tag for a set of whitelisted descendant
> tags (, , ...)
>
> The last two options are really functionally equivalent, but given that we
> opted for  tag instead of attribute, I'm also favoring a 
> tag.
>
> -Michal
>
>
> On Tue, Oct 15, 2013 at 11:43 AM, Braden Shepherdson  >wrote:
>
> > It's not true that adding these tests only creates larger binaries. They
> > will be fetched and parsed by the plugin loader code at app startup time.
> > It goes through the list of all plugins in cordova_plugins.js and loads
> > them all. That parses them, and runs the outermost layer, which is the
> > wrapping function function(require, module, exports) { ... }. So there is
> > still runtime memory and CPU impact.
> >
> > I support  tags or  or whatever.
> > Similarly, prepare for tests. I realize we want to avoid tooling support,
> > but I think tooling support is a lesser evil than production performance
> > impact.
> >
> > Overall approach makes me happy.
> >
> > Braden
> >
> >
> > On Fri, Oct 11, 2013 at 9:43 PM, Michal Mocny 
> wrote:
> >
> >> On Fri, Oct 11, 2013 at 9:08 PM, Andrew Grieve 
> >> 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 . 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  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 

Re: Medic status and plans

[David Kemp]

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  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 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  wrote:
>>
>> > You can't force push to apache :-/
>> >
>> > On Thu, Oct 10, 2013 at 1:40 PM, Brian LeRoux  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 
>> 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 > >
>> > >> 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
>> &

Re: Medic status and plans

[David Kemp]

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 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  wrote:
>
> > You can't force push to apache :-/
> >
> > On Thu, Oct 10, 2013 at 1:40 PM, Brian LeRoux  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  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 
> > >> 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 g

Re: Medic status and plans

[David Kemp]

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  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 expensive
> part of setting up medic.
>
>
> On Thu, Oct 10, 2013 at 9:47 AM, David Kemp  wrote:
>
> > Hi Sergey,
> > Yes that is the only change to mobilespec regarding medic. It simply
> allows
> > the automated test components to be installed as a plugin without editing
> > any source files other than config.xml.
> >
> > There is a separate discussion going on about changing mobilespec to a
> > wrapper that gets tests out of plugins (since thats mostly what it
> tests),
> > but even that would not significantly change how the CI system operates,
> > just how the test app is built.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Thu, Oct 10, 2013 at 9:37 AM, Sergey Grebnov (Akvelon) <
> > v-seg...@microsoft.com> wrote:
> >
> > > Hi David,
> > >
> > > Thank you for the very valuable input. As per " I recent made a change
> to
> > > mobilespec to support a medic plugin to make the insertion of testing a
> > bit
> > > smoother. " Do you refer to the following changes? Are there other
> > changes
> > &

Re: Medic status and plans

[David Kemp]

Hi Sergey,
Yes that is the only change to mobilespec regarding medic. It simply allows
the automated test components to be installed as a plugin without editing
any source files other than config.xml.

There is a separate discussion going on about changing mobilespec to a
wrapper that gets tests out of plugins (since thats mostly what it tests),
but even that would not significantly change how the CI system operates,
just how the test app is built.









On Thu, Oct 10, 2013 at 9:37 AM, Sergey Grebnov (Akvelon) <
v-seg...@microsoft.com> wrote:

> Hi David,
>
> Thank you for the very valuable input. As per " I recent made a change to
> mobilespec to support a medic plugin to make the insertion of testing a bit
> smoother. " Do you refer to the following changes? Are there other changes
> in this direction in mobile-spec?
>
> https://github.com/apache/cordova-mobile-spec/commit/de23e302daefcfac603fc992e41467d43ae40d87
>
> Thx!
> Sergey
> -Original Message-
> From: David Kemp [mailto:drk...@google.com]
> Sent: Thursday, October 10, 2013 5:06 PM
> To: dev@cordova.apache.org
> Subject: Re: Medic status and plans
>
> More info...
>
> The system I am using uses buildbot which has a master controller that
> provides a web interface, moitors the git repos and generally manages
> things. When it detects a need for a build, it communicates with
> build-slaves to run the tests and report back.
>
> The build master is typically run on a linux box. It seems happy there,
> but should run on a Windows machine - I have never tried, but the docs says
> it works.
> The build slaves can run on other machines and OSs (including Windows) as
> required to run tests.
> If you are building iOS, that slave must be a Mac. If you are building
> Windows, it probably needs to be a Windows slave.
>
> Buildbot is written (and configured) in Python.
>
> The test results are written to a couchDB on every run. You can inspect
> the DB and find out exactly which component versions were used and the
> detailed test results.
>
> Plans (mine at least):
>
> Get the  test output viewable by the community. We are very close to
> having our test master available on a public IP so anyone can see the
> current state. It is my hope that as more people run CI systems, we can
> aggregate the views on ci.cordova.io so all platforms are easily viewed.
> This should include a tidy dashboard to look at the couchDB aggregate data.
>
> Make the test more plugin-based. The previous medic system did sed-style
> editing of files to insert some of the automated test elements.
> I recent made a change to mobilespec to support a medic plugin to make the
> insertion of testing a bit smoother. That is not being used yet in the test
> system because it does not exist in release 3.1. A rough plugin exists in
> the repo.
>
> Move the medic deploy bits to simpler scripts that are just command line
> methods to run the package in debug/attached mode.
>
> Hope that helps.
> There are several other people interested in or using this or similar
> systems. Please jump in...
>
> David Kemp
>
>
>
>
>
> On Thu, Oct 10, 2013 at 3:08 AM, Sergey Grebnov (Akvelon) <
> v-seg...@microsoft.com> wrote:
>
> > Hi guys,
> >
> > I would like to contribute to Medic project by adding Windows
> > platforms support (Windows 8, Windows Phone 8).  After reviewing
> > related discussion threads and project status I have the following
> > questions. Could someone clarify them?
> >
> > 1. The main repo[1] seems to be not active at all (last commit was 6
> > months ago).  I also see special ticket with done status to create
> > official repo, but new repo is not active too.
> > 2. Don't see any issue/task for Medic component in Jira.
> > 3. Medic future is unclear. Fil Maj (Medic lead) has recently moved to
> > saucelabs . Who drives this direction right now? Will we  continue
> > contributing to Medic project or there will be a different project
> > used for test authomation (Appium)?
> > 4. Are there plans or (anyone is already looking)  on adding WP8, W8
> > support? Are there any known technical restrictions or issues here?
> > The only big difference I see is that it should run on Windows instead
> > of Mac OS.
> > 5. Currently Medic uses own logic to install builds on devices
> > (cordova cli already provides this functionality). Are there plans to
> > change this (running Medic on top of cordova cli)?
> > 6. To get test results Medic previously used special logs/trace
> > parsing so that final results were pushed to db from PC, NOT directly
> > from mobile test app installed on a device. Do you plan to change this
> behavior?
> >
> > [1] https://github.com/filmaj/medic/commits/master
> >
> > Thank you,
> > Sergey Grebnov
> >
>

Re: Medic status and plans

[David Kemp]

More info...

The system I am using uses buildbot which has a master controller that
provides a web interface, moitors the git repos and generally manages
things. When it detects a need for a build, it communicates with
build-slaves to run the tests and report back.

The build master is typically run on a linux box. It seems happy there, but
should run on a Windows machine - I have never tried, but the docs says it
works.
The build slaves can run on other machines and OSs (including Windows) as
required to run tests.
If you are building iOS, that slave must be a Mac. If you are building
Windows, it probably needs to be a Windows slave.

Buildbot is written (and configured) in Python.

The test results are written to a couchDB on every run. You can inspect the
DB and find out exactly which component versions were used and the detailed
test results.

Plans (mine at least):

Get the  test output viewable by the community. We are very close to having
our test master available on a public IP so anyone can see the current
state. It is my hope that as more people run CI systems, we can aggregate
the views on ci.cordova.io so all platforms are easily viewed. This should
include a tidy dashboard to look at the couchDB aggregate data.

Make the test more plugin-based. The previous medic system did sed-style
editing of files to insert some of the automated test elements.
I recent made a change to mobilespec to support a medic plugin to make the
insertion of testing a bit smoother. That is not being used yet in the test
system because it does not exist in release 3.1. A rough plugin exists in
the repo.

Move the medic deploy bits to simpler scripts that are just command line
methods to run the package in debug/attached mode.

Hope that helps.
There are several other people interested in or using this or similar
systems. Please jump in...

David Kemp





On Thu, Oct 10, 2013 at 3:08 AM, Sergey Grebnov (Akvelon) <
v-seg...@microsoft.com> wrote:

> Hi guys,
>
> I would like to contribute to Medic project by adding Windows platforms
> support (Windows 8, Windows Phone 8).  After reviewing related discussion
> threads and project status I have the following questions. Could someone
> clarify them?
>
> 1. The main repo[1] seems to be not active at all (last commit was 6
> months ago).  I also see special ticket with done status to create official
> repo, but new repo is not active too.
> 2. Don't see any issue/task for Medic component in Jira.
> 3. Medic future is unclear. Fil Maj (Medic lead) has recently moved to
> saucelabs . Who drives this direction right now? Will we  continue
> contributing to Medic project or there will be a different project used for
> test authomation (Appium)?
> 4. Are there plans or (anyone is already looking)  on adding WP8, W8
> support? Are there any known technical restrictions or issues here? The
> only big difference I see is that it should run on Windows instead of Mac
> OS.
> 5. Currently Medic uses own logic to install builds on devices (cordova
> cli already provides this functionality). Are there plans to change this
> (running Medic on top of cordova cli)?
> 6. To get test results Medic previously used special logs/trace parsing so
> that final results were pushed to db from PC, NOT directly from mobile test
> app installed on a device. Do you plan to change this behavior?
>
> [1] https://github.com/filmaj/medic/commits/master
>
> Thank you,
> Sergey Grebnov
>

Re: Medic status and plans

[David Kemp]

Hi Sergey,
I have been working with medic ( or bits if it) for a couple months. We
have a test system running for just Android and iOS in our office.
You are welcome (encouraged) to grab the code and run your own for windows
testing. The code is in my repo:
https://github.com/drkemp/bb-test

The system I am using is a bit different since the build management is done
with buuldbot. The preparation of a build is done with coho, CLI, etc and
the deploy to devices is done with scripts built from medic.

David Kemp
On Oct 10, 2013 3:09 AM, "Sergey Grebnov (Akvelon)" 
wrote:

> Hi guys,
>
> I would like to contribute to Medic project by adding Windows platforms
> support (Windows 8, Windows Phone 8).  After reviewing related discussion
> threads and project status I have the following questions. Could someone
> clarify them?
>
> 1. The main repo[1] seems to be not active at all (last commit was 6
> months ago).  I also see special ticket with done status to create official
> repo, but new repo is not active too.
> 2. Don't see any issue/task for Medic component in Jira.
> 3. Medic future is unclear. Fil Maj (Medic lead) has recently moved to
> saucelabs . Who drives this direction right now? Will we  continue
> contributing to Medic project or there will be a different project used for
> test authomation (Appium)?
> 4. Are there plans or (anyone is already looking)  on adding WP8, W8
> support? Are there any known technical restrictions or issues here? The
> only big difference I see is that it should run on Windows instead of Mac
> OS.
> 5. Currently Medic uses own logic to install builds on devices (cordova
> cli already provides this functionality). Are there plans to change this
> (running Medic on top of cordova cli)?
> 6. To get test results Medic previously used special logs/trace parsing so
> that final results were pushed to db from PC, NOT directly from mobile test
> app installed on a device. Do you plan to change this behavior?
>
> [1] https://github.com/filmaj/medic/commits/master
>
> Thank you,
> Sergey Grebnov
>

Re: buildbot failure in Cordova Testing on IOS_Master

[David Kemp]

Hi James,
I had to head out of the office and I am not there tomorrow.
I re-ran the tests just now (remotely) on both master and release just to
check again.
If something went screwy with the device, then the release one should have
a failure too (it was clean)

On release branch, both iPads pass all tests.

On Master Branch, one iPad passes all tests, one failed one test...

6.0 - iPad3,1 failed one test.

I can't give much more detail without pulling the device and running the
tests on a development station.
I can't do that until Friday, but if you don't get anywhere I can do that.

failures0specAccelerometer (navigator.accelerometer) getCurrentAcceleration
accelerometer.spec.5 success callback Acceleration object should return a
rec...<http://172.23.188.139:5900/_utils/document.html?mobilespec_results/ios__master__1381359373__6.0__iPad3%2C1#expand>
assertions0exceptionExpected 1381359462105.384 to be greater than
1381359462107.trace





On Wed, Oct 9, 2013 at 6:43 PM, James Jong  wrote:

> Thanks Shaz.  Does anyone else have an iOS 6.0 device they can run the
> tests on?
>
> -James Jong
>
> On Oct 9, 2013, at 6:23 PM, Shazron  wrote:
>
> > Just tested on an iPad 3, iOS 7.0.2  with the dev branch of
> > cordova-plugin-device-motion, it passes all tests.
> >
> >
> > On Wed, Oct 9, 2013 at 2:45 PM, Shazron  wrote:
> >
> >> I have an iPad 3 here with 7.0.2 - I'll test and verify soon.
> >>
> >>
> >> On Wed, Oct 9, 2013 at 2:29 PM, James Jong 
> wrote:
> >>
> >>> I'm ok if you want to skip it.  Right now the issue looks like it's
> >>> limited to iPad 3 and/or 6.0.
> >>> -James Jong
> >>>
> >>> On Oct 9, 2013, at 5:23 PM, Steven Gill 
> wrote:
> >>>
> >>>> Should I skip this plugin for today's release until these issues get
> >>> sorted?
> >>>>
> >>>>
> >>>> On Wed, Oct 9, 2013 at 2:01 PM, James Jong 
> >>> wrote:
> >>>>
> >>>>> Hmm...   Let me check if I have an iPad at 6.0.  I definitely don't
> >>> have
> >>>>> an iPad3 but may have an iPad2.
> >>>>>
> >>>>> -James Jong
> >>>>>
> >>>>> On Oct 9, 2013, at 4:53 PM, David Kemp  wrote:
> >>>>>
> >>>>>>
> >>>>>> Hi James,
> >>>>>>
> >>>>>> That problem went away with the new commit, but now I am getting two
> >>>>> failures on one iPad (6.0__iPad3,1)
> >>>>>> the other iPad passes all tests (6.1.3 - iPad2,5):
> >>>>>>
> >>>>>> I tried it twice with the same results.
> >>>>>>
> >>>>>> failures
> >>>>>> 0
> >>>>>> spec
> >>>>>> Accelerometer (navigator.accelerometer) getCurrentAcceleration
> >>>>> accelerometer.spec.5 success callback Acceleration object should
> >>> return a
> >>>>> rec...
> >>>>>> assertions
> >>>>>> 0
> >>>>>> exception
> >>>>>> timeout: timed out after 7500 msec waiting for win never called
> >>>>>> trace
> >>>>>> 1
> >>>>>> spec
> >>>>>> Accelerometer (navigator.accelerometer) watchAcceleration
> >>>>> accelerometer.spec.5 success callback Acceleration object should
> >>> return a
> >>>>> recent t...
> >>>>>> assertions
> >>>>>> 0
> >>>>>> exception
> >>>>>> Expected 1381351391115.972 to be greater than 1381351399373.
> >>>>>> trace
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Wed, Oct 9, 2013 at 4:36 PM, Andrew Grieve  >
> >>>>> wrote:
> >>>>>> Awesome!
> >>>>>>
> >>>>>>
> >>>>>> On Wed, Oct 9, 2013 at 4:34 PM, James Jong 
> >>> wrote:
> >>>>>>
> >>>>>>> Added.
> >>>>>>> -James Jong
> >>>>>>>
> >>>>>>> On Oct 9, 2013, at 4:23 PM, James Jong 
> wrote:
> >>>>>>>
> >>>>>>>> Ah yes.  Sorry.  I need to add the new framework.
> >>>>>>>>
> >>>>>>>> -James Jong
> >>>>>>>>
> >>>>>>>> On Oct 9, 2013, at 4:08 PM, Andrew Grieve 
> >>>>> wrote:
> >>>>>>>>
> >>>>>>>>> James - our build bot thinks you broke things! Sadly still
> haven't
> >>>>> got
> >>>>>>> it exposed, but the error is:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>>
> /Users/drkemp/buildbot/slave_ios2/IOS_Master/build/mobilespec/platforms/ios/build/emulator/mobilespec.app/mobilespec
> >>>>>>>>> Undefined symbols for architecture armv7:
> >>>>>>>>> "_OBJC_CLASS_$_CMMotionManager", referenced from:
> >>>>>>>>>objc-class-ref in CDVAccelerometer.o
> >>>>>>>>> ld: symbol(s) not found for architecture armv7
> >>>>>>>>> clang: error: linker command failed with exit code 1 (use -v to
> see
> >>>>>>> invocation)
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> ** BUILD FAILED **
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> The following build commands failed:
> >>>>>>>>>Ld build/emulator/mobilespec.app/mobilespec normal armv7
> >>>>>>>>> (1 failure)
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Likely you need to add CoreMotion to the  of the
> >>> plugin.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>
>
>

Re: buildbot failure in Cordova Testing on IOS_Master

[David Kemp]

Hi James,

That problem went away with the new commit, but now I am getting two
failures on one iPad (6.0__iPad3,1)
the other iPad passes all tests (6.1.3 - iPad2,5):

I tried it twice with the same results.

failures0specAccelerometer (navigator.accelerometer) getCurrentAcceleration
accelerometer.spec.5 success callback Acceleration object should return a
rec...
assertions0exceptiontimeout: timed out after 7500 msec waiting for win
never calledtrace1specAccelerometer (navigator.accelerometer)
watchAcceleration accelerometer.spec.5 success callback Acceleration object
should return a recent
t...
assertions0exceptionExpected 1381351391115.972 to be greater than
1381351399373.trace





On Wed, Oct 9, 2013 at 4:36 PM, Andrew Grieve  wrote:

> Awesome!
>
>
> On Wed, Oct 9, 2013 at 4:34 PM, James Jong  wrote:
>
> > Added.
> > -James Jong
> >
> > On Oct 9, 2013, at 4:23 PM, James Jong  wrote:
> >
> > > Ah yes.  Sorry.  I need to add the new framework.
> > >
> > > -James Jong
> > >
> > > On Oct 9, 2013, at 4:08 PM, Andrew Grieve 
> wrote:
> > >
> > >> James - our build bot thinks you broke things! Sadly still haven't got
> > it exposed, but the error is:
> > >>
> > >>
> > >>
> > >>
> >
> /Users/drkemp/buildbot/slave_ios2/IOS_Master/build/mobilespec/platforms/ios/build/emulator/mobilespec.app/mobilespec
> > >> Undefined symbols for architecture armv7:
> > >>  "_OBJC_CLASS_$_CMMotionManager", referenced from:
> > >>  objc-class-ref in CDVAccelerometer.o
> > >> ld: symbol(s) not found for architecture armv7
> > >> clang: error: linker command failed with exit code 1 (use -v to see
> > invocation)
> > >>
> > >>
> > >> ** BUILD FAILED **
> > >>
> > >>
> > >> The following build commands failed:
> > >>  Ld build/emulator/mobilespec.app/mobilespec normal armv7
> > >> (1 failure)
> > >>
> > >>
> > >>
> > >> Likely you need to add CoreMotion to the  of the plugin.
> > >>
> > >>
> > >
> >
> >
>

Re: Mobilespec / CI / version problems

[David Kemp]

With the release, its been a bit busy, but this issue needs some love.

Note that someone else has commented on the same problem from a different
angle (not mobilespec)
[Commented] (CB-4889)  ~ 3am this morning

The renaming of plugins created a hole and there are a couple possible
resolutions.

to help out in a general way (not mobilespec)
1) smack a tag into the git repos for 3.0.x just in front of the name
change. I think you can still do that?
2) publish plugins under the old name. might work if you use new tools with
a 3.0 project
3) document the bug and tell people using 3.0 to switch to 3.1 or update
the plugin name references in their project

to fix mobilespec:
1) #1 above works
2) re-release mobilespec for 3.0.x
3) patch the ios project for 3.0.x to finish removing the Echo plugin files
so you can build 3.0.x with the 3.1.x mobilespec

Thoughts?



On Tue, Oct 1, 2013 at 1:30 PM, David Kemp  wrote:

> Just for clarification...
>
> Testing 3.1.x works fine using 3.1 platforms, 3.1 mobilespec, and master
> plugins.
> Testing 'HEAD' works fine using master platforms, master mobilespec, and
> dev plugins.
>
> Thats all as expected.
>
> Up until a week ago, you could test 3.0.x using 3.0.x platforms, 3.0.x
> mobilespec, and master plugins.
> That no longer works.
>
>
>
> On Tue, Oct 1, 2013 at 12:40 PM, Joe Bowser  wrote:
>
>> Aren't we testing 3.1.0 with the tests that were tagged in 3.1.0?
>> Testing with 3.0.0 tests seems like you'll always have failing tests,
>> since ideally the tests should have been added with the bug (although
>> I don't know where to put platform-specific mobile-spec tests, the
>> don't really have a home and people get upset when I check them in.)
>>
>>
>>
>> On Tue, Oct 1, 2013 at 9:34 AM, David Kemp  wrote:
>> > I believe that will be OK - testing it out now.
>> >
>> > It still probably deserves some documentation somewhere that the
>> previously
>> > stated relationships don't work anymore, and that any plugin references
>> in
>> > a 3.0.x project need attention.
>> >
>> >
>> >
>> > On Tue, Oct 1, 2013 at 12:03 PM, Andrew Grieve 
>> wrote:
>> >
>> >> Would it fix it to use mobile-spec from master when testing 3.0.x?
>> >> Mobile-spec generally stays in sync with the plugins more so than the
>> >> platforms, so it would make sense to me to use mobile-spec at master if
>> >> using plugins from master/dev.
>> >>
>> >>
>> >> On Tue, Oct 1, 2013 at 4:40 PM, David Kemp  wrote:
>> >>
>> >> > The issue is the that stated methodology for getting the right
>> versions
>> >> to
>> >> > test is:
>> >> > * for release, get plugins from the master branch and platforms,
>> tests
>> >> etc
>> >> > from the release branch (3.0.x)
>> >> > * for tip of tree, get plugins from the dev branch and platforms,
>> tests
>> >> etc
>> >> > from the master branch
>> >> > Since the rename was done to the plugins on master (appropriate for
>> >> 3.1.x)
>> >> > that no longer leaves a place to get plugins that are 'compatible'
>> with
>> >> > 3.0.x
>> >> >
>> >> > The issue that I am pointing out right now is that the file:
>> >> > cordova-mobile-spec/dependencies-plugin/plugin.xml
>> >> > explicitly names the plugins with the old name in the 3.0.x branch of
>> >> > mobile-spec. so it breaks.
>> >> >
>> >> > If a developer has a similar references to their 3.0.x plugins, it
>> will
>> >> > also fail next time they build a fresh new project.
>> >> >
>> >> > For CI it means that all tests of the 3.0.x branch now fail.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > On Tue, Oct 1, 2013 at 11:23 AM, Marcel Kinard 
>> >> wrote:
>> >> >
>> >> > > In the past I've used #3. When checking out code to test, I try to
>> get
>> >> > all
>> >> > > the assets from the same branch / time period. But I may be skewed
>> in
>> >> > that
>> >> > > approach, since our product that embeds Cordova has a snapshot of
>> the
>> >> > > platforms and plugins, and doesn't get updates from the online
>> repos.
>> >> > >
>> >> > > Do

Re: Mobilespec / CI / version problems

[David Kemp]

Just for clarification...

Testing 3.1.x works fine using 3.1 platforms, 3.1 mobilespec, and master
plugins.
Testing 'HEAD' works fine using master platforms, master mobilespec, and
dev plugins.

Thats all as expected.

Up until a week ago, you could test 3.0.x using 3.0.x platforms, 3.0.x
mobilespec, and master plugins.
That no longer works.



On Tue, Oct 1, 2013 at 12:40 PM, Joe Bowser  wrote:

> Aren't we testing 3.1.0 with the tests that were tagged in 3.1.0?
> Testing with 3.0.0 tests seems like you'll always have failing tests,
> since ideally the tests should have been added with the bug (although
> I don't know where to put platform-specific mobile-spec tests, the
> don't really have a home and people get upset when I check them in.)
>
>
>
> On Tue, Oct 1, 2013 at 9:34 AM, David Kemp  wrote:
> > I believe that will be OK - testing it out now.
> >
> > It still probably deserves some documentation somewhere that the
> previously
> > stated relationships don't work anymore, and that any plugin references
> in
> > a 3.0.x project need attention.
> >
> >
> >
> > On Tue, Oct 1, 2013 at 12:03 PM, Andrew Grieve 
> wrote:
> >
> >> Would it fix it to use mobile-spec from master when testing 3.0.x?
> >> Mobile-spec generally stays in sync with the plugins more so than the
> >> platforms, so it would make sense to me to use mobile-spec at master if
> >> using plugins from master/dev.
> >>
> >>
> >> On Tue, Oct 1, 2013 at 4:40 PM, David Kemp  wrote:
> >>
> >> > The issue is the that stated methodology for getting the right
> versions
> >> to
> >> > test is:
> >> > * for release, get plugins from the master branch and platforms, tests
> >> etc
> >> > from the release branch (3.0.x)
> >> > * for tip of tree, get plugins from the dev branch and platforms,
> tests
> >> etc
> >> > from the master branch
> >> > Since the rename was done to the plugins on master (appropriate for
> >> 3.1.x)
> >> > that no longer leaves a place to get plugins that are 'compatible'
> with
> >> > 3.0.x
> >> >
> >> > The issue that I am pointing out right now is that the file:
> >> > cordova-mobile-spec/dependencies-plugin/plugin.xml
> >> > explicitly names the plugins with the old name in the 3.0.x branch of
> >> > mobile-spec. so it breaks.
> >> >
> >> > If a developer has a similar references to their 3.0.x plugins, it
> will
> >> > also fail next time they build a fresh new project.
> >> >
> >> > For CI it means that all tests of the 3.0.x branch now fail.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > On Tue, Oct 1, 2013 at 11:23 AM, Marcel Kinard 
> >> wrote:
> >> >
> >> > > In the past I've used #3. When checking out code to test, I try to
> get
> >> > all
> >> > > the assets from the same branch / time period. But I may be skewed
> in
> >> > that
> >> > > approach, since our product that embeds Cordova has a snapshot of
> the
> >> > > platforms and plugins, and doesn't get updates from the online
> repos.
> >> > >
> >> > > Does what you are saying infer that the rename of the plugins is a
> >> > > breaking change? And needs to have some verbage in the Upgrading
> >> guides?
> >> > >
> >> > > On Oct 1, 2013, at 11:14 AM, David Kemp 
> wrote:
> >> > >
> >> > > > Summary: Due to the renaming of plugins, there is no longer a
> >> sensible
> >> > > way
> >> > > > to test 3.0.x
> >> > > >
> >> > > > Detail:
> >> > > > The process to test 3.0.x is to get platforms, mobile-spec, etc
> from
> >> > > 3.0.x
> >> > > > and plugins from master. With the change on plugin names (remove
> >> core)
> >> > > the
> >> > > > 3.0.x mobile-spec still refers to the names with core , but the
> >> master
> >> > > > branch of the plugins no longer have that name.
> >> > > >
> >> > > > Possible resolutions:
> >> > > > 1) never mind - mobilespec for 3.0.x is broken, it will be fixed
> in
> >> > 3.1.x
> >> > > > 2) cherrypick the change to mobilespec dependencies back to 3.0.x
> >> > > > 3) find some other way to get the older plugins available to test.
> >> > > >
> >> > > > Thoughts?
> >> > > >
> >> > > > David Kemp
> >> > >
> >> > >
> >> >
> >>
>

Re: Mobilespec / CI / version problems

[David Kemp]

In answer to Andrews response, there was a problem with 3.0.x where the
echo plugin was mostly removed, but the two source files CDVEcho.m,
CDVEcho.h were left in iOS core. When you build 3.0.x with the master
version (or 3.1.x) of Mobilespec and it includes the new Echo plugin, you
get duplicate symbols.

We could fix that by back-patching 3.0.x to remove the two source files
(should have no effect), then the current master Mobilespec would build
with 3.0.x




On Tue, Oct 1, 2013 at 12:40 PM, Joe Bowser  wrote:

> Aren't we testing 3.1.0 with the tests that were tagged in 3.1.0?
> Testing with 3.0.0 tests seems like you'll always have failing tests,
> since ideally the tests should have been added with the bug (although
> I don't know where to put platform-specific mobile-spec tests, the
> don't really have a home and people get upset when I check them in.)
>
>
>
> On Tue, Oct 1, 2013 at 9:34 AM, David Kemp  wrote:
> > I believe that will be OK - testing it out now.
> >
> > It still probably deserves some documentation somewhere that the
> previously
> > stated relationships don't work anymore, and that any plugin references
> in
> > a 3.0.x project need attention.
> >
> >
> >
> > On Tue, Oct 1, 2013 at 12:03 PM, Andrew Grieve 
> wrote:
> >
> >> Would it fix it to use mobile-spec from master when testing 3.0.x?
> >> Mobile-spec generally stays in sync with the plugins more so than the
> >> platforms, so it would make sense to me to use mobile-spec at master if
> >> using plugins from master/dev.
> >>
> >>
> >> On Tue, Oct 1, 2013 at 4:40 PM, David Kemp  wrote:
> >>
> >> > The issue is the that stated methodology for getting the right
> versions
> >> to
> >> > test is:
> >> > * for release, get plugins from the master branch and platforms, tests
> >> etc
> >> > from the release branch (3.0.x)
> >> > * for tip of tree, get plugins from the dev branch and platforms,
> tests
> >> etc
> >> > from the master branch
> >> > Since the rename was done to the plugins on master (appropriate for
> >> 3.1.x)
> >> > that no longer leaves a place to get plugins that are 'compatible'
> with
> >> > 3.0.x
> >> >
> >> > The issue that I am pointing out right now is that the file:
> >> > cordova-mobile-spec/dependencies-plugin/plugin.xml
> >> > explicitly names the plugins with the old name in the 3.0.x branch of
> >> > mobile-spec. so it breaks.
> >> >
> >> > If a developer has a similar references to their 3.0.x plugins, it
> will
> >> > also fail next time they build a fresh new project.
> >> >
> >> > For CI it means that all tests of the 3.0.x branch now fail.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > On Tue, Oct 1, 2013 at 11:23 AM, Marcel Kinard 
> >> wrote:
> >> >
> >> > > In the past I've used #3. When checking out code to test, I try to
> get
> >> > all
> >> > > the assets from the same branch / time period. But I may be skewed
> in
> >> > that
> >> > > approach, since our product that embeds Cordova has a snapshot of
> the
> >> > > platforms and plugins, and doesn't get updates from the online
> repos.
> >> > >
> >> > > Does what you are saying infer that the rename of the plugins is a
> >> > > breaking change? And needs to have some verbage in the Upgrading
> >> guides?
> >> > >
> >> > > On Oct 1, 2013, at 11:14 AM, David Kemp 
> wrote:
> >> > >
> >> > > > Summary: Due to the renaming of plugins, there is no longer a
> >> sensible
> >> > > way
> >> > > > to test 3.0.x
> >> > > >
> >> > > > Detail:
> >> > > > The process to test 3.0.x is to get platforms, mobile-spec, etc
> from
> >> > > 3.0.x
> >> > > > and plugins from master. With the change on plugin names (remove
> >> core)
> >> > > the
> >> > > > 3.0.x mobile-spec still refers to the names with core , but the
> >> master
> >> > > > branch of the plugins no longer have that name.
> >> > > >
> >> > > > Possible resolutions:
> >> > > > 1) never mind - mobilespec for 3.0.x is broken, it will be fixed
> in
> >> > 3.1.x
> >> > > > 2) cherrypick the change to mobilespec dependencies back to 3.0.x
> >> > > > 3) find some other way to get the older plugins available to test.
> >> > > >
> >> > > > Thoughts?
> >> > > >
> >> > > > David Kemp
> >> > >
> >> > >
> >> >
> >>
>

Re: Mobilespec / CI / version problems

[David Kemp]

I am running regression tests on 3.0.x as well as tests on the tip of tree.
I have not yet switched to running regression on 3.1.x since it isn't
actually released yet.

The problem is that suddenly the 3.0.x tests fail. This is mostly because
the plugins are not tied to a release, but mobilespec is.

Ideally, I would expect that I should be able to go back and check out the
'right' versions and retest any release. That is not true currently since
there is no 'right' versions to get.


On Tue, Oct 1, 2013 at 12:40 PM, Joe Bowser  wrote:

> Aren't we testing 3.1.0 with the tests that were tagged in 3.1.0?
> Testing with 3.0.0 tests seems like you'll always have failing tests,
> since ideally the tests should have been added with the bug (although
> I don't know where to put platform-specific mobile-spec tests, the
> don't really have a home and people get upset when I check them in.)
>
>
>
> On Tue, Oct 1, 2013 at 9:34 AM, David Kemp  wrote:
> > I believe that will be OK - testing it out now.
> >
> > It still probably deserves some documentation somewhere that the
> previously
> > stated relationships don't work anymore, and that any plugin references
> in
> > a 3.0.x project need attention.
> >
> >
> >
> > On Tue, Oct 1, 2013 at 12:03 PM, Andrew Grieve 
> wrote:
> >
> >> Would it fix it to use mobile-spec from master when testing 3.0.x?
> >> Mobile-spec generally stays in sync with the plugins more so than the
> >> platforms, so it would make sense to me to use mobile-spec at master if
> >> using plugins from master/dev.
> >>
> >>
> >> On Tue, Oct 1, 2013 at 4:40 PM, David Kemp  wrote:
> >>
> >> > The issue is the that stated methodology for getting the right
> versions
> >> to
> >> > test is:
> >> > * for release, get plugins from the master branch and platforms, tests
> >> etc
> >> > from the release branch (3.0.x)
> >> > * for tip of tree, get plugins from the dev branch and platforms,
> tests
> >> etc
> >> > from the master branch
> >> > Since the rename was done to the plugins on master (appropriate for
> >> 3.1.x)
> >> > that no longer leaves a place to get plugins that are 'compatible'
> with
> >> > 3.0.x
> >> >
> >> > The issue that I am pointing out right now is that the file:
> >> > cordova-mobile-spec/dependencies-plugin/plugin.xml
> >> > explicitly names the plugins with the old name in the 3.0.x branch of
> >> > mobile-spec. so it breaks.
> >> >
> >> > If a developer has a similar references to their 3.0.x plugins, it
> will
> >> > also fail next time they build a fresh new project.
> >> >
> >> > For CI it means that all tests of the 3.0.x branch now fail.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > On Tue, Oct 1, 2013 at 11:23 AM, Marcel Kinard 
> >> wrote:
> >> >
> >> > > In the past I've used #3. When checking out code to test, I try to
> get
> >> > all
> >> > > the assets from the same branch / time period. But I may be skewed
> in
> >> > that
> >> > > approach, since our product that embeds Cordova has a snapshot of
> the
> >> > > platforms and plugins, and doesn't get updates from the online
> repos.
> >> > >
> >> > > Does what you are saying infer that the rename of the plugins is a
> >> > > breaking change? And needs to have some verbage in the Upgrading
> >> guides?
> >> > >
> >> > > On Oct 1, 2013, at 11:14 AM, David Kemp 
> wrote:
> >> > >
> >> > > > Summary: Due to the renaming of plugins, there is no longer a
> >> sensible
> >> > > way
> >> > > > to test 3.0.x
> >> > > >
> >> > > > Detail:
> >> > > > The process to test 3.0.x is to get platforms, mobile-spec, etc
> from
> >> > > 3.0.x
> >> > > > and plugins from master. With the change on plugin names (remove
> >> core)
> >> > > the
> >> > > > 3.0.x mobile-spec still refers to the names with core , but the
> >> master
> >> > > > branch of the plugins no longer have that name.
> >> > > >
> >> > > > Possible resolutions:
> >> > > > 1) never mind - mobilespec for 3.0.x is broken, it will be fixed
> in
> >> > 3.1.x
> >> > > > 2) cherrypick the change to mobilespec dependencies back to 3.0.x
> >> > > > 3) find some other way to get the older plugins available to test.
> >> > > >
> >> > > > Thoughts?
> >> > > >
> >> > > > David Kemp
> >> > >
> >> > >
> >> >
> >>
>

Re: Mobilespec / CI / version problems

[David Kemp]

I believe that will be OK - testing it out now.

It still probably deserves some documentation somewhere that the previously
stated relationships don't work anymore, and that any plugin references in
a 3.0.x project need attention.



On Tue, Oct 1, 2013 at 12:03 PM, Andrew Grieve  wrote:

> Would it fix it to use mobile-spec from master when testing 3.0.x?
> Mobile-spec generally stays in sync with the plugins more so than the
> platforms, so it would make sense to me to use mobile-spec at master if
> using plugins from master/dev.
>
>
> On Tue, Oct 1, 2013 at 4:40 PM, David Kemp  wrote:
>
> > The issue is the that stated methodology for getting the right versions
> to
> > test is:
> > * for release, get plugins from the master branch and platforms, tests
> etc
> > from the release branch (3.0.x)
> > * for tip of tree, get plugins from the dev branch and platforms, tests
> etc
> > from the master branch
> > Since the rename was done to the plugins on master (appropriate for
> 3.1.x)
> > that no longer leaves a place to get plugins that are 'compatible' with
> > 3.0.x
> >
> > The issue that I am pointing out right now is that the file:
> > cordova-mobile-spec/dependencies-plugin/plugin.xml
> > explicitly names the plugins with the old name in the 3.0.x branch of
> > mobile-spec. so it breaks.
> >
> > If a developer has a similar references to their 3.0.x plugins, it will
> > also fail next time they build a fresh new project.
> >
> > For CI it means that all tests of the 3.0.x branch now fail.
> >
> >
> >
> >
> >
> > On Tue, Oct 1, 2013 at 11:23 AM, Marcel Kinard 
> wrote:
> >
> > > In the past I've used #3. When checking out code to test, I try to get
> > all
> > > the assets from the same branch / time period. But I may be skewed in
> > that
> > > approach, since our product that embeds Cordova has a snapshot of the
> > > platforms and plugins, and doesn't get updates from the online repos.
> > >
> > > Does what you are saying infer that the rename of the plugins is a
> > > breaking change? And needs to have some verbage in the Upgrading
> guides?
> > >
> > > On Oct 1, 2013, at 11:14 AM, David Kemp  wrote:
> > >
> > > > Summary: Due to the renaming of plugins, there is no longer a
> sensible
> > > way
> > > > to test 3.0.x
> > > >
> > > > Detail:
> > > > The process to test 3.0.x is to get platforms, mobile-spec, etc from
> > > 3.0.x
> > > > and plugins from master. With the change on plugin names (remove
> core)
> > > the
> > > > 3.0.x mobile-spec still refers to the names with core , but the
> master
> > > > branch of the plugins no longer have that name.
> > > >
> > > > Possible resolutions:
> > > > 1) never mind - mobilespec for 3.0.x is broken, it will be fixed in
> > 3.1.x
> > > > 2) cherrypick the change to mobilespec dependencies back to 3.0.x
> > > > 3) find some other way to get the older plugins available to test.
> > > >
> > > > Thoughts?
> > > >
> > > > David Kemp
> > >
> > >
> >
>

Re: Mobilespec / CI / version problems

[David Kemp]

The issue is the that stated methodology for getting the right versions to
test is:
* for release, get plugins from the master branch and platforms, tests etc
from the release branch (3.0.x)
* for tip of tree, get plugins from the dev branch and platforms, tests etc
from the master branch
Since the rename was done to the plugins on master (appropriate for 3.1.x)
that no longer leaves a place to get plugins that are 'compatible' with
3.0.x

The issue that I am pointing out right now is that the file:
cordova-mobile-spec/dependencies-plugin/plugin.xml
explicitly names the plugins with the old name in the 3.0.x branch of
mobile-spec. so it breaks.

If a developer has a similar references to their 3.0.x plugins, it will
also fail next time they build a fresh new project.

For CI it means that all tests of the 3.0.x branch now fail.





On Tue, Oct 1, 2013 at 11:23 AM, Marcel Kinard  wrote:

> In the past I've used #3. When checking out code to test, I try to get all
> the assets from the same branch / time period. But I may be skewed in that
> approach, since our product that embeds Cordova has a snapshot of the
> platforms and plugins, and doesn't get updates from the online repos.
>
> Does what you are saying infer that the rename of the plugins is a
> breaking change? And needs to have some verbage in the Upgrading guides?
>
> On Oct 1, 2013, at 11:14 AM, David Kemp  wrote:
>
> > Summary: Due to the renaming of plugins, there is no longer a sensible
> way
> > to test 3.0.x
> >
> > Detail:
> > The process to test 3.0.x is to get platforms, mobile-spec, etc from
> 3.0.x
> > and plugins from master. With the change on plugin names (remove core)
> the
> > 3.0.x mobile-spec still refers to the names with core , but the master
> > branch of the plugins no longer have that name.
> >
> > Possible resolutions:
> > 1) never mind - mobilespec for 3.0.x is broken, it will be fixed in 3.1.x
> > 2) cherrypick the change to mobilespec dependencies back to 3.0.x
> > 3) find some other way to get the older plugins available to test.
> >
> > Thoughts?
> >
> > David Kemp
>
>

Mobilespec / CI / version problems

[David Kemp]

Summary: Due to the renaming of plugins, there is no longer a sensible way
to test 3.0.x

Detail:
The process to test 3.0.x is to get platforms, mobile-spec, etc from 3.0.x
and plugins from master. With the change on plugin names (remove core) the
3.0.x mobile-spec still refers to the names with core , but the master
branch of the plugins no longer have that name.

Possible resolutions:
1) never mind - mobilespec for 3.0.x is broken, it will be fixed in 3.1.x
2) cherrypick the change to mobilespec dependencies back to 3.0.x
3) find some other way to get the older plugins available to test.

Thoughts?

David Kemp

Re: Plugman Release

[David Kemp]

+1  to a plugman npm release.

David Kemp



On Mon, Sep 30, 2013 at 4:34 PM, Steven Gill  wrote:

> Anyone see any issue with me doing a npm plugman release today? Testing the
> CLI RC is kind of weird when the plugman dependency is incompatible.
>
> -Steve
>

Re: Cordova CI - Medic

[David Kemp]

Good to know!

I have been co-ordinating with Mike Billau directly (not so much on the
list) just because the traffic was specialized.
Probably a mistake on my part.

I have located a low-cost hub that works well with iPads (has a 2.1A
output) and collected 7 or 8 Android & iOS devices here to runs tests on.
Past that I have been trying to get the tests to run reliably (fixing
mobilespec) and reporting bugs that people introduce.

I am not aware of any plans to move buildbot to Apache. I'm not connected
with the group that maintains it at all, its just that theres lots of
people around here that know it well so help is always at hand.

I would recommend that if you spin this up, put the build master on a Linux
instance, and run the slaves on a Mac. Running the build master on the same
Mac as the slaves seems to introduce instability. Also weak from a security
standpoint.

We are putting up a virtual Linux box that will be build master and the
couchDB and will ultimately be exposed to the community. Then perhaps
ci.cordova.io can be a central access point for anyone running tests.





On Mon, Sep 30, 2013 at 1:49 PM, Steven Gill  wrote:

> Hey David,
>
> A few of us here at Adobe are just ramping up on the CI stuff again. We are
> waiting for our device wall to ship to the SF office and will be spending
> time getting medic/buildbot running. Would love to coordinate efforts.
>
> Also, any plans on moving build bot to apache?
>
> -Steve
>
>
> On Mon, Sep 30, 2013 at 10:25 AM, David Kemp  wrote:
>
> > Hi all,
> >
> > I have been running the buildbot/medic CI system at Google for several
> > weeks now. I have been corresponding with Mike Billau who is also running
> > the system.
> >
> > The is a plan in the works to get the output available publicly to the
> > community, but approvals are required. It will still take a little while.
> >
> > Is anyone else looking into CI or interested in checking it out?
> > Is there interest on the list for email notifications when the build
> > breaks?
> >
> > David Kemp
> >
>

Cordova CI - Medic

[David Kemp]

Hi all,

I have been running the buildbot/medic CI system at Google for several
weeks now. I have been corresponding with Mike Billau who is also running
the system.

The is a plan in the works to get the output available publicly to the
community, but approvals are required. It will still take a little while.

Is anyone else looking into CI or interested in checking it out?
Is there interest on the list for email notifications when the build breaks?

David Kemp

CLI tool - Medic testing

[David Kemp]

Summary:
Fresh checkout of Cordova-Cli from master results in a cli that will not
add a plugin.

[Error: Error fetching plugin: TypeError: Cannot call method 'fetch'
of undefined]


Details:
The current Cordova-cli master requires a version of plugman that has not
yet been published.
Cli requires plugman 0.12.x and that plugman does not expose 'raw'.
Cordova-plugman (master) does expose 'raw', but that version has not been
published to npm.

This will only be an issue if you get a fresh git checkout of cli from
master, and don't overwrite the plugman with a fresh checkout as well. It
does not affect the version of cli that is published via npm.

David Kemp

Re: mobile-spec and releases: How do we test?

[David Kemp]

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  wrote:

> Yeah, I have pushed some changes to mobile-spec, and when I did I also
> copied the tests into the plugin involved.
> Until we get the magic test runner happening, I think we just keep
> duplicating.
>
> @purplecabbage
> risingj.com
>
>
> On Wed, Sep 25, 2013 at 4:38 PM, Steven Gill 
> wrote:
>
> > We copied over tests into plugins when we first broke them out, but I
> don't
> > believe they have been updated.
> >
> > I would say for now to just add the tests to mobile spec, and possibly in
> > the future we go all voltron to build mobile spec and keep tests with
> their
> > corresponding plugins.
> >
> >
> > On Wed, Sep 25, 2013 at 4:22 PM, Joe Bowser  wrote:
> >
> > > Hey
> > >
> > > Right now, I'm working on a weird file issue that requires me to
> > > update mobile-spec, but I'm wondering where the tests should live.
> > > Should it all keep living in mobile-spec, or is it with the plugins.
> > > And if it's with the plugins, will there be scripts to assemble
> > > mobile-spec all Voltron style?
> > >
> > > This came up earlier, but I haven't found any fix that needed a
> > > mobile-spec test.  (Many that need native testing, like recursive file
> > > copy, etc).  Any thoughts?
> > >
> > > Joe
> > >
> >
>