Added support for building with Sencha Cmd on Travis-CI

[superstructor]

• installs Sencha Cmd 3.1.2.342 in .travis.yml
• installs jsduck rubygem in .travis.yml
• executes sencha package build in .travis.yml
• sets up framebuffer and adds Firefox to Karma tests
• removes compiled JavaScripts from repository

In future pre-built releases will be available on the http://deftjs.org website and as downloads on the GitHub releases feature. The GIT repository itself will no longer be ready to use without Sencha Cmd.

Any comments / concerns / questions @johnyanarella , @brian428 before we merge this ?

Should we also remove generated documentation from the repository as it is also a build artefact ?

Thanks

[brian428]

I'm pretty strongly against the idea of removing the JS files from the repo. Not everyone uses Cmd, especially for existing Ext JS projects. We have older projects with their own build processes (usually Maven) that predates Cmd, and I'm sure many others do as well. I think it would be a mistake to make Cmd the only way to obtain the library.

For the docs, I could go either way. But there's probably some benefit to having them in the repo and readily available if people have it cloned.

Basically, I agree that supporting Cmd is important now, but I don't think we should FORCE people to use Cmd.

[brian428]

Ah, I missed your last bit about having the libs available as downloads. That covers most of my concern, but guess I could see how having the libs as part of the repo may still be useful. But as long as the libs are available outside of Cmd (and you're saying they would be), I could go either way.

[superstructor]

@brian428 These are valid concerns. I want to assure you that this does not FORCE people to use Sencha Cmd.

A package ZIP file including pre-concatenated and inidividual JavaScript source files will be available both from GitHub via the releases feature and via the http://deftjs.org website.

This change is not in relation to supporting command or not. Instead the motivation is from a testability perspective that we are doing a full build in continuous integration instead of just testing committed compiled artefacts.

Does this alleviate your concerns ? Apologies if this was not clear or for any confusion.

[brian428]

It would mean we'd probably need to be more diligent (automated?) in keeping the deftjs.org download link up to date. Right now it's still serving up 0.8.0, so that prompted me to update the link to 0.9.1. ;-)

I also emailed Github to ask them to add an option to allow a generic archive link that just always points at the most recent tag, e.g. github.com/user/repo/archive/latest/zip. But now I digress heh.

[brian428]

Nope, all good now. It wasn't a lack of clarity on your part, it was a lack of finishing reading on my part!

[superstructor]

Note issue #117 aims to automate deployment of up-to-date packages to both the GitHub releases feature and the deftjs.org website.

[johnyanarella]

@brian428 I'd like to start taking advantage of the GitHub Releases feature and Releases API anyway. I imagine that the download link would take you to a page that outlines your options for installing Deft JS -- preferencing Sencha Cmd and our package repo, but also offering a link to our releases page (or a custom page populated via the Release API if possible).

[johnyanarella]

@superstructor Looks great.

Thanks for adding the Travis CI config for Firefox!