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?
Related
I am working on a project which pulls in artifacts from nexus as dependencies using gradle. I am not trying to test the changes I am making in a dependency, and would like to test it. Rather than deploy it to nexus, and bump the version before I know it works, I would like to build in a way that I normally would in maven using :
mvn clean intall
Is there a way to do this with gradle? I can't find exactly what I am looking for, essentially I want to build my snapshot, and be able to import it in my project instead of pulling down the version on nexus.
I know someone is going to tell me to google this - but maybe I have been using the wrong search term - I can't find exactly what I am looking for at all with regard to this.
You can use the maven plugin:
apply plugin: "maven"
and the use the gradle install task.
Otherwise you can use the maven-publish plugin:
apply plugin: 'maven-publish'
and then the publishToMavenLocal task. More info here.
These tasks build the project and then publish into the local Maven repo.
Make sure to add mavenLocal() to get the dependencies in your project.
repositories {
mavenLocal()
}
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>
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.
I have a build tool thats tied the version to the SCM. I can't set the version of a jar when I build it locally. If someone were to change what I'm working on locally it would push the version number (which I can get), but when I publish to my local repo (Ivy) Gradle seems to prefer the external repo.
build.gradle
repositories {
mavenCentral()
ivy {
url "${System.properties['user.home']}/.ivy2/local/"
layout "pattern", {
artifact "[organization]/[module]/[revision]/[artifact](-[classifier]).[ext]"
ivy "[organization]/[module]/[revision]/ivy.xml"
}
}
ivy {
url "https://repo/"
layout "pattern", {
artifact myPattern
ivy myIvyPattern
}
}
}
Without changing the build for the jar that I'm editing. How can I have gradle always prefer the local repo? I have a feeling that resolutionStrategy might be the best way, but I don't know how accomplish this.
Edit 1
To help clarify, Artifactory has a jar (published by jenkins) with version 1.2.3. I have a jar that I build locally that saves into my local repository as 1.2.3. When I build a project having both repositories in my repository closure (with my local one on top) Gradle seems to pull in the one from Artifactory.
Edit 2
Dependency definition
dependencies {
compile ('company:project:1.2.+')
}
I don't really understand what you are saying, but Gradle searches repositories in their declared order, and picks the first matching module that it finds (as least as long as fixed versions are used).
I have a project built by gradle that publishes an artifact to a local ivy repository. Historically, we have used gradle purely with flatDir repositories, as we want to keep everything local. However, I'm starting to see the benefit of using ivy over copying the generated artifacts everywhere.
I can publish the artifact to ivy easily, but other projects that use the repository to pull this artifact in fail on its transient flatDir dependencies.
I'm trying to work out the best way to handle these transient dependencies. It's clear they are needed by anyone using the artifact as they have classes that artifact uses. Should I publish the transient dependencies with my artifact to ivy? What's the best way to do this?
I've tried (what I consider a hack) declaring the jars in the flatLib dir as artifacts themselves with:
group 'utils'
repositories {
flatDir {
dirs 'lib'
name 'librepo'
}
}
dependencies {
compile ":antlr:3.4"
// ...
}
artifacts {
project.repositories.librepo.dirs.each { dir ->
dir.eachFile {
if (it.isFile()) {
archives file(it)
}
}
}
}
However, projects that include the artifact fail because the flatDir files are uploaded to the same group as the main artifact (in this case, 'utils'), but are defined with no group in the dependencies section, and so the entries in ivy.xml have no org value, i.e.
<dependency org="" name="antlr" rev="3.4" conf="compile->default"/>
I think I'm missing something, any help would be appreciated on how to mix flatDir and ivy.
Should I migrate the flatDir dependencies to ivy so they resolve correctly, and I can then change my build to use just the ivy repository it's publishing to as a source as well? I can't really think of a better way, but if I do this, it'll have quite an impact in that every dependency will have to move out of the main project dir's lib dir, to ivy, and I only really want to use the ivy repository to manage our generated artifacts, not third party libraries.
For completeness, I couldn't find a decent solution to this and ended up moving all the lib/ jars to ivy too with the help of this article. Still, this question ended up earning me the tumbleweed award!