Defining multiple jar dependencies


(mike.h.smith37) #1

We have a multi-module build setup (about 60 projects), but our library dependency management is very unsophisticated. I’d like to simplify and make it more flexible wrt future library upgrades.

For example, we have multiple projects defined with the following style dependencies (in each project build.gradle):

compile ' lib:spring-3.1.1/org.springframework.aop-3.1.1.RELEASE'

        compile
' lib:spring-3.1.1/org.springframework.asm-3.1.1.RELEASE'

        compile
' lib:spring-3.1.1/org.springframework.aspects-3.1.1.RELEASE'

        compile
' lib:spring-3.1.1/org.springframework.beans-3.1.1.RELEASE'

        compile
' lib:spring-3.1.1/org.springframework.context-3.1.1.RELEASE'

Its a longer list in reality! We are using flat file repositories.

I would like to change this to a single dependency declaration and separately define this as a collection of jars in the top level build.gradle file or somewhere similar, a bit like a group of external dependencies?

I have seen brief mentions of dependencies.gradle where this might be defined (?), but have not found any examples of usage.

Any pointers much appreciated.

Regards,
Mike


(James Justinic) #2

For an example of a dependencies.gradle that has several groups of external dependencies, look at the Gradle project itself. The collections of dependencies are created under libraries.name and then referenced that way in the dependencies blocks of the various modules. The root project uses apply from: 'dependencies.gradle' to pull in this dependency information.


(mike.h.smith37) #3

Thanks James, working a treat for me


(Ken Krugler) #4

Is there a simpler version that shows how to just change one jar dependency when building for test vs. production? Specifically there’s a compile-scope jar that must be included for a war build, but must not be included for unit tests.

Thanks!

– Ken


(James Justinic) #5

The original question is about declaring all libraries for your project in a single location and grouping the ones that would be used together so that individual projects can use aliases rather than multiple full dependency declarations. This is a completely different concern from what you’re asking about.

You instead want to exclude a particular dependency from the relevant test related configuration: testCompile, testRuntime, or testImplementation (if you’re using a new enough version to start using the new configurations).

dependencies {
    compile 'com.example:no-test:1.0'
}

configurations {
    testCompile.exclude group: 'com.example', module: 'no-test'
}