ah as soon as I sent, I realized that failed test output goes to the console, so all is well on that front. There are no dumb questions, right?
On Tue, Nov 12, 2019 at 9:11 AM Michael Sokolov <msoko...@gmail.com> wrote: > > Hi I am playing around with the gradle build. Overall looks great! > Thanks to everyone who has been pushing this forward. I have a few > questions; maybe just gradle noob questions, since I haven't used it > much (except as part of Android Studio, where all the details are kind > of taken care of for you). > > 1) I'm not sure which branch is the "current" one. Ideally I'd like to > be using a branch based off master. I see there are lots of branches: > jira/SOLR-13452_gradle_2, 3, 4, ... I started with _7 since that is > what is referenced in the wiki: > https://cwiki.apache.org/confluence/display/SOLR/Intro+to+the+Gradle+build, > but that seems to be a little out of date, so I switched to 8, because > you know, bigger is better. What are all these numbers? Just tracking > snapshots along the way? Which is the one based off 8x? > > 2) When I run any gradle command I get this warning: > > > Configure project : > not user home user.gradle /home/sokolov/user.properties > > Its grammar is throwing me: does it mean it expects to find these > files and can't find them? I have no user.properties file in my > homedir: should I? > > 3) I can run tests in a package using (eg) ./gradlew > lucene:lucene-core:test and see the test report output in an html file > - cool. Is it possible to get test output to stdout though? I am used > to running tests in emacs and have a script set up for parsing stack > traces in the output so emacs can jump there. I know I can use > intellij, and I often do, but I would like to also get the emacs > workflow going - definitely should not be a blocker for switching to > this - I am just looking for some hints as to getting errors logged to > stdout by gradle. > > 4) If I use the --tests option to specify a single test class to run, > and the class does not exist (I made a booboo, say), the build runs no > tests, and succeeds, but this is misleading: it should fail instead, > as the ant build does. Again, not a blocker, but if anybody knows how > to fix this, it would be great. I'll open an issue anyway. > > again thanks, this looks awesome; with the daemon it runs so nicely :) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
