Maven Release Plugin — Difference Between “preparationGoals” and “goals” in configuration
Maven Release Plugin lets you release your project easily. However, often during release you want to perform some additional goals. For example, copy the artifact to another server.
There are several ways to do that. Among those is possibility to define goals during Maven release by adding goals or preparationGoals in configuration.
What is the difference between those? When you specify goals, you take over the deployment phase. I mean if you want to run some maven task1 task2 and then still continue deploying your released artifact to the repository, you need to specify the following:
<plugin>
<artifactId>maven-release-plugin</artifactId>
<version>2.0</version>
<configuration>
<goals>task1 task2 deploy</goals>
</configuration>
</plugin>
But if you want to do some additional task, it is better to use preparationGoals. Released artifact anyway will be deployed to the repository, so you don't need to specify deploy explicitly.
Moreover, preprationGoals are activated just before the commit.
Copy Files with SCP Using Maven
You can use Maven AntRun Plugin and Ant SCP task in order to transfer files with SCP:
Building Obfuscated Signed Java Web Start Applications with Maven
I have Java Web Start application with several libraries, some of which I want to obfuscate before the release. Unfortunately, I cannot use Webstart Maven Plugin since it works correctly only when all the dependencies, which will be assembled, are already present in the repository. In my case, I want to obfuscate libraries on-the-fly, sign them, put into zip file and deploy to my repository.
Instead, I attach the following chain of plugins to maven build lifecycle:
- Download keystore (refer to my older post
- Download all dependencies (except ones, which I will obfuscate) with Maven Dependency Plugin
- Run ProGuard on needed jars with Maven ProGuard Plugin
- Sign all the jars with Maven Jarsigner Plugin
- Filter JNLP file with Maven Resources Plugin
- Assemble application with Maven Assembly Plugin
Obfuscating Several Jars in One Single Maven Build with ProGuard
ProGuard is nice and free tool for obfuscating your code. Actually, it can do a lot more: shrink, optimize and verify your application. But here we will stick solely on obfuscating several jars in one build with ProGuard and Maven.
There are some documentation on ProGuard Maven Plugin website, something on Stack Overflow and ofcourse in official documentation.
Say, you have a complex Java Web Start application consisting of several modules. And you want to obfuscate each module before release. Of course, you do not want to obfuscate for internal usage, but want to do it only before release. What you can do is to use
Signing Jars on a Build Server
Here I will discuss a problem which occurs, when you want to sign a jar in your continuous integration. Where keystore should be kept? A solution is provided using local maven repository.
However, we do not want to hardcode path to the keystore in our pom.xml. But keystore is pretty static, so we can copy it to all developers machines and build server! But this is solution, since different machines can have different operation systems.
But since keystore is static, we can
Providing Build Information Automatically for Every Maven Project
This article describes a possibility to automatically inject properties file with build information into any Maven module.
Sometimes you need to provide version and build information in "About" dialog of the application. You can easily create a simple properties file in your resources folder and apply filtering on it, where build version and timestamp would be automatically replaced on each maven build. But what to do when you have dozen of such project? Is there a way to do this automatically? Indeed, there is.
The idea is simple. We start by creating a Maven "template" project which would just hold a general build properties file. Then we create a parent project which would know how to intervene into a build cycle and inject build properties file. Then we simply inherit this parent project in all other projects which require such automatic build numbering injection.
As an example we will only
Maven Versioning Problems Having Different Purpose Modules Under One Parent
If you have modules with different purpose, you eventually hit the versioning problem.
When you change only one module and want to make a release, usually you go for parent project release, since otherwise there will be a mess having modules with different numbers. But another module was not changed! But the versioning number was increased.
Here is live example. You have a maven project. Then, you introduce an
Modularized Installers with IzPack
link to dependency plugin
One may want to modularize installer's components and support them separately. It is easy to do with IzPack too!
In this example, we suppose, that installers are built with Maven.
Ok, now we
Dumping Maven Dependencies to Specific Folder
In order to dump all specified dependencies, which are specified in pom.xml, one has to use Maven Dependency Plugin:
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<outputDirectory>${dependencies.dir}</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
where ${dependencies.dir} stands for folder where to dump the dependencies.
Why Cyclic Project Dependencies Are Bad
Imagine you have
- a project
projectAwith submodulesprojectA.module1and-
projectA.module2
- a project
projectB
projectB dependes on projectA.module1.
projectA.module2 depends on projectA.module1 too and on projectB.
What is wrong here? Cyclic dependency! When