I'm trying to import core libraries of OpenRDF Sesame into a Grails Application.
This is an extract of my BuildConfig.groovy file:
repositories {
inherits true // Whether to inherit repository definitions from plugins
grailsPlugins()
grailsHome()
mavenLocal()
grailsCentral()
mavenCentral()
}
dependencies {
compile 'org.openrdf.sesame:sesame-core:2.7.7'
}
I get this error message:
Error Could not find artifact org.openrdf.sesame:sesame-core:jar:2.7.7 in grailsCentral (http://repo.grails.org/grails/plugins) (scope: runtime) (Use --stacktrace to see the full trace)
I can't figure out how to solve this issue, the artifact is available on Maven Central:
http://search.maven.org/#artifactdetails%7Corg.openrdf.sesame%7Csesame-core%7C2.7.7%7Cpom
There's no jar there, just a POM file, and it has no dependencies: http://repo1.maven.org/maven2/org/openrdf/sesame/sesame-core/2.7.7/
Looks like you're going to need to specify the individual jar dependencies that you need - e.g. http://repo1.maven.org/maven2/org/openrdf/sesame/sesame-http-client/2.7.7/
Related
I have developed a custom Gradle plugin and assembled as jar. This plugin has one dependency:
plugin/build.gradle
dependencies {
compile 'com.jcraft:jsch:0.1.53'
}
I have included my plugin in another consumer project (as jar in libs):
consumer/build.gradle
apply plugin: 'gg-release-plugin'
buildscript {
repositories {
flatDir {
dirs 'libs'
}
mavenCentral()
}
dependencies {
classpath 'com.myplugin.plugin:myplugin:1.0'
}
}
Everything works fine, but when code that uses classes of the dependency com.jcraft:jsch:0.1.53 is executed, I get an error:
java.lang.NoClassDefFoundError: com/jcraft/jsch/JSch
What am I doing wrong? How can I include the dependencies in jar file?
Seems, you've created a plugin jar library with compile time depnedency, that is not included anywhere in your final jar.
You can try to create your plugin jar as a fat jar, using Gradle FatJar plugin or something else. In that case, you'll have a single jar with all the dependent classes inside. But this could lead to problems, if someone will use the same library.
Or you can try to provide a JSch library together with your plugin jar and make a consumer build script dependency like:
buildscript {
repositories {
flatDir {
dirs 'libs'
}
mavenCentral()
}
dependencies {
classpath 'com.myplugin.plugin:myplugin:1.0'
classpath 'com.jcraft:jsch:0.1.53'
}
}
As I know, if you use a Maven repo to publish your plugin, you can provide a pom.xml to describe all the plugin's dependencies, but as I see, you are using a flatDir for it, so, it seems not to be possible.
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).
Hello I have following GSON dependency in my BuildConfig.Grooovy file
compile 'com.google.code.gson:gson:2.2.4'
and these repos
repositories {
inherits true // Whether to inherit repository definitions from plugins
grailsPlugins()
grailsHome()
mavenCentral()
grailsCentral()
mavenLocal()
mavenRepo "http://repo1.maven.org/maven2/"
mavenRepo "http://repo.grails.org/grails/libs-releases/"
}
This is a pretty basic question but I am getting following error and dont know how to fix it!
Resolve error obtaining dependencies: Could not find artifact com.google.code.gson:gson:zip:2.2.4 in mavenCentral (http://repo1.maven.org/maven2/) (Use --stacktrace to see the full trace)
What it looks like from the error message is that you have declared the dependency as a grails plugin inside plugins section.
//incorrect, hence it is looking for a .zip artifact instead of a .jar
plugins {
compile 'com.google.code.gson:gson:2.2.4'
}
instead add it as a dependency
dependencies {
compile 'com.google.code.gson:gson:2.2.4'
}
I am new to gradle.
I have seen some examples about java dependency like the following example but my project will be simply a zip file.
I just want to download the zip file.
apply plugin: 'java'
dependencies {
compile 'commons-lang:commons-lang:2.6'
}
In the above example, it will automatically download the jar file. But it doesn't download my zip file if my maven repositories contains zip that mentioned in the pom.xml about that package.
Questions:
What is the flow when depend on a maven repository? It will first read the pom.xml and then download the zip file?
How to dynamically load the dependency? e.g 'commons-lang:commons-lang:2.6' will have dependency of 'commons-lang:en:1.0" in the pom.xml. How to make it automatically load and loop the dependency list?
Thanks all
I have tried the follwoing script but it gives me error on compile but I have apply the java plugin
My gradle file
apply plugin: 'java'
repositories {
mavenLocal()
maven {
url "http://nexus.com/myrepo/"
}
}
dependencies {
compile 'com.a.b:projectA:2.0#zip'
}
I can run without problem that files downloaded are inside .m2
Question about the transitive dependency
I have the pom.xml like this. But it is unable to load the dependency one. It will directly go to the new pom.xml first or download zip directly if i mention sth like this?
<dependencies>
<dependency>
<groupId>com.a.b.c</groupId>
<artifactId>base</artifactId>
<version>1.2</version>
<type>zip</type>
</dependency>
</dependencies>
When declaring a dependency and a maven repository, this maven repository will be used to resolve the artifact. this means that usually first the metadata is read and then the artifact will be downloaded. If no repository is declared the resolution will fail early.
Having a dependency notation like yours:
dependencies {
compile 'commons-lang:commons-lang:2.6'
}
gradle resolves the default artifact of that dependency. If you want to resolve additional declared zip files from maven central, you have to use this notation
repositories{
mavenCentral()
}
dependencies {
compile 'commons-lang:commons-lang:2.6#zip'
}
As a default, the a dependency is transitive. This means, that if e.g 'commons-lang:commons-lang:2.6' has a dependency on 'commons-lang:en:1.0" in its pom.xml the commons-lang library (and again its transitive dependencies if any) is also resolved.
cheers,
René