Agreed, this seems awesome. Thanks Josh!
> On Sep 10, 2015, at 1:09 PM, David McLaughlin <[email protected]> wrote: > > +1 to this, seems like an ideal solution to getting testing into the UI > asap. > > On Thu, Sep 10, 2015 at 10:30 AM, Joshua Cohen <[email protected]> > wrote: > >> One question: will this effort get us any closer to improving >> iteration speed? I.e. not requiring gradle run on a host machine >> before jumping into vagrant? >> >> >> No, this won't have any impact on iteration speed, as things currently >> stand, there's going to be some need for gradle to run on the host machine >> to process the resources into the correct format/location for serving. >> There are certainly things we can do to get around that, but I feel like >> the current `./gradlew processResources --continuous` solution is Good >> Enough, and additional work on this front is not worthy of additional >> attention at the moment. >> >> On Thu, Sep 10, 2015 at 11:34 AM, Maxim Khutornenko <[email protected]> >> wrote: >> >>> +1. Thanks for driving this Joshua! >>> >>> One question: will this effort get us any closer to improving >>> iteration speed? I.e. not requiring gradle run on a host machine >>> before jumping into vagrant? >>> >>> On Thu, Sep 10, 2015 at 9:20 AM, Joshua Cohen <[email protected]> >>> wrote: >>>> Yes, it should be. I haven't actually verified it myself yet, but based >>> on >>>> the description of the gradle node.js plugin[1], it seems completely >>>> painless: >>>> >>>> This plugin enables you to run any NodeJS script as part of your build. >>> It >>>> does not depend on NodeJS (or NPM) being installed on your system. The >>>> plugin will download and manage NodeJS distributions, unpack them into >>> your >>>> local .gradle directory and use them from there. >>>> >>>> [1] https://github.com/srs/gradle-node-plugin >>>> >>>> >>>> On Thu, Sep 10, 2015 at 11:18 AM, Bill Farner <[email protected]> >>> wrote: >>>> >>>>> I think this is great! Am i understanding correctly that this will >> all >>> be >>>>> self-bootstrapping on dev machines? >>>>> >>>>> On Thu, Sep 10, 2015 at 8:44 AM, Joshua Cohen < >> [email protected]> >>>>> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> I recently posted an update on this ticket: >>>>>> https://issues.apache.org/jira/browse/AURORA-451 describing what I >>> see >>>>> as >>>>>> the best way forward to enable tests for our UI code. I figured this >>>>>> warranted some extra attention so calling it out here as well. To >>> restate >>>>>> what's in the ticket, I propose the following: >>>>>> >>>>>> - Add gradle nodejs support ( >>>>> https://github.com/srs/gradle-node-plugin >>>>>> ). >>>>>> This lets us use node.js to drive tests but does not require >>>>> developers >>>>>> install node.js manually. The plugin instead manages the node.js >>>>> install >>>>>> for you. >>>>>> - Configure karma ( >>>>>> >>>>>> >>>>> >>> >> http://stackoverflow.com/questions/22336537/how-to-run-js-karma-tests-from-gradle >>>>>> ). >>>>>> Karma is a test runner that can launch webdriver tests for >> testing >>>>>> angular >>>>>> apps in the browser. >>>>>> - Write tests (https://docs.angularjs.org/guide/unit-testing). >>> Should >>>>>> speak for itself. >>>>>> >>>>>> The benefit of using karma/webdriver is that tests will load code >> the >>>>> same >>>>>> way the browser does, so no need to bring in something like >>>>>> browserify/webpack so that code can be resolved in a node.js >>> environment >>>>> as >>>>>> well as in the browser. >>>>>> >>>>>> Interested to hear thoughts on this proposal. >>>>>> >>>>>> Thanks! >>>>>> >>>>>> Joshua >>>>>> >>>>> >>> >>
