we have a project structure like so:
root
core
auth
...
In the root's build.gradle file:
allprojects {
apply plugin: 'idea'
}
and its settings.gradle:
include 'core'
The core has a gradle.build file and a settings.gradle with:
include 'auth'
So, when I run from the root:
gradle idea
It'll build the ipr, iws and iml files on the root, and the core folder will have a core.iml. But the auth module does not get created. I have to go into intellij and manually add the module to core. Kind of annoying. Does gradle support deeply nested projects like this, or is this a limitation of the IDEA plugin? Or, quite possibly, I'm doing something wrong :)
Figured it out. I'll phrase this for best google results: A deeply nested gradle project only can have one settings.gradle file at the root, and it looks like this:
include 'core'
include 'core:auth'
Once this is done, gradle will read in all subprojects and configure IDEA accordingly.
Related
I have a 3 microservices and now i need to create a docker-compose for all of it. So when i trying to fellow all my microservices in one project i get this issue
Project directory 'C:\Users\Dany\IdeaProjects\target-root\target-discovery\app' is not part of the build defined by settings file 'C:\Users\Dany\IdeaProjects\target-root\settings.gradle.kts'. If this is an unrelated build, it must have its own settings file.
What i have to read for fix it?
setting.gradle.kts
project structure
The include in settings.gradle.kts should look like:
include(
":target-discovery"
)
in case there are more sub-folders (e.g. target-discovery/app, target-discovery/app2):
include(
":target-discovery:app",
":target-discovery:app2"
)
When defining a module it should always start with : and sub-folders should be delimited by :
Also make sure your root build.gradle.kts define all relevant plugins or define them in each sub-module. You can also create conventions (https://docs.gradle.org/current/samples/sample_convention_plugins.html)
If you just define plugins in the root it wont affect your sub-projects, one way to achive it (altough i prefer convention plugins) is:
build.gradle.kts
plugins {
kotlin("jvm") version ...
}
subprojects {
apply(plugin = "kotlin")
}
As Tom said, what you need to include isn't target-discovery but target-discovery/app
However, projects included in settings.gradle (or settings.gradle.kts) don't start with the colon symbol, so you should have:
settings.gradle.kts
rootProject.name = "target-root"
include("target-discovery:app")
So it actually seems to mostly work, with both projects as sub-modules of the overall project. But the major annoyance is that when I debug in one of the modules, if code calls something in the other module it picks up the dependency from the Gradle cache instead of the other project/module's code and steps into a decompiled .class file from its cache instead of the actual source code.
I'd like to find a way so Intellij recognizes one module is using the other and uses the source code from the module itself which is of course checked out and available in the local filesystem.
See gradle documentation here about setting up multiple projects as "sub-modules", though gradle lingo usually refers to them as sub-projects.
Basically, if you have some projects that are sub projects of a root project, you would setup the folder structure like this:
root
├───build.gradle
├───settings.gradle
│
├───subA
│ └───build.gradle
├───subB
│ └───build.gradle
└───subC
└───build.gradle
In your root settings.gradle, you include your sub projects by adding:
include 'subA', 'subB', 'subC'
From this point on, you can refer to any project in your setup from any other project by its name: project(':subB')
so If you want to add subC as a compile time dependency of subA, in subA's build.gradle, you would have:
dependencies{
compile project(':subC')
}
Declared this way, the dependency is on the current files of subC instead of the last built/installed binaries from the repository. You could also have root project just a holder project with no code of its own.
I've had some success using dependency substitution in a development mode kinda like this:
if (project.has("devMode")) {
configurations.all {
resolutionStrategy.dependencySubstitution {
substitute module("foo.group:bar") with project(":bar")
}
}
}
Hopefully something like that may work for you, too.
EDIT: note that you'll also have to conditionally add the :bar project in settings.gradle as well
I understand the basic functionality of gradle, but I don't understand how to use a build.gradle file other than the one in the project's root. I have a project which contains a gradle wrapper in it's root, and a module which has it's own build.gradle file. How do I specify for gradlew to use the module's build.gradle file instead of the one in the root directory?
Specifically, I have an IntelliJ project I have uploaded to my CI server, and I am trying to setup a script to run the builds automatically.
Cheers
It looks like you have a multi-module build which only has a single module... correct?
You could include a settings.gradle which points to the module
You could declare a GradleBuild task in the root module to invoke the sub module.
A good place to look for inspiration is the java samples and the organizing build logic page in the documentation. An impressive feature of gradle is that all of the code snippets which appear in the documentation is sourced from the samples directory which is run as part of their CI build.
Happy Gradling!
Usually in a normal IDEA project I can hide the ".idea" folder from the project tree view by excluding it in the project structure settings. How can I achieve the same in a Gradle project? There I can still exclude that folder manually as mentioned, but then it re-appears in the project tree view after I restart IDEA.
I don't think You can obtain solve this issue using gradle configuration.
But there are some possible solution that you can try. Try using plugin idea. Just put:
apply plugin: 'idea'
With this plugin you can use cleanIdea task to clean all .idea and .iml files.
With this plugin you can also configure how exactly idea should interpret your folder structure.
There is also simple way to hide this files once and for all. Just go to :
File -> Settings -> Editor -> File Types -> Ignore Files And folders
and there append for example something like this:
.idea;.gradle;build;
with this you would not have any problem with unnecessary files in your project structure.
I am developing a plugin for IntelliJ IDEA. The way I am going about this is by creating a plugin project in IDEA, then packaging this into a jar with appropriate META-INF/plugin.xml, and installing the plugin from the jar.
The problem is that I would like to add a dependency on org.scala-lang:scala-library:2.11.0. I have this specified as a library dependency in the IDEA project, but this information never seems to get passed along to the generated JAR.
How can I include this information in such a way that IntelliJ IDEA will recognize it?
As far as I understand, you want to bundle some library (e.g. scala library) with your plugin.
This is pretty simple.
Go to Project Settings, select module and go to Dependencies tab. Set scope for the library you want to bundle to 'Compile'. In this example it is 'checker-framework' library. 'groovy-2.3.6' library will not be bundled due to its scope set to 'Provided'. Save changes.
Prepare plugin for deployment
Then you got plugin, zipped, ready for deployment (uploading to repo or installing locally) in the root of project. It will contain lib folder with all necessary jars.
The officially supported plugin dependency management solution is to use Gradle with the gradle-intellij-plugin, via Gradle's dependencies or the intellij.plugins entry points. If you want to add a dependency on an artifact (ex. hosted on Maven Central), then configure dependencies just as you normally would in a Gradle based project:
buildscript {
repositories {
mavenCentral()
}
}
dependencies {
compile("org.scala-lang:scala-library:2.11.0")
}
The intellij.plugins entry point will add an artifact in the current project, as well as a <depends> tag to your plugin.xml file. To install an external plugin alongside your own, for example if you are using the Plugin Extensions feature (suppose the plugin is hosted on the JetBrains Plugin Repository), use the following snippet:
plugins {
id "org.jetbrains.intellij" version "0.2.13"
}
intellij {
//...
plugins "org.intellij.scala:2017.2.638"
}