Is there a way to translate this human language in an xml codeblock that Maven will happily understand?
Hey Maven, look you are a great dependency management system. I am working on a JavaEE project which is intended to be deployed on Wildfly 10.1.0. Please put all Libraries that are specified in Wildflys parent BOM http://repo1.maven.org/maven2/org/wildfly/wildfly-parent/10.1.0.Final/wildfly-parent-10.1.0.Final.pom on the compiletime classpath and consider them as provided by Wildfly at runtime. And please dont bother me to list every single referenced artifact in the dependencies section of the projects pom file. Thank you Maven, you are so cool.
To clarify:
As far as I understand, importing the bom file in the dependencyManagement section of my pom file will only spare me to specify the Version Number of every single artifact, but I will still have to declare every artifactID and groupID.
This is indeed discussed here How to use BOM file with Maven
But in this answer is also stated:
Then you do not have to specify the version attribute of a dependency.
I would prefer to declare only that I am using wildfly and then be able to use all client libraries without declaring any other dependencies.
But I must admit, I have the feeling to miss something obvious. There should be an easy way to do this.
If you want everything in a another pom to be set as a dependency and as provided you can specify that in your pom. A minimal pom for wildfly 10.1.0.Final that includes everything seems to be as follows:
<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>wft</groupId>
<artifactId>wft</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>war</packaging>
<name>wft</name>
<description>wft</description>
<properties>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
<failOnMissingWebXml>false</failOnMissingWebXml>
</properties>
<dependencies>
<dependency>
<groupId>org.wildfly</groupId>
<artifactId>wildfly-spec-api</artifactId>
<version>10.1.0.Final</version>
<type>pom</type>
<scope>provided</scope>
</dependency>
</dependencies>
</project>
But I would still recommend doing it the way that wildfly does it themselves, which is to put the BOM in the depencency management section and declare artifacts as you need them. Why? I don't know other than it's cleaner to read and maybe easier for maven/java to compile and build.
Related
Hi Meier I have used the following goal:
mvn versions:update-property
-Dproperty="emom.web.dependency.shr.version"
-Dincludes:org.safeway.com:emom-shr
-DgenerateBackupPoms=false
-DallowIncrementalVersios=true
-DallowSnapshots=true
clean package
My Job B pom.xml is:
<dependency>
<groupId>com.safeway.app</groupId>
<artifactId>emom-shr</artifactId>
<version>${emom.web.dependency.shr.version}</version>
</dependency>
Under the properties it has the version hard-coded:
<emom.web.dependency.shr.version>19.6.5-SNAPSHOT</emom.web.dependency.shr.version>
My Job A pom.xml:
<groupId>com.safeway.app</groupId>
<artifactId>emom-shr</artifactId>
<version>20.1.0-SNAPSHOT</version>
<packaging>jar</packaging>
When I run the above goal, Maven is picking the latest version (i.e. 20.1.0) from Artifactory but when I check the pom.xml of Job B under properties it still says 19.6.5. I need a way to change the 19.6.5 or current version to latest version available. Am I doing something wrong? I'm not able to figure it out.
Here's an example of versions-maven-plugin:update-property working in practice. I've used the common Mockito library as an example that works for everyone as it's in Maven Central.
Starting with this POM (noting the mockito-version property):
<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>abc</groupId>
<artifactId>def</artifactId>
<version>0.0.1-SNAPSHOT</version>
<properties>
<mockito-version>2.22.0</mockito-version>
</properties>
<dependencies>
<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-core</artifactId>
<version>${mockito-version}</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>
The simplest way to upgrade it to the latest release version is this:
mvn versions:update-property -Dproperty=mockito-version
Replace mockito-version with emom.web.dependency.shr.version in your case.
You can then start to use more of the goal options to adjust the options. For example, you might:
Permit snapshots, not just releases, with -DallowSnapshots=true.
Disallow major version updates (i.e. third element from the right) with -DallowMajorUpdates=false. Note that the logic around these version number sections seems a bit flaky in the plugin - or isn't how I expect.
Avoid creating backup POMs with -DgenerateBackupPoms=false. This is cleaner, but if you omit this option then you can use mvn versions:revert to get yourself back to where you started.
To apply this to your scenario, I think you need to:
Check you've not got typos in your actual command (like you have in the question and comments).
Get rid of options that don't appear in the options.
Probably, keep things simple by not trying to run this in conjunction with anything else (unless it's in automation), so get rid of the clean package at the end of the command.
We have a couple of different applications which may or may not interact together. When they interact together, there have been issues because of mismatch in third party library versions (Let it be Spring or something else).
The pom files for these applications are separate, but to solve the above issue, we want them to use the same versions of third party libraries. The easiest way to do this is to specify the versions in common properties file, and then let respective pom.xml read the versions from the properties file.
Usually I am used to specify the versions as properties in the parent pom, and let the module pom read it from there. Is there a way I can make pom.xml read the properties file for reading the versions?
Some projects, e.g. spring-cloud and spring-boot, express their 'release train' (a set of dependencies and their versions that are known to work well together) in a 'BOM' (bill of materials). The BOM is nothing but a POM with only a dependencyManagement section, where all these dependencies are listed with the correct version. That BOM is then included in each project's POM that should follow these dependencies/versions in its dependencyManagement section, with scope 'import'.
E.g.
You create your separate project 'my-bom', containing only a pom like this:
<project>
<groupId>your.organication.program</groupId>
<artifactId>my-bom</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>pom</packaging>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.whatever</groupId>
<artifactId>somedependency</artifactId>
<version>1.2.3</version>
</dependency>
<dependency>
<groupId>com.whatever</groupId>
<artifactId>someotherdependency</artifactId>
<version>4.5.6</version>
</dependency>
</dependencies>
</dependencyManagement>
</project>
And then you include that in each project that should be aligned with these dependencies/versions:
groupId>your.organication.program.project</groupId>
<artifactId>some-project</artifactId>
<version>0.0.1-SNAPSHOT</version>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>your.organisation.program</groupId>
<artifactId>my-bom</artifactId>
<version>0.0.1-SNAPSHOT</version>
</dependency>
</dependencyManagement>
Within the projects the dependencies that are effectively used must still be referenced in dependencies-section, but without the version - the versions are managed by the BOM.
Here I have two projects those are project(1) and project(2).
I am going to generate a .war file for the project(1) but it depends on project(2).
I built the project(2) as a .jar file and added it to the project(1)'s build path but while runnig mvn install it results in compilation errors like:
package com.disha.db.dao.orm.gen does not exist` the package is in the project(2).
Can any one please help to me.
You have to delegate dependency management to Maven and that's actually where it comes in hand, otherwise you can move on packaging and resolving inter-projects dependencies by hand and let the Maven alternative be dropped.
You should make sure you have provided the correct Project Object Module description for your projects (pom.xm) along with tha packaging type.
Then since you want the project(2) to be availble for project(1) at compilation time, you have to declare, project(2) as a dependency of project(1).
project(2) pom.xml (I will refer to it as project-2 since 'project(2)' does not match a valid id pattern.):
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>project2.group.id</groupId>
<artifactId>project-2</artifactId>
<version>1.0</version>
<packaging>jar</packaging>
</project>
Now the project(1) will refer to the project-2 artifact as a dependency with scope compile:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>project1.group.id</groupId>
<artifactId>project-1</artifactId>
<version>1.0</version>
<packaging>war</packaging>
<dependencies>
<dependency>
<groupId>project2.group.id</groupId>
<artifactId>project-2</artifactId>
<version>1.0</version>
</dependency>
</dependencies>
</project>
Note: Update the group and artifact IDs with ones you are using.
I have all these version numbers throughout parent pom and children poms including the parent reference like so
<parent>
<groupId>com.cigna.ifp</groupId>
<artifactId>ifp-core</artifactId>
<version>${parent.version}</version>
</parent>
and dependency references to other child projects like so
<dependency>
<groupId>com.cigna.ifp</groupId>
<artifactId>ifp-shared</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
and finally the declaration of the version of the thing we are building
<modelVersion>4.0.0</modelVersion>
<groupId>com.company</groupId>
<artifactId>artifcat</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>jar</packaging>
<name>ifp-shared</name>
<url>http://maven.apache.org</url>
EDIT based on some answers which solved half the question...
We want to have all the versions be ${project.version} since it is really just one project with one release number.
I can seem to do ${project.version} in the dependency but this does not work in the parent xml code above. Is there another way? (man, I should really just switch to gradle).
thanks,
Dean
<parent>
<groupId>com.cigna.ifp</groupId>
<artifactId>ifp-core</artifactId>
<version>1.2.3-SNAPSHOT</version> <!-- real version-->
</parent>
<artifactId>blah</artifactId>
<!-- No version here, will be inherited -->
<dependency>
<groupId>com.cigna.ifp</groupId>
<artifactId>ifp-shared</artifactId>
<version>${project.version}</version>
</dependency>
project.version is what you want. Not parent.version.
You need to use dependencyManagement tag to centerilize the versions in the parent pom for the dependencies.
See this question and answers
differences between dependencymanagement and dependencies in maven
For you your own modules, some of the properties are inherited from the parent pom. You will need to declare the parent version in each child but you don't need to declare a groupId/version in your child poms if you want them to be same as their parent's.
We switched to gradle which works fabulously now. Every automated build a new version is released as 1.2.x where x is the next build number. Downstream, projects depend on 1.2.+. This allows every release to be official so QA can test it, reject it or go, yup, build 1.2.568 is the release we will release to the world. Projects can depend on 1.2. but then they don't get bug fixes. This seems to work much better than all that snapshot nonsense as you give QA a snapshot and they approve and you have to change and do another build. We want every build to look official so they can release the one that happens to pass all QA tests.
I have specified following dependencies(For example mentioned one here) in pom.xml which will look for saaj.jar under the specified sytempath and Maven used to pick it from same path and working fine.
<dependency>
<groupId>saaj</groupId>
<artifactId>saaj</artifactId>
<version>1.0</version>
<scope>system</scope>
<systemPath>${basedir}/src/main/webapp/WEB-INF/lib/saaj.jar</systemPath>
</dependency>
Now I have moved to windows 7 and Spring Tool suite 2.7.1 version(Previously Win XP and Spring older vesion). In this new setup am getting below error.
Missing artifact saaj:saaj:jar:1.0:system
Now, It is looking for saaj-1.0.jar instead of saaj.jar and under the folder ${basedir}/src/main/webapp/WEB-INF/lib/saaj/saaj/1.0/ instead of ${basedir}/src/main/webapp/WEB-INF/lib/.
Why is it so? Please provide the solution where my previous setup should work fine.
Avoid systemPath, you must create a local repository like :
this is you pom file :
<repositories>
<repository>
<id>local-repo</id>
<url>file://${basedir}/lib</url>
</repository>
</repositories>
<dependency>
<groupId>tiago.medici</groupId>
<artifactId>eureka</artifactId>
<version>0.0.1</version>
</dependency>
on project you create a lib folder to put your jar and maven pom file generated from
mvn install:install-file -Dfile=c:\tiago.medici-0.0.1.jar -DgroupId=tiago.medici -DartifactId=eureka -Dversion=0.0.1 -Dpackaging=jar
tiago.medici-0.0.1.pom
<?xml version="1.0" encoding="UTF-8"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<modelVersion>4.0.0</modelVersion>
<groupId>tiago.medici</groupId>
<artifactId>eureka</artifactId>
<version>0.0.1</version>
<description>POM was created from install:install-file</description>
</project>
Don't use system scope. It was meant for system provided libraries. Given the path you gave for it, you are obviously creating a web application.
Use a war project and specify your dependencies with provided scope if they're already available (e.g. because they are provided by your application server) or without a scope specification otherwise. Maven will take care of packaging your project dependency in a correct way, both for Eclipse development and for deployment in your application server.