Okay, the bootstrap compiler doesn't need src/main/groovy anymore, so that
is gone too.
On Mon, May 20, 2019 at 6:32 AM Paul King wrote:
>
> On Mon, May 20, 2019 at 4:46 AM Jochen Theodorou
> wrote:
>
>> and how did the build times change? Do we still have incremental builds
>> for the java par
On Mon, May 20, 2019 at 4:46 AM Jochen Theodorou wrote:
> and how did the build times change? Do we still have incremental builds
> for the java parts? Because as I understood Cedric this is not the case
> anymore now.
>
I am unsure what you are asking. I haven't done any performance testing of
On 19.05.19 14:26, Paul King wrote:
True. But "good" separation of concerns is to some degree in the eye of
the beholder. Separating by language of implementation caters for one
concern, i.e. language of implementation. Another way would be to group
all source related to one bit of functionality
True. But "good" separation of concerns is to some degree in the eye of the
beholder. Separating by language of implementation caters for one concern,
i.e. language of implementation. Another way would be to group all source
related to one bit of functionality together and hide away a potentially
u
This is not just about Gradle, and not related to the build cache. There
are different things: mixing Java and Groovy sources in a single source
tree **only** makes sense for sources which are _joint compiled_. Otherwise
you're just slowing down your build arbitrarily, because Groovy has to
generat
Yes, the split of java/groovy files into src/main[java|groovy] can be
considered a bit of an anti-pattern for humans, it does help gradle. Gradle
supports both but performs better when split strictly according to
guidelines, e.g. for build caching purposes. All of the subprojects should
be structur
