"Remap jars" not working with local Maven repo in eclipse

Help/Discuss
1

Hello!

Background

I have been struggeling for quite a while now to get a “resolve workspace artifacts”-like behavior (as I know it from the m2e-plugin) with Gradle dependencies in eclipse.

That is, when I have two Gradle projects A and B in my workspace where A depends on B, I want changes in B to become available in A immediately and without deploying B to any repository first.

I found a lot of discussion on this topic, always resulting in the recommendation to use the STS Gradle Integration and enable the “remap jars”-functionality, e.g. “How to use “remap Jars to maven projects” feature” or “eclipse gradle workspace resolution between gradle projects not working” and many more.
People always emphasized the fact that the dependency should be installed at least once locally (in the referenced version).

Working Solution + Question

I found that it makes a big difference how you install the dependency locally:

  • When install it via the maven plugin (./gradlew install), the
    artifact goes to my local maven repo (~/.m2). This installation does
    not cause eclipse to resolve my workspace project, however.
  • When I upload the artifact to a remote repository (delete the copy
    in ~/.m2) and let Gradle download the dependency again, this time
    my dependency goes to ~/.gradle/caches. This works perfectly:
  • Changes in the dependency become visible in the referencing project
    immediately.
  • Refactorings (e.g. renaming methods) work fine across the two
    projects.

Now that I have one way to make it work, I can perfectly live with it. I still doubt that this is the orthodox solution. So, is there a more elegant way to make this work or am I missing something? What could be the reason for the thing not working with the local Maven repo?

Tools

I’m using:

  • Gradle 2.4 (wrapper)
  • eclipse 4.5.0 (Mars) with integrated Maven support
  • STS + Gradle IDE 3.7.0

I have the two “remap jars”-options enabled in Preferences->Gradle. I have Gradle Dependency Management activated on both projects.

Thanks for any inspiration!

2

Are you aware of the new dependency substitution rules feature in gradle 2.5?

https://docs.gradle.org/current/release-notes#dependency-substitution-rules

1 Like
3

I wasn’t aware of these rules, yet, thank you for the hint!

I was able to achieve the desired behavior in eclipse by adding these snippets to the my referencing project (A):

build.gradle:

configurations.all {
    resolutionStrategy.dependencySubstitution {
        substitute module("com.company:gradledependency") with project(':gradledependency')
    }
}

settings.gradle:

include 'gradledependency'
project(':gradledependency').projectDir = new File('../gradledependency')

I’m not sure though if I fully understand the implications of this approach:

  • Did I just turn my simple project into a multi-module project?
  • I can observe the same resolution behavior in eclipse and when I
    run the build from the command-line. (Which would be a difference
    with respect to the “remap jars” feature and the analog behavior
    of Maven/m2e.) Am I right in assuming that there is no built-in
    condition that triggers the substitiotion and that Gradle will always
    apply it.
  • So, I would need to make the substitution conditional on the
    environment in the build script (and also the include in the
    settings.gradle?) so that the build would work out of the box in a
    non-development environment? (As described in
    51.8.3.3. Conditionally substituting a dependency.)