Workflow for multiple separate gradle projects?

Old Forum
1

We have 2 projects, one that depends on the other. They need to be versioned separately, so they each have their own repository and are their own gradle project. Here’s a code example:

group = 'net.ll86'
project = 'foo'
version = '2.1.2-SNAPSHOT'
apply plugin: 'java'

project = 'bar'
version = '2.1.1-SNAPSHOT'
apply plugin: 'java'
  dependencies {
    compile 'net.ll86:foo:2.1.2-SNAPSHOT'
}

I’ve experimented with a couple workflows. Here are some ideas I’ve tried: 

  /* Using code tags b/c I can’t figure out nested lists

  • using mavenLocal():

    • apply plugin ‘maven’ to project foo

    • add mavenLocal() to the repositories list for bar

    • when there’s a change in foo I run ./gradlew build install for foo, and ./gradlew build --refresh-dependencies for bar (takes a long time)

    • using eclipse:

    • apply plugin ‘eclipse’ to project foo and bar

    • run ./gradlew eclipse on each project

    • import the generated eclipse projects

    • configure the bar eclipse project by hand to include the foo eclipse project

*/

The eclipse method is less than ideal because I need to make sure the gradle build passes before I commit the code. Do you have any other suggestions for this type of workflow?

Thanks in advance!

Joe

2

A few ideas:

  • Instead of using ‘mavenLocal()’, you could declare your own local Maven or Ivy repo (avoids pollution with all the stuff in ‘mavenLocal’). * Instead of ‘–refresh-dependencies’, you could set a timeout for caching dynamic versions (see ResolutionStrategy). * Given that the projects are versioned separately, you could consider to use the same indirect workflow in Eclipse (edit upstream project, publish to local repo with Gradle, refresh downstream project). Alternatively, you could customize Eclipse project generation.
3

Interesting. If I set the timeout for caching changing modules to 0 (for my workstation), would that only check for versions that have “-SNAPSHOT” in them?

Furthermore, would you recommend using a dynamic version (e.g., foo-latest.development) over a changing module (e.g., foo-2.1.2-SNAPSHOT) for this type of workflow?

4

Yes, Maven snapshots are currently implemented as changing modules. You can also manually set a module to changing.

When working with Maven repositories, I’d use snapshots (which currently means changing modules); when working with Ivy repositories, I’d use dynamic versions.