Re: Gradle / Mvn diff

Well it is more about consistency and reliability than speed here. Comoilabtion result is just corrupted :( Le 25 janv. 2018 20:33, "Lukasz Cwik" a écrit : > You can only get incremental support at the build system level, not at the > individual tool level like javac. The task

Re: Gradle / Mvn diff

One pitfall I noted with javac wrappers is that if you dont clean - and loose javac incremental support then deleted classes stay here and are considered in the output. Common example is a nested class which has been deleted leading to a corrupted enclosing class or a test which is ran but deleted

Re: Gradle / Mvn diff

These are two different things: dependency-driven build (which works) and incremental build (which seems not to, at least right now?). On Wed, Jan 24, 2018 at 2:24 PM, Romain Manni-Bucau wrote: > Hmm, I'll try to refine it then next time we work with Ismael but can be a >

Re: Gradle / Mvn diff

Hmm, I'll try to refine it then next time we work with Ismael but can be a setup issue or a human (bad command) issue at the end. Thanks for the help, will make next iteration way easier probably :) Romain Manni-Bucau @rmannibucau | Blog

Re: Gradle / Mvn diff

Tasks always run any dependencies that are required. So if you ask to run test it shouldn't run javadoc/checkstyle/... but should compile the code and compile the code of all dependencies. test should never have a dependency on checkstyle or javadoc or similar 'check' like tasks as they shouldn't

Re: Gradle / Mvn diff

Hmm, do I miss something or it only works for iterative runs when trying to identify an issue and not for the case you rebuild due to code changes (where you would need like 5-6 tasks at least - generate, compile, test, ...)? In case it is unclear: there are 2 needs: direct execution/task ->

Re: Gradle / Mvn diff

Gradle already has each task explicitly broken out. Kenn is pointing out that you your development use case shouldn't use the './gradlew :sdks:java:core:build' task since it is really an aggregator that represents do everything within that project. This is the current list of tasks available for

Re: Gradle / Mvn diff

Can have mischecked gradle setup but I don't think we are here yet, if you are not bound in a module and work accross 2 modules and iterate between working on both and one, you will likely not bypass the "checks" in a satisfying way without a long -x command, is there a magic flag I missed? Also

Re: Gradle / Mvn diff

On Tue, Jan 23, 2018 at 2:51 PM, Romain Manni-Bucau wrote: Hmm, did you read it right Kenn? I think the idea was to skip all > validation/sanity checks tasks at once (gradle -Pfast) instead of > doing it manually (gradle -x findbugs -x checkstyle etc...) > Yes, I

Re: Gradle / Mvn diff

2018-01-24 0:08 GMT+01:00 Lukasz Cwik : > > > On Tue, Jan 23, 2018 at 2:51 PM, Romain Manni-Bucau > wrote: > >> >> >> 2018-01-23 23:44 GMT+01:00 Kenneth Knowles : >> >>> Romain - really good point about docs getting out of date. >>> >>>

Re: Gradle / Mvn diff

On Tue, Jan 23, 2018 at 2:51 PM, Romain Manni-Bucau wrote: > > > 2018-01-23 23:44 GMT+01:00 Kenneth Knowles : > >> Romain - really good point about docs getting out of date. >> >> > On 01/23/2018 09:29 AM, Romain Manni-Bucau wrote: >>> >> Yep, >>> >> >>>

Re: Gradle / Mvn diff

2018-01-23 23:44 GMT+01:00 Kenneth Knowles : > Romain - really good point about docs getting out of date. > > > On 01/23/2018 09:29 AM, Romain Manni-Bucau wrote: >> >> Yep, >> >> >> >> a compromise can be to ensure all custom tasks have a description >> maybe: >> > > This is a

Re: Gradle / Mvn diff

Romain - really good point about docs getting out of date. > On 01/23/2018 09:29 AM, Romain Manni-Bucau wrote: > >> Yep, > >> > >> a compromise can be to ensure all custom tasks have a description maybe: > This is a great idea. Let's do both! I think the thing that the comments in the gradle

Re: Gradle / Mvn diff

Big +1 to Kenneth's idea on a cookbook for common tasks, it is easy to feel frustrated with gradle when we cannot achieve easily some of the tasks we need to, like overwriting a configuration property. The case that Romain mentioned above is a common one, e.g. I used to test kafka with a different

Re: Gradle / Mvn diff

Good idea. It sounds like a simple and good improvement to me. Regards JB On 01/23/2018 09:29 AM, Romain Manni-Bucau wrote: > Yep, > > a compromise can be to ensure all custom tasks have a description maybe: > > diff --git a/examples/java/build.gradle b/examples/java/build.gradle > index

Re: Gradle / Mvn diff

Yep, a compromise can be to ensure all custom tasks have a description maybe: diff --git a/examples/java/build.gradle b/examples/java/build.gradle index 0fc0b17df..001bd8b38 100644 --- a/examples/java/build.gradle +++ b/examples/java/build.gradle @@ -130,7 +130,7 @@ def preCommitAdditionalFlags

Re: Gradle / Mvn diff

Hi Romain, I think we are pretty close: agree to add some explicit tasks & projects names. We can add additional tasks like skipAudit, for instance. As reminder, gradle tasks provides the list of tasks and gradle projects provides the list of projects/modules. Regards JB On 01/23/2018 08:12

Re: Gradle / Mvn diff

Hmm, I have to admit docs dont have my favor cause they are easily outdated and hard to search but you hit a good point. Starting by renaming properly the tasks and maybe writing what is done in build files - since it is code and even "api for dev", it requires as much comments than the main api -

Re: Gradle / Mvn diff

On Mon, Jan 22, 2018 at 10:03 PM, Romain Manni-Bucau wrote: > @Kenneth: why not dropping the doc for a script with comments in the > project? A "RUNME.sh" ;). > That's cool, too, but also any shell one liner can be a gradle one liner or mvn two/three liner :-). it is just

Re: Gradle / Mvn diff

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 wrote: > > > > > On Mon,

Re: Gradle / Mvn diff

On Mon, Jan 22, 2018 at 2:40 PM, Romain Manni-Bucau wrote: > > > Le 22 janv. 2018 21:46, "Lukasz Cwik" 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

Re: Gradle / Mvn diff

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

Re: Gradle / Mvn diff

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

Gradle / Mvn diff

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