+1 On Thu, Sep 10, 2015 at 1:30 PM, Joseph Smith <[email protected]> wrote:
> 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 > >>>>>> > >>>>> > >>> > >> > >
