https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# community-support
s
This message was deleted.
v
Can you show the behavior in an MCVE? Because if you did it properly I don't think this warning should be shown.
j
We also had warnings like this in a project recently and they looked to me like false positives. We did not investigate further at that point and now they are gone. On which Gradle version are you? Maybe double check with another Gradle version to make sure that this is not some kind of bug.
e
The problem here is, that if one triggers a build using 
-Dorg.gradle.project.buildDir=/tmp/foo
(which is fairly interesting when running builds in the container, but this is a other story), and this build ends up having composite builds, all composite builds are relocated, but without any namespacing. This leads to issues that the buildDir is shared. Without composite builds, this works without any issues. Odd that buildDir is not namespaced by default in this cases, but yes, all composites usually have there own dedicated build folder, so there is no need for that usually
we are on 7.4.2 in this case, but as mentioned, the mystery is solved :)
j
When 
org.gradle.project.buildDir
was added as a thing (Gradle 0.1 probably 😄) included builds where not invented yet. In general, I would not modify it the build directory through this built-in property. If you pass any property via command line, it is passed to all builds of the composite. I didn’t know that this works at all with several subprojects. This is old Gradle functionality I think that is not maintained to work well with composites. To change the the build dir via a command line parameter, I would use my own and add something like this to the build for all projects:
Copy code
layout.buildDirectory.set(layout.dir(providers.gradleProperty("my-own-property").map { File("$it/${project.name}") }))
In the 
map { }
part you may also use “project.path” or something like this if names are not unique. Building your own namespacing.
e
Well it was not a question of does it make sense. Gradle workflows are still fairly clunky for container usage, eventhough since 5.x all the caching an cache reusing parts got a lot better of course. Still the usual issues with containers, which run under a different UID/GUID remain. If you mount your java project into the container for e2e testing and builds
(as a developer, not in the CI), the builds inside the container create files with a UID/GUID which the developer can not manipulate, but more not delete on his local machine. This means, without relocating the build folder, it is shared between the container and the developer, which makes running IT tests locally and running e2e in the container problematic. Sure the finaly touch is using GOSU and a dynamic UID/GUID mapping so the build files are writting using the UID/GUID of the developer OS, but that is way harder then relocating the build folder. But well, this or that, relocating the build folder for builds including composite builds obviously is a nogo, wished to find it out a different way. E.g. gradle directly blocking this and throwing an error instead of showing some kind of warnings of arbitrary side effects which one has to conclude from
But the more we work with composite build the more we learn that it is not perfect yet - and for sure a hard problem for the gradle devs to deal with (def. complex problems to solve). But one has for sure to learn a lot more about gradle and its side effects before really using those composite builds in a wide manner IMHO
2 Views
Open in Slack
PreviousNext
Powered by