I have a plugin which can run either using a pom.xml or without (depends upon the version of the artifact we're building: new versions go without a pom. Strange, I know).
I want to have that plugin run in Jenkins.
But when creating a maven project, I have to set a pom (or as a default, Jenkins suppose there is one in the base folder given).
Question: Is it possible to configure Jenkins to not use a pom when there is none?
As per my comment, you should use a Jenkins freestyle project build in this case, in order to have more flexibility and avoid the default assumptions of a Jenkins Maven build.
In such a build, you can then configure a build step executing a shell or a Windows command (depending on the Jenkins server OS).
Indeed, in the Jenkins Maven build, a pom file is always required, as mentioned in the help support of the Configuration > Build > Root Pom entry
If your workspace has the top-level pom.xml in somewhere other than the 1st module's root directory, specify the path (relative to the module root) here, such as parent/pom.xml.
If left empty, defaults to pom.xml
Related
Currently we have a number of maven projects (specifically Apache Camel) that reside in isolation. We also have one Jenkins job per project because we need to specify the pom.xml file in the maven build and since the projects are independent then we require one job per project.
However, we also know most of the projects share a lot of dependencies and we want to turn them into a maven multi-module project with a parent pom file where the dependencies and versions are stated. We also want to have fewer Jenkins jobs to maintain and allow more projects to be added without having to create new Jenkins job.
My question is, in the Jenkins job for the maven build I still need to specify a single pom file. Does this mean that I need to point to the parent pom file and then add theparent directory as the directory to for Jenkins to receive the git trigger? In a sense, whenever a code is committed to any of the child projects, the job gets triggered and it uses the parent pom file to build only that project where the code was committed?
We have an in-house developed MOJO that generates content and doesn't require you to have an existing project or POM. Think of the maven archetype plugin, where you can just run mvn [mojo]:[goal] and have maven just execute that goal without a POM.
This MOJO connects to a specific database instance in a specific environment, and generates some metadata for the contents of the database, so our testers can inspect the metadata and locate production-like data that has certain attributes they need for a given test.
When you execute the metadata mojo, maven resolves the MOJO from the available repo's (in our case an Artifactory repo), and it then does its work and returns. It does not create any artifacts or other outputs.
We use TeamCity as our CI server, but it also has metadata generation jobs so with one click a dev can kick of a metadata generation job against a specific database.
The problem with this is the Maven runner in TeamCity requires a POM. If TC hasn't already checked out a project from a VCS, or the project it's checked out doesn't have a POM, the maven runner won't do anything. In this case, there is nothing to check out (the MOJO is resolved from Artifactory) so there is no POM.
I can set up the TC job to use the Command Line runner and have it execute, say, mvn com.example:metadata-generate -DenvironmentName=UAT1, but then it's impossible to specify the maven settings file that maven should use.
So my question is, how do I do this? Is it possible to have the maven runner execute an arbitrary maven command without needing a POM? Alternatively, using the Command line runner, is it possible to have a TC job copy a specific maven settings file to the build agent so it can be referenced in the maven command as mvn com.example:metadata-generate -DenvironmentName=UAT1 -s {path-to-settings-file}?
So its turns out that TC handles pom-less maven builds just fine. My problem was that the MOJO was not declared to not require a project.
Comparing my MOJO with the MavenArchetypePlugin source, I needed to declare my MOJO with the class level javadoc tag #requiresProject false.
Once I had that in place, TC ran my pom-less job perfectly well. All I had to do was clear the Path to POM file: field in the TC build configuration and leave it blank.
You can customize the name of the pom file that you use as an argument into the maven build-step in the teamcity and use this as the second "build step".Lets call the parameter as pom.file.name
In the first step , resolve all the in-house dependencies that you have and set the name of the pom file you want to execute into the variable pom.file.name
If you want to know more about how to change tha value of a variable in teamcity, you can read about it here
I have several modules that I build in a maven multi module project. I can call maven on the head pom.xml in the parent directory and build all modules. However, Jenkins only builds the first module of several svn repos I have configured by calling mvn -f <first child module it sees>, and never builds the other child modules. I tried creating a new Jenkins project, but the same problem occurs.
In the Advanced section of the maven configuration block, are you definitely pointing at the parent pom? Jenkins only executes maven once, against the pom specified in this section.
I have a Maven deployment problem:
When I execute Maven deploy, Maven pushes all my jars to a remote repository under the project version which is specified in the POM files:
<version>version.x.y.z</version>
The problem is that I don't want to overwrite my previous jars every time I rebuild my project, I want to increment the version automatically every time I build as part of the building process.
(So, I don't want to use CLI tool such "Versions Maven Plugin" to change the pom files before the building process.)
I have an environment variable, $project.buildnumber, that I can use to set the project version.
Is it possible to configure maven-deploy-plugin to automatically change the version (for instance using this environment variable)?
Many thanks!!
Forgive me if this is remedial, but I am still new to Maven and it's functionality.
In my project, when it "builds" and gets to the compile phase, it will create a target directory with just compiled libraries and update (or create if not there) the local .m2 directory.
When I get to the "test" phase, I want it to build against the target directory's library files, and not the local .m2 directory.
Any hints, recommendations, or suggests would be greatly appreciated. Thanks!
Maven has this concept of “the reactor”, which is just a fancy term for the list of projects being built. At the start of a Maven build, and at the end, Maven prints out this list of projects (using /project/name if defined or groupId:artifactId otherwise).
For each project in the reactor, Maven maintains a list of artifacts that have been attached. By default, each module's pom.xml is attached, and as each plugin runs, they have the option of attaching additional artifacts. Most plugins do not attach artifacts, here are some plugins that do:
jar:jar creates a .jar and attaches it
war:war creates a .war and attaches it
source:jar creates a .jar of the source Java code and attaches it with a classifier of source
java doc:jar creates a .jar of the JavaDocs ad attaches it with a classifier of javadoc
There is also a default primary artifact (this is the one that gets replaced by jar:jar) which is actually a directory and not a file, as such it will not get installed or deployed to the local repository cache or a remote repository.
So when in the reactor, and a plugin that attaches the primary artifact has not run yet, and another plugin asks for the primary artifact, it will be given the directory ${project.build.outputDirectory}. If after the primary artifact as been attached, then that primary artifact will be provided.
The test phase happens before the package phase, so will use the directory and not the .jar. The integation-test phase happens after, so will always use the .jar.
Things get more complex in a multi-module project (which is where my long intro should help you out)
Maven has to build the test classpath. If one of the dependencies is within the reactor, Maven will use the artifact attached to the reactor. Otherwise it will use the local cache (populating from the remote repositories if necessary).
When you run
mvn test
In a multimdule project from the root, there is no replacement of the default (directory-based) artifact, so intra-module classpath will be to the target/classes directories.
When you run
mvn package
In the same project, however, because each module completes its life cycle sequentially, all the dependent modules will have swapped in their .jar files as their attached artifact.
All of this should show you that Maven is doing the sensible thing. Hope this has helped.
The test phase is going to execute tests on your project. The project won't reference itself via the dependency mechanism. Only dependencies will be referenced via your local repository, i.e. .m2/repository
Also, it's not the compile phase that installs the artifact to the local repository, it's the install phase. And, then, there's a later phase, called deploy, that will deploy the artifact to a remote repository, provided you have a remote repository configured as the deploy target. Note, install and deploy are nearly identical phases except install is a local only thing; thus, it's the common build phase to hit when doing dev environment work. Normally the build server will do the deploy stuff.