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 unimportant detail being the language of implementation. We could debate this but we always try to be pragmatic and we get benefit from Gradle from the former. So, I did that for the src/main folder. I have only done this in master so far and wasn't planning to back port to 2_5_X at this stage. It also revealed a bunch of Javadoc assertion tests that weren't being run. That is fixed also.
Cheers, Paul. On Sun, May 19, 2019 at 10:08 PM Cédric Champeau <cedric.champ...@gmail.com> wrote: > 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 > generate stubs for all Java classes just in case they would be used by > Groovy sources. The intuitive part to me is that Groovy sources should live > in `src/main/groovy`, the Java sources in `src/main/java`, and that joint > sources should be in another directory (we don't do this). Then it's also > about performance: it means we can use incremental Java compilation, and > soon Groovy incremental compilation too. So this is not just about what a > human would think, this is just about good separation of concerns, and > software architecture in general. > > Le dim. 19 mai 2019 à 00:29, Paul King <pa...@asert.com.au> a écrit : > >> 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 structured according to gradle guidelines but I don't think we quite >> ever got src/main and src/test in groovy to be fully compliant. We should >> probably look at that again. >> >> On Sun, May 19, 2019 at 5:35 AM Milles, Eric (TR Tech, Content & Ops) < >> eric.mil...@thomsonreuters.com> wrote: >> >>> 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 since I need to guess which folder a source is likely >>> to be in. And I didn't expect to find any "org.codehaus" packages in >>> src/main/groovy, but there are some in there. Could they be ported to Java >>> so that src/main/groovy only contains the groovy.* packages? Or could all >>> the packages in src/main/java be moved to src/main/groovy? >>> >>
