Hi Lukasz, you are right for the command, missed the naming done in the loop :).
About the default I still think being CI friendly instead of user/dev friendly by default is not the best but it is subjective. About mvn module build: seems at the end I manage to build 1 or 2 modules only - which fits well mvn - often enough to see gradle project init slow but can be specific to my machine too and my way to iterate. @Kenneth: why not dropping the doc for a script with comments in the project? A "RUNME.sh" ;). Le 23 janv. 2018 00:41, "Kenneth Knowles" <[email protected]> a écrit : This thread does bring up a nice idea: We should add a little FAQ / Cookbook somewhere for common tasks, like running just an IT with a particular runtime config or running the unit tests of a deep module. On Mon, Jan 22, 2018 at 2:58 PM, Lukasz Cwik <[email protected]> wrote: > > > > > On Mon, Jan 22, 2018 at 2:40 PM, Romain Manni-Bucau <[email protected] > > wrote: > >> >> >> Le 22 janv. 2018 21:46, "Lukasz Cwik" <[email protected]> a écrit : >> >> 1. Are you trying to have version overrides in a module depend on the >> parent's version and not in one global place?, >> Doesn't this lead to compatibility issues if you don't live with a single >> version of a dependency across the entire repo (unless that dependency is >> shaded away of course). >> >> >> Ismael can detail this point more than me but this is sadly already the >> case. We were looking to override part of the tree due to incompatibilities >> between spark and bigquery driver. >> >> >> 2. How is what you describe different from './gradlew >> :runners:spark:build' >> >> >> I want to run only spark in the wordcount module for instance. Not a >> runner module but a runner execution in a multi runners module. >> > > I see. I think your referring to './gradlew :examples:java:sparkRunnerPreC > ommit' > > >> >> >> 3. Can be overridden on command line or per user properties file but I >> would rather have our users execute as close to what we test in Jenkins so >> that the differences between a dev and CI workflow is minimal. >> >> >> Hmm, are you sure it is the case everywhere? For me default should be >> usable and CI use overrides but both options are valid. Just a very >> different experience compared to maven. >> > > '--no-parallel' and '--max-workers' on the command line, > 'org.gradle.parallel' and 'org.gradle.workers.max' within > 'gradle.properties' in gradle user home > > >> >> 4. configuration on demand is enabled by default and it should only >> configure the projects that are needed so I'm not sure what you are asking >> for here. >> >> >> Running a submodule only is slower than maven so when working on a module >> - during dev - it is quite costly, in particular debugging through the >> build. >> > > Is there a better alternative in Maven then continuously installing > modules anytime you make a cross module change which is error prone or > build all the modules with '-am' all the time which is slow? > > >> >> >> On Mon, Jan 22, 2018 at 12:20 PM, Romain Manni-Bucau < >> [email protected]> wrote: >> >>> Hi >>> >>> As mentionned in another thread, Im sending this mail to report some >>> differences between maven and gradle setups - percieved as regressions from >>> this side of the fence: >>> >>> 1. Parent versions are not usable in children as variables - btw why not >>> putting them in gradle.properties as ut is often done? (Not blocking) >>> 2. Multi executions are not all runnable once by one. Typical example is >>> surefire executions are selectable using surefire:test@id with maven >>> but the for loop in gradle is never parameterized so no way to run only >>> spark runner test suite for instance. (Almost blocking to work efficiently >>> but easy to fix) >>> 3. Concurrency is hardcoded and way too high for most computers leading >>> to freezing the computer and preventing the user to do anything (tested on >>> an i7 with 32G of RAM and a SSD). (Blocking but easy to fix i guess if we >>> use the rule of thumb to keep concurrency off by default) >>> 4. Setup is slow when not using the daemon since it browses the whole >>> project so a lazy setup can be beneficial when working on submodules (not >>> that blocking until you rely on build.gradle setup) >>> >>> >>> >> >> >
