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:sparkRunnerPreCommit' > > > 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) >> >> >> > >
