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
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
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
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
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
I've been curious about the split made to the main sources for a while now.
https://github.com/apache/groovy/tree/master/src/main
Since src/main/groovy can contain both java and groovy sources, why are there
any sources in src/main/java? For me, it makes locating and navigating
cumbersome
