the maven release plugin doesn't update the pom files which are included:
<plugin>
<artifactId>maven-invoker-plugin</artifactId>
<version>1.6</version>
<executions>
<execution>
....
....
<configuration>
<projectsDirectory>.</projectsDirectory>
<streamLogs>true</streamLogs>
<pomIncludes>
<pomInclude>pomDisContainer.xml</pomInclude>
</pomIncludes>
how can i force the release plugin to update all my pom.xml files?
regards
Perhaps you are looking at this from the wrong direction. Would a better solution be to have the Maven Invoker Plugin update the invoked pom.xml files every time instead?
The Invoker plugin will automatically replace properties in the pom, providing they are using the alternative syntax:
#project.version#
Will be replaced by the invoking project's version.
Related
What I am trying to do, is to obfuscate a certain packages in a multi module application, before it gets installed to my local repository, so that the final package will be an EAR file which contains obfuscated jars.
I tried to obfuscate the jars during EAR building process without success. Now i want to build the EAR with obfuscated jars instead ob obfuscating then during the build.
So I've got the following plugin configuration:
<plugin>
<groupId>com.github.wvengen</groupId>
<artifactId>proguard-maven-plugin</artifactId>
<version>2.0.11</version>
<dependencies>
<dependency>
<groupId>net.sf.proguard</groupId>
<artifactId>proguard-base</artifactId>
<version>${version.proguard}</version>
</dependency>
</dependencies>
<executions>
<execution>
<phase>process-classes</phase>
<goals>
<goal>proguard</goal>
</goals>
</execution>
</executions>
<configuration>
...
</configuration>
</plugin>
So there are two problems for me:
Progruard always runs after the install phase, so that the EAR build always gets the not obfuscated jars
I always have to add proguard:proguard to the maven command, which of course fails in a multi module project where some modules don't have to be obfuscated
So my questions:
How can I obfuscate the package before it gets installed?
How can I make plugins like this one run on default without adding <phase>:<goal> to the maven call?
Thnx.
It seems that for the proguard plugin to work, JAR files are needed. Perhaps you can achieve this by attaching the proguard plugin's proguard goal to the package phase (and not process-classes phase) of the default Maven build life cycle as proposed here by Alexey Shmalko. It's not clear to me if you are using the maven-shade-plugin, but if you are, then place the proguard plugin configuration your in pom.xml after that of maven-shade-plugin (this is because both these plugin attach to the same phase: package).
My expectation is that since package phase is achieved before install phase, it should give you the effect you are looking for.
I have a project with client and server components. Both have their own Maven multi-module build projects.
The correct server version must be referenced in various frontend modules. To accomplish this I set a property in my client parent POM like this:
<properties>
<server.version>1.2.3</server.version>
</properties>
Now I'd like to update the version number in the POM (i.e. not just injecting a different version from the command line with -D...) during/after a Jenkins build job. Is there a way to do this?
I found the com.google.code.maven-replacer-plugin:replacer Maven plugin which works perfectly for my case. It accepts an xpath and a regex to define what to replace in an XML file.
Example plugin configuration:
<plugin>
<groupId>com.google.code.maven-replacer-plugin</groupId>
<artifactId>replacer</artifactId>
<version>1.5.3</version>
<configuration>
<file>${project.basedir}/pom.xml</file>
<xpath>/project/properties/server.version/text()</xpath>
<token>^.*$</token>
<value>${newServerVersion}</value>
</configuration>
</plugin>
And the plugin can be run for each affected maven module:
mvn --non-recursive replacer:replace -DnewServerVersion=xxxx
At itembase we use Jenkins Pipeline Plugin. It comes with some useful built in functions like for example readMavenPom and writeMavenPom. So in your build pipeline you could do something like:
def pom = readMavenPom file: 'pom.xml'
//Do some manipulation
writeMavenPom model: pom
Did you check maven versions plugin?
(Tbe website is shutdown but the plugin page is still avaiable in google cache)
mvn -DnewVersion=<version> versions:set
I want to use svn revision number of pom file as its version.
In pom.xml, if we use buildnumber-maven-plugin, we need to define scm repository url, so that it can check to repository and use buildnumber.
But i want to ask that when we have checkedout code to our system, isn't there any way to get buildnumber without using scm urls. As revision number is stored as subversion in property of each file. we can see it if we right click on file and go to properties.
I want to use buildnumber in version tag of pom and other module's buildnumber in their vaersion tag in dependencies to them.
So if i can store all subversion numbers initially, infact earlier than resolving dependencies, then these subversions can be placed in version of module in dependency and also in version of each pom file.
Problem is that dependencies are resolved before plugin reads version number ( this is what i think), so it cannot resolve expression.
I tried it using properties-maven-plugin to write pom's version number in a file and then read it in other module's pom which is dependent on it. But dependencies are to be resolved before execution of any plugin is started.
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<version>1.0-alpha-2</version>
<executions>
<execution>
<id>pre-clean-config</id>
<phase>validate</phase>
<goals>
<goal>read-project-properties</goal>
</goals>
<configuration>
<files>
<file>${project.basedir}/../app.properties</file>
</files>
</configuration>
</execution>
</executions>
</plugin>
So, it is not working.
Starting with Maven 3.2.1 you can define a property ${revision} which you can use in your versions like this:
<project...>
<groupId>..</groupId>
<artifactId>...</artifactId>
<version>1.0-${revision}</version>
...
The result of this you need to give a property while calling Maven like this:
mvn -Drevision=123456 clean package
This will also work in dependencies etc. Currently one drawback is that you always creating a release from maven's point of view.
I have Maven javadoc plugin working nicely right now, but I do not know how to add it to the remote directory via scp.
How do I transfer the javadoc files via scp, but AFTER they have been generated? Can this automatically happen when I call site:site?
Thanks!
maven-javadoc-plugin doesn't attach to any phase/goal by default, you need configure it manually in pom.xml.
See Generate Javadocs As Part Of Project Reports:
To generate javadocs as part of the site generation, you should add the Javadoc Plugin in the section of your pom:
<project>
...
<reporting>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.8.1</version>
<configuration>
...
</configuration>
</plugin>
</plugins>
...
</reporting>
...
</project>
When you execute mvn site, the javadocs will be generated and included in the generated site. A link to the javadocs will be added in the Project Reports menu.
Alternatively, if you use maven-release-plugin, javadoc generation (and upload) is automatically handled by default, see here:
The following delvierables are created and deployed to local and remoted repositories after the execution of the release:perform goal has finished.
artifact id-version.jar
The binaries for the current release of the project.
artifact id-version-javadoc.jar
The javadoc explaining the current functionality of the classes within the current release.
artifact id-version-source.jar
The source code revisions used to build the current release of the project.
artifact id-version.pom
The contents of the pom.xml file used to create the current release of the project.
If you want to attach javadoc generation to some phase/goal other than site, check out How to deploy Javadoc jar file?
I am using the preparationGoals configuration option of the Maven release plugin to transform additional files to reflect the version of the project being released. This works beautifully.
The problem is that when executing the commit, the plugin explicitly specifies that only the pom.xml files should be included thus leaving my other files uncommited:
[INFO] Executing: /bin/sh -c cd /Users/jw/dev/Test && git commit --verbose -F /var/folders/w0/hr1h_7h50f3_pwd_nrk9l808000195/T/maven-scm-114713951.commit pom.xml library/pom.xml sample/pom.xml
Is there any way for me to override this behavior and specify additional files or globs to include in the commit?
(I also need this behavior for the completionGoals as well which I have configured to do that same transformation)
I also need to commit some additional files (changed by Maven Replacer plugin). I did it in the following way:
First I configured Maven Release plugin to execute additional goals:
<plugin>
<artifactId>maven-release-plugin</artifactId>
<version>2.5.3</version>
<configuration>
<preparationGoals>-Prelease -DreplacerVersion="${releaseVersion}" clean replacer:replace scm:checkin verify</preparationGoals>
<completionGoals>-Prelease -DreplacerVersion="${developmentVersion}" clean replacer:replace scm:checkin verify</completionGoals>
</configuration>
</plugin>
release profile defines configuration of Maven SCM plugin
replacerVersion argument is used by Maven Replacer plugin to set correct version in some files
clean is a standard goal run by Maven Release plugin (default: clean verify)
replacer:replace goal is responsible for modifying files
scm:checkin does commit and push
verify is a standard goal run by Maven Release plugin (default: clean verify)
Next I configured Maven Replacer plugin:
<plugin>
<groupId>com.google.code.maven-replacer-plugin</groupId>
<artifactId>replacer</artifactId>
<version>1.5.3</version>
<configuration>
<includes>
<include>${basedir}/file1.txt</include>
<include>${basedir}/file2.txt</include>
</includes>
<replacements>
<replacement>
<token><![CDATA[<pattern>.*</pattern>]]></token>
<value><![CDATA[<pattern>${replacerVersion}</pattern>]]></value>
</replacement>
</replacements>
</configuration>
</plugin>
${replacerVersion} allows to use the same configuration for changing from a development to a release and next from the release to a next development version.
Finally I defined which version of Maven SCM plugin I want to use:
<plugin>
<artifactId>maven-scm-plugin</artifactId>
<version>1.9.5</version>
</plugin>
and configuration it in the release profile (I defined it in the profile to prevent accidental commits during non-release build):
<profile>
<id>release</id>
<build>
<pluginManagement>
<plugins>
<plugin>
<artifactId>maven-scm-plugin</artifactId>
<configuration>
<message>[maven-scm-plugin] set ${replacerVersion} version in files</message>
<includes>file1.txt, file2.txt</includes>
</configuration>
</plugin>
</plugins>
</pluginManagement>
</build>
</profile>
Thanks to that after executing a command:
mvn release:prepare -DdevelopmentVersion=1.2.1-SNAPSHOT -DreleaseVersion=1.2.0 -Dtag=1.2.0
I see 4 commits:
[maven-scm-plugin] set 1.2.0 version in files
[maven-release-plugin] prepare release 1.2.0
[maven-scm-plugin] set 1.2.1-SNAPSHOT version in files
[maven-release-plugin] prepare for next development iteration
Could you use the maven-scm-plugin? Add a plugin execution running the scm:checkin goal to commit the files you want. Bind it to a phase that will execute when preparationGoals are run (if you specified one or more phases as the value for that element), or include the scm:checkin goal in preparationGoals directly.
It appears the failure to allow specification of additional tag files is actually a bug in Maven. On line 130 in the org.apache.maven.shared.release.phase.AbstractScmCommitPhase class of the Maven Release Plugin, there are references to a "commitByProject" flag first introduced in Maven 2.0-beta-7.
A branch is used to determine the mechanism by which files are added to the Maven release:prepare commit. The SCM plugin is loaded with files in advance of the commit using the SCMFileSet class. One of the branch instantiations of that class may have been trying to add all files in the base directory, but it doesn't work that way in SCM.
This is a point where a fix could be implemented to take a list of files or to add a directory of files to commit.
Bottom line, after deep-diving into a debug execution of the Maven Release Plugin, it is invoking SCM Plugin to add only the POMs from the repos. Changing the poorly documented "commitByProject" flag has zero impact on the results in respect to which files are added into the SCM commit.
Another workaround is to configure another plugin (e.g. Maven AntRun Plugin) to manually run git add ., and then execute that as part of preparationGoals as well. This just happens to work and the modified files are part of the "[maven-release-plugin] prepare release ..." commit. However, I am not sure if this behavior is guaranteed, so this might rely on implementation details of the Maven Release Plugin.
Example configuration using the Maven AntRun Plugin to run git add:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>3.0.0-M6</version>
<configuration>
<preparationGoals>
... other goals ...
antrun:run#git-add-changed
</preparationGoals>
</configuration>
</plugin>
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<version>3.1.0</version>
<executions>
<execution>
<id>git-add-changed</id>
<goals>
<goal>run</goal>
</goals>
<configuration>
<target>
<exec executable="git" dir="${project.basedir}" failonerror="true">
<arg value="add" />
<arg value="." />
</exec>
</target>
</configuration>
</execution>
</executions>
</plugin>
The main advantage of this compared to using the Maven SCM Plugin is that this does not require you to know in advance which files were modified and have to be committed. This can be useful when you replace a certain string in multiple files, e.g. #since NEXT in the Javadoc of all source files. With the scm:add goal of the Maven SCM Plugin the includes parameter seems to execute git add for all matching files separately, which will be slower and can cause issues when it matches by accident a file listed in .gitignore.