• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Devaka Cooray
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Paul Clapham
  • Knute Snortum
  • Rob Spoor
Saloon Keepers:
  • Tim Moores
  • Ron McLeod
  • Piet Souris
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Frits Walraven
  • Ganesh Patekar

How to find if dependency exclusions are needed in a maven Java project?

 
Greenhorn
Posts: 26
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I have a Java project with maven. I added many dependencies to the pom. I need to find out if any dependencies could cause conflicts and remove them.
I did mvn clean install -DskipTests to check if there are any compile time dependency conflicts. Is this enough or should I do something more ?

Thanks !
 
Rancher
Posts: 1170
18
IntelliJ IDE Hibernate Firefox Browser MySQL Database Spring Tomcat Server Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Which idea are you using? For intelij by example if you go to your projectstructure and click on problems you can see if there are any issues with your dependencies.
Most likely your idea will also red underline them in your pom and they will simply not work...
 
Tom Joe
Greenhorn
Posts: 26
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Daniel Demesmaecker wrote:Which idea are you using? For intelij by example if you go to your projectstructure and click on problems you can see if there are any issues with your dependencies.
Most likely your idea will also red underline them in your pom and they will simply not work...



I am using the community edition 2018.3.5. Intellij shows no problems under File > Project Structure > Problems. Is it enough to check this or do I need to do more ?

Thanks.
 
Daniel Demesmaecker
Rancher
Posts: 1170
18
IntelliJ IDE Hibernate Firefox Browser MySQL Database Spring Tomcat Server Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What is the reasson you think there would be issues? Of there are and you would notice at runtime. I never boughtered to extra check my dependencies...  so i would say it's enough...
 
Saloon Keeper
Posts: 10407
223
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can use the maven-dependency-plugin to perform all kinds of useful operations to check your dependencies.

For instance, executing mvn dependency:tree -Dverbose will show a dependency tree that includes conflicting dependencies.
 
Tom Joe
Greenhorn
Posts: 26
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:You can use the maven-dependency-plugin to perform all kinds of useful operations to check your dependencies.

For instance, executing mvn dependency:tree -Dverbose will show a dependency tree that includes conflicting dependencies.



By the way, I am new to maven. I only know a few basic commands for the things I need to do. I saw the dependency tree. It has a lot of "omitted for duplicate" and "omitted for conflict with" items, but the build was successful. I don't see any errors though. Does this mean that everything is okay or do I have to do something more about these conflicts ?
 
Stephan van Hulst
Saloon Keeper
Posts: 10407
223
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"Omitted for..." means that a dependency wasn't included, because it was either already included earlier, or because it conflicts with a dependency that was already included but has a different version.

"Omitted for duplicate" is fine, and happens a lot. You can still try to eliminate these by not declaring these dependencies in your POM if they are already included as transitive dependencies.

You really should try to get rid of all "Omitted for conflict" notices however, by explicitly excluding the version that you don't want. Even if you've removed all conflicts this way, it's never certain if everything will be okay, because the version that you included in your project may not be backwards compatible with the version that one of your dependencies requires. The only way to find out is to thoroughly test your application.
 
Tom Joe
Greenhorn
Posts: 26
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:"Omitted for..." means that a dependency wasn't included, because it was either already included earlier, or because it conflicts with a dependency that was already included but has a different version.

"Omitted for duplicate" is fine, and happens a lot. You can still try to eliminate these by not declaring these dependencies in your POM if they are already included as transitive dependencies.

You really should try to get rid of all "Omitted for conflict" notices however, by explicitly excluding the version that you don't want. Even if you've removed all conflicts this way, it's never certain if everything will be okay, because the version that you included in your project may not be backwards compatible with the version that one of your dependencies requires. The only way to find out is to thoroughly test your application.



Thanks. I was also told that sometimes dependency conflicts only show up when an app (web, mobile, java etc.) is run, but not when its compiled or its tests are executed. Is this correct ? If yes, then why do conflicts sometimes only show up when the app is running ?
 
Stephan van Hulst
Saloon Keeper
Posts: 10407
223
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Because conflicts usually manifest in code that has already been compiled, not code that is yet to be compiled.

Let's say you have an application A that has dependencies on B and C.

B depends on D.v1.
C depends on D.v2.

Maven resolves this conflict by picking the newest version. It compiles application A by including dependency D.v2, which will obviously fail if code inside A uses classes or methods that were only available in D.v1, and removed or changed in D.v2. If not, then it will compile successfully.

Maven doesn't compile B, because it has already been built and you might not even have access to the code of B in the first place. So if in A you call a method from B which in turn calls a method from D.v1 that no longer exists in D.v2, then you will obviously get a runtime exception.

While that is obviously a big problem, an even more nefarious class of issues exist where the conflict doesn't manifest in an error, but in a subtle but dangerous change of behaviour. Consider the following code in B:

In D.v1, the method looks like this:

in D.v2, Freddy had a change of heart:

B explicitly depends on D.v1 because they know that Freddy is going through some rough times in D.v2. However, if A depends on D.v2 (either directly or transitively), then the doNiceThings() method in B will end up kicking the dog!

The best thing to do is to have a whole battery of tests for your application, and when you change the version of any of your dependencies, you should always rerun your tests.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!