Gradle: Make a 3rd party jar available to local gr

问题:

currently, I'm testing Gradle as an alternative to Maven. In my projects, there are some 3rd party jars, which aren't available in any (Maven) repositories. My problem is now, how could I manage it to install these jars into my local .gradle repository. (If it's possible, I don't want to use the local Maven repository, because Gradle should run independently.) At the moment, I get a lot of exceptions because of missing jars. In Maven, it's quite simple by running the install command. However, my Google search for something similar to the Maven install command wasn't successful. Has anybody an idea?

回答1:

you can include your file system JAR dependencies as:

dependencies {
    runtime files('libs/a.jar', 'libs/b.jar')
    runtime fileTree(dir: 'libs', include: '*.jar')
}

you may change runtime for compile/testCompile/etc..

回答2:

A more comprehensive answer was given on a mailing list by Adam Murdoch at http://gradle.1045684.n5.nabble.com/Gradle-Make-a-3rd-party-jar-available-to-local-gradle-repository-td1431953.html

As of April 2010 there was no simple way to add a new jarfile to your ~/.gradle repository. Currently researching whether this has changed.

As of October 2014, this is still the case--because gradle does an md5 checksum of your jarfile, you can't simply download it and put it into a directory under .gradle/caches, and gradle doesn't, as far as I can tell, have any tasks which let you take a local file and push that file to its cache.

回答3:

Used option (1) out of Adam Murdoch post (already linked above: http://gradle.1045684.n5.nabble.com/Gradle-Make-a-3rd-party-jar-available-to-local-gradle-repository-td1431953.html) with gradle-1.3 and it works just nicely!

Here his comment:

1. Copy the jars to a local directory and use a flatDir() repository to use them out of there. For example, you might copy them to $projectDir/lib and in your build file do:

repositories { flatDir(dirs: 'lib') }

The files in the lib directory must follow the naming scheme: name-version-classifier.extension, where version and classifier are optional. So, for example you might call them groovy-1.7.0.jar or even groovy.jar

Then, you just declare the dependencies as normal:

dependencies { compile 'groovy:groovy:1.7.0' }

There's a little more detail one flatDir() repository at: http://gradle.org/0.9-preview-1/docs/userguide/dependency_management.html#sec:flat_dir_resolver

2. Similar to the above, but using an ivy resolver instead of flatDir(). This is pretty much the same as the above, but allows a lot more options as far as naming and locations go.

There's some detail at: http://gradle.org/0.9-preview-1/docs/userguide/dependency_management.html#sub:more_about_ivy_resolvers

3. Don't bother with declaring the dependencies. Just copy the jars to a local directory somewhere and add a file dependency. For example, if the jars are in $projectDir/lib:

dependencies { compile fileTree('lib') // this includes all the files under 'lib' in the compile classpath }

More details at: http://gradle.org/0.9-preview-1/docs/userguide/dependency_management.html#N12EAD

4. Use maven install to install the dependencies into your local maven cache, and the use the maven cache as a repository:

repositories { mavenRepo(urls: new File(System.properties['user.home'], '.m2/repository').toURI().toURL()) }

回答4:

Maybe I'm missing something from my reading of your question, assuming your gradle repo is of the flatDir type, you should be able to copy the files there in the form myjar-1.0.jar and resolve them as myjar of version 1.0.

Not sure why should it be necessary for Gradle to run maven in order to access a local maven repository. You can just define the maven repos and it should resolve dependencies. You can use gradle upload to push the jars local or remote maven repos if you need to. In that case, it will execute maven.

回答5:

In short: deploy to repository manager. It can local, on company LAN.

An altogether different way of thinking about this type of problem, specially if it happens often, is to use a repository manager. There are some great open source options out there such as Artifactory, Nexus or Archiva.

Lets assume you have a jar file from some dubious origin that needs to be included in your build until you have the opportunity of refactoring it out. A repository manager would allow you to upload the file to your own repository as, for the sake of this example, dubious-origin-UNKNOWN.jar

Then your build.gradle would look something like this:

repositories {
    mavenRepo urls: "http://your.own.repository/url";
}

dependencies {
    compile "dubious:origin:UNKNOWN";
}

There are a lot of other advantages to using a repository manager such as caching of remote artifacts, remove artifacts from scm, staging releases, more granular user permissions, and so forth.

On the down side, you would be adding a server which carries some maintenance overhead to keep your builds running.

Depends on the size if your project, I suppose.

回答6:

I think something like this should work:

dependencies {
  files('yourfile.jar')
}

Does it work for you?