I have a custom task in buildSrc that, among other things, I want to copy a file from buildSrc into the main build. However, when actually running the custom task, the buildSrc project appears to be pretty much invisible, e.g. I can't reference it as a project. How does one refer to and copy a file from the buildSrc project to the main project?
You are correct that the main projects can not see buildSrc. buildSrc is run as a separate project.
The outputs of buildSrc project are put onto the classpath of the main Gradle projects.
One solution then is to generate a Jar artifact with all of your resources, and then use the classpath resource loader in the main projects to access the files you need.
A second option might be to just manually hard code the buildSrc path into your main projects. Of course you can not access it as project(:buildSrc') because it is not valid. The better option is to use file("${rootProject}/buildSrc/") (Not tested).
Related
Sorry for the naive question. I am new to Gradle.
Conceptually, it looks like we should commit the buildSrc folder to repo but I see some temp files as well in that folder, which led me to ask this question - Should we commit the entire buildSrc folder to the repo?
buildSrc can be used to abstract imperative logic. In other words, declutter your main Gradle build files.
https://docs.gradle.org/current/userguide/organizing_gradle_projects.html#sec:build_sources
The buildSrc folder is basically another Gradle project. So things you would normally ignored for a Gradle project, should also be ignored from the buildSrc project.
If you have logic defined in buildSrc that is required for your project, then yes it should be committed. If not, then that folder should be deleted entirely to avoid Gradle attempting to automatically build it.
Suppose I have a gradle project named Xenon, and several modules there like Xenon-Task, Xenon-API, something like that.
Which style should be preferred. One means only one global project level gradle file VS every single module has their own gradle file respectively, project level only has module info, but no details which works inside module.
The answer is: it depends. There is no "preferred" style, you're the one who choose.
General advice is to put all common logic in the higher level build files, in allprojects / subprojects blocks. Good candidates are repositories as they are the same for all the submodules or publishing configs.
However, there are plugins, like The Application Plugin that will have different configs in different modules (main classes). A set of particular submodule's dependencies will be different for each submodule as well. So put that in module's build.gradle.
I need to figure out a quick/scripted way of excluding a set of folders across multiple IntelliJ gradle modules in an IntelliJ project imported from Gradle.
I have a Gradle multi-module project that I have imported into IntelliJ. The project is a refactoring of a legacy codebase into modules. Part of the resulted refactoring is that there are multiple copies of the same class across multiples modules (this was done to break dependency cycles in code): there is the original class and a number of "mock" copies
I'm trying to exclude a bunch of folders containing copies of classes in these "mock" sourcesets in a scripted manner.
I've imported the Gradle project into InteliJ. To begin excluding the folders I started by excluding one of the folders in one of the modules... ...
I then tried to determine where in my .idea folder this particular setting is persisted... I have been unable to find it...
My question is: can someone point me to the IntelliJ file (e.g. .idea/workspace.xml) that stores this setting? Alternatively can someone point me to the folder that stores this setting?
Update
I manually went and excluded all the folders that contain mock copies of my classes. Those settings appear to be persisted (still not sure where those settings are being stored).
The second problem I need to solve is that I need to declare custom dependencies between Gradle imported modules that are different from those configured in the Gradle project. I can add dependencies within the project, but whenever I refresh my Gradle project or import any changes, my changes are lost.
I am using gradle and its local repository is at \.gradle\caches\modules-2\files-2.1 which has all the downloaded jar but not my modules.Is there any specific place I should be searching it for ?
I need it as is in settings.gradle I am having a dependency path specified like :
include ':model'
project (':model').projectDir = new File(settingsDir, './model')
in a new project. Also I don't want to give path in that way because if I have a dependency from multiple projects on this project then mentioning path will be difficult and weird.
How can I make gradle search it from local maven or gradle repositories.
I'm still not sure what is being asked here, and I suspect there is some confusion over how multi-project builds work. So I'm going to attempt to provide a general-purpose answer.
The first question you need to answer is whether you're interested in dependencies between projects that are part of the same build — as in part of a multi-project build — or in separate builds.
Project dependencies (multi-project builds)
Project dependencies are covered in the user manual and only apply to multi-project builds. They use a logical path, using colons as 'path' separators, to specify the location of the target module, like so:
dependencies {
implementation project(":model")
}
At this point, Gradle needs to know where ":model" exists on the file system. There's no getting around that. You have a few options:
Follow the convention of directory structure matching the logical path structure, i.e. have a MyBigProject/model directory containing the ":model" child project
Specify the file path of ":model" in settings.gradle, e.g. with project(":model").projectDir = new File(rootDir, "unusual/path/to/model")
Automate the discovery of projects
The most common approach is the first one. The second is not unusual, particularly if you want to put child projects into a separate directory, like subprojects — something the build of Gradle itself does. I haven't seen the last option done, and I don't know whether it runs into problems.
For the sake of completeness, and at your own risk if you use something like it, here's an example of automatic discovery of projects in the settings.gradle file:
rootDir.eachDir { File dir ->
if ("build.gradle" in dir.listFiles()*.name) {
include dir.name
}
}
This fragment basically looks for directories within the root project folder that have a build.gradle file in them and adds them as child projects. The child projects' directory names become the projects' names.
It's not particularly clever, and you should really use different names for the build files, but it may give you some ideas to work with.
Non-project dependencies
As with project dependencies, Gradle needs to know where to get the corresponding JAR or other form of artifact for a specified module. You normally specify Maven Central or something similar for this, but there are other useful, but less common, options:
Copy a project's artifacts into the local Maven repository — both the Maven Plugin and Maven Publish Plugin support this
Publish to a Maven-compatible repository using a file:// URL rather than an HTTP/HTTPS one, which protects your projects from corruption of Maven Local
Worth noting is that Gradle supports composite builds that allow you to substitute a normal dependency with (effectively) a project dependency from another build. So if model were part of a separate build but you had the source code and build locally, you could make changes and immediately test them in another build's project without going through the whole "install" intermediate step that's common in the Maven world (and Gradle pre-composite-builds).
Hope all this makes sense.
I have a custom Gradle Task in my project under /buildSrc/src/main/groovy. Since this folder is in parallel to the main project's /src/main/groovy folder, my IDE considers /buildSrc as a sub-project.
From the documentation, I understand the custom tasks can reside either under /buildSrc or under a separate project.
I don't want to create a new project, so I am thinking of keeping it somewhere other than /buildSrc. Is it possible to achieve this?
No, it isn't possible. The IDE likely considers buildSrc a subproject in order to offer IDE support for developing custom tasks and plugins (not because the directory is "parallel" to anything).