I specify wicket version 1.5-RC7 in my pom.xml. When I do a mvn install it complains about: The following artifacts could not be resolved: org.apache.wicket:wicket:jar:1.5-RC7, javax.transaction:jta:jar:1.0.1B. So I try searching for the javax.transaction.jta-1.0.1B.jar on mvnrepository.com, and I am able to find it. Why does maven tell me it can't resolve avax.transaction:jta:jar:1.0.1B?
My pom.xml:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
…
<repositories>
<repository>
<id>mvnrepository</id>
<url>http://repo1.maven.org/maven2</url>
</repository>
</repositories>
<dependencies>
<!-- WICKET DEPENDENCIES -->
<dependency>
<groupId>org.apache.wicket</groupId>
<artifactId>wicket</artifactId>
<version>${wicket.version}</version>
</dependency>
<dependency>
<groupId>org.apache.wicket</groupId>
<artifactId>wicket-spring</artifactId>
<version>${wicket.version}</version>
</dependency>
<dependency>
<groupId>org.apache.wicket</groupId>
<artifactId>wicket-extensions</artifactId>
<version>${wicket.version}</version>
</dependency>
…
</dependencies>
</build>
<properties>
<wicket.version>1.5-RC7</wicket.version>
...
</properties>
</project>
First, http://repo1.maven.org/maven2 is the default one that Maven will lookup. You don't need to declare it again.
Can you check, when you build, which server your Maven is trying to connect? You should see something like Downloading: http://whatever.com/path/to/dependencies.pom.
I have just checked in maven central repo, there is no org.apache.wicket:wicket:1.5-RC7. You have better to check if you have declared the correct dependency
For JTA, it is a bit tricky. For quite some Java spec JARs, because of licensing issue, the actual JAR is not available in the public central Maven repo. If you look at http://search.maven.org/#artifactdetails|javax.transaction|jta|1.0.1B|jar , you will see it only contains POM, but not the JAR.
There are some ways to solve:
If you have a Maven repo in your own company, consider getting the JAR from Sun/Oracle, and deploy it yourself
For JTA spec itself, JAR is available for newer version (1.1) . Check if it is fine for you to use to latter spec
Switch to use Geromino spec. It should be compatible. http://search.maven.org/#search|gav|1|g%3A%22geronimo-spec%22%20AND%20a%3A%22geronimo-spec-jta%22
Edit
I have missed the wicket 1.5-RC7 in my previous search. Sorry. After looking into the POM, it seems that it is not a JAR POM. org.apache.wicket:wicket:1.5-RC7 is of type POM, in which declares dependency to wicket-core artifact.
You have two ways to do:
Change your dependency to point to wicket-core (and maybe other wicket modules) instead of wicket.
Change your dependency declaration to have <type>pom</type> (because default is jar)
I am not familiar with Wicket, but I believe method 1 is preferred.
Check your ~/.m2/settings.xml, I'm guessing you have an internal company (Nexus) repo mirror/proxy setting avoiding you fetching from internet -- and this mirror is stale.
If this is the case there are two common way to fix it: fix your internal Nexus repo so it's up to date, or bypass the Nexus repo so you fetch from the internet
I had faced this issue just now and resolved it. I have seen lot of questions in stack overflow related to this . Since my resolution was slightly different I am posting this answer. .
Issue :-Failed to execute goal on project Apigee-Edge-deploy-plugin: Could not resolve dependencies for project io.apigee.build-tools.enterprise4g:Apigee-Edge-deploy-plugin:maven-plugin:1.0.0: The following artifacts could not be resolved:
Root Cause:- The Repo had the dependency jars mentioned in the project. But the dependencies in turn had other dependencies which was not present in the repo and caused this issue. I added exclusion to the dependency and it worked.
eg:-
<dependency>
<groupId>org.apache.axis2</groupId>
<artifactId>axis2-metadata</artifactId>
<version>1.3</version>
<type>jar</type>
<scope>compile</scope>
<exclusions>
<exclusion>
<artifactId>woden</artifactId>
<groupId>org.apache.woden</groupId>
</exclusion>
</exclusions>
</dependency>
Reference:-
Also checkout the very good article on maven dependencies and exclusion
Related
I'm trying to construct a codebase where subsystems can be developed as maven modules, without the importing POM needing to concern itself with the internal structure of the maven module.
The "importing" pom
<project>
<artifactId>application</artifactId>
<packaging>jar</packaging>
<dependencies>
<dependency>
<artifactId>submodule-1</artifactId>
</dependency>
</dependencies>
</project>
The "imported" pom
<project>
<artifactId>submodule-1</artifactId>
<packaging>pom</packaging>
<modules>
<module>api</module>
<module>implementation</module>
</modules>
<dependencies>
<dependency>
<artifactId>api</artifactId>
</dependency>
<dependency>
<artifactId>implementation</artifactId>
</dependency>
</dependencies>
</project>
This does seem to work, at least partially; the generated JARs appear to be on the classpath during mvn package. IntelliJ shows the application has a dependency on submodule-1 and transitively on api and implementation. However, mvn dependency:tree fails while building submodule-1 saying
Could not resolve dependencies for project submodule-1:pom:1.0.0-SNAPSHOT: Could not find artifact api:jar:1.0.0-SNAPSHOT
I'm trying to determine if this is a valid pattern, that of having packaging of pom, with defined dependencies which are also defined modules in the POM.
Have I stumbled upon a working-but-not-supported edge case, or is the dependency plugin broken in some way, or I'm breaking it in some way, or something else?
I am trying to migrate a java application to maven. There are some dependencies which have been provided as jar files so far. One of these dependencies is jung2, which is available from the maven repository: mvnrepository.com
I need all of the provided modules and I do not understand how to declare this dependecy correctly in my pom.xml such that all corresponding jar files are downloaded and the classes are available at compile time.
This is what my pom.xml file looks like right now:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>groupId</groupId>
<artifactId>myProject</artifactId>
<version>1.0-SNAPSHOT</version>
<dependencyManagement>
<dependencies>
<!-- https://mvnrepository.com/artifact/net.sf.jung/jung2 -->
<dependency>
<groupId>net.sf.jung</groupId>
<artifactId>jung2</artifactId>
<version>2.0.1</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
</project>
I also tried leaving out <scope>import</scope> and put the dependency into the dependencies section. When executing mvn compile or mvn package, error message occur that the corresponding packages do not exist.
If I additionally add a dependency inside dependencies but outside of dependencyManagement, e.g.
<dependencies>
<dependency>
<groupId>net.sf.jung</groupId>
<artifactId>jung2</artifactId>
</dependency>
I receive an error about missing version. But as far as I understood, this should not be necessary due to dependencyManagement? If I also add <version>2.0.1</version>, then I get the following error message:
Failure to find net.sf.jung:jung2:jar:2.0.1
The dependencyManagement tag is used generally when you have a multi module project in maven (where you will have parent-child relationship).
If you specify any dependencies within the dependencyManagement tag, it would NOT actually download the dependencies.
Putting the dependency within this tag simply means that this dependency is available (to download / to use) for the child pom. The child pom will have to explicitly provide the groupId and the artifactId co-ordinates to download and use the jar to compile its classes.
If you just have a single module project (looks like yours is a single module project) then you can fix this issue by not using the dependencyManagement tag.
Simply put your jars in the dependencies tag.
For ex:
<dependencies>
<dependency>
<groupId>com.abc</groupId>
<artifactId>def</artifactId>
<version>1.0.0</version>
<type>pom</type> // This will now download the pom and its associated transitive dependent jars
</dependency>
<dependency>
<groupId>com.pqr</groupId>
<artifactId>xyz</artifactId>
<version>1.0.0</version>
<type>pom</type> // This will now download the pom and its associated transitive dependent jars
</dependency>
</dependencies>
Like I said before, the dependencyManagement tag will mostly make sense to use if you have a multi-module project, which isn't your case.
i am in a situation to modify all the dependency management versions manually...
<dependencymanagement>
<dependencies>
<dependency>
<groupId>group-a</groupId>
<artifactId>artifact-a</artifactId>
<version>1.0</version>
</dependency>
<dependency>
<groupId>group-a</groupId>
<artifactId>artifact-a</artifactId>
<version>1.0</version>
</dependency>
</dependencies>
</dependencymanagement>
i have more than 100 dependencies in the management which are not third party jars, all are project jars....
previously we have all the same versions,so we don't have any issues to modify....
now we introduced different versions for each module, for each and every time modifying the dependency management manually is some what difficulty...is there any easiest way to update by using the commands or any plugins.
You could use the Versions Maven Plugin which allows you to execute goals in order to handle versions, check the list here.
If you have 100-odd dependencies as you have mentioned, you should be using a repository manager like nexus or artifactory. Once you deploy your dependencies to the repository manager, then what #patric-lc suggests will work.
I am referencing a repository in my POM.xml to add the ojdbc.jar to my project but Maven (I use the STS plugin) keeps telling me it can't find the jar.
I am showing below my repositories and jar dependency as defined in my POM.xml.
Anyone has an idea as to why the jar can't be found? Is my POM.xml not setup properly?
Note the vaadin repo works fine as the vaadin jars are correctly added to my project.
<repositories>
<repository>
<id>myrepo</id>
<url>http://mvnrepository.com/</url>
</repository>
<repository>
<id>vaadin-addons</id>
<url>http://maven.vaadin.com/vaadin-addons</url>
</repository>
</repositories>
and here is the dependency setup as defined at http://mvnrepository.com/artifact/ojdbc/ojdbc/14:
<dependencies>
<dependency>
<groupId>ojdbc</groupId>
<artifactId>ojdbc</artifactId>
<version>14</version>
</dependency>
</dependencies>
Anyone has an idea as to why the jar can't be found?
The jar can't be found due to license constraints.
Is my POM.xml not setup properly?
No it isn't, but adding to your pom the dependency:
<dependency>
<groupId>ojdbc</groupId>
<artifactId>ojdbc</artifactId>
<version>14</version>
</dependency>
you are able to download only the ojdbc14 pom because it has not a license limitation about distribution.
In order to make the above dependency works the jar has to be manually installed into your local Maven repository, without violating the license, by running:
mvn install:install-file -Dfile={Path_to_your_ojdbc.jar} -DgroupId=ojdbc
-DartifactId=ojdbc -Dversion=14 -Dpackaging=jar
eventually changing to the appropriate version number in -Dversion attribute, as correctly suggested by user1570577.
To use Oracle jdbc(OJDBC) driver with Maven, you can download the jar to your local machine and install it manually into your Maven local repository.
After downloading the jar install using the following command :
mvn install:install-file -Dfile={Path_to_your_ojdbc.jar} -DgroupId=com.oracle
-DartifactId=ojdbc -Dversion=14 -Dpackaging=jar . If the version is less than 14 change the appropriate version number in -Dversion attribute
Now you can set the dependency details in the pom file :
<dependencies>
<dependency>
<groupId>com.oracle</groupId>
<artifactId>ojdbc</artifactId>
<version>14</version>
</dependency>
</dependencies>
Oracle now has a maven repository: maven.oracle.com
See https://blogs.oracle.com/WebLogicServer/entry/weblogic_server_and_the_oracle
I have a maven build which generates some duplicated JARs in classpath.
Here are some examples:
groupId: javax.xml.stream
artifactId: stax
version: 1.0-2
groupId: stax
artifactId: stax
version: 1.0.1
groupId: jboss
artifactId: javassist
version: 3.7.0 GA
groupId: javassist
artifactId: javassist
version: 3.9.0 GA
These JARs are not imported directly from my project, they are transitive dependencies. Since the groupId and artifactId of the different versions does not matches, maven thinks that they are independent.
I can hunt down (may be using some tool for that) these duplicates and exclude them explicitly in pom.xml. However I don't want to manually hunt them down and exclude them, because this defeats the automatic dependency managing from maven and is a nightmare when some dependency is upgraded and the transistive dependencies mismatches again. There exist some way to make maven smarter and fix this automatically?
Answering that. I found no way to make maven smarter and had to hunt down and manually exclude every duplicated dependency. Switching the repositories to use a set of repositories that does not messes up one to the other helps too, but this is not always possible and can have side-effects of breaking some dependencies.
There is a workaround using the relocation mechanism, though it may only work in certain environments.
In short relocation allows you to "redirect" all dependencies from e.g. javax.xml.stream:stax to stax:stax. The problem is, adding a relocation is nothing you can do in your own project. You have to add a new version to the original groupId and artifactId containing the relocation information. If you have a private (e.g. corporate) Maven repository you can add it there or if there are only few developers the developers local repository can be used. In other cases you are probably out of luck with this solution.
Now the details:
Create a new Maven project with a pom.xml like this:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<!-- Coordinates of the artifact you want to replace -->
<groupId>javax.xml.stream</groupId>
<artifactId>stax</artifactId>
<!-- Some dummy version that would never be released -->
<version>relocate-to-stax</version>
<distributionManagement>
<relocation>
<!-- Coordinates of the new artifact -->
<groupId>stax</groupId>
<!-- artifactId stays the same → no need to specify again -->
</relocation>
</distributionManagement>
</project>
Add this to your repository (e.g. using mvn install).
In your project add this new version for the artifact to the dependencyManagement section:
<project>
<!-- ... -->
<dependencyManagement>
<dependencies>
<dependency>
<groupId>javax.xml.stream</groupId>
<artifactId>stax</artifactId>
<version>relocate-to-stax</version>
</dependency>
</dependencies>
</dependencyManagement>
</project>
With this, all dependencies to javax.xml.stream:stax will use the "version" relocate-to-stax which will relocate to stax:stax:relocate-to-stax. The only thing left to do is to add the desired version of the destination artifact to the dependencyManagement:
<project>
<!-- ... -->
<dependencyManagement>
<dependencies>
<!-- ... -->
<dependency>
<groupId>stax</groupId>
<artifactId>stax</artifactId>
<version>1.0.1</version>
</dependency>
</dependencies>
</dependencyManagement>
</project>