I have a multi-module POM file:
...
<modules>
<module>../project1</module>
<module>../project2</module>
<module>../project3</module>
...
</modules>
...
Each of the modules is itself a Maven project with its own POM. Inside each of these POMs I have the scm tag defined with the developerConnection specified like this:
<scm>
<developerConnection>scm:svn:svn://hostname:port/path/to/trunk</developerConnection>
</scm>
My goal is to run the following Maven goals/options:
versions:update-parent versions:commit scm:checkin \
-Dmessage="automated commit" -Dusername=user -Dpassword=pass
My expected results are:
The parent of each module's POM is updated to the latest released version.
The changes to each POM would be checked in to the SVN path specified in the POM for the module. E.g. project1 POM checked in using project1 <scm>/<developerConnection> path, project2 checked in using project2 path, etc.
Actual Results:
The parent of each module's POM is updated to latest released version. This works as expected.
Only the multi-module POM is checked in to SVN, none of the module POMs are checked in. This is the problem.
Is there a way to achieve the expected results above or is this something that the SCM plugin simply was not designed to do? If it is possible, how would I modify what I have in order to get the results I want?
Note: I can't change the project structure - I can't put the modules inside of the parent project, they have to remain separate.
Not sure if it's relevant but I'm using Maven 3.3.9.
Related
My parent pom modules list looks something like this:
<modules>
<module>jarProject1</module>
<module>jarProject2</module>
<module>jarProject2</module>
<module>warProject1</module>
<module>warProject2</module>
</modules>
I would like warProject1 and warProject2 to be ignored when I run mvn clean install on the parent pom. I want install to only build jars and put them in the maven repo but not the war producing projects. Currently I do it using profiles but I have some problems related to that. I would like the parent pom to keep a comprehensive list of modules in its default modules tag and not under profiles. Is there a way to do it and how?
I have a bulk full of projects which have the same URLs in their pom.xml:
<url>https://github.com/malkusch/${project.artifactId}</url>
<scm>
<connection>scm:git:git://github.com/malkusch/${project.artifactId}.git</connection>
<developerConnection>scm:git:git#github.com:malkusch/${project.artifactId}.git</developerConnection>
<url>https://github.com/malkusch/${project.artifactId}</url>
</scm>
<issueManagement>
<system>github</system>
<url>https://github.com/malkusch/${project.artifactId}/issues</url>
</issueManagement>
So I thought it's a great idea to put that into a parent pom.xml. But the effective pom produces odd ${project.artifactId}:
<parent>
<groupId>de.malkusch.parent</groupId>
<artifactId>oss-parent</artifactId>
<version>1.1-SNAPSHOT</version>
</parent>
<groupId>de.malkusch.localized</groupId>
<artifactId>localized</artifactId>
<url>https://github.com/malkusch/localized/localized</url>
<scm>
<connection>scm:git:git://github.com/malkusch/localized.git/localized</connection>
<developerConnection>scm:git:git#github.com:malkusch/localized.git/localized</developerConnection>
<url>https://github.com/malkusch/localized/localized</url>
</scm>
<issueManagement>
<system>github</system>
<url>https://github.com/malkusch/localized/issues</url>
</issueManagement>
You notice that only issueManagement.url was resolved correctly. The others are totally strange, especially ${project.artifactId}.git -> localized.git/localized. I'm using Maven 3.0.4. Am I using some undefined feature? Is it a bug?
Yes, this behaviour is confusing.
Perhaps the easiest way to understand this is to consider how Maven itself is built. It's in Subversion, and the reactor poms (the poms with <modules> sections) tend to also be the parent poms of the modules themselves.
project/pom.xml (artifactId: parent)
|-+ module1/pom.xml (artifactId: module1, inherits parent)
|-+ module2/pom.xml (artifactId: module2, inherits parent)
Here, the parent pom (project/pom.xml) contains a <modules> section, and is also inherited by module1 and module2.
Now suppose the SCM URL for parent is svn://host/path/project/: what should maven do so that you don't have to specify the SCM URL again in the two modules?
Well, the SCM URL for module1 is svn://host/path/project/module1, and Maven can compute that by adding the artifactId to the SCM URL it inherits from the parent pom. It simply needs to append the artifactId to the SCM URL. So that's exactly what it does.
So that's the behaviour you're seeing:
${project.artifactId}.git becomes localized.git/localized as follows:
localized -> from ${project.artifactId} in the inherited SCM URL
.git -> from the the inherited SCM URL
/localized -> from adding the artifactId to the inherited SCM URL
You will see this behaviour in the SCM URLs, and (I think) for project.url and the URL in distributionMangement.site.url. However, Maven doesn't assume that the issueManagement URL structure follows your directory structure, which is why you see it inherited correctly.
Since Maven 3.6.1, inheritance can avoid appending any path to parent value by setting model attribute value to false for each url
src : maven-model-builder
You need to append following properties to SCM tag in your POM :
<scm child.scm.connection.inherit.append.path="false" child.scm.developerConnection.inherit.append.path="false" child.scm.url.inherit.append.path="false">...</scm>
It seems IntelliJ shows error, but at then end, it does the job perfect.
Adding to the already great background information given, in order to still deploy with a valid scm url, since Maven 3.5 you can correct the "module" name that gets appended per the project.directory property:
<properties>
<project.directory>${project.artifactId}</project.directory>
</properties>
And then you just simplify your developerConnection to not include the artifactId anymore since it will be appended as the project.directory:
<scm>
<developerConnection>scm:git:git#server:</developerConnection>
</scm>
Assuming this doesn't conflict with any other goals, that should allow a deploy goal to do its job with the correct git url for a non-multi-module Maven project where you've defined the scm.developerConnection in the parent pom.
When I run a deploy, I see maven doing a correct push like:
[INFO] Executing: /bin/sh -c cd /projectDir/proj && git push git#server:proj master:master
I have a parent pom and children pon and when I run the mvn clean package on the parent pom I am getting .jar file, is there anyway to change this to tar.gz file? For the children files I have created assembly.xml files to specify tar.gz file do I need to do the same for parent pom?
Specify POM packaging:
<packaging>pom</packaging>
I'm a little surprised that your parent POM is working without that setting. I've received errors from Maven before when I create a new parent POM and forget to change the packaging from jar (default) to POM.
The parent is not really meant to produce artifacts other tan the pom.
You could try attaching the assembly plugin to a phase such as process-resources or something and try to have it package whatever resources you have in mind, but... generally, it's not a good idea to keep resources in your parent.
If the projects that extend this parent do not define <packaging/>, their packaging will default to pom.
I don't understand what is the parent version and for what it should be good?
We use svn in our team and when I did update for the project the last time I notcied that the parent version is changed:
local pom.xml
<parent>
<artifactId>foo</artifactId>
<groupId>bar</groupId>
<version>0.42-SNAPSHOT</version>
</parent>
svn pom.xml
<parent>
<artifactId>foo</artifactId>
<groupId>bar</groupId>
<version>0.45-SNAPSHOT</version>
</parent>
When does parent version change and for what it should be good?
A parent POM contain settings that apply to all child modules. This may include declaring plugin settings or choosing dependency versions.
A parent POM is no different to any other Maven artifact. It can change and when it does the version number must increment. Typically you want to always be using the latest available version of your parent.
You can use the Maven versions plugin to help manage versions, including forcing an update to the latest available parent version.
Parent pom and child pom come into picture if you have a multi-module project. For example like the below
/myapp
|- pom.xml --> parent pom
|+ module1/
| - pom.xml --> child pom
| - src/
|- module2/
There can be several such hierarchies. There are 2 ways to define this inheritance
Add a xml block in parent pom to tell it which are the dependent modules. OR
Add a xml block in a module to tell whose is it's parent. (This is your case)
This means that, the child pom is dependent on parent and will try to find the the concerned artifact with 0.45-SNAPSHOT version. This version has changed probably due to a newer build of parent has taken place replacing the version.
I would like to be able to deploy only the POM artifact (file) without the main artifact (JAR, WAR, etc), when running mvn deploy and version is a SNAPSHOT version.
Why?
We several developers working on multiple Maven projects. We have a Hudson server with a job per Maven project and version (e.g. foo-1.2, foo-1.3). Each job builds the project and deploys it to a Nexus server (upon success). Maven projects under development are marked as such by using -SNAPSHOT postfix in the version. For example: 1.2-SNAPSHOT, 1.3-SNAPSHOT.
Here's a sample scenario how a developer work is damaged due to this architecture.
Assume two Maven projects: foo-core and foo-webapp, both at version 1.2-SNAPSHOT.
Developer A is working on foo-core, made several changes and compiled it.
Developer A continues to work, but on foo-webapp.
Developer B started working and changing foo-core. It commits his work and pushes it to the SCM.
Hudson is triggered by SCM; Builds foo-core and deploys it to the snapshot repository in Nexus.
Developer A is running mvn install on foo-webapp. Maven is checking with Nexus, and finds that there is a newer version of foo-core in Nexus. It downloads it (filled with developer B changes) and than it fails compilation, since the changes made by developer A are not in the jar located in the local repository. The download overrides the file installed there by developer A.
Existing Solutions
I looked into maven-deploy-plugin, but this plugin deploys all artifacts attached to the project. If they had a way to configure which artifacts to deploy, it would have been great.
Question: Is there any way to solve this without resorting to writing my own deploy plugin, based on maven-deploy-plugin?
Basically to the -Dfile parameter, instead of the artifact, pass the pom.xml. Run the command and yay! mvn deploy won't give you any issues now. Here's a sample deploy command :
$ mvn deploy:deploy-file -DpomFile=pom.xml -Dfile=./pom.xml -DgroupId=my.group.id -DartifactId=artifact-id -DrepositoryId=bigdata-upload-snapshots -Durl=http://maven.mymaven.com/content/repositories/snapshots/
A prerequisite for this is that the repository be added in your settings.xml
[Edit]: I have supplied the parameters -DgroupId and -DartifactId of the project in the sample deploy command but they're not required (refer to Zac's comment below)
I never heard of such a possibility and also would be very astonished if that would be possible. As the pom and the resulting artifact are some kind of unit it would make no scence (to me) to deploy only parts of them.
Nevertheless you should consider to make a separate pom project which specified dependencies and plugins you might want to use on your JAR/WAR projects like this:
<groupId>foo.bar</groupId>
<artifactId>my-pom</artifactId>
<version>1.0.0</version>
<packaging>pom</packaging>
and then inherit that pom project by your JAR/WAR projects like this:
<parent>
<groupId>foo.bar</groupId>
<artifactId>my-pom</artifactId>
<version>1.0.0</version>
</parent>
This is called project inheritance. You can change and deploy your pom project independent of the "child" artifacts.
EDIT after reading motivation:
As I understand you want to prevent maven to resolve SNAPSHOT artifacts from a repository (so that local version won't be overwritten). Have you ever tried to use the mvn -nsu option (see mvn -help)?
-nsu,--no-snapshot-updates Suppress SNAPSHOT updates
I never tried it but found this reported issue. Nevertheless I would give it a try (as the issue is not commented yet).
This works for me for deploying a pom file only (e.g next to an existing jar):
(Note: you need to specify packaging also, otherwise it will be uploaded as an .xml file which is not what you want.)
mvn deploy:deploy-file \
-Dfile=pom.xml \
-Dpackaging=pom \
-DgroupId=com.mycompany.package \
-DartifactId=my-artifact \
-Dversion=2.0.1 \
-DrepositoryId=serverIdFromSettingsXMLForCredentials \
-Durl=http://repositoryserver/myrepo/
Not exactly the answer these folks were asking for. My situation was I wanted to deploy only the parent pom. I'm using the spring-boot-thin-layout in a child module. This requires the parent module be deployed into artifactory. I added the following into my project. It enables skipping of install and/or deploy phase.
In my parent pom:
<properties>
<disable.install>true</disable.install>
<disable.deploy>true</disable.deploy>
<enable.deployAtEnd>true</enable.deployAtEnd>
</properties>
<profiles>
<profile>
<id>deploy-parent</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<disable.install>true</disable.install>
<disable.deploy>true</disable.deploy>
<deployAtEnd>${enable.deployAtEnd}</deployAtEnd>
</properties>
<build>
<finalName>${project.version}</finalName>
</build>
</profile>
</profiles>
And the in my child pom(s) or any module you don't want deployed with parent:
<properties>
<maven.install.skip>${disable.install}</maven.install.skip>
<maven.deploy.skip>${disable.deploy}</maven.deploy.skip>
<deployAtEnd>${enable.deployAtEnd}</deployAtEnd>
</properties>
So effectively when I run mvn deploy on the parent pom, it will compile all the modules, not run install on anything, and then at the end deploy any module not having `