groovy project's src/main/* folders

["Milles, Eric (TR Tech, Content & Ops)" <er...@thomsonreuters.com>]

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?

Re: groovy project's src/main/* folders

[Paul King <pa...@asert.com.au>]

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 <pa...@asert.com.au> wrote:

>
> On Mon, May 20, 2019 at 4:46 AM Jochen Theodorou <bl...@gmx.org>
> 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
> the build. We are now more compliant with the Gradle recommendations that
> Cédric referred to, so in theory faster now and more likely to have
> incremental build support. We still add 'src/main/groovy' as a Java
> sourceSet (for the bootstrap compiler). I haven't checked whether that is
> still needed and I am unsure whether that means the extra structuring has
> no affect on performance as yet.
>
> Cheers, Paul.
>
>

Re: groovy project's src/main/* folders

[Paul King <pa...@asert.com.au>]

On Mon, May 20, 2019 at 4:46 AM Jochen Theodorou <bl...@gmx.org> 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
the build. We are now more compliant with the Gradle recommendations that
Cédric referred to, so in theory faster now and more likely to have
incremental build support. We still add 'src/main/groovy' as a Java
sourceSet (for the bootstrap compiler). I haven't checked whether that is
still needed and I am unsure whether that means the extra structuring has
no affect on performance as yet.

Cheers, Paul.

Re: groovy project's src/main/* folders

[Jochen Theodorou <bl...@gmx.org>]

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 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.

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.

For development I think it depends on your IDE-setup what you need. I
usually have the sources compiled by the IDE for java and them being
used over the Groovy jar. That way I do not to rebuild the jar for most
cases. And in that kind of setup the gradle really is only needed for a
full build. But that setup is actually difficult to explain to the IDEs.

If you go with the more obvious version and let the IDE rebuild the jars
everytime you execute, then you do want incremental builds normally.

bye Jochen

Re: groovy project's src/main/* folders

[Paul King <pa...@asert.com.au>]

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 <ce...@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.milles@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?
>>>
>>

Re: groovy project's src/main/* folders

[Cédric Champeau <ce...@gmail.com>]

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.milles@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?
>>
>

Re: groovy project's src/main/* folders

[Paul King <pa...@asert.com.au>]

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.milles@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?
>