Hi in my buildSrc dir I have two separate projects, lets name them one and two.
I add build.gradle and settings.gradle file in buildSrc dir and in them I wrote:
settings.gradle
include \
"one",
"two"
But when I tried to use some of the plugins, which are provided from this projects, Gradle says that this imports can not be found. I searched for simmilar problems and found that I have to write in build.gradle file in buildSrc:
dependencies {
runtime subprojects.collect { owner.project(it.path) }
}
What does this line mean? And why I have to add it? BuildSrc adds copiled classes automatically on the classpath,or I am wrong?
Gradle puts the "buildSrc project" and it's runtime dependencies on the buildscript classpath automatically but does not automatically put subprojects of buildSrc on your buildscript classpath.
If you have a multiproject build like described above, buildSrc is the root project but your custom logic is in the subprojects. Now when gradle puts buildSrc.jar on the buildscript classpath it is more or less empty.
The snippet
dependencies {
runtime subprojects.collect { owner.project(it.path) }
}
adds all your subproject as runtime dependencies to your root buildSrc project. This should fix your problem as Gradle puts the buildSrc AND it's runtime dependencies on the buildscript classpath.
Related
Gradle 2.4 and Eclipse Mars here. Here's my project directory structure:
myapp/ <-- root project
myapp-client/
src/main/groovy/*
build.gradle <-- just declares some client-specific deps
myapp-shared/
src/main/groovy/*
build.gradle <-- shared-specific deps
myapp-server/
src/main/groovy/*
build.gradle <-- server-specific deps and how to package server JAR
build.gradle
settings.gradle
Where myapp/build.gradle is:
allprojects {
apply plugin: 'groovy'
apply plugin: 'eclipse'
apply plugin: 'maven'
apply plugin: 'codenarc'
sourceCompatibility = '1.8'
targetCompatibility = '1.8'
[compileJava, compileTestJava]*.options*.encoding = 'UTF-8'
repositories {
// ...etc.
}
dependencies {
// ...etc.
}
task wrapper(type: Wrapper) {
gradleVersion = '2.4'
}
}
And where myapp/settings.gradle is:
include ':myapp-shared'
include ':myapp-client'
include ':myapp-server'
When I do a ./gradlew eclipse I get messages indicating that the command was successful. I then open Eclipse to import myapp as a series of individual subprojects.
Expectation based on what I'm used to seeing, historically
In previous projects that contained subprojects, I would go to Import >> Existing Projects into Workspace, where I would see this dialog:
I would then click Browse and select the project root (in this particular case, myapp). Eclipse would then auto-detect the 3 subprojects and populate them as a checked list inside the Projects component in the UI above. I would then click "Finish" and Eclipse would load the 3 subprojects into my workspace, each showing as a separate project (as it should).
What's actually happening
Instead, when I click on myapp as the root project, Eclipse just populates it as a single project, almost as if it doesn't detect that I have subprojects at all:
When I click Finish it imports a single project into my workspace, that has source folders for each of the 3 subprojects. And while that's just an annoyance, the real problem is that the classpath seems to be totally jacked up. For instance, I can add a class to myapp-shared, and then include it in a class defined inside myapp-client, and Eclipse doesn't force me to add an import statement into the client class! It's like the whole project is sharing the same package/namespace.
Can any Gradle gurus spot a defect in my Gradle setup that could be the cause of this?
This was nasty, but I figured it out. Posting the solution here in case anybody else runs into this.
Instead of a single allprojects closure, you need allprojects and subprojects closures. Not sure what is "safe" to put in either closure, but I got this working by simply declaring my repositories inside of allprojects and then putting everything else inside subprojects.
The problem was that I had previously ran gradle eclipse on the root project (before I added in the subprojects closure), and so Gradle generated the typical artifacts (e.g. .projects, .classpath, .settings/*) in the parent/root project directory. So...
Delete Gradle-Eclipse artifacts out of the root directory. Delete the project from your Eclipse workspace (but not the disk!!!). I'd even go so far as to restart Eclipse to clear out any caches if they exist.
Run gradle clean for good measure. Probably not needed.
Run gradle eclipse again.
Re-import into Eclipse, and all will be well in your kingdom once again, my friend.
I have created the Gradle web app which is running inside the NetBeans. Now I want to add some external jar files in it so how can I add the jar from NetBeans.
Modify your Gradle project to add your dependency and refresh it in NetBeans to pick up the changes. There is plenty of documentation how to do it. For example How to add local .jar file dependency to build.gradle file?
If you really need to take that .jar from a local directory,
Add next to your module gradle (Not the app gradle file):
repositories {
flatDir {
dirs 'libs'
}
}
dependencies {
compile name: 'gson-2.2.4'
}
ref:check here
I have a jar, build-plugins.jar with a gradle plugin that is build with this in build.gradle:
apply plugin 'java'
dependencies {
compile gradleApi()
compile localGroovy()
compile('eviware:maven-soapui-plugin:4.5.1')
compile('org.antlr:stringtemplate:4.0.2')
compile('commons-io:commons-io:2.4')
compile('joda-time:joda-time:2.1')
}
This builds build-plugins.jar. And the project that consumes the plugin references the plugin jar by file
apply plugin 'thepluginwahoo'
buildscript {
dependencies {
classpath 'org.jfrog.buildinfo:build-info-extractor-gradle:2.2.1'
classpath files('/path/to/build-plugins.jar')
}
}
The problem is when I run any task of the second project, I get "class proxy could not be created for class xyz" with the root cause being that the four dependencies (joda-time, commons-io, stringtemplate, maven-soapui-plugin) are not there. If I add the dependencies to the plugin-consuming project then it works just fine:
apply plugin 'thepluginwahoo'
buildscript {
dependencies {
classpath 'org.jfrog.buildinfo:build-info-extractor-gradle:2.2.1'
classpath files('/path/to/build-plugins.jar')
classpath 'eviware:maven-soapui-plugin:4.5.1'
classpath 'org.antlr:stringtemplate:4.0.2'
classpath 'joda-time:joda-time:2.1'
classpath 'commons-io:commons-io:2.4'
}
}
My question is why don't the classes of the "compile" dependencies in the plugin project appear in the plugin-consuming project when the jar is included in the classpath of the buildscript of the plugin-consuming project.
Jars typically do not contain their dependencies. Instead, they are published to a repository along with some kind of metadata descriptor (pom.xml or ivy.xml) which describes the artifact's dependencies. When you refer to the jar file directly as a dependency, Gradle has no way of knowing what its transitive dependencies are. You have a couple of ways to deal with this:
Publish your plugin jar to a repository, along with the necessary metadata (which Gradle will do for you) and bring it in as an external module dependency
Explicitly declare the plugin's transitive dependencies using a client module dependency.
Use something like the Gradle fatjar or shadow plugins to bundle dependencies within your jar.
I'm writing a custom Gradle plugin for my company to assist with integration tests of our product. My team wants to have the plugin be built with and used in the main product build (like a 'buildSrc' plugin would), but also need the plugin to be published as an artifact for other teams to use in integration with our product.
If I try and include it as a standalone plugin in the settings.gradle file and then also include it in the buildscript as a dependency, it obviously does not work because the buildscript block is interpreted first.
I also tried running another build from within the buildscript like so:
buildscript {
def connection = GradleConnector.newConnector()
.forProjectDirectory(file("${project.projectDir}/theplugin"))
.connect()
try {
connection.newBuild()
.forTasks('clean', 'build', 'install')
.run()
} finally {
connection.close()
}
repositories {
mavenLocal()
...
}
dependencies {
classpath 'com.company.product.gradle.theplugin'
}
}
This causes the plugin to be built and placed in the local Maven repo, but then the initial Gradle build fails directly afterward because it can't resolve the newly built archive. If I run it again, it works. I don't understand this behavior.
I'm probably going down a rabbit hole with this approach. Is there a way to make this work and in a less 'hacky' way?
I discovered a hacky way to accomplish this: symlink the plugins to the buildSrc (on *nix at least).
project directory
project/
buildSrc/ -> gradle_plugins/
gradle_plugins/
pluginA/
pluginB/
...
build.gradle
settings.gradle
...
build.gradle
settings.gradle
project/settings.gradle
include 'gradle_plugins:pluginA'
include 'gradle_plugins:pluginB'
...
project/gradle_plugins/settings.gradle
include 'pluginA'
include 'pluginB'
...
project/gradle_plugins/build.gradle
...
rootProject.dependencies {
runtime project(path)
}
...
The way I'm solving this is the following:
Regular multi project build with buildSrc/myPlugin/.. Within my build process I call ./gradlew -b buildSrc/myPlugin/build.gradle uploadArchives (or whichever task you use to publish your maven artifact).
Due to the "official" hack of having to add the gradle plugin to the runtime dependencies of the root project this step would fail. So I surround it with a try catch. I feel that is not perfect but it seems to work.
I'm using Gradle with Eclipse and am trying to reference Project1 from Project2 (both under the same root directory), like so:
settings.gradle:
include ':Project1'
project(':Project1').projectDir = new File(settingsDir, '../Project1')
build.gradle
dependencies {
compile project(':Project1')
...}
Project1 is also referenced through the build path. But eclipse/gradle does not recompile and instead uses include the old jar classes. I've also tried to set the plugin to apply plugin: 'eclipse-wtp'.
Just out of curiosity, do you have a block like this somewhere in your build.gradle
eclipse.project {
referencedProjects 'Project1'
}
I ask because, if you don't tell Eclipse that this project references Project1, it won't be included in the build path.