Le 22 janv. 2018 21:46, "Lukasz Cwik" <lc...@google.com> 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. 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. 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. 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) > > >
