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")
Related
I have a Gradle project with two subprojects. The parent does not contain any code; all the Kotlin code is in the two subprojects. All Gradle build files are defined in the Kotlin DSL.
Upon building, Gradle generates two JAR files, one in the build subfolder of each subproject. I believe this is the intended default behavior of Gradle. But this is not what I want.
I want to publish the JAR file of the parent project as a Maven artifact. Therefore, I need both subprojects to be included in one JAR file. How can I achieve this?
Note: On this web page, the author seems to achieve pretty much what I would need in this code snippet:
apply plugin: "java"
subprojects.each { subproject -> evaluationDependsOn(subproject.path)}
task allJar(type: Jar, dependsOn: subprojects.jar) {
baseName = 'multiproject-test'
subprojects.each { subproject ->
from subproject.configurations.archives.allArtifacts.files.collect {
zipTree(it)
}
}
}
artifacts {
archives allJar
}
However, this is defined in Gradle's native Groovy DSL. And I find myself unable to translate it into the Kotlin DSL. I tried to put a Groovy build file (*.gradle) besides the Kotlin build file (*.gradle.kts), but this led to a strange build error. I'm not sure if mixed build file languages are supported. Besides, I would consider it bad practice too. Better only define all build files in just one language.
Also, the example above pertains to the Java programming language. But I do not expect this to be a big problem, as both Java and Kotlin produce JVM bytecode as compile output.
More clarification:
I am not talking about a "fat JAR". Dependencies and the Kotlin library are not supposed to be included in the JAR.
I do not care if the JAR files for the subprojects are still getting built or not. I'm only interested in the integrated JAR that contains both subprojects.
The main point is getting the combined JAR for the binaries. Combined JARs for the sources and JavaDoc would be a nice-to-have, but are not strictly required.
I would use the Gradle guide Creating "uber" or "fat" JARs from the Gradle documentation as a basis. What you want is essentially the same thing. It's also much better than the Groovy example you found, as it doesn't use the discouraged subprojects util, or 'simple sharing' that requires knowing how the other projects are configured.
Create a configuration for resolving other projects.
// build.gradle.kts
val mergedJar by configurations.creating<Configuration> {
// we're going to resolve this config here, in this project
isCanBeResolved = true
// this configuration will not be consumed by other projects
isCanBeConsumed = false
// don't make this visible to other projects
isVisible = false
}
Use the new configuration to add dependencies on the projects we want to add into our combined Jar
dependencies {
mergedJar(project(":my-subproject-alpha"))
mergedJar(project(":my-subproject-beta"))
}
Now copy the guide from the docs, except instead of using configurations.runtimeClasspath we can use the mergedJar configuration, which will only create the subprojects we specified.
However we need to make some modifications.
I've adjusted the example to edit the existing Jar task rather than creating a new 'fatJar' task.
for some reason, setting isTransitive = false causes Gradle to fail resolution. Instead I've added a filter (it.path.contains(rootDir.path)) to make sure the Jars we're consuming are inside the project.
tasks.jar {
dependsOn(mergedJar)
from({
mergedJar
.filter {
it.name.endsWith("jar") && it.path.contains(rootDir.path)
}
.map {
logger.lifecycle("depending on $it")
zipTree(it)
}
})
}
I have a Kotlin project which is comprised of three modules:
Core < Service < Web
The structure is:
build.gradle
core/
build.gradle
service/
build.gradle
web/
build.gradle
The structure for the root build.gradle file is:
buildscript {
ext.kotlin_version = '1.1.60'
repositories {
mavenCentral()
jcenter()
}
dependencies {
classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
}
}
subprojects {
apply plugin: 'kotlin'
apply plugin: 'jacoco'
compileKotlin {
kotlinOptions.jvmTarget = '1.8'
}
repositories {
mavenCentral()
jcenter()
}
}
The individual build files look like (for core):
dependencies {
// Kotlin
compile "org.jetbrains.kotlin:kotlin-stdlib-jre8:$kotlin_version"
...
}
And for service (note the only difference is the project dependency):
dependencies {
compile project (':core')
// Kotlin
compile "org.jetbrains.kotlin:kotlin-stdlib-jre8:$kotlin_version"
...
}
There are a few optimizations I'd like to make, but I'm still learning Gradle, and can't find the right way to reorganize things. The problems I have are:
I can't build service or web individually, as they complain about not being able to find their dependent sub-projects. (Via a gradle build in the service/ directory, for example.)
How can I define the Kotlin stdlib-jre8 dependency at the root level, so it's not duplicated in my three build files?
How can my subproject/buildscript tasks of the root buildfile use the same repository definitions, so that I don't have to define mavenCentral()/jcenter() twice?
Basically this build structure that I have was cobbled together through some experimentation/web resources, and happens to mostly work, but I'd like some guidance on doing it the right way, such that (1) it follows good Gradle practices, and (2) still works well via auto-import into IDEA.
If you want to run a build on a module you can do by running: gradle :web:build
In the same way that you are adding repositories in the subprojects clause, you can add the dependencies block in there. Make sure that only the shared dependencies are in there. For instance, compile project(':core') should only be in the relevant project. It's ok to have multiple dependency blocks. That said, it's usually more of a headache to use the subproject clause. Because, if dependencies change for one of the modules you are forced to update that for all of them
Regarding the repository definitions, they are very different. The one in the buildscript block is used by Gradle itself in order to find plugins and other 'pre-build' requirements. The one on the submodules is used to find the dependencies of the source code in the given module. As mentioned on the previous point, it's easier to manage when placed on the respective module build scripts.
Update:
If you want to keep the same version for all modules, the variables defined on ext in the buildscript should be able to be accessed from the submodules too: ext.kotlin_version = '1.1.60' and if you have multiple ones you can add them like:
ext {
kotlin_version = '1.1.60'
junit_version = '4.12'
}
Also, if you want to share code between modules, you can always extract it to gradle file and load it where needed using: apply file: "$rootDir/path/to/script.gradle"
Regarding #3, I'll give you a practical example.
Google has its own maven repository that contains all the dependencies for an android module. If you have a project that contains both a server-side module and android module you may not need the server-side one to look up dependencies on the Gradle artefact repository (artefact is the name of the jar dependency).
As for the buildscript repositories, in your case you are only loading one classpath (pre-build) dependency which is located on mavenCentral() so you may be ok removing jcenter() here.
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'm not sure if this is more Gradle or Intellij Idea question. In projet I'm importing to Idea using gradle import(import from Gradle external model in Idea) my build.gradle contains, besides other things, following:
apply plugin: 'idea'
idea {
project {
// When ext.(extra property) is not used, gradle complains about
// deprecated dynamic property, but only here, not when setting
// module name.
ext.name = 'SimpleStoreClient'
}
module {
name = 'SimpleStoreClient'
}
}
When project import is finished, I open module settings in Idea, module name is set to one from gradle build script, but project name is just rootdir name. I tried few alternatives of setting project name, but no has propagate the name into Idea.
I thing I just miss some property of Idea plugin, but I cant find what is it.
Thanks in advance for any advice!
What you can do is setting the root projects name in settings.gradle
rootProject.name = "Your alternative project name"
This will set the project name in project settings of idea and in the gradle tasks view to "Your alternative project name".
The project name that is displayed in the projects in Project View can't be influenced as far as I know.
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.