To resolve issue of dependencies, maven is one of the solution. But maven does not include latest version.
Question:
1) Is there any solution for solving dependency issue other than maven?
2) How can i get latest version in maven?
Thanks to all
I guess you want to include a latest version of a dependency, If that is the case you can use,
Maven tag
<version>LATEST</version>
or
<version>[1.0.0,)</version>
this will get the highest dependency version available grater than 1.0.0.
And note <version>LATEST</version> does not work for maven versions 3.x.
If we are talking about transitive dependencies maven uses dependency which is placed nearest to root.
For example:
A depends on B, B depends on C(v 1.1)
A directly depends on C(1.0).
In that situation, C(1.0) will be included in the application classpath.
More info here and here.
Hope, it will help.
Related
I have install maven and JDK and tried to create maven project and add some dependencies, as you can see in the screenshot but the dependency is not downloading so I can not import. can you help.
That's because you are using dependencyManagement, where you only specify dependency meta-information, but not the actual dependencies.
More details about managing dependencies via Maven you can find here:
maven dependency mechanism
maven dependency management
Change the version of guice to 4.1.0
What it seems like there is no 4.1
https://mvnrepository.com/artifact/com.google.inject/guice
I have a bit of a thorny maven dependency problem. A plugin in a parent pom.xml requires guava v10 and a dependency in the module I'm trying to build requires guava v18. Not exactly sure how to proceed as both are needed but maven resolves in favor of v10, which crashes the dependency at runtime. I tried skipping the plugin as outlined here (although I'm not sure if it's a good idea), but that didn't help. How do I dig my way out of this?
Please reference to this post and try to use exclusion to exclude the guava version you don't want to use
I want to build a library as a Maven project that depends on some Spring libraries (version 3).
I want this to be used in projects that are also using Spring 3 - but I don't want the versions to clash, otherwise we'll have both versions of the spring libraries on the classpath.
I want to get the minor version for my library pom.xml from the enclosing project.
My question is: Is it possible to have a Maven library that inherits a dependency minor version from the enclosing project?
I believe you are worrying about something that is not going to happen. Conflicting versions between different dependencies on the same artifact will be resolved by a process called dependency mediation, and Maven will not pull in multiple versions of the same artifact onto the same classpath. E.g., if you make your library your-group:your-library:1.0 depend on org.springframework:spring-context:3.2.4.RELEASE, and my project my-group:my-artifact:1.0 depends on both org.springframework:spring-context:3.1.4.RELEASE and your-group:your-library:1.0, then Maven will only pull version 3.1.4 of spring-context into my build, not both 3.1.4 and 3.2.4. If your library also depends spring-beans:3.2.4 and there happens to exist some incompatibility between spring-context:3.1.4 and spring-beans:3.2.4, then you can consider it the responsibility of my project to add spring-beans as a dependency and explicitly override its version to 3.1.4 in my-artifact's POM.
That being said, you can sort of accomplish what your question is directly asking by using version ranges:
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>[3.0.0.RELEASE,3.2.16.RELEASE]</version>
</dependency>
This will effectively tell projects depending on your library that your library is okay with any existing 3.X version of spring-context, but version ranges have their own set of rules during dependency mediation that can possibly be unfriendly and obscure, and they won't link up between different artifacts either, so I would recommend just sticking with a regular version number in your case.
Not really, no.
Are you happy to declare variables in the parent pom for this purpose? If not, then you'll have to create variables in your project pom or in a new parent pom that inherits from the enclosing project. ${project.version} and ${project.parent.version} aren't built from other variables and you can't compose/decompose them; you would need to duplicate those values into other variables and build your version string from those variables.
And even when you do that, maven will complain about version not being a constant.
The normal pattern in this case is to completely ignore the parent version and maintain your project's version independently: just because your project uses Spring 3 doesn't mean that it shouldn't start at version 1. You can manually track the parent version if you want to. Since your project is not part of the parent project, the maven convention of omitting ${project.version} and inheriting it from the parent project is probably not appropriate.
I have configured a Maven build with dependencies to Eclipse plugins, which are collected through a Nexus proxy which points to Maven Central. For example, I need version 2.7.0 of the org.eclipse.emf.common jar in my build. So I added a dependency in the dependency management section of the parent pom with a version like this:
<dependency>
<groupId>org.eclipse.emf</groupId>
<artifactId>org.eclipse.emf.common</artifactId>
<version>2.7.0</version>
</dependency>
However, Eclipse plugins usually suffix their version numbers with date and build number, so the plugin is actually org.eclipse.emf.common_2.7.0-v20110520-1406.jar - and it looks as if Maven fails because it believes that a 2.7.0-something is a smaller version than 2.7.0. When put the full version number in my pom, the builds works.
Now my question is: is there a good and maybe agreed upon way to specify a version 2.7.0 or higher, no matter if there are date or build number suffixed to it?
You can check all available versions using search on maven central:
http://search.maven.org/#search%7Cga%7C1%7Corg.eclipse.emf.common
Specify dependency exists only with date and build number version, so you have to use full version... But there is another dependency (with different group id) that has exact 2.7.0 version.
Just go through all availables artifacts on search.maven.org and pick what you need.
I have a strange situation. In jar A, I explicitly bring in version 1.3 of commons-dbcp. In jar B, I have a dependency on jar A. However, when I bring in the jar A dependency in jar B, my maven dependency hierarchy shows that jar B is now using 1.4. If I remove that dependency, commons-dbcp is gone from my maven dependency hierarchy so I feel certain it's not being pulled in elsewhere. And when I'm in jar A's maven dependency hierarchy, it only shows 1.3.
Does anyone have any idea why this might be happening?
Maven automatically determines the version to bring in for transitive dependencies. You may have more than one dependency on commons-dbcp (perhaps you're test wouldn't show it if they are in different scope). Use the Maven dependency plugin via mvn dependency:tree to see the other dependencies.