I was wondering if there is a standard way (i.e. a plugin) to apply a set of patches during a Maven build. Patching the code base in a dedicated step before building is getting tedious as soon as you have different builds or generated sources.
To give an example, this script should deploy 3 different versions from a fresh SVN checkout:
#!/bin/bash
# checkout project
svn checkout http://example-project.googlecode.com/svn/tag/v1_0 example-project-read-only
cd example-project-read-only
# build example-project-1.0
mvn deploy
# build example-project-1.0-a3
mvn -Dmaven.patch.dir=/path/to/patchesA -Dmaven.patch.buildSuffix=a3 clean patch:patch deploy
# build example-project-1.0-b0
mvn -Dmaven.patch.dir=/path/to/patchesB -Dmaven.patch.buildSuffix=b0 clean patch:patch deploy
Currently I'm doing similar things with another build script I'd like to get rid of. Therefore I'm considering to write such a plugin if it's not available yet. (Maybe with dedicated patch artifacts for easy distribution as an added bonus?)
The maven patch plugin might help.
The Patch Plugin has a single goal that can apply either a single declared patch or a directory of patches. Application of an entire patch directory can be configured with various patch-inclusion, -exclusion, and -ordering options:
I haven't heard of any such plugin. However I imagine that you could do something with profiles that applied patches and conditionalized the build dir. Sounds interesting.
Related
When creating spring-boot projects by using start.spring.io, some maven wrapper files get included:
mvnw
mvnw.bat
Should these files be ignored when committing to a git repo?
A mvnw Maven wrapper script allows you to run a Maven command without having Maven installed and present on your PATH. It does by looking for Maven on your PATH and, if not found, it downloads and installs Maven in a default location (your user home directory, IIRC).
They are a convenience but they are not necessarily part of your project, not in the same way as your project code and configuration is. In other words:
Any given mnvw file could be used for multiple, unrelated projects
A mnvw file will almost certainly not be different from one version of your project to another
On this basis you could make a case for not committing mvnw to your code repository.
However, including a mvnw script in your repo does have these benefits:
Allows anyone who clones / checks-out your repo to build your project without having to install Maven first.
Ensures that the version of Maven in use is the version with which your project is compatible.
On this basis you could make a case for committing mvnw to your code repository.
So, there are pros and cons on both sides. Just choose the side which best fits the needs of those who will use your repo. Either:
Include something in your readme which makes clear that (a) Maven is a prerequisite and (b) which version of Maven is required.
... or:
Include a mvnw script.
It depends, if you want to use the Maven wrapper or not. If not, then you can delete those files. If you want to use it, then you have to commit the files in the repository, otherwise it doesn't make sense to use it.
Currently, my built structure for a plugin in is a bit messy: I'm using the normal IDEA project file to build the plugin locally. When I push it to the repo and travis-ci is building it, it uses the maven pom.xml because for travis to work, it always has to download the complete IDEA sources.
Although this works, this has several drawbacks:
I need to keep two built mechanisms up to date. This is
When a new IDEA version is out (every few weeks), I need to change the SDK in maven and in my IDEA settings
When I add a new library, change resources, etc. I need to do this for two the two settings as well
I ran into problems when I kept the IDEA Maven plugin turned on because it saw the pom.xml and interfered with my local built. Turning it off means, I cannot download libraries with Maven which has the feature of tracking dependencies.
I saw that Gradle has an 'idea' plugin and after googling, I got the impression that Gradle is the preferred choice these days. I have seen Best way to add Gradle support to IntelliJ IDEA and I'm sure I can use the answers there to turn my pom.xml into a valid build.gradle.
However, maybe someone else has already done this or can provide a better approach. What I'm looking for is a unified way to build my plugin locally and on Travis-CI.
Some Details
For compiling an IDEA plugin, you need its SDK which you can access through an installation of IDEA or a download of the complete package. Locally, I'm using my installation for the SDK. With Travis, my maven built has the rule to download the tar.gz and extract it.
It turns out that in particular for building an IntelliJ plugin, Gradle seems to have many advantages. This is mainly due to the great IntelliJ plugin for Gradle which makes compiling plugins so much easier. With Gradle, I could turn my >220 lines of Maven build into a few lines of easily readable Gradle code. The main advantages are that
It takes care of downloading and using the correct IDEA SDK while you only have to specify the IDEA version.
It can publish your plugin to your Jetbrains repository and make it instantly available to all users
It fixes items in your plugin.xml, e.g. you can use one central version number in gradle.build and it will keep plugin.xml up-to-date or it can include change-notes
It seamlessly integrates with Travis-CI
How to use Gradle with an existing IDEA plugin
Do it manually. It's much easier.
Create an empty build.gradle file
Look at an example and read through the README (there are many build.gradle of projects at the end) to see what each intellij property does.
Adapt it to your plugin by
Setting the intellij.version you want to build against
Setting your intellij.pluginName
Define where your sources and resources are
Define your plugin version
Define a Gradle wrapper that enables people (and Travis) to build your plugin without having Gradle
Create the gradle wrapper scripts with gradle wrapper
Test and fix your build process locally with ./gradlew assemble
If everything works well, you can push build.gradle, gradlew, gradlew.bat and the gradle-folder to your repo.
Building with Travis-CI
For Travis you want to use the gradlew script for building. To do so, you need to make it executable in the travis run. An example can be found here.
I am trying to find a solution for the following puzzle. I have java projects, managed by maven, which needs some native dependencies to work (run unit and integration tests). Those are provided in form of deb packages, which needs to be installed prior to running a build.
I use Jenkins for CI. Native dependencies can not be installed on Jenkins nodes, because of conflicts with other builds and they can change often. What I do now is not to create a Jenkins job type 'maven', but 'freestyle' and use a pbuilder to create an clean sandbox, install all that is necessary and invoke maven build.
This is working great, but I am loosing Jenkins maven goodies like automatic upstream projects, trigger build when dependency change, etc. Jenkins simply does not know that maven is there.
Finally, my question. Is there a way how to achieve both, isolate build so installed libraries does not affect other builds and leverage Jenkins's 'magic' applied to maven builds and their dependencies?
You could split your build in three jobs, which trigger the next one.
Create needed environment
Run maven job
Clean Up
Even a Freestyle job has "Invoke top-level Maven targets". You could use that to get "maven goodies" while also having ability to run other build steps.
There is an option to "use private Maven repository" which will make sure it will use the .m2/repository folder location relative to the workspace. If you need to separate into multiple jobs, you can use "Custom/shared workspace" between those jobs.
Even in Maven-style job, there is an option to use private repository, so that one job does not affect another.
The problem can be solved by using distributed Jenkins builds. Slave agents can be configured to provision clean environment (e.g. via VMs, docker,...) for each build and tear it down after build is done. This way Jenkins job can be of Maven type and any changes done by pre-build step will not affect others.
More information can be found here.
Consider docker. There you can run processes in isolated environments just as you want. Docker works in a way that it easily communicates with Jenkins.
As a benefit you can also use that docker container to run local builds in the same environment as they run in Jenkins.
I have a muti-module maven project, and I created a new module that depends on 3 other modules. (I already have a web app maven module that produces a .war file, now I need this)
This module's output is a .jar, and it has a few resources also which are:
spring context xml file
properties file
Now I want to produce a production ready folder so I can upload it to my server. I am hoping maven can do this for me.
I need the following layout:
myjar.jar
/libs/ (the 3 other maven modules that are dependancies)
/resources
Also, there are some generic dependancies that my parent pom.xml have like slf4j/log4j/ that I also need to package.
It would be cool if I could add a switch to mvn that will produce this like:
mvn clean install production
I plan on running this on my server via the command line.
I think what you are looking for is a Maven Assembly:
https://maven.apache.org/plugins/maven-assembly-plugin/
You can use profiles to disable the generation of the assembly by default (can speed up the development process).
#puce is right in that you may be best to use the Assembly Plugin. What you can't do easily is add another lifecycle 'production' to maven. If you have time you could write a plugin to do this, but you might be better off using a profile called 'production' or 'prod-deploy' to enable the coping into place on the server.
mvn clean install -Pprod-deploy
One thing to remember with maven is that it is very good at building projects in using it's conventions, but it is pretty bad at actually script things to happen out side of the build lifecycle.
I have on several occasions used external scripting tools such as ant/python/bash and groovy to first run the build using mvn then to script the deployment in a more natural language.
The intention of Maven is building not deployment in the sense to production. For this purpose i would recommend things like Chef or Puppet. From a technial point of view it's of course possible to handle such things via Maven. What also possible to build on CI solution like Jenkins. Furthermore it's possible to run a script from Jenkins to do the deployment on production.
If I have 6 modules in my project is it possible to build only one out of six ? without commenting out others ?
EDIT
Submodule will not work itselft because or parent tags. I need to install the parent first to make it build. how can I do it without installing parent
is it possible to build only one out of six ? without commenting out others ?
My understanding is that you want to launch maven from the aggregating project (i.e. a reactor build) but only build one module. This is possible using the -pl, --projects project list option (see advanced reactor options):
mvn --projects my-submodule install
This is a very powerful option, especially when combined with --aslo-make (to also build the projects on which the listed modules depend) or the --also-make-dependents (to also build the projects that depends on the listed modules). On the basis of your update, you might want this actually:
mvn --projects my-submodule --also-make install
Launching Maven from the directory of the module you want to build is of course an option but this won't allow you to do the things mentioned above nor to build a subset of all modules. For such use cases, the advanced reactor options are the way to go.
Opening a command shell, navigating to the submodule directory and executing mvn install (or whatever your preferred lifecycle is) should do the trick.
You can simply build the module by going in this module directory and run the mvn clean install.
However, note that with this method, the dependencies with the others modules will be taken from your local repository (or the entreprise repository).
Let's take a simple example:
project
+ commons
+ business
Now, imagine that you build, on the root directory the whole project, using the mvn clean install command. Consider that all your modules are in version 1.0.
Now, you move to version 1.1. If you run the mvn clean install on the business project only, it will try to get the 1.1 of module commons. You will then have an error, as Maven will not find any version 1.1 in your local repository.
Within Eclipse, assuming you have m2eclipse installed: Right-click on the module in question and choose Run As -> Maven package.