I am trying to set up the Sonar-Runner with my existing gradle project. I am using Sonar-Runner 2.4 Gradle 2.2.1 and our Sonar server is 4.3.1. When I run gradle sonarRunner I get the following error:
Could not resolve all dependencies for configuration ':sonarRunner'.
Cannot resolve external dependency org.codehaus.sonar.runner:sonar-runner-dist:2.4 because no repositories are defined.
I do have the artifact "org.codehaus.sonar.runner:sonar-runner-dist:2.4" in my nexus server that is set up in my build.gradle file. Does anyone have any intuition about this error? I have googled it extensively and been stuck on this for a couple of hours now.
My build.gradle for the sonar runner is very simple:
apply plugin: 'sonar-runner"
sonarRunner{
toolVersion = '2.4'
sonarProperties{
property "sonar.host.url", "$sonarHost"
}
}
It seems no repository is declared for the project you want to use with the sonar-runner plugin.
You might have configured repositories for buildscript or for other projects only (in your multiproject build?)
To resolve the sonar-runner you need to configure a repository where it could be resolved from. You might have a coorporate repository in your company or you could use public ones like mavencentral or bintray. to declare for example the jcenter repository to resolve the sonar-runner. just add the following to your build script:
repositories {
jcenter()
}
Related
My gradle project cannot build. It fails with Plugin with id 'sonar-runner' not found.
Here's my build.gradle
subprojects {
apply plugin: 'sonar-runner'
}
I've refreshed my Gradle project. Then I've deleted my ~/.gradle/caches folder, but didn't work. Then I deleted my entire ~/.gradle folder, still the same error.
Any ideas please?
It's funny that gradle build doesn't run and gives me that exception, but bash gradle build runs fine, can someone clarify the difference in between? Thanks. My setup is on Mac OSX 10.11.6.
From https://docs.sonarqube.org/display/SONARQUBE51/Analyzing+with+Gradle:
Users of Gradle Sonar or Sonar Runner Plugins ? The existing Gradle
Sonar Runner and Gradle Sonar plugins, which are part of the Gradle
distribution, should no longer be used (See this official note from
the Gradleware team). The use of the Gradle SonarQube plugin is
recommended instead.
You have to use it as described at https://plugins.gradle.org/plugin/org.sonarqube
Build script snippet for use in all Gradle versions:
buildscript {
repositories {
maven {
url "https://plugins.gradle.org/m2/"
}
}
dependencies {
classpath "org.sonarsource.scanner.gradle:sonarqube-gradle-plugin:2.2.1"
}
}
apply plugin: "org.sonarqube"
Build script snippet for new, incubating, plugin mechanism introduced in Gradle 2.1:
plugins {
id "org.sonarqube" version "2.2.1"
}
Issue discussing this problem:
https://discuss.gradle.org/t/plugin-with-id-org-sonarqube-not-found/11588/10
I have Maven with M2_HOME defined to /Users/manuelj/apache/maven/3.2.5
I have the settings.xml file, located on /Users/manuelj/apache/maven/3.2.5/conf/settings.xml
where I have the following declared:
<localRepository>/Users/manuelj/apache/maven/repository</localRepository>
Until here with Maven all works fine. Any new dependency goes there.
I have a project based with Gradle, among many things in my build.gradle, exists the following:
apply plugin: 'java'
apply plugin: 'maven'
apply plugin: 'eclipse'
apply plugin: 'application'
version = '1.0.0'
sourceCompatibility = '1.8'
repositories {
mavenLocal()
mavenCentral()
}
… more
Until here, all works fine too. Code compile, executes well.
My confusion is the following.
According with my understanding is that Gradle's mavenLocal() should use the same path than <localRepository> defined on Maven's settings.xml file.
Now confirming that in the Maven local repository exists some dependencies already downloaded.
When I execute for example gradle build, I did realize that
If a dependency already exists from the Maven Local Repository, it is used from there.
If a dependency does not exist from the Maven Local Repository Gradle download the new dependency to: /Users/manuelj/.gradle/caches/modules-2/files-2.1
I want that the new dependency go directly to the same Maven Local Repository.
Therefore, what extra configuration is need it?
Resolving Dependencies From Local Maven Repository
Gradle is able to resolve artifacts stored in the local Maven repository (usually ~/.m2/repository) via mavenLocal().
According to the documentation, mavenLocal() is resolved like this:
Gradle uses the same logic as Maven to identify the location of your local Maven cache. If a local repository location is defined in a settings.xml, this location will be used. The settings.xml in USER_HOME/.m2 takes precedence over the settings.xml in M2_HOME/conf. If no settings.xmlis available, Gradle uses the default location USER_HOME/.m2/repository.
To resolve artifacts from a non-standard local Maven repository, you can use the following configuration in your build.gradle:
repositories {
maven {
url '/Users/manuelj/apache/maven/repository'
}
}
(From: How does Gradle resolve the directory of the local maven repository?)
Custom Maven repositories are documented here.
Storing Artifacts in the Local Maven Repository
Gradle stores resolved dependencies in its own Dependency Cache. The dependency cache is so much more than just a simple Maven artifact repository:
Stores binaries (jars), artifact meta-data (POM, Ivy files), dependency resolution results and module descriptors.
Tuned for performance, for example shorter file paths.
De-duplicates artifacts: Same binaries are stored only once.
Tracks where a dependency came from. A dependency resolved from jcenter() might be different to the one resolved from mavenCentral().
Automatic, time and usage bases, cache cleanup.
Artifacts produced by the build can be easily pushed to the local Maven repository via publishToMavenLocal task contributed by the Maven Publish Plugin.
But what about resolved dependencies? For the aforementioned reasons, Gradle cannot store dependencies in the local Maven repository. There's currently no built-in functionality to even publish dependencies to the Maven's local repository from the build script. So what are your options:
Create a shell script that does the necessary legwork. Daniel Dietrich once wrote one and published it on Twitter (Gist).
Use an artifact proxy like Nexus or Artifactory. Maven and Gradle can be configured to consume dependencies from the same proxy. This setup is quite common in professional environments and my personal preference.
Use
mavenLocal()
for example:
buildscript {
ext {
springBootVersion = '2.0.0.M1'
}
repositories {
mavenCentral()
mavenLocal()
maven { url "https://repo.spring.io/snapshot" }
maven { url "https://repo.spring.io/milestone" }
}
dependencies {
classpath("org.springframework.boot:spring-boot-gradle-plugin:${springBootVersion}")
}
}
apply plugin: 'java'
apply plugin: 'eclipse'
apply plugin: 'org.springframework.boot'
apply plugin: 'io.spring.dependency-management'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = 1.8
repositories {
mavenCentral()
mavenLocal()
maven { url "https://repo.spring.io/snapshot" }
maven { url "https://repo.spring.io/milestone" }
}
dependencies {
compile('org.springframework.boot:spring-boot-starter-data-jpa')
compile('org.springframework.boot:spring-boot-starter-web')
compile('com.oracle:ojdbc6:11.2.0.4')
testCompile('org.springframework.boot:spring-boot-starter-test')
}
I am using Gradle 3.5
This drove me to drink.
If I do mvn install for a project having a version of 1.1.1.SNAPSHOT it goes into my local maven repository (~/m2/repository/...) with no errors. However, Gradle using mavenLocal() will not attempt to locate it in the local maven repository (having used ./gradlew bootRun --debug and inspecting the logs).
If I change the version to 1.1.1-SNAPSHOT (note the dash), then Gradle will attempt, and will find the repository.
It doesn't make sense to me that Maven finds this to be a valid version number for local use, but Gradle completely ignores it.
I came across this issue because I'm working on a legacy project where I need to run my build with the sudo gradle build command. The build involves copying XSD files, which require root permissions. I opted not to employ the solutions of the previous answers because I didn't want to change the build file; I didn't want to accidentally checkin my build.gradle changes. What I found was that Gradle was checking for mavenLocal in the /var/root/.m2 folder. My solution was to copy /Users/me/.m2/settings.xml to /var/root/.m2 and add a line for the localRepository to point back to my /Users/me/.m2 folder. A sample line and where to add it is:
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
<localRepository>/Users/me/.m2/repository</localRepository>
<profiles>
If I have multiple maven repositories specified in a gradle build, I am expecting that if gradle cannot find a dependency in one of the repositories it should just try the other ones. Instead, it fails on the first repository (internal company nexus repo) for a dependency that does not exists there and fails the build
repositories {
maven {
url = 'http://mavencentral.it.att.com:8084/nexus/content/groups/att-public-group'
}
mavenLocal()
mavenCentral()
maven { url 'http://maven.springframework.org/milestone/' }
}
FAILURE: Build failed with an exception.
* What went wrong: Could not resolve all dependencies for configuration ':metadata-security:compile'.
> Artifact
'spring-security-kerberos-core.jar
(org.springframework.security.extensions:spring-security-kerberos-core:1.0.0.M2)'
not found. Searched in the following locations:
http://mavencentral.it.att.com:8084/nexus/content/groups/att-public-group/
org/springframework/security/extensions/spring-security-kerberos-core/1.0.0.M2/spring-security-kerberos-core-1.0.0.M2.jar
As said by #Mark Viera in the comments:
Try running the build with --debug. It likely means that Gradle found
a descriptor (pom.xml) but not the artifact itself.
That is, it was missing the jar file (as confirmed by the OP).
We have a project that is using Java 1.5 and we are trying to convert from Maven to Gradle.
We have a repository that is local to us containing all the versions of all the jars we need as the dev environment has no access to the internet.
The problem we are seeing is that it cannot find the commons-io jar and keeps trying to goto the external maven repo. we have not even set that up so where is it finding it from?
we have repositories and dependencies set up in the All projects section as follows
allprojects {
apply plugin: 'java'
sourceCompatibility = 1.5
targetCompatibility = 1.5
project.tasks.withType(AbstractCompile, { AbstractCompile ac -> ac.options.bootClasspath = "C:/Program Files/java/1.5.0_14/jre/lib/rt.jar" })
repositories {
mavenLocal()
maven { url "http://internalrepo/maven-local" }
}
dependencies {
compile "org.apache.commons:commons-io:1.3.2"
}
But its reporting
Could not resolve org.apache.commons:commons-io:1.3.2.
inconsistent module metadata found
even though it works fine in Maven using mvn install
Gradle will never query a repo that isn't set up. mavenlocal() is misspelled (should be mavenLocal()), which will make the build fail. "Inconsistent metadata" could mean that the group ID, artifact ID, or version in the POM doesn't match the one in the build script. mavenLocal() should only be used if the Gradle build needs to exchange artifacts with local Maven builds.
Found the issue,
Unbeknownst to me there was a hidden repo in the maven settings.xml in the maven install folder.
Adding that resolved the issue.
What I have is a maven repository (nexus) to which maven has been publishing. In each artifact version folder in my artifact repository folder there are the standard maven artifacts: a maven-metadata.xml, a jar, and a pom.xml, etc.
Now I want to resolve these using gradle. In my gradle.build file if I list them as:
dependencies {
compile group: 'com.company', name: 'artifact', version: '1.0-SNAPSHOT'
}
Then they will resolve correctly. However, I want to use the version "latest.integration" so that I can automatically integrate the latest versions of my dependencies. When I do this though, gradle fails to resolve it.
I imagine that gradle is looking for some ivy specific files that maven is not publishing up to the repository in order to resolve latest.integration, but I am not sure. Should I go back and re-publish all of my upstream dependencies with gradle before trying to resolve down stream? It would seem that since gradle supports maven repositories under the repositories element that it should already know how to interpret "latest.integration" for that repository type.
This is my repositories section:
repositories {
mavenCentral()
maven { url "http://<server>/nexus/content/repositories/snapshots" }
}
Thank you for any help you can provide
latest.integration is an Ivy concept, and only works for Ivy repositories. In other words, both publication and consumption would have to happen in an Ivy-compatible manner. (Gradle is capable of this; not sure about Nexus.)
The obvious alternative is to use Maven snapshot dependencies. What do you hope to gain from using latest.integration?