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).
2. How is what you describe different from './gradlew :runners:spark:build' 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. 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. On Mon, Jan 22, 2018 at 12:20 PM, Romain Manni-Bucau <rmannibu...@gmail.com> 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) > > >
