I have a webapp compilation subproject which is written in a separate script plugin and is being added to the root project via "apply from: scriptSrc" syntax. Top of my script plugin looks like this:
buildscript {
repositories {
jcenter()
}
dependencies{
classpath 'com.moowork.gradle:gradle-grunt-plugin:0.10'
}
}
apply plugin: "com.moowork.grunt"
However its not recognizing the plugin and fails on the initialization phase saying
Plugin with id 'com.moowork.grunt' not found.
I am following this: https://plugins.gradle.org/plugin/com.moowork.grunt/0.10.
Anyone else having issues with grunt plugin inclusion in script plugin?
Not sure exactly what exactly is causing the issue. Make sure you have the buildscript setup the following way.
apply plugin: 'com.moowork.grunt'
buildscript{
dependencies{
classpath 'com.moowork.gradle:gradle-grunt-plugin:0.13'
classpath 'com.moowork.gradle:gradle-node-plugin:0.12'
}
// In this section you declare where to find the dependencies of your project
repositories {
jcenter()
mavenCentral()
}
}
If you go plan to use plugin:0.13, you need to include the node-plugin as well or else you may get a NoClassDefFound Exception. This may not be necessary if you continue to use version 0.10.
Also, if you are working on a gradle project in eclipse and building the project from commandline, make sure you refresh the project so build reflects in your workspace.
Related
I have a project with two subprobjects: gradle-plugin and plugin-consumer. I want to apply the plugin from gradle-plugin to plugin-consumer. I tried to do this:
// plugin-consumer/build.gradle
buildscript {
dependencies {
classpath project(':gradle-plugin')
}
}
apply plugin: 'my.plugin.id'
But I was greeted with the following error:
A problem occurred configuring project ':plugin-consumer'.
> Cannot use project dependencies in a script classpath definition.
I assume this is not supported because it'd require fully building gradle-plugin before plugin-consumer can be configured.
Fortunately I can use a fileTree dependency to accomplish my goal:
// plugin-consumer/build.gradle
buildscript {
dependencies {
classpath fileTree(includes: ['*.jar'], dir: '../gradle-plugin/build/libs')
}
}
apply plugin: 'my.plugin.id'
This works, but it feels like a massive hack and leads to "bootstrapping problems".
For example, I can't clean gradle-plugin because the (deleted) jar file is necessary for configuring plugin-consumer, which must be done to (re)build gradle-plugin.
Fortunately this can be avoided by always running build immediately after clean (in the same 'run' so to speak). This can be done manually (gradle clean build) or automatically (with clean.finalizedBy(build)). Again, this works, but feels like a hack.
At last, my actual question: is there a better way to do this?
Please note that gradle-plugin is an independent plugin that's not only used by plugin-consumer, therefore buildSrc is unfortunately not an appropriate solution here.
You can publish the plugin to your local Maven repository with the Maven Publish plugin. Then simply consume it like any other artifact.
Assuming you have something similar in your plugin project:
plugins {
`maven-publish`
`java-gradle-plugin`
}
Simply publish it locally:
./gradlew :my-plugin-project:publishToMavenLocal
Then in your consuming project, something like:
buildscript {
repositories {
mavenLocal()
}
dependencies {
"classpath"("com.example:my-plugin-gav:1.0.0-SNAPSHOT")
}
}
// apply plugin
We have a Gradle build that includes a buildSrc with some custom plugins. Those plugins apply yet other plugins. For example, our plugin applies com.android.tools.build:gradle. For annotation processing that library needs to be on Gradle's classpath during compilation. So, putting this in our main build.gradle works:
buildscript {
repositories {
google()
}
dependencies {
classpath "com.android.tools.build:gradle:$gToolsVersion"
}
}
However, that means that for a user to apply this plugin they must (1) apply our plugin and (2) add that buildscript boilerplate. It seems like that shouldn't be necessary. We can also add a project.buildscript block inside our plugin but that too seems unnecessary and, due to this bug is problematic: https://developer.android.com/studio/build/gradle-plugin-3-0-0.html?utm_source=android-studio#known_issues.
I added the com.android.tools.build:gradle dependency to buildSrc/build.gradle as a runtime dependency. It seems like that should work: I thought that tells Gradle that in order to run my plugin that library (and its dependencies) need to be on the classpath. However, gradle buildEnvironment (and the fact that our build fails) makes it clear that's not the case.
So, questions:
What's the difference between a runtime dependency specified in buildSrc/build.gradle and a classpath dependency specified in a buildscript block in a regular build.gradle?
How can I arrange things so that users can apply the plugin from buildSrc and not have to also add the buildscript block to their build.gradle?
I got a slightly different problem and found an acceptable solution that might help with for your second question: I wanted to apply the same repositories in the buildSrc/build.gradle and twice in the root build.gradle.
repositories.gradle in the project root:
repositories {
if (project.hasProperty('nexus')) {
maven {
url 'http://localhost:8081/repository/JCenter/'
}
maven {
url 'http://localhost:8081/repository/Maven_Google/'
}
} else {
jcenter()
google()
}
}
ext {
androidGradleBuildToolsDependency = 'com.android.tools.build:gradle:3.1.3'
}
buildSrc/build.gradle:
buildscript {
apply from: '../repositories.gradle'
}
allprojects {
apply from: '../repositories.gradle'
}
dependencies {
// androidGradleBuildToolsDependency is defined in repositories.gradle
implementation androidGradleBuildToolsDependency
}
Root build.gradle:
buildscript {
apply from: 'repositories.gradle'
}
allprojects {
// this line will also be executed from the build.gradles in subprojects, so the working
// directory isn't always the same, so we use the absolute path here
apply from: "${rootProject.projectDir}/repositories.gradle"
}
Note that you do not need the classpath dependency inside the buildscript block of the root build.gradle as you normally would. The implementation dependency in the repositories.gradle seems to auto apply it.
My solution probably doesn't work when the build.gradles are supplied via a dependency.
Stumbled upon this while digging into a tangential problem.
I've been successfully using buildSrc/build.gradle as the place to define dependencies that would normally belong in the root-project's buildscript classpath for a few of my projects.
You can see a working example here: https://github.com/episode6/chop/blob/develop/buildSrc/build.gradle
I used to use compile dependencie but just switched to runtimeClasspath which feels more appropriate and also works. I don't think your classpath dependencies were working because they would be on the classpath of the buildSrc project, but not compiled into or run along side it.
If you decide to go this route, you may run into the problem I was just digging into which only came up because of this approach.
When I tried this approach with the dokka plugin, I got the following error
Could not resolve all files for configuration ':detachedConfiguration1'.
> Cannot resolve external dependency org.jetbrains.dokka:dokka-fatjar:0.9.17 because no repositories are defined
I was able to workaround this by adding jcenter() to the root project's buildscript repositories: https://github.com/episode6/chop/blob/develop/build.gradle#L2
I am trying create an Gradle multi project similar to this structure
ouat-services
- ouat-contract
- ouat-servicesImpl (web project)
I followed the eclipse example and define my ouat-services settings.gradle as
include "ouat-contract", "ouat-servicesImpl"
In my ouat-servicesImpl build-gradle I define
dependencies {
compile project(':ouat-contract')
}
My problem starts when I try apply war plug-in in ouat-servicesImpl, I receive the following message in eclipse problem view:
Invalid classpath publish/ export dependency /ouat-contract. Project entries not supported
My ouat-services build.gradle
configure(subprojects) {
apply plugin: 'com.github.ben-manes.versions'
apply plugin: 'eclipse'
apply plugin: 'java'
version = '1.0'
sourceCompatibility = 1.8
targetCompatibility = 1.8
def defaultEncoding = 'UTF-8'
[compileJava, compileTestJava]*.options*.encoding = defaultEncoding
repositories {
jcenter()
mavenLocal()
mavenCentral()
}
jar {
manifest.attributes provider: 'Company'
}
}
configure(project(':ouat-servicesImpl')) {
apply plugin: 'checkstyle'
apply plugin: 'eclipse-wtp'
apply plugin: 'findbugs'
apply plugin: 'jacoco'
//apply plugin: 'jetty'
apply plugin: 'pmd'
apply plugin: 'war'
}
buildscript {
repositories {
jcenter()
mavenCentral()
mavenLocal()
}
dependencies {
classpath 'com.github.ben-manes:gradle-versions-plugin:0.10.1'
}
}
My ouat-servicesImpl build gradle was changed to:
dependencies {
compile project(':ouat-contract')
cxfArtifacts.each { artifact ->
compile "org.apache.cxf:$artifact:$cxfVersion"
}
springArtifacts.each { artifact ->
compile "org.springframework:$artifact:$springVersion"
}
testCompile "org.testng:testng:$testNGVersion"
testCompile "org.hamcrest:hamcrest-all:$hamcrestVersion"
testCompile "org.springframework:spring-test:$springVersion"
//WAR PLUGIN
providedCompile "javax.servlet:javax.servlet-api:$servletAPIVersion"
runtime "javax.servlet:jstl:$jstlVersion"
}
Is this an eclipse plug-in problem or I am doing something wrong?
Here's the magic steps I've discovered to make it work without messing with Project settings manually.
Run command: gradle cleanEclipse eclipse
as a result of this command Eclipse forgets that the project was supposed to have a gradle nature.
Add gradle nature back to the project by doing Configure -> Convert to Gradle Project.
as a result of this command the error reappears.
if incompatible plugin java version error appears then just delete .settings directory and refresh.
Run command: gradle cleanEclipseClasspath eclipseClasspath
this final step should get it fixed until the next time.
In my case, this was due to mixing "faceted" and non-faceted projects. The projects with the error had been converted to faceted form, and the project they referenced which it was complaining about had not been. You can configure the project to be faceted via use of the eclipse-wtp plugin, by adding this to your ouat-contract gradle file:
eclipse{
wtp{
facet{}
}
}
This will add facets for Java and a utility module when using the java and war plugins (see the EclipseWTPFacet documentation for more information on the defaults and manually adding facets if you aren't using the war plug-in). The utility module part is the key to avoid the error.
Note that within this block you can also access the facet file directly to perform manual XML manipulation if you need to do other things, like specify a particular Apache Tomcat Runtime or or similar
Once you make this change, you can use Eclipse to do Gradle -> Refresh All on ouat-contract within your workspace - once I did this, the error went away
I've also run into this problem long time ago. It really seems to be the problem related to the Eclipse plugin included in "Gradle IDE Pack" (as it works from the command line without problems).
My setup is probably way more complex than Yours (I'm including modules from one top-level gradle project into another top-level gradle project), but to overcome this specific error
Invalid classpath publish/ export dependency /my-project. Project entries not supported
... i excluded project dependency if some specific gradle property was missing:
if(project.hasProperty("myProjectRefAddedFromIDE")) {
println "NB! Build script started with property 'myProjectRefAddedFromIDE' - expecting that this project in IDE is configured to add the direct reference to my-project"
} else {
compile project(':my-project')
}
And to add the property "myProjectRefAddedFromIDE" only from IDE, i have configured eclipse plugin as follows:
Window -> Preferences -> Gradle -> Arguments -> Program arguments -> Use: ´-PmyProjectRefAddedFromIDE´
Just a warning: this will probably work for you, but there might be some other problem with Your setup, as for simple multi-module project (that doesn't include modules form another multi-module project) I don't have to use this workaround.
This works for me to remove the duplicate jar files from JRE System Library.
Steps Right click on Project and go to Build Path->configure build path->Libraries.
Remove the jars that are not in the classpath or duplicated in Maven dependency.
I have a Gradle build that invokes various other gradle scripts, using apply from. Both the main build.gradle and each of the sub-scripts make use of the same build script plugin (the gradle-cargo-plugin, specifically).
The only way I've managed to get this to work is to repeat the declaration of the plugin in each script:
build.gradle:
buildscript {
repositories {
jcenter()
}
dependencies {
classpath 'org.gradle.api.plugins:gradle-cargo-plugin:1.5.1'
}
}
apply from: 'other.gradle'
// do something with the cargo plugin
other.gradle:
buildscript {
repositories {
jcenter()
}
dependencies {
classpath 'org.gradle.api.plugins:gradle-cargo-plugin:1.5.1'
}
}
// do something else with the cargo plugin
As you can see, the buildscript section is repeated in each script. Changing that dependency becomes tedious and error-prone, but the sub-script don't inherit the dependency from the main build.gradle.
Is there a way to clean this up, either by allowing the invoked scripts to inherit the buildscript dependency, or a different way to delegate to the sub-scripts instead of using apply from?
Works fine for me with Gradle 2.1. Build scripts declared in a build.gradle's buildscript block are visible in script plugins.
Plugins in the new plugin portal (http://plugins.gradle.org/) can be applied in a single line, and don't require a buildscript block (with Gradle 2.1 and higher).
I wrote a custom gradle plugin which comes with an additional compile step. For the compilation some classes of the plugin itself are needed, since it is an annotation processor.
I try to solve it by adding the plugin as a compile dependency this way:
// in the custom plugin
project.dependencies {
compile "com.thilko.spring:gradle-springdoc-plugin:0.1.SNAPSHOT"
compile localGroovy()
}
This solution is working but introduces duplication since I have to declare the same plugin version that is already declared in the build script section of the project that uses the plugin:
// build.gradle of the project that uses the plugin
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath "com.thilko.spring:gradle-springdoc-plugin:0.1"
}
}
apply plugin: 'springdoc'
Is there a way to reuse the dependencies defined in the buildscript section?
If you think it's worth it, you can declare an extra property inside the buildscript block (e.g. ext.springdocPlugin = "com.thilko.spring:gradle-springdoc-plugin:0.1.SNAPSHOT"), and then reuse it from outside (e.g. dependencies { compile buildscript.springdocPlugin }).
If you add the dependency to the pom of the your plugin, it will be added to the buildscript dependencies of the project you apply your plugin to.