How do I know which version of a pom dependency I should use if its version is not in the jar name. For example the jar commons-lang.jar, what version of the pom dependency should I use ?
Here are its search results on maven central repo - http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22net.sf.staccatocommons%22%20AND%20a%3A%22commons-lang%22
First, use the one from Apache.
Second, you have two options, the 2.x or 3.x branches; from searching mvnrepository.com:
2.6
<dependency>
<groupId>commons-lang</groupId>
<artifactId>commons-lang</artifactId>
<version>2.6</version>
</dependency>
3.1
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-lang3</artifactId>
<version>3.1</version>
</dependency>
If you're using Maven, you shouldn't have "just a jar", you should only know about POM dependencies.
(As of Feb 2014 it's up to 3.3.2, the 2.x series is still at 2.6. Note that you may use both in the same application because of their different packages.)
While the other answers are correct a very handy way to find out exact match for an unknown jar where all you have is the jar itself and it does not contain a useful manifest is to create a sha1 checksum of the jar and then do a checksum search on http://search.maven.org in the Advanced Search at the bottom or on your own instance of a Nexus repository server that downloaded the index of the Central Repository.
And btw your search on central was incorrect since it had the wrong groupId as part of it. Here is a corrected link:
http://search.maven.org/#search%7Cga%7C1%7C%22commons-lang%22
If you are migrating to Maven and just have a bunch of jars then you can try examining their META-INF/MANIFEST.MF files inside of those jars.
I've just opened commons-lang.jar and saw the following in its META-INF/MANIFEST.MF:
...
Implementation-Title: Commons Lang
Implementation-Vendor: The Apache Software Foundation
Implementation-Vendor-Id: org.apache
Implementation-Version: 2.4
...
So you can use Implementation-Version as your version in pom.xml:
<dependency>
<groupId>commons-lang</groupId>
<artifactId>commons-lang</artifactId>
<version>2.4</version>
</dependency>
Related
How to use the Liberty's distributedmap feature in a Java application?
Where I can find the required Maven dependencies (com.ibm.websphere.cache..)?
The Maven dependencies for WebSphere features like the DistributedMap are defined in the https://github.com/WASdev/ci.maven.tools repository and they are published on Maven central.
The following dependency loads all APIs:
<dependency>
<groupId>net.wasdev.maven.tools.targets</groupId>
<artifactId>liberty-apis</artifactId>
<version>${liberty.dependency.version}</version>
<scope>provided</scope>
<type>pom</type>
</dependency>
The Maven coordinates for the distributedMap API would be:
<dependency>
<groupId>com.ibm.websphere.appserver.api</groupId>
<artifactId>com.ibm.websphere.appserver.api.distributedMap</artifactId>
<version>2.0.68</version>
</dependency>
Each release of Liberty will have a different version, but that is from 22.0.0.9 the latest version as of this response. I found this by using search.maven.org and searching for distributedMap. This should work for other features APIs as well.
I have dependency in pom with groovy-all
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-all</artifactId>
<version>3.0.7</version>
<type>pom</type>
</dependency>
But if I check libs inside, I see 2.5.13 versions. How can I change all of this libs to 3.0.7? Of course I can add separately, but maybe is another option?
The versions are managed in the <dependencyManagement> section of the POM, either directly or by using a BOM (scope import).
If you want to update them, you need to look there.
You are importing Groovy 2.5.13 elsewhere likely as a transitive dependency and maven is deciding to use 2.5.13 instead of 3.0.7.
Look at the groovy 3.0.7 pom:
https://repo1.maven.org/maven2/org/codehaus/groovy/groovy-all/3.0.7/groovy-all-3.0.7.pom
It has no reference to 2.5.13.
I am running storm jar in a cluster ,where I configured hadoop,kafka,storm cluster
when I run the jar in local mode it works fine ,when I run it on storm cluster, I am finding respective error in Storm UI:
java.lang.NoSuchMethodError: org.apache.hadoop.security.authentication.util.KerberosUtil.hasKerberosTicket(Ljavax/security/auth/Subject;)Z at
org.apache.hadoop.security.UserGroupInformation.<init>(UserGroupInformation.java:666) at org.apache.hadoop.security.UserGroupInformation.loginUserFromSubject(UserGroupInformation.java:861) at
org.apache.hadoop.security.UserGroupInformation.getLoginUser(UserGroupInformation.java:820)
pom.xml
Click here to view POM file
After some google I found I found we have add hadoop auth jar.even after i finding same error
I think you're packaging an old Hadoop jar.
Take a look at the storm-hdfs POM https://github.com/apache/storm/blob/v1.0.6/external/storm-hdfs/pom.xml. When you use the Shade plugin, the jar you end up with will contain all your dependencies, including transitive ones brought in through direct dependencies. Storm-hdfs declares a dependency on a list of Hadoop jars. You need to make sure that you're declaring the same list of Hadoop jars in your POM if you want to use a different version of Hadoop from the default.
Specifically what's happening is that you haven't declared hadoop-auth in your POM, so your POM gets packaged with the default version of that jar (2.6.1). Since that version of hadoop-auth is incompatible with the other Hadoop jars (which are 2.9.1), you get an exception at runtime.
You should either exclude all Hadoop jars from your import of storm-hdfs and then put the jars you want to use in Storm's lib directory, or add the right versions of the Hadoop jars to your dependency list in your POM.
Edit:
I think I found your issue. You haven't set the scope of storm-core to provided. Since storm-core depends on hadoop-auth, and you haven't declared it explicitly, Maven will try to guess which version of hadoop-auth you need based on where the dependency appears in the tree. Since hadoop-auth appears as 2.9.1 through some of your Hadoop dependencies, but 2.6.1 through storm-core, you happen to get 2.6.1 put in your jar.
If you want to avoid this kind of thing in the future, you should use Maven's dependencyManagement block https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management.
i.e. you should add something like the following to your pom, and then remove the exclusions of hadoop jars.
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.apache.hadoop</groupId>
<artifactId>hadoop-client</artifactId>
<version>${hadoop.version}</version>
</dependency>
<dependency>
<groupId>org.apache.hadoop</groupId>
<artifactId>hadoop-auth</artifactId>
<version>${hadoop.version}</version>
</dependency>
<dependency>
<groupId>org.apache.hadoop</groupId>
<artifactId>hadoop-common</artifactId>
<version>${hadoop.version}</version>
</dependency>
</dependencies>
</dependencyManagement>
I am trying to automate process of changing version of a product that has ServiceMix (FuseESB) as an integration module.
Changing the version in each POM is quite easy with the Maven versions plugin:
mvn versions:set -DnewVersion=NEW_VERSION -DgenerateBackupPoms=false
However, I am now struggling with updating version in dependencies that are other modules of this product. Particularly, in many Service Units' POM files there are dependencies like these (where OLD_VERSION is the same, older version number):
<dependencies>
<dependency>
<groupId>com.company.department.product.module1</groupId>
<artifactId>artifact1</artifactId>
<version>OLD_VERSION</version>
</dependency>
<dependency>
<groupId>com.company.department.product.module1</groupId>
<artifactId>artifact2</artifactId>
<version>OLD_VERSION</version>
</dependency>
<dependency>
<groupId>com.company.department.product.module2</groupId>
<artifactId>artifact3</artifactId>
<version>OLD_VERSION</version>
</dependency>
</dependencies>
And I would like to set the version number in those dependencies to "NEW_VERSION".
Do you guys have any ideas?
Just found very simple solution for this - replace dependencies' version with ${project.version} - works for me because in my project the dependencies have the same version as the project itself (they are all artifacts of the same product).
I have a maven plugin which is using hsqldb 1.8.0.10. In my pom.xml from the plugin, it is declared like this:
<dependency>
<groupId>hsqldb</groupId>
<artifactId>hsqldb</artifactId>
<version>1.8.0.10</version>
</dependency>
But if I run that plugin from another maven project, and that project has a newer version of hsqldb (for instance 1.9.0), how can I configure my plugin that he will use the newest version of hsqldb, without changing it's pom.xml?
And is it possible to do this the other way around as well? If my other maven project uses hsqldb 1.7.0 (for instance), that he will use the 1.8.0.10 version which is specified in the maven plugin itself?
I hope someone can answer my question.
Kind regards,
Walle
Your main question is possible, but it might not work properly if the plugin doesn't work with the newer code for any reason.
A plugin can have it's own personal dependencies section, and will use standard Maven dependency resolution, choosing the highest version requested. So, you can do
<plugin>
<groupId>some.group.id</groupId>
<artifactId>some.artifact.id</artifactId>
<version>someversion</version>
<dependencies>
<dependency>
<groupId>hsqldb</groupId>
<artifactId>hsqldb</artifactId>
<version>1.9.0</version>
</dependency>
</dependencies>
</plugin>
I don't think going the other way around is possible, though.
use properties place holder for the version, say ${hsqldb.version} then declare in different project pom the version you want to put in it