CODEWITHSUNDEEP
gradle
vicsz
vicsz

Reputation: 9764

Relative project dependencies in Gradle?

When specifying Gradle project dependencies, can I avoid using a full absolute project name and use a relative one instead? (i.e. in my example I don't want to explicitly specify :app-a when referencing :domain-a)

//Directory structure
app-a/
  domain-a/
    build.gradle
  webapp-a/
    build.gradle

WebApp-A build.gradle:

apply plugin: 'java'

//Build.gradle for webapp-a
dependencies {

  // Works
  compile project(':app-a:domain-a')

  //Doesn't work
  compile project(projectDir.path + '/../domain-a/')

  //Doesn't work
  compile findProject('../domain-a')

  //Doesn't work
  compile project(':domain-a')
}

Upvotes: 30

Views: 39650

Answers (6)

DTK
DTK

Reputation: 115

I have just checked a Gradle training and asked about relative paths, I was given the answer that the best practice is the method file("...") handy for relative paths. You can checkout the documentation .

I have not tested yet, but I would suppose this would work:

compile findProject(file("domain-a"))

Upvotes: 0

Apurva Singh
Apurva Singh

Reputation: 5010

Use compile project':'. Nothing else is required. Now your 'using' project will use this shared project on your file system/Eclipse/IntelliJ.

Upvotes: 0

Bogdan Emil Mariesan
Bogdan Emil Mariesan

Reputation: 5647

A late answer never hurts. My solution was close to what @lihsus suggested.

Say you have the following project structure:

//Directory structure
app-a/
   domain-a/
       build.gradle
   webapp-a/
       build.gradle

Make sure your app-a has a build.gradle and a settings.gradle.

In the settings.gradle of app-a you can then include both modules/projects such as:

include ':domain-a'
include ':webapp-a'

And then in webapp-a you can add domain-a as a compile dependency such as you suggested:

compile project(':domain-a')

Upvotes: 1

lihsus
lihsus

Reputation: 297

Although using relative paths might be a bad practice, sometimes you might just need it that way. Nevertheless, here is how you can get it to work.

You need to create settings.gradle file inside webapp-a

webapp-a/settings.gradle

include '..:domain-a'

Then in webapp-a/build.gradle

compile project(':..:domain-a')

(haven't tested it myself but it should work)

EDIT: replaced ../domain-a by ..:domain-a in both files

Upvotes: 9

J c
J c

Reputation: 6413

For Android development under Android Studio and gradle, here's how to compile a library that isn't under your project's root but has a relative path:

  1. Include the library in settings.gradle and override the projectDir:

    include 'MyTestLibProject:MyTestLib'
project(':MyTestLibProject:MyTestLib').projectDir = new File(settingsDir, '../MyTestLibProject/MyTestLib')

  2. Edit the build.gradle for the library to use the android-library plugin instead of android, this causes the library outputs to be included into projects that reference it:

    apply plugin: 'android-library'

  3. Specify that your project has a dependency on the lib by editing the build.gradle for the non-lib project:

    compile project(path: ':MyTestLibProject:MyTestLib')

  4. If the lib includes any jars that your project also includes, the build will see them as a collision when it is generating the apk. Abstract jars into an additional lib that both the project and lib reference, or just exclude the colliding jar from the main project and let it pick up the jar from the dependency:

    dependencies {
    compile fileTree(dir: 'libs', include: '*.jar', exclude: '**/android-support-v4.jar')
    compile project(path: ':MyTestLibProject:MyTestLib')
}

DISCLAIMER: This isn't how gradle wants you to do this - you're intended to publish the lib using maven and then reference the dependency using the "POM" of the published lib (which includes the version number). This provides better dependency management - for example, maven simplifies the scenario of having many projects (with varying release cycles) all using various versions of a common lib. The relative path technique described here is a quick way to get up and running for small projects or as an interim step for projects being ported from ant.

Reference: http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Creating-a-Library-Project

Upvotes: 44

Manfred Moser
Manfred Moser

Reputation: 29912

Relative names are a bad idea since they make your project depend on the wider project it is located in. That should not be the case. I suggest to avoid using the relative name.

In terms of retrieving the parent project as a dependency this would be done via the default being the parent directory or that failing it would use the usual dependency resolution mechanism, which uses the coordinates (groupId, artifactId and version) and looks the artifact up in the local repository..

Upvotes: 2

Related Questions