CODEWITHSUNDEEP
javamavenjarpom.xmlnexus
Adam Bronfin
Adam Bronfin

Reputation: 1299

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]

Upvotes: 1

Views: 3069

Answers (1)

A_Di-Matteo
A_Di-Matteo

Reputation: 27862

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.

Upvotes: 4

Related Questions