During the gradle migration, we used to have something like:
include(":sdks:java:core")
include(":sdks:java:extensions:sql")
include(":sdks:python")
but we discovered the Maven module names that were used during publishing
were "core" / "sql" / ... (effectively the directory name) instead of
"beam-sdks-java-core". Using the default at the time also broke the
artifact names for intra project dependencies that we generate[1]. Finally,
we also ran into an issue because we had more then one Gradle project with
the same directory name even though they were under a different parent
folder (I think it was "core") and that was leading to some strange build
time behavior.
We didn't migrate to a flat project structure where each project is a
folder underneath the root project because of the existing Maven build
rules that were being maintained in parallel and I'm not sure if people
would want to have a flat project structure either.
1:
https://github.com/apache/beam/blob/a85ea07b719385ec185e4fc5e4cdcc67b3598599/buildSrc/src/main/groovy/org/apache/beam/gradle/BeamModulePlugin.groovy#L1055
On Mon, Apr 1, 2019 at 9:49 AM Michael Luckey <[email protected]> wrote:
> Hi,
>
> although I did not yet manage to get deeper involved into actual
> development, I think this ability would be a useful addition.
>
> But I would also like to point out, that this is kind of implicit, as soon
> we get https://issues.apache.org/jira/browse/BEAM-4046 included.
>
> For instance, we would change the current setup from
>
> include "beam-sdks-java-core"
> project(":beam-sdks-java-core").dir = file("sdks/java/core")
>
> to something like
>
> include(":sdks:java:core")
> include(":sdks:java:extensions:sql")
> include(":sdks:python")
>
>
> With this in place a plain
>
> $ ./gradlew -p sdks/java build
>
> would exactly do what you want. And, of course, this will also work for
> 'sdks/java/io', 'runners/' etc. Hope, you get the point.
>
> Currently, we deviate from gradle default convention and therefore have to
> implement some quirks to restore default behaviour. And I somehow dislike
> the structure introduced by parent/child folders, which will be destroyed
> by our current project definitions.
>
> But, to be honest, although I have some clear understanding on how to
> proceed here - especially regarding the requirement to keep the change
> backwards compatible - we might decide not to switch. Because deeper
> investigation might reveal issues, which I am currently not aware of.
>
> Best,
>
> michel
>
> On Mon, Apr 1, 2019 at 5:52 PM Jean-Baptiste Onofré <[email protected]>
> wrote:
>
>> Hi guys,
>>
>> I would like to introduce a Gradle "meta" project for the build:
>> beam-sdks-java.
>>
>> The idea is to simply build all Java SDK related resources (core, IO,
>> ...).
>>
>> The purpose is also to be aligned with the other SDKs which provide
>> beam-sdks-go and beam-sdks-python.
>>
>> Thoughts ?
>>
>> Regards
>> JB
>> --
>> Jean-Baptiste Onofré
>> [email protected]
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
