We've a collection of libraries developed by different teams and individually pushed to different Git repositories. To minimize the hassle of publishing to local Maven repositories or publishing snapshot versions, we've put together a root project to include all those libraries with Gradle's dependencies substitutions.
The structure is as follows:
- root (Git-root)
...
- modules
- module-a (Git-module-a)
- a-core
- build.gradle.kts
- a-data
- build.gradle.kts
- settings.gradle.kts
- module-b (Git-module-b)
- b-core
- build.gradle.kts
- b-data
- build.gradle.kts
- settings.gradle.kts
- settings.gradle.kts
- settings.gradle.kts
It's a bit confusing but module-a and module-b are included as git submodules inside a modules folder of the root project.
The Gradle files are as follow:
settings.gradle.kts
rootProject.name = "project-root"
includeBuild("modules")
modules/settings.gradle.kts
rootProject.name = "modules"
includeBuild("module-a")
includeBuild("module-b")
modules/module-a/settings.gradle.kts
rootProject.name = "module-a"
include("a-core")
include("a-data")
modules/module-b/settings.gradle.kts
rootProject.name = "module-b"
include("b-core")
include("b-data")
Just to illustrate the reason for this, lets say that the module-b:b-core depends on the module-a:a-core library.
The problem is that when I run this build it comes back with the following message:
Multiple build operations failed.
Failed to get Gradle name for :a-core
Failed to get Gradle name for :a-data
Failed to get Gradle name for :b-core
Failed to get Gradle name for :b-data
I don't know if what I'm trying to achieve is possible, but I couldn't find anything in the documentation. It looks like we're always very close to what we desire, but it's almost impossible to get there.
Do you guys know what I'm missing?
Error messsages come from AGP ModelBuilder.getBuildeName()
The reason is that most "bottom" projects in composite build ("a-core", "a-data", "b-core" and "b-data") have gradle.rootProject.parent set to "topmost" project ("project-root"), instead of their immediate parents ("module-a" and "module-b").
You can check it putting
println("${project.name} parent is ${project.gradle.parent?.rootProject?.name}")
in build.gradle.kts of all the projects and running sync
It whether Gradle or AGP problem, depending on is such a root behavior correct or a gradle bug.
I have created the issue about this case in gradle project. Will look what gradle team answer :)
As temporary solution add includeBuild("a-core") and other bottom level projects in modules/settings.gradle.kts. If still will got error, try add it to the topmost "project-root" settings.gradle.kts instead.
Related
I got some source code and was asked to build it. It was a Gradle project. So I changed to the project directory and ran:
$ gradle clean assemble
and the following error came up:
...
* What went wrong:
A problem occurred evaluating root project 'pcase'.
> Could not get unknown property 'postgresql.jdbc' for root project 'pcase' of type org.gradle.api.Project.
...
There is a settings.gradle file in the project folder too. It contains:
rootProject.name = 'pcase'
I took a look at build.gradle and found lots of occurrences like
${project['x']}
For example:
buildscript {
dependencies {
...
// FlywayDB, JOOQ.
classpath "org.postgresql:postgresql:${project['postgresql.jdbc']}"
classpath "org.flywaydb:flyway-gradle-plugin:${project['flywaydb.plugin.version']}"
classpath "nu.studer:gradle-jooq-plugin:${project['jooq.plugin.version']}"
...
What could be ${project['x']}? Looks like associative array in bash and the build script tries to get the value of the key 'x'.
But I didn't find the place in code where this array would be declared and initialized.
The question is: Is the project buildable or is it better to consult the company that worked at it before me?
From the information provided, the project is perfectly buildable, to some certain extend. First of all, project['a.b.c'] is Groovy syntax to access properties from the project object. They're referred to as project properties.
They can be set via
Project properties via command line: gradle -Ppostgresql.jdbc=x.y.z
System properties via command line: gradle -Dorg.gradle.project.postgresql.jdbc=x.y.z
System properties via gradle.properties: org.gradle.project.postgresql.jdbc=x.y.z
All 3 properties (postgresql.jdbc, flywaydb.plugin.version, jooq.plugin.version) denote the version numbers of the particular build script dependencies. However, which versions to use best is beyond my knowledge. I would certainly consult the respective project websites, Maven artifact search or simply ask the company.
org.postgresql:postgresql is the database JDBC driver and certainly depends on the database version.
org.flywaydb:flyway-gradle-plugin is for database migrations. Try with the latest version.
I wasn't able to find gradle-jooq-plugin on Maven central. It's most likely available on the Gradle Plugin Portal.
afterburner.fx for JavaFX 8 is a minimalistic (3 classes) JavaFX MVP framework based on Convention over Configuration and Dependency Injection created by Adam Bien.
afterburner.fx use Maven 3.
I would like to use it with Gradle.
How to use Afterburner.fx with Gradle instaed of Maven 3, while leaving the original project structure of afterburner.fx ?
In the build.gradle File add dependencies
dependencies {
compile group: 'com.airhacks', name:'afterburner.fx', version: afterburnerfxVersion
}
In the build.gradle File add the additional Resources (.fxml , .css , .properties)
sourceSets.main.resources.srcDirs("src/main/java").includes.addAll(["**/*.fxml", "**/*.css", "**/*.properties"])
and (re-)add all the standard Resources (in the resources folder)
sourceSets.main.resources.srcDirs("src/main/resources").includes.addAll(["**/*.*"])
Update for Gradle Version 6.8.1 : if you run gradlew with --warning-mode all there is a deprecated Message:
Copying or archiving duplicate paths with the default duplicates strategy has been deprecated. This is scheduled to be removed in Gradle 7.0.
Solution
add this line:
// from https://docs.gradle.org/6.8.1/userguide/upgrading_version_5.html#implicit_duplicate_strategy_for_copy_or_archive_tasks_has_been_deprecated
// and https://docs.gradle.org/current/userguide/java_plugin.html
// Java Plugin Task processResources(type: Copy)
processResources.duplicatesStrategy = DuplicatesStrategy.INCLUDE // allow duplicates
Thanks, this helped me a lot. I added the short form of it to dependencies:
compile 'com.airhacks:afterburner.fx:1.6.0'
Additionally I added a second line to include the files from the resources folder and not only from /java. I also added **/*.png to include png files because new Image("filename.png") wasn't working anymore.
sourceSets.main.resources.srcDirs("src/main/java").includes.addAll(["**/*.fxml", "**/*.css", "**/*.properties", "**/*.png"])
sourceSets.main.resources.srcDirs("src/main/resources").includes.addAll(["**/*.fxml", "**/*.css", "**/*.properties", "**/*.png"])
I don't know why the above two lines broke the default behavior - seems like I have to add every new file type to the above lines. :/ If anyone has a better solution please tell me.
I have a multi-project Gradle build, which is currently configured through a single build.gradle file.
There are over 70 modules in this project, and the single (gigantic) build.gradle file has become cumbersome to use, so I'd like to split it into small per-module buildscript files.
Now, I don't want to have 70 small build.gradle files (one in each module), as that would make navigating to a specific build.gradle a pain in the IDE (the only difference between the files is their path).
What I want is my per-module buildscript files to be named after the module name.
Instead of this:
root
|--foo\
|--| build.gradle
|--bar\
|--| build.gradle
I want this:
root
|--foo\
|--| foo.gradle
|--bar\
|--| bar.gradle
Since this doesn't seem to be officially supported, I tried hacking around the root build.gradle a bit, but it seems that applying a .gradle file happens before the projects are configured, so this gives an error for projects that depend on other projects:
in root build.gradle:
subprojects { subProject ->
rootProject.apply from: "${subProject.name}/${subProject.name}.gradle"
}
foo.gradle, which is not a standard build.gradle file:
project('foo') {
dependencies {
compile project(':bar')
}
}
Is there any way of making it work like this?
A web search for "gradle rename build.gradle" rendered the below example settings.gradle file:
rootProject.buildFileName = 'epub-organizer.gradle'
rootProject.children.each { project ->
String fileBaseName = project.name.replaceAll("\p{Upper}") { "-${it.toLowerCase()}" }
project.buildFileName = "${fileBaseName}.gradle"
}
Note that the author is here also renaming the root project's build script, which you may or may not want.
One of the authors of Gradle, Hans Dockter, has said somewhere (I believe it was in his "Rocking the Gradle" demo from 2012), that he felt one of their biggest mistakes was using build.gradle as the default file name.
You can customize name of your build scripts in settings.gradle file. Check recent presentation from Ben Muschko about multi-project builds or look at Gradle sources where similar customization is done.
rootProject.children.each {
it.buildFileName = it.name + '.gradle'
}
You can find this content in Gradle in action, manning
In the Gradle samples (included with version 2.2.1) there is a java/multiproject project.
The settings.gradle file defines the following projects:
include "shared", "api", "services:webservice", "services:shared"
Note that services is not itself a project, merely a directory which contains the webservice and shared projects.
When I run the command gradle build from the root directory, I notice that after gradle successfully builds it creates inside the /services directory a /build directory containing /lib and a /tmp directories.
Inside of /services/build/lib is a jar: services-1.0.jar which contains very little; specifically just a META-INF/MANIFEST.MF file containing:
Manifest-Version: 1.0
provider: gradle
So what is causing Gradle to build a jar for this non-project? And how can I prevent this behavior in my similarly structured multiproject project?
/services isn't a project, I don't want to create anything inside /build folder at all. Yes I could just delete it, but I would like to avoid the unnecessary work of building this jar/running any tasks on this non-project in the first place.
To be honest I've no reasonable idea why gradle builds this folder. I guess that because it's a kind of a transient folder. However it can be excluded by adding the following piece of code to main build.gradle script:
project(':services').jar { onlyIf { false } }
Desired effect (services.jar elimination) can be also obtained with the following settings.gradle content:
include "shared", "api", "services/webservice", "services/shared"
File instead of project paths are included.
My guess would be that this is a combination of the next 2 gradle rules:
When you're including subprojects in the build.settings file using the include keyword according to Gradle Documentation here:
the inclusion of the path 'services:hotels:api' will result in
creating 3 projects: 'services', 'services:hotels' and
'services:hotels:api'.
In simple words, this means that the inclusion of services::webservice will also build the services project
The bulid.gradle file in your root that applies the 'java' plugin. According to Gradle Documentation here every configuration defined in the root.gradle takes effect for all sub projects. This means that it will also hold as the default configuration for the services project. As the 'java' plugin was applied a jar will be created, but as there is no src/main folder under the services directory nothing will be compiled and the jar will include only a META-INF/MANIFEST.MF file.
I see a lot of examples of Gradle-built Java/Groovy projects that have the following structure:
some-app/
src/
main/
test/
docs/
README.md
build.gradle
gradlew
gradlew.bat
settings.gradle
gradle.properties
gradle/
*.gradle
I understand that build.gradle is the main buildscript and that gradle.properties is its properties file. But settings.gradle really throws me. Inside it I see:
rootProject.name = "someApp"
But this seems like it belongs in gradle.properties. I'm also wondering where the gradlew and gradlew.bat files come from, they seem to be generated.
Finally, I'm wondering why there are so many *.gradle files under the gradle/ dir: are these plugins, or extension scripts of some sort. They are all pulled in from the main build.gradle like so:
apply "gradle/fizz.gradle"
apply "gradle/buzz.gradle"
etc.
So:
What properties are supposed to go in settings.gradle that are not supposed to go in gradle.properties?
How are the gradlew/gradlew.bat files generated?
Why would someone have so many disparate *.gradle files? Why not just 1 big build.gradle buildscript?
1) gradle.properties is normal properties file, while settings.gradle is also a build script. You can add there some code that will be executed during build. Typically this file is needed when You have a multi-module project.
2) When You type gradle tasks in project build directory (empty build.gradle is enough to see it) You'll see wrapper task. This task is used to generate scripts You're asking about. More info.
3) The reason is that all these files have different responsibilities that are cleanly separated.