1

I have project which has some dependencies, I am using Gradle.

I am declaring them by:

dependencies {
  compile 'org.json:json:20180130'
  compile 'com.test.myapi:1.0.1'
}

the com.test.myapi:1.0.1 jar has org.json inside it (Really bad deprecated thing I have..).
Now, I need to use the function JSONTokener which has new constructor in the latest version, and I do not have it in my com.test.myapi package.

The build successfully creating me jar and tgz as I taking distroJar, but I am getting runtime error because for some reason it takes the JSONTokener method from the old version.

Is there any way to force the project taking org.json from the new one, or disable the org.json from the internal package?

Thanks.

gabi
  • 1,003
  • 5
  • 12
  • 30

1 Answers1

2

Assuming that myapi will work with new version of org.json you can exclude old one like this 

compile ('com.test.myapi:1.0.1'){
    exclude group: 'org.json', module:'json'
}

You can also use project-report plugin to explore where that unwanted dependency is coming from. Using gradle to find dependency tree

Obviously exclude won't work on uber jars.

Devstr
  • 4,431
  • 1
  • 18
  • 30
  • Still getting exception `Exception in thread "main" java.lang.NoSuchMethodError: org.json.JSONTokener.(Ljava/io/InputStream;)`. I tried `exclude group: 'org.json', module:'json'` as you recommended, but it seems that it still taking it from this jar, deleting the jar from the classpath seems to work, so I am sure it is taking it from this one.. – gabi Feb 21 '18 at 21:12
  • 1
    Try checking your dependencies tree. I've updated the answer with a link on how to do this. – Devstr Feb 21 '18 at 21:19
  • Will check `./gradlew htmlDependencyReport` – gabi Feb 21 '18 at 21:32
  • On the Report I see this line: `org.json:json:20160810 ➡ 20180130` - what does it means ? looks like it override with the new version, which seems to be what I need, right? Any idea why I still getting the exception? – gabi Feb 21 '18 at 21:41
  • Can it be due to classpath order of jars? – gabi Feb 21 '18 at 21:42
  • You are correct, that that line means Gradle will automatically resolve the conflict and use newer version. Could you please post your actual classpath? How are you running your application? Where the classpath is generated? – Devstr Feb 21 '18 at 22:09
  • Order of jars should not matter because in case of conflicting classes on the classpath only one will be loaded and it's undefined which one. It might even change from run to run. – Devstr Feb 21 '18 at 22:13