We Keep Coding

How version of lib defined in classpath?

i have hirarhy of modules.
I set up version of hibernate-validator as 6.1.5.Final
But when i build project version of library another
maven dependencies: tree ouput
org.hibernate:hibernate-validator:jar:5.3.4.Final:compile
I can not understand how it works.
I put all dependency tree here https://paste2.org/CwB2H4W2

Problems with dependencies should always bring you to the "Dependency Hierarchy" Tab of your POM.xml. There you will see your projects dependencies, and dependencies of that dependencies.
If I had to guess I'd say there you will find a module providing the dependency you think you don't use.
Further information to maybe change this:
First declared dependencies get used first. So if you define your dependency before the Module that brings the other dependency in, Maven should select yours.

How to find if I need to exclude dependencies in a maven java project?

I use both Intellij IDEA (2018.3.5) & Eclipse IDEs, but I prefer Intellij. I have a maven based Java project with multiple poms. I added some dependencies to one of the pom files. I need to find out if there are any dependency conflicts which could prevent the build from running when its deployed, and then exclude them. I tried the steps given below to find conflicts which could cause problems. Are they enough or do I need to do more ?
Check if there are any compile time dependency conflicts with mvn clean install -DskipTests. Build was successful with no errors.
Check if Intellij shows no problems under File > Project Structure > Problems. There are no problems.
I also saw the dependency tree with mvn dependency:tree -Dverbose. 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 ?

The best way to tell if everything is fine with your application is to have good tests.
However normally one doesn't exclude transitive dependencies from project's <dependency> libraries. Doing it can potentially break the dependency in a subtle and hard to notice way. It's usually safer to remove the whole <dependency>.
There are few scenario when one should use <exclude>:
Dealing with incompatible transitive dependencies between different libraries e.g. A requires library C-1.0 but library B requires library C-2.0 while C-1.0 and C-2.0 can't coexist on the classpath.
Having transitive dependencies already provided by system e.g. deploying to Tomcat with additional JARs in the TOMCAT_HOME/lib directory.
If you decide to exclude a dependency it's important that you check the final artifact because sometimes plugins do weird things e.g. there were versions of maven-assembly-plugin affected by a bug that resulted in different dependencies being resolved during shaded JAR creation than maven-dependency-plugin used for compilation.

New maven dependency version pulling pom, not jar into private nexus repo?

I'm upgrading some dependency versions I have in a java/maven/spring application, which is using our nexus repo as the central repository mirroring maven central.
I tried upgrading hibernate to it's newest version of 3.5.4-Final as listed:
Hibernate newest release stable version
And when I run maven install, I see in my nexus server that there is now 3.5.4-Final listed, but inside its directory there is only a pom.xml file for the project and none of it's associated JAR's.
When I inspect the POM, I can see it's packaging is listed as POM and not JAR.
Why is this, and how can I make maven take the jar packaged version of the library rather than just the POM?
EDIT - mvn install error message posted:
[ERROR] Failed to execute goal on project app: Could not resolve dependencies for project com.app:app:war:16.2.1-SNAPSHOT: Failure to find org.hibernate:hibernate:jar:3.5.4-Final in http://ssp-nexus1.mynexus-server.com:8081/nexus/content/groups/public was cached in the local repository, resolution will not be reattempted until the update interval of company.nexus.mirror has elapsed or updates are forced -> [Help 1]

As mentioned in the link you provided
Aggregator of the Hibernate Core modules.
So, the artifact you linked is effectively a pom which aggregates (as a multimodule) other Hibernate artefacts.
Instead, the hibernate-core artifact, as an example, can be found here, as a standard maven dependency (that is, a jar).
By default dependencies have type jar, so if you add the maven coordinates (GAV) for a dependency that is instead of type pom, maven will then look up for it as a jar. So that's why you are getting the error mentioned in your edit.
You should remove its dependency from your pom and only add the hibernate dependency you effectively need. As a rule of thumb, add the dependency you explicitly use in your code (as import statements, for instance) or your configuration files, and let then maven take care of the required transitive dependencies, given that they will be available on your company repository, obviously.
Update
Following your latest comments and feedback, here is a further explanation about why just changing the version of the existing Hibernate dependency you got to this issue:
The new 3.5.4-Final and the previous 3.2.7.ga version share the same groupId and artifactId on the Maven repository
However, the former has type pom (it's a pom file), while the latter has type jar (the default one)
So, the previously existing version was working fine and changing the version of the dependency you switched it from jar to pom, breaking the maven resolution (which was looking for a jar for a version which instead was a pom)
This mainly happened because you switched from a ga to a FINAL version. For a further explanation about the difference between these versions, you can check this SO question and this one
As a side note, I find a bit inconsistent that changing a version number also changes the dependency type, it might a point of debate, but if I were the Hibernate team, I would handle this version management differently.

Issues excluding transitive dependency of project reference from eclipse class path

I have several gradle projects in my eclipse workspace. For the sake of simplicity I'm only really interested in 2 of them, let's just use A and B for this.
So the problem I'm having is that Project A has an included dependency on JBoss, which pulls in javax validation-api 1.0.0.GA, and Project B has a dependency on javax validation-api 1.1.0.Final. Since Gradle itself resolves the conflict by using the newer library first, B is happy when built by gradle. But Eclipse itself includes errors which are very distracting while editing.
The correct version of the validation-api jar ends up in B's class path but the problem is that the Gradle IDE plugin changes the project(':A') dependency to a project reference, and Eclipse seems to give the project reference precedence over the external jar. So the old jar is preferred by extension.
I tried adding { exclude module: 'validation-api' } in B's build.gradle for the dependency on A which works according to the output of 'gradle dependencies', however since Eclipse just gets as far as making it a project reference, it won't exclude the jar and the problem remains.
Also per this question I tried adding { transitive = false } and the same thing happens. I don't think even the hack posed there would work for me since the .classpath contains a single reference to the Gradle container so there's nothing to remove.
I've managed to get around this by explicitly including a reference to the correct version of the jar from my gradle cache and then moving it above the Gradle Classpath Container so that eclipse sees that version first.
My question is: Is there a better/more generic way to do this? Preferably one that I can commit to source control without breaking other people's builds or requiring them to manually modify paths or properties somewhere? There is another project with what appears to be a similar issue so something I can fix in the build.gradle file would be awesome.
Worst case scenario, I could probably switch to IntelliJ if that behaves itself better than the Eclipse-Gradle integration?

These kind of transitive dependency issues are long-standing problem with Gradle Eclipse integration (both in STS tooling and also commandline generated .classpath metadata from Gradle's Eclipse plugin. The problem is the way that Eclipse computes transitive classpaths.
Only recently we found a reasonable solution to this problem. Actually there are now two solutions, one better than the other but depending on your situation you might want to use either of them.
The first solution is a bug fix that changes the classpath order of project dependencies so that they are no longer 'preferred' over jar dependencies PR-74. To get this fix you may need to install gradle tooling from a snapshot update site because the fix went in after 3.6.3.
This solution doesn't fix the real problem (you still have the 'wrong' stuff on the classpath) but just makes it less likely to cause real problem in your projects.
The second solution is to enable use of the 'Custom Tooling API model' PR-55 introduced in STS 3.6.3. This is a bit experimental and only works for recent version of Gradle, at least 1.12 but probably better to use 2.x. It also only works for projects that have 'Dependency management' enabled (if not enabled you are using the .classpath generated by Gradle's eclipse plugin which has the same 'broken' classpath issues as the STS tooling).
The 'custom tooling model' is really the better solution in principle as it fixes the way gradle classpath get mapped to eclipse projects so that project dependencies are no longer exported and each project gets its own classpath considering dependencies conflict resolution.
To enable this go to "Window >> Preferences >> Gradle" and enable checkbox "Use Custom Tooling Model".

Is there some way to clean the maven dependencies?

I am working in a Maven project which has about 250 jar dependencies. Approximately Four out of five dependecies are not direct dependencies, I mean, they are dependencies of our dependencies (i.e jasperreport has about 8 dependencies).
Also, I suspect that there are some jar which we don't need to the project because they were old dependencies of old tool that we needed in the past but they were replaced by others.
What I need is:
To detect what jars of my pom.xml are not needed by the
project.
A way of removing the indirect jars from my pom.xml.
*Note: I'd swear that some time ago I manage to the indirect jars were downloaded by the direct dependencias, but I can't find how.

You're after mvn dependency:analyze:
Analyzes the dependencies of this project and determines which are: used and declared; used and undeclared; unused and declared.
This will let you remove any dependency which is not directly used from your pom. The dependencies that are used will still bring in their transitive (indirect) dependencies, as required.

I'm not really sure if you need to remove some dependencies of any of your direct dependencies or just want to clean jars downloaded.
If your problem is the first one, you can use "exclude" for that dependencies -> http://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html
If it's the second one, just remove your .m2/repository content and rebuild again your project