https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# community-support
s
This message was deleted.
e
the empty 
:something
project is the parent of 
:something:else
. if you don't want that then you need to flatten the project hierarchy. you can do that without changing directory layout,
Copy code
include(":something-else")
project(":something-else").projectDir = file("something/else")
🙌 2
m
Love this! Are there any performance ramifications that this change could cause?
c
only the initial bump to change settings.gradle accordingly; after that it’s routine builds.
🙌 1
m
Perfect, going to give this a try
Sorry, quick question - I was writing an extension function on 
Settings
to wrap this logic, but where does the 
file(...)
method come from? Is that just 
<http://java.io|java.io>.File($PATH)
?
c
Gradle provides a file function in various contexts that resolves to java.io.File ultimately.
m
Right - but the 
Settings
object doesn't seem to have a 
file(..)
method defined? https://docs.gradle.org/current/javadoc/org/gradle/api/initialization/Settings.html
c
not sure where Gradle defines it, if it even does for settings.gradle. Use 
File
if need be.
👍 1
e
m
Ah this is why I was confused - I was defining my extension in a 
.kt
file of an included build:
Copy code
fun Settings.includeProject...
And that object doesn't have a 
file
defined. I would rather not copy+paste the 
projectDir...
thing everywhere, trying to figure out a way to standardize
Perhaps I'll define the extension on 
Script
instead
e
using 
File
directly fails on some platforms while 
file
works (we've hit this in our own build, never determined why) https://github.com/gradle/gradle/issues/19249
😢 1
v
File(...)
with a relative path is relative to the current working directory. The current working directory often is the project directory, but not always and also in no way guaranteed. So whenever you use 
File(...)
with a relative path, your build is broken at least as time bomb. Using 
File(...)
with a relative path is almost always wrong in any program unless the relative path comes from the user via command line option. 
file(...)
on the other hand resolves the path relative to the project or settings directory.
e
we encountered the issue even with 
File("$projectDir/...")
, it's not just the working directory, it was some weird classloader stuff
never dug into it because 
file()
is better anyway
v
Ok, never seen that, but if it is Mac only that's clear as I'm not a Mac man. :-)
e
I don't work on mac typically, but need to support developers who do
getting back to OP's point, if you write the function inside of your settings script, it has access to everything in the script context anyways, no need to make it an extension fun of 
Settings
or any other specific receiver
Copy code
// settings.gradle.kts
fun includeFlattened(projectDir: String) {
    val projectName = projectDir.replace('/', '-')
    include(projectName)
    project(projectName).projectDir = file(projectDir)
}
includeFlattened("something/else") // etc.
you can see that Gradle itself uses this trick (although a bit fancier): https://github.com/gradle/gradle/blob/master/settings.gradle.kts#L223
m
Right, but I have multiple builds with multiple 
settings.gradle.kts
files - wanted to define this method in one place and use it everywhere
v
Then write a settings plugin, or at least some library that you then add via 
buildscript { ... }
block if not a plugin. Then you can use it.
👍 1
4 Views
Open in Slack
PreviousNext
Powered by