I am building a project that runs on top of Wildfly 14.0.1-Final.
I wanted to try the BOM feature of maven, so I thought: "I will add the wildfly 14 BOM to the dependency management of my parent POM, and then I will only need to define the groupId and artifactId of each artifact, without caring about version number/scope".
So, in my parent POM, I did add:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.wildfly.bom</groupId>
<artifactId>wildfly</artifactId>
<version>14.0.1.Final</version>
<type>pom</type>
</dependency>
</dependencies>
</dependencyManagement>
and to my children POM, I did add a reference to the CDI API:
<dependencies>
<dependency>
<groupId>javax.enterprise</groupId>
<artifactId>cdi-api</artifactId>
</dependency>
</dependencies>
Yet maven protests that it does not have the version for cdi-api.
The error is:
ERROR] [ERROR] Some problems were encountered while processing the POMs:
[ERROR] 'dependencies.dependency.version' for javax.enterprise:cdi-api:jar is missing. # line 29, column 15
#
I have also tried with the wildfly-javaee8 BOM artifact.
What am I missing/missunderstanding?
#JamesR.Perkins comment made me realize that I did not have setup the import scope for the POM. Also, the correct artifact is org.wildfly.bom:wildfly-javaee8
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.wildfly.bom</groupId>
<artifactId>wildfly-javaee8</artifactId>
<version>14.0.1.Final</version>
<scope>import</scope>
<type>pom</type>
</dependency>
</dependencies>
</dependencyManagement>
James was right in that I need to define the scope as provided when I needed to use the dependency, otherwise it cdi-api.jar would end packaged in the ear and this could cause problems.
<dependencies>
<dependency>
<groupId>javax.enterprise</groupId>
<artifactId>cdi-api</artifactId>
<scope>provided</scope>
</dependency>
</dependencies>
When you add a dependency to the section of your parent POM, it sets a default version for that dependency, but it does not automatically add it to the dependencies section of your children POMs.
In your case, you need to add the for cdi-api to the section of your children POMs, not just in the section of your parent POM.
This should like this:
<dependencies>
<dependency>
<groupId>javax.enterprise</groupId>
<artifactId>cdi-api</artifactId>
<version>14.0.1.Final</version> <!-- version should match the version of wildfly BOM you are using -->
</dependency>
</dependencies>
Also, you can use wildfly-javaee8 BOM artifact instead of wildfly artifact that you are using, it covers all the dependencies you will need for your wildfly application development.
You can also check your wildfly documentation for more information on how to use BOM feature in wildfly.
Related
Maven novice here. The pom file of the Spring Data Redis module version 2.6.1 can be found at https://repo1.maven.org/maven2/org/springframework/data/spring-data-redis/2.6.1/spring-data-redis-2.6.1.pom. The spring-aop, and a bunch of other Spring modules don't have a version specified in the file, but when I look at the dependence tree, the version is 5.3.15.
So where is the version specified?
They come from the parent, which is org.springframework.data.build:spring-data-parent:2.6.1. That POM contains a dependencyManagement section:
<properties>
…
<spring>5.3.15</spring>
…
</properties>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-framework-bom</artifactId>
<version>${spring}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
…
</dependencies>
</dependencyManagement>
And that spring-framework-bom, called a Bill of Materials (AKA BOM), has all the version of various Spring libraries.
When you import that BOM in your project, the versions listed in its dependencyManagement section become kind of recommendations: they will be used if no other version is specified:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-aop</artifactId>
<version>5.3.15</version>
</dependency>
</dependencies>
…
</dependencyManagement>
I've got a multi-module maven project, with a structure like:
projectA-parent
- module-1
- module-2
And I have another project where I want to bring in all the modules in projectA-parent as runtime dependencies (it's a Spring application, and each module in projectA-parent contains Spring services that I want to be able to autowire).
What I'd like to do is something like
<dependency>
<groupId>projectA-group</groupId>
<artifactId>projectA-parent</artifactId>
<scope>runtime</scope>
</dependency>
so that if I add another module to projectA-parent it is automatically brought in as a runtime dependency (i.e., I don't want to have to add each new module as a dependency in my Spring application as I add them). Is such a thing possible?
You will have to use
<dependencies>
<dependency>
<groupId>projectA-parent-groupId</groupId>
<artifactId>projectA-parent-artifactId</artifactId>
<type>pom</type>
</dependency>
</dependencies>
This will transitively add all dependencies declared in com.my:commons-deps to your current POM.
Using
<dependencyManagement>
<dependencies>
<dependency>
<groupId>...</groupId>
<artifactId>...</artifactId>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
works as a simple 'include' of artifacts versions in your dependency management. Thus, it won't add any dependency in your project.
UPDATE:
Another aprroach would be to use a BOM (Bill of Materials). Check this link for the usage of BOM. It is hidden somewhere at the bottom.
You can create a BOM that lists all your modules as dependencies and then you can include the BOM into your pom.xml like this:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>your_bom_group_id</groupId>
<artifactId>your_bom_artifact_id</artifactId>
<version>you_bom_version</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
I guess I'd just add another module that referred to the other modules in your project, e.g.:
projectA-parent
- module-1
- module-2
- module-deps
with module-deps as a jar or pom that depends on module-1 and module-2.
You'll have to update module-deps as you add more modules, but at least it's only in one place.
I'm working in an application server environment in which I'm using a bom to gather the dependency information like so:
<dependency>
<groupId>org.jboss.bom.eap</groupId>
<artifactId>jboss-javaee-6.0-with-security</artifactId>
<version>${jboss.bom.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
However, this particular bom specifies a dependency as "compile" that I wish to have scoped for all of my projects as "provided". However, when I attempt to override the scope in the same pom from which I'm importing the dependency like so:
<dependency>
<groupId>org.picketlink</groupId>
<artifactId>picketlink-federation</artifactId>
<scope>provided</scope>
</dependency>
Maven complains that it cannot find the version, or if I use the version property specified in the bom, the property cannot be found.
I'm fairly certain this is an issue with the import + override in the same pom, because I can override the scope in child projects just fine. Is there a way to both import and override the scope in a single pom?
*all code snippets above come from the same section.
It is certainly doable:
<dependencyManagement>
...
<dependency>
<groupId>org.jboss.bom.eap</groupId>
<artifactId>jboss-javaee-6.0-with-security</artifactId>
<version>${jboss.bom.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
...
</dependencyManagement>
<dependencies>
...
<dependency>
<groupId>org.picketlink</groupId>
<artifactId>picketlink-federation</artifactId>
<scope>provided</scope>
</dependency>
</dependencies>
Just remember that you need to redefine your scopes in the <dependencies>and not in the <dependencyManagement> section.
Your scope override will of course propagate to any child POMs, if you use inheritance.
In my maven-project there are three dependencies corresponding to RichFaces:
<dependency>
<groupId>org.richfaces.framework</groupId>
<artifactId>richfaces-api</artifactId>
</dependency>
<dependency>
<groupId>org.richfaces.framework</groupId>
<artifactId>richfaces-impl</artifactId>
</dependency>
<dependency>
<groupId>org.richfaces.ui</groupId>
<artifactId>richfaces-ui</artifactId>
</dependency>
And in the root of my eclipse project MavenDependencies branch contains richfaces-api/ui/core -3.3.3. How can I change the pom to upload latest available version? The thing is there is no version defined anywhere in the pom.
There has to be a version defined otherwise it would not work. Eclipse will tell you what version you're using and where to find the definition if you hover over the dependency.
I Think there's a bom dependency somehwere in your pom such as this
<dependency>
<groupId>org.richfaces</groupId>
<artifactId>richfaces-bom</artifactId>
<version>BOM-VERSION</version>
<scope>import</scope>
<type>pom</type>
</dependency>
Update the BOM-VERSION part to something new such as "4.3.7.Final".
Well, I'm not talking about the well-known commons-logging problem, I know I can disable it by setting the 99.0-does-not-exist version.
My problems is, some packages are contained in different dependencies, say, aspectjlib is contained both in org.aspectj:aspectjlib and aspectj:aspectjlib. In some cases, transitive dependencies may introduce the two jars at the same time, while of different versions, e.g., org.aspectj:aspectjlib:1.7.3, aspectj:aspectjlib:1.6.1. And mis-loading aspectj:aspectjlib:1.6.1 accidentally is not my intention. So is there a way like commons-logging that I can disable aspectj:aspectjlib completely?
I tried the same trick using 99.0-does-not-exist, only to find an error from maven:
[ERROR] Failed to execute goal on project XXX: Could not resolve
dependencies for project XXX:jar:1.0.0-SNAPSHOT: The following
artifacts could not be resolved:
aspectj:aspectjlib:jar:99.0-does-not-exist,
aspectj:aspectjrt:jar:99.0-does-not-exist,
aspectj:aspectjweaver:jar:99.0-does-not-exist: Could not find artifact
aspectj:aspectjlib:jar:99.0-does-not-exist in tbmirror
(http://mvnrepo.taobao.ali.com/mvn/repository) -> [Help 1]
Well, although some repositories do provide 99.0-does-not-exist for logging system dependencies like log4j, slf4j-log4j, commons-logging, etc., this is not a universal solution.
I find a solution to do this: use 'provided' scope.
To clarify, in my example above, I have two conflicting dependencies: org.aspectj:aspectjlib:1.7.3, aspectj:aspectjlib:1.6.1, I want to disable aspectj:aspectjlib:1.6.1, I only need to put this in top-level pom:
<dependency>
<groupId>aspectj</groupId>
<artifactId>aspectjlib</artifactId>
<version>1.6.1</version>
<scope>provided</scope>
</dependency>
in this way, aspectj:aspectjlib:1.6.1 will never appear in the final built lib.
You can use Maven's dependency exclusions to eliminate the version you don't want. Using your example:
<dependencies>
<dependency>
<groupId>com.example</groupId>
<artifactId>includes-new-aspectj</groupId>
</dependency>
<dependency>
<groupId>com.example</groupId>
<artifactId>includes-old-aspectj</groupId>
<exclusions>
<exclusion>
<groupId>org.aspectj<groupId>
<artifactId>aspectjlib</artifactId>
<exclusion>
</exclusions>
</dependency>
</dependencies>
Alternatively, you can simply pin the version you desire using dependency management:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.aspectj</groupId>
<artifactId>aspectjlib</artifactId>
<version>1.7.3</version>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>com.example</groupId>
<artifactId>includes-new-aspectj</groupId>
</dependency>
<dependency>
<groupId>com.example</groupId>
<artifactId>includes-old-aspectj</groupId>
</dependency>
</dependencies>
If you are not sure which dependencies include which versions, you can use this to discover that info:
mvn dependency:tree -Dincludes='org.aspectj:aspectjlib'
There is no 99.0 version for aspectj:aspectjlib, your project is configured to use wrong version, check for 99.0 in your pom.xml