CODEWITHSUNDEEP
gradlecontinuous-integration
Héctor
Héctor

Reputation: 26044

Continuous integration and Gradle: external project as dependency

I have a Gradle-based project with a external project as dependency.

settings.gradle

include ':app'
include ':mylibrary'
project(':mylibrary').projectDir = new File('/path/to/my/library')

I'm developing mylibrary at the same time as my app, this is the reason why I include it in my project this way, instead of as dependency (I would have to upload the artifact in each change or copy the jar to libs folder, and that is tedious).

My problem is that when I commit changes of my app, Jenkins build fails because it can't find the module mylibrary (obviously, beacuse it is in my local file system).

How should I handle with that?

Upvotes: 0

Views: 180

Answers (2)

Jolta
Jolta

Reputation: 2725

I just solved the same problem this way.

Add mylibrary as a proper dependency in app. The app build will try to pull the library from your configured remote Maven or Ivy repo(s).

When you change mylibrary, you may want to make that change visible to app immediately, without publishing to the binary repo. You can accomplish this by using the :mylibrary:publishToMavenLocal task, which will put the binary lib in your ~/.m2/reposity. This only takes one extra command so it's not too bad, I think. This assumes the new Maven publisher is being used in mylibrary:

apply plugin: 'maven-publish'

Next, app needs to be instructed to fetch dependencies from there:

repositories {
    mavenLocal()
    //other repos
}

The app:compileJava task should now check your local Maven repo first, before checking remote repos.

I find this approach is preferable to the answer by taringamberini, because you don't have to publish changes to library which are not ready for customer release. You can even test that your changes to mylibrary don't break app, before you merge library changes to master.

(You don't want to publish changes to the binary repo, which are not in master. That would be a recipe for disaster...)

Upvotes: 1

taringamberini
taringamberini

Reputation: 2747

You should work with 2 gradle projects in your workspace:

  • mylibrary
  • myapp (with a dependency on mylibrary)

When mylibrary is modified you should test it and, if test have passed, commit it to source repository and to binary repository. (If you didn't want do that manually you might configure 3 Jenkins jobs, build <-- test <-- deploy to binary repository, configuring a little continuous-delivery pipeline).

Next when mylibrary is modified you should test it and, if test have passed, commit it to repository. Such commit triggers a Jenkins build and because mylibrary exists both in the source and binary repositories, it will compile successfully.

You may version mylibrary adopting Semantic Versioning and managing the last version of mylibrary with graddle's Dynamic Versions or Changing Modules feature.

Upvotes: 1

Related Questions