I wish to upload a binary from one of the child Maven modules to Nexus. This child module tar.gz's jars from other child modules using maven assembly plugin.
question 1#: So should I add the distributionmanagement section to just that particular child module? Or should I add distributionmanagement to parent modules and all other child modules?
question#2: Is it enough to make changes to distributionmanagement and settings.xml? Or should I include "maven deploy plugin" too somewhere?
Thanks in advance.
You're not specifying where you'll be deploying the artifacts from, so I'm assuming you have some sort of CI server like Jenkins or TeamCity already installed.
question 1#: So should I add the distributionmanagement section to
just that particular child module? Or should I add
distributionmanagement to parent modules and all other child modules?
If you'd like to deploy just that module's artifact, then I would recommend you have a separate job for this in your CI server. Alternatively, when deploying from a command-line, you would need to cd in the directory of the module and only execute mvn deploy from there. And -- yes -- you will need to have the <distributionManagement/> section for sure.
question#2: Is it enough to make changes to distributionmanagement and
settings.xml? Or should I include "maven deploy plugin" too somewhere?
You will need both a <distributionManagement/> section in your pom and a properly defined <server/> section in your pom.xml. You shouldn't need to explicitly define settings for the maven-deploy-plugin, unless you need some special options.
You only need distributiionManagement in some parent pom you are inheriting from. Typically this is only set up in an organization wide top level pom. You do NOT need to have it in every project since it is inherited.
Settings has to be configured correctly.
All you need to do is call mvn deploy for the module you want to deploy.
Check out the first videos of the Nexus training video series.. it shows it all.
Related
We have multi-module project that consists of 17 modules. There'a base jar module. There are 15 filter jar modules that depend upon that base jar. Then, there's the Ear that we build that contains the 16 other jars.
We have the build working just fine, but we'd like to deploy our Ear to our Maven repository -- mainly because it'll make it easy for our deployment tools to get to it. Plus, we can easily do that via mvn deploy without having to put together another tool.
The problem is that when we say mvn deploy, we deploy the Ear and the 16 other jars. Those jars are not used in any other project, and we simply don't want them clogging up our Maven repository.
Is there a way to specify that a particular module doesn't get put into the Maven repository when I say mvn deploy?
Looking through the documentation, I found the ${maven.skip.deploy} property. I actually set this to true in the parent project, then set it to false in the EAR build. That does what I want, deploys only the EAR. This way, if another module is added, it will by default not be deployed.
steve c recommended mvn -pl core-ear clean deploy which doesn't work in my circumstance. The module I want to deploy is actually a module of a module, so the main level build doesn't see it.
Our structure is like this:
parent --|
|-engine
|-filter1
|-filter2
.
.
|-distribution --|
|--jar
|--sar
|--ear <-Deploying this one only
khmarbaise mentioned setting <skip>true</skip> in all of the modules except for the one I want to deploy. khmarbaise recommends against this, and I don't blame him. However, there are several issues here. First, we're doing continuous delivery which means that we will have a new version in our repository for each build. I also want to make sure no one tries to depend upon these jars.
I set the property ${maven.deploy.skip} to false in my parent module. This means it's that way in all of my modules and none of them will deploy. I don't need to configure my maven-deploy-plugin in order to set this.
I then set ${maven.deploy.skip} to true in the only module I actually want to deploy (which is the ear module of the distribution submodule). Running mvn clean deploy from the parent now only deploys the ear distribution module I actually want to deploy.
does it make sense to have a maven submodule (which doesn't have any submodules to itself) to have a pom packaging?
Is there any use of doing that at some instance?
If not does it mean that all my last level submodules should have a packaging which is not pom?
Typically, there is a certain lifecycle associated with the packaging, e.g. the "jar" packaging will run the maven-compiler-plugin during the "compile" phase, etc.
If you choose "pom", then there is a very limited default lifecycle - I guess only the the "install" and "deploy" plugins are bound to the respective phases. You could probably use it if you want to have more control over what happens in a build.
Typically, you only would use "pom" packaging for aggregator modules (those that have submodules).
For more details on packagings and the Maven lifecycle, you can refer to Maven: The Complete Reference - 4.2. Package-specific Lifecycles
As a real-world where I actually use "pom" packaging in a submodule:
In some projects, I have a submodule called "PROJECT-doc" which contains asciidoc documentation that I compile to HTML and PDF as part of the build. These modules have the "pom" packaging - there is no Java code to compile, no JAR to build, and no unit tests to run - just the documentation is built. I manually bind the "asciidoctor-maven-plugin" to the "generate-resources" and that's it.
I think the main question is the use of packaging pom in maven - this question was answered here: What is "pom" packaging in maven?
The short form is: yes, you shouldn't have a module without submodules that uses packaging pom.
I've got a maven project which generates a set of resources files using some plugins defined in a pom.xml. I'd like to use something like distributionManagement to push these generated files to a branch in Git. I can see that I can use something like Apache Wagon to do the distribution but the distributionManagement settings seem to only cater for the repository, site and relocation elements.
Is there a way of adding some custom distributionManagement elements, or can anyone suggest another way of pushing my generated resources to a git branch?
Use a usual maven project, put the generated of the resources into the generate-resources life-cycle phase and package the result into a jar file and finally use the usual deployment (** mvn deploy **) or in relationship with creating a release to transfer the resulting artifacts into a maven repository.
I have a multi module maven project. One of the modules is a reusable part which is packaged into a jar, and the other is a war web-app which depends on the first module. When I use jetty:run-exploded on the second module, the packaged jar is taken from local maven repository whereas I want the first module to be rebuild and packaged into the resulting war. Is there any way to force such behavior instead of the default one?
From everything I can tell from reading documents about Maven's design and using Maven myself this cannot be done in the projects own directory.
Maven will not follow module paths UP a hierarchy. Using -amd (also make dependencies) will only work at the top level module that ties all the other multi-module pom's together. So what you can do is this:
At the TOP level directory
mvn -amd -pl jetty_module jetty:run-exploded
I think you can use maven Advanced Reactor Options to archive this.
http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-advanced-reactor-options/
The -pl or –projects option allows you to select a list of projects from a multimodule project. This option can be useful if you are working on a specific set of projects, and you’d rather not wait through a full build of a multi-module project during a development cycle.
Maven -amd(also-make-dependents ) also help to build multi module project once. Using that you can build a project and any project that depends on that project.
I've refactored all repository configuration out of my various projects into a parent pom that I've created for the specific purpose of having a single point of configuration for stuff like repo's and distribution management. This is supposed to be best practice as I understand it. In deployed my parent pom to the nexus server, and then tried to run my child projects. They can't find my parent pom . . . this kind of makes sense to me since, wihtout the parent pom they don't know about the nexus repo . . . seems like a chicken and egg kind of thing? Am I missing something obvious?
It's true that your project needs to know where to find the repositories to download its dependencies. But before going to external repositories, Maven will check your local repository to see if the artifacts it needs are in there. Does your local repository contain the parent pom? If not, you can add it by running
mvn install
on the parent pom. The problem may have been caused by deploying the parent pom directly to Nexus, bypassing your local one. You can avoid this in future by deploying using
mvn deploy
This will first install the artifact locally, and then deploy it to the external repository (Nexus, in your case). More details here: http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
If you're in a situation whereby your parent pom is built and deployed by others, this won't help. You can either specify the repositories in your project's pom, or in your local settings.xml. A common approach is to expect all developers to include a repository definition in their local settings.xml which points to your Nexus repository, using it as a mirror for all other repositories. You can then configure each external repository you need in Nexus, and let it retrieve any dependencies you need for you. I'm not familiar with Nexus, but more details on mirroring can be found here: http://maven.apache.org/guides/mini/guide-mirror-settings.html
You must maintain the repositories definitions for each child (maven module), this is main best practice in a build process: "Make the build portable".
Any developer/system should be able to build any module without source dependencies to the parent or other modules, only with the repository reference.