update gradle from 4.4 to 5.4 make joda-time dependancy issue

Question

HI I've migrated a project to gradle version 5.4 from 4.4. Since then gradlew build returns error as below.

....ConvTable.java:6: error: package org.joda.time does not exist import org.joda.time.DateTime;

...ConvetService.java:5: error: package org.joda.time does not exist import org.joda.time.DateTime;

...ConvetService.java:34: error: cannot find symbol ConvTableP getLastCononTableDate(String fromCurrency, String toCurrency, DateTime dateTimeZone) throws IOException;

symbol: class DateTime location: interface ConvetService Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details

* What went wrong: Execution failed for task ':cur-api:compileJava'

gradle file looks like below. and its a sub project of bigger one

apply plugin: "j-library" 
apply plugin: "m-publish" 

group = "com.t.cur" 

sourceCompatibility = JavaVersion.VERSION_1_7 
targetCompatibility = JavaVersion.VERSION_1_7 

publishing { publications { mavenJava(MavenPublication) { } } 

repositories { 
  maven { url "${mv_repo_url}" } } 
} 

dependencies { 
  implementation "com.t.com:x-core:1.0.0" 
  implementation "commons-lang:commons-lang:2.6" 
}

Answer 1

My guess is that as part of the upgrade, you changed compile configurations with implementation. One of the differences with the new configuration is that the dependencies will not be exposed to consuming projects as part of the compilation classpath. The idea is that the dependencies you put into implementation are implementation specific and should not "leak" onto the consuming projects. This speeds up the build when using incremental compilation as dependent classes are only recompiled if the public API changes but not the internal implementation. There is also a case to be made for providing looser coupling between projects, though this is a bit more subjective. The implementation dependencies will still be part of, and resolved, in the runtimeClasspath configuration though.

So (assuming this is the underlying issue of cause), the dependency x-core used to provide Joda as a transitive dependency for compilation. But this is no longer the case.

There are two ways to fix it. If you use Joda as part of the public API of x-core, you need to declare it using the api configuration instead of implementation (and use the java-library plugin if you don't already). This will make Joda part of the compilation classpath of dependent projects.

On the other hand, if this sub-project just happens to use Joda as well, but in a completely unrelated way to x-core, you should declare it as dependency here as well (either as implementation or api using the same rules as before).