How to stop Maven from downloading all historical versions of aws-java-sdk? - maven

I am using Maven to download aws-java-sdk dependency for version 1.11.23, though in Maven repository I find all historical versions till most recent ones; i.e. aws-java-sdk-sqs downloaded versions (1.9.0 to 1.11.642) any idea why is that and how can I limit to only the version specified for aws-java-sdk artifact?

This "dependency loop" is a problem with some older versions of aws-lambda-java-events, which is probably a dependency of your dependency.
Try updating or your dependencies to the latest, or overriding aws-lambda-java-events to at least 2.2.7:
<dependency>
<groupId>com.amazonaws</groupId>
<artifactId>aws-lambda-java-events</artifactId>
<version>2.2.7</version>
</dependency>

For me, After specifying the BOM of AWS SDK in the dependencyManagement section & the version I would like to use, The historical downloads were stopped. Below are my dependencies.
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.amazonaws</groupId>
<artifactId>aws-java-sdk-bom</artifactId>
<version>1.10.6</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>com.amazonaws</groupId>
<artifactId>aws-java-sdk-s3</artifactId>
</dependency>
<dependency>
<groupId>com.amazonaws</groupId>
<artifactId>aws-java-sdk-dynamodb</artifactId>
</dependency>
<dependency>
<groupId>com.amazonaws</groupId>
<artifactId>aws-lambda-java-core</artifactId>
<version>1.0.0</version>
</dependency>
<dependency>
<groupId>com.amazonaws</groupId>
<artifactId>aws-lambda-java-events</artifactId>
<version>1.0.0</version>
</dependency>
</dependencies>

I created a project (with Maven 3.5.4) with just:
<project ... >
....
<dependencies>
<dependency>
<groupId>com.amazonaws</groupId>
<artifactId>aws-java-sdk</artifactId>
<version>1.11.23</version>
</dependency>
</dependencies>
</project>
All of ~/.m2/repository/com/amazonaws/* (as declared in aws-java-sdks POM) contain just the sub-directory /1.11.23.
UPDATE
To exclude dependencies of your dependencies see Introduction to the Dependency Mechanism, Transitive Dependencies:
Excluded dependencies - If project X depends on project Y, and project Y depends on project Z, the owner of project X can explicitly exclude project Z as a dependency, using the "exclusion" element.

Related

why version dependency needs to be specified?

I have pom.xml like,
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.eclipse.microprofile</groupId>
<artifactId>microprofile</artifactId>
<version>1.3</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>7.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.enterprise</groupId>
<artifactId>cdi-api</artifactId>
<version>1.2</version>
<scope>provided</scope>
</dependency>
</dependencies>
I am unable to understand why am I required to specify version on cdi-api under dependencies when it is already defined in microprofile (inside dependencymanagement).
This pom isn't a standard bom that would define version of the dependencies but must be used like a standard dependency: https://github.com/eclipse/microprofile-bom
This style of BOM does not go in a
dependencyManagement section, using import
scope, and you cannot add dependencies declared in the BOM without
version elements as is typically done with that style of BOM.
You actually need to depend on that pom:
<dependency>
<groupId>org.eclipse.microprofile</groupId>
<artifactId>microprofile</artifactId>
<type>pom</type>
</dependency>
Don't forget to add the type pom and either specify the version or reference this version in your dependency management with type pom if you want everything to work. glytching forgot the type pom, that's why this doesn't work.
The org.eclipse.microprofile:microprofile artifact declares a dependency on javax.enterprise:cdi-api so if you declare org.eclipse.microprofile:microprofile as a dependency in your POM then javax.enterprise:cdi-api will be provided transitively.
In the example in your question you declared org.eclipse.microprofile:microprofile in the <dependencyManagement> section, this section consolidates management of the version, scope, and exclusions for each dependency but in order to use that dependency in your project you must include it in the <dependency> section.
So, if you add this to your <dependency> section ...
<dependency>
<groupId>org.eclipse.microprofile</groupId>
<artifactId>microprofile</artifactId>
</dependency>
... then org.eclipse.microprofile:microprofile will be included in your project and hence javax.enterprise:cdi-api will be included transitively and you won't have to declare it explicitly.

How to properly use org.wildly wildfly-server dependency in pom.xml?

I'm trying to setup an easy to maintain Maven config for my current project. The EAR with two EJB und one WAR module will be deployed to JBoss Wildfly v8.2.0.Final and I want to ease the build process by using the following dependency in my pom.xml:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.wildfly</groupId>
<artifactId>wildfly-server</artifactId>
<version>8.2.0.Final</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
I've thought this would allow me to use all the provided modules like EJB, CDI and the others without explicitly naming them in my modules pom.xml. But that doesn't seem to be the case. I had to add the following dependencies manually... is this really needed?
<dependencies>
<dependency>
<groupId>org.jboss.spec.javax.interceptor</groupId>
<artifactId>jboss-interceptors-api_1.2_spec</artifactId>
</dependency>
<dependency>
<groupId>org.jboss.spec.javax.faces</groupId>
<artifactId>jboss-jsf-api_2.2_spec</artifactId>
</dependency>
<dependency>
<groupId>org.jboss.spec.javax.servlet</groupId>
<artifactId>jboss-servlet-api_3.1_spec</artifactId>
</dependency>
<dependency>
<groupId>org.jboss.spec.javax.ejb</groupId>
<artifactId>jboss-ejb-api_3.2_spec</artifactId>
</dependency>
<dependency>
<groupId>org.jboss.spec.javax.el</groupId>
<artifactId>jboss-el-api_3.0_spec</artifactId>
</dependency>
<dependency>
<groupId>org.jboss.spec.javax.transaction</groupId>
<artifactId>jboss-transaction-api_1.2_spec</artifactId>
</dependency>
</dependencies>
Or is this the way it should be? How to use jars from Wildfly correctly in Maven? is not clear at this point.
What are you looking for is not usage of wildfly-server, which is artifact that is entry point for booting the server and not needed by application developers in general.
You are looking for boms that go with WildFly.
you can find all different kind of boms here https://github.com/wildfly/boms
to include all dependencies you could use
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.wildfly.bom</groupId>
<artifactId>jboss-javaee-7.0-with-all</artifactId>
<version>8.2.1.Final</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
If you only need the Java EE API then just use the Java EE API dependency. However, you may hit issues during unit and low-level integration testing.
So the approach I use is the glassfish-embedded-all dependency which is at least the reference implementation and bundles everything up nicely for me. However, I only recommend it only for testing and needs to be before the javaee dependency.
My core dependencies in my parent pom usually looks like this
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.glassfish.main.extras</groupId>
<artifactId>glassfish-embedded-all</artifactId>
<version>4.1</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>7.0</version>
<scope>provided</scope>
</dependency>
</dependencies>
By using this approach I get the best of both worlds. I can run low level integration tests against a reference implementation while I ensure that when it compiles it only compiles against the standard API.
It is important you keep the glassfish-embedded-all before the API dependency otherwise the classloader will pick the API dependency first which isn't want you want during testing.

Why does my project always try to download the latest spring-beans 3.2.*.RELEASE artefact

I have a spring MVC web application that has the following spring dependencies:
spring-aop-3.2.1.RELEASE
spring-beans-3.2.1.RELEASE
spring-context-support-3.2.1.RELEASE
spring-context-3.2.1.RELEASE
spring-core-3.2.1.RELEASE
spring-expression-3.2.1.RELEASE
spring-jdbc-3.2.1.RELEASE
spring-jms-3.2.1.RELEASE
spring-orm-3.2.1.RELEASE
spring-test-3.2.1.RELEASE
spring-tx-3.2.1.RELEASE
spring-web-3.2.1.RELEASE
spring-webmvc-3.2.1.RELEASE
spring-aspects-3.2.1.RELEASE
spring-spring-security-core-3.2.0.RELEASE
spring-security-web-3.2.0.RELEASE
spring-security-config-3.2.0.RELEASE
spring-security-taglibs-3.2.0.RELEASE
My question is that when i build using mvn clean install does it try and download spring-beans-3.2.10.RELEASE. I am assuming one of my dependencies is dragging it in but not sure which.
Any help would be greatly appreciated.
Thanks in advance.
You can define your dependencies in the <dependencyManagement> section of POM. The versions that you define in <dependencyManagement> will apply not only to the dependencies that you mention in the top-level <dependencies> section, but also to their transitive dependencies.
For example:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
<version>3.2.1.RELEASE</version>
</dependency>
...
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
</dependency>
...
</dependencies>
These fragments will make sure that Maven uses only version 3.2.1.RELEASE. (Note that there are no <version> in the second section.)
If you still want to find out where that dependency comes from, and if you use Eclipse, open your pom.xml and have a look at the Dependency Hierarchy tab. If necessary, you can double-click on dependencies there: it will open the dependency's own pom.xml where you can research transitive dependencies further.
You can solve your proble in the following way:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-framework-bom</artifactId>
<version>4.1.0.BUILD-SNAPSHOT</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-web</artifactId>
</dependency>
<dependencies>
and then you can manage your dependency without worry of single version number. In this way all spring dependencies will have the same 4.1.0.BUILD-SNAPSHOT version

Resolve maven transitive dependency conflict

My project depends on a thirdparty library, the dependency is defined in my POM like this:
<dependency>
<groupId>thirdparty</groupId>
<artifactId>main</artifactId>
<version>1.0.0-SNAPSHOT</version>
</dependency>
This thirdparty main library in turn depends on other two libraries, here's a part of dependency management defined in its pom:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>thirdparty</groupId>
<artifactId>x</artifactId>
<version>1.0.0</version>
</dependency>
<dependency>
<groupId>thirdparty</groupId>
<artifactId>y</artifactId>
<version>1.0.0</version>
</dependency>
...
Now the thirdparty x library has a dependency on y defined in its pom like this:
<dependency>
<groupId>thirdparty</groupId>
<artifactId>y</artifactId>
<version>1.0.0-SNAPSHOT</version>
</dependency>
Note the snapshot version! This looks like a problem in thirdparty poms, but I have no control over it.
The interesting thing though is that if you try to maven build the main thirdparty project it uses (resolves and installs to local repo) the correct thirdparty:y:1.0.0 version of artifact. But when I'm building my original project it tries to resolve the snapshot version of thirdparty:y.
My questions are:
Why does this happen? I was sure that maven should choose the artifact version that is found closest to the project root, which would be 1.0.0 in my case.
Is there any way to fix this problem without adding explicit dependencies to thirdparty:y:1.0.0 to my project's pom?
First of all make sure you realy need the snapshot version. There should normaly be a released version (without -SNAPSHOT).
if you do need it, this should do the trick:
<properties>
<dependeny.main.version>1.0.0-SNAPSHOT</dependeny.main.version>
<dependeny.x.version>1.0.0</dependeny.x.version>
<dependeny.y.version>1.0.0</dependeny.y.version>
<properties>
<dependencies>
...
<dependency>
<groupId>thirdparty</groupId>
<artifactId>main</artifactId>
</dependency>
<dependency>
<groupId>thirdparty</groupId>
<artifactId>x</artifactId>
</dependency>
<dependency>
<groupId>thirdparty</groupId>
<artifactId>y</artifactId>
</dependency>
...
</dependencies>
<dependencyManagement>
<dependencies>
...
<dependency>
<groupId>thirdparty</groupId>
<artifactId>main</artifactId>
<version>${dependeny.main.version}</version>
<exclusions>
<exclusion>
<groupId>thirdparty</groupId>
<artifactId>x</artifactId>
</exclusion>
<exclusion>
<groupId>thirdparty</groupId>
<artifactId>y</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>thirdparty</groupId>
<artifactId>x</artifactId>
<version>${dependeny.x.version}</version>
<exclusions>
<exclusion>
<groupId>thirdparty</groupId>
<artifactId>y</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>thirdparty</groupId>
<artifactId>y</artifactId>
<version>${dependeny.y.version}</version>
</dependency>
...
</dependencies>
</dependencyManagement>
I hope this helps you out.

slf4j-log4j12 not packaged by maven with "runtime" scope

I have a project managed by maven with slf4j-api-1.5.8 and log4j-1.2.14 dependencies.
At runtime, slf4j needs slf4j-log4j12-1.5.8.jar to "bridge" output to log4j.
So in pom.xml , I add this dependency :
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.5.8</version>
<type>jar</type>
<scope>runtime</scope>
</dependency>
</dependencies>
</dependencyManagement>
After building (war:war) , log4j-1.2.14.jar and slf4j-api-1.5.8.jar are both added to WEB-INF/lib directory , but I cannot find slf4j-log4j12-1.5.8.jar within!
I then use "Dependency Hierarchy" to check the resolved dependencies , but cannot find slf4j-log4j12 (so it's not packaged into WEB-INF/lib)
What's going wrong here?
environment : maven 3.0-beta1 , m2-eclipse-0.10.0.20100209
The dependency management section is a mechanism for centralizing dependency information, adding a dependency in the dependency management section doesn't make it a dependency of your project by itself, you still need to declare it as dependency:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.5.8</version>
<type>jar</type>
<scope>runtime</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
</dependency>
</dependencies>

Resources