I'd like to rename all dependencies to strip off SNAPSHOT so my file handling scripts and installer don't break when I release.
I presently, use maven-dependency-plugin:copy-dependencies and copy with individual artifacts listed and renamed. I'd rather have something akin to ant's regex mapper establish a renaming rule.
Presently, I plan to copy-dependencies to 1st stage directory in prepare-package and use antrun's copy + regex mapper in package to copy/rename but that wastes time and space.
Is there a more direct way to approach this problem? Can the dependency plugin handle rule based renames?
Thanks
Peter
If you just want to remove the version from the dependencies, then add the stripVersion parameter to the plugin configuration:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.4</version>
<executions>
<execution>
<id>copy-dependencies</id>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<silent>true</silent>
<outputDirectory>libs</outputDirectory>
<stripVersion>true</stripVersion>
<includeTypes>swc</includeTypes>
<excludeGroupIds>com.adobe.flex.framework</excludeGroupIds>
<excludeTypes>pom</excludeTypes>
</configuration>
</execution>
</executions>
</plugin>
Related
We're using the Maven plugin git-commit-id-maven-plugin and want to make both hash and dirty status available to our build. Our plugin:
<plugin>
<groupId>io.github.git-commit-id</groupId>
<artifactId>git-commit-id-maven-plugin</artifactId>
<version>5.0.0</version>
<executions>
<execution>
<id>get-the-git-infos</id>
<goals>
<goal>revision</goal>
</goals>
<phase>validate</phase>
</execution>
</executions>
</plugin>
E.g. we have a filtered properties file with:
git=${git.commit.id.describe}
However this describe-variant cares about tags, which we do not want into our usage of it. If doing this from terminal I see from other questions and answers that this is easily done.
E.g. ${git.commit.id.describe} might return:
mytag-hash-dirty
Our ideal result would be only:
hash-dirty
How can I achieve the "hash and dirty status"-only result using the git-commit-id-maven-plugin with Maven?
I am trying to replace maven exec with MavenInvokerPlugin because of problems on Jenkins with forwarding the maven settings file.
So in bash it looks straight:
mvn dependency:copy-dependencies#resolve-maven-deps
My translation to MavenInvokerPlugin configuration is
<plugin>
<artifactId>maven-invoker-plugin</artifactId>
<version>3.0.1</version>
<configuration>
<projectsDirectory>${project.basedir}/src/main/docker</projectsDirectory>
<localRepositoryPath>${project.build.mavenDependencies}</localRepositoryPath>
<goal>dependency:copy-dependencies#resolve-maven-deps</goal>
</configuration>
<executions>
<execution>
<id>integration-test</id>
<goals>
<goal>run</goal>
</goals>
<phase>compile</phase>
</execution>
</executions>
</plugin>
It looks like that execution id is completely ignored, because I tried random strings and mvn builds the project with success.
mvn dependency:copy-dependencies#asdfasdfa
So I'd like to know whether this feature is supported at all and what I am doing wrong.
P.S. I know that calling maven out of maven is anti pattern, but here is exactly that rare case when there is no other way.
After looking at projects using maven invoker I figured out the trick.
goal tag is not used, instead provide invokerPropertiesFile:
<pom>${project.basedir}/xxx/pom.xml</pom>
<invokerPropertiesFile>${project.basedir}/invoker.properties</invokerPropertiesFile>
content of the file:
invoker.goals=compile -P resolve-maven-deps
I'm try to use the maven-dependency-plugin's copy-dependencies goal.
I checked its official example with the snippet below.
My problem is: the dependencies are always copied to
target\dependency folder, even if I specify an <outputDirectory> node.
Here is the part of my pom.xml:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.10</version>
<executions>
<execution>
<id>copy-dependencies</id>
<phase>package</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
</execution>
<configuration>
<outputDirectory>${project.build.directory}/aaa</outputDirectory>
<overWriteReleases>true</overWriteReleases>
<overWriteSnapshots>true</overWriteSnapshots>
<overWriteIfNewer>true</overWriteIfNewer>
</configuration>
</executions>
</plugin>
</plugins>
</build>
Question: What I'm doing wrong? Is it possible to declare the output directory outside of the project? For example: c:\temp ?
You configured an execution of the maven-dependency-plugin with a configuration only defined within its scope, hence it will only be picked up by the plugin during a mvn package invocation, that is, while performing the package phase and the plugin (executions) having a binding to it.
If you invoke the plugin from command line as following:
mvn dependency:copy-dependencies
It will indeed only use default values, since your configuration will be ignored.
In fact, the default value for the outputDirectory option is indeed:
Default: ${project.build.directory}/dependency
In maven, a plugin configuration can be defined as general configuration (outside of an execution section, applied to all executions and to command line invocations) or per execution (within an execution section, like in your case).
In your case, you probably want the configuration to be valid in both cases, so simply change your plugin section to the following:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.10</version>
<configuration>
<outputDirectory>${project.build.directory}/aaa</outputDirectory>
<overWriteReleases>true</overWriteReleases>
<overWriteSnapshots>true</overWriteSnapshots>
<overWriteIfNewer>true</overWriteIfNewer>
</configuration>
<executions>
<execution>
<id>copy-dependencies</id>
<phase>package</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
Note: we moved up the configuration, from execution scope to plugin (global) scope.
Also note, in the configuration above we kept the execution, which means maven will always execute this plugin goal at each an every mvn package invocation. If you don't want this behavior and only expect to use the command line execution, then you can remove the executions section at all.
Since Maven 3.3.1 it's also possible (see the note at the very end of Using the executions Tag section):
Since Maven 3.3.1 this is not the case anymore as you can specify on the command line the execution id for direct plugin goal invocation.
to execute copy-dependencies execution directly not modifying your pom at all:
mvn dependency:copy-dependencies#copy-dependencies
Note that of the two copy-dependencies separated by #, the former refers to the plugin goal and the latter refers to the execution id. And general direct invocation of an execution is:
mvn <plugin-prefix>:<goal>#<execution>
See also accepted answer to almost the same question
I ve got an maven based web project including the "normal" directory structure.
I've the need to generate to war artifacts, one is the normal app, the other is an admin "version", which is realised by using 2 different maven-profiles.
In case of the admin version I need to rename a JSP-file just before the war file is packaged.
How can I do this?
Which maven-plugin fits this requirement?
IMHO you must use ant run to rename your files and attach this execution to prepare-package phase.
sorry, but to copy/rename the JSPs during prepare-package phase doesn't work, because the files are not yet in the target directory at this point.
sample code:
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.7</version>
<executions>
<execution>
<phase>prepare-package</phase>
<configuration>
<target>
<copy file="${project.build.directory}\myProject\loginAdmin.jsp"
tofile="${project.build.directory}\myProject\loginUser.jsp"/>
</target>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
im at the point in my project where im moving data connections to the beta and production databases for testing. obviously, having the alpha database credentials stored in the source repository is fine, but the beta and production credentials, id be put in front of a firing squad for that one.
i know maven can have a {userdir}/build.properties file. this is the file i want to use to keep the db credentials out of the source repository. but i can't seem to get maven to figure out that for file x.cfg.xml it has to replace values.
so i have in one of my hibernate.cfg.xml files this line
<property name="hibernate.connection.url">#ssoBetaUrl#</property>
now how do i get maven to replace that variable with the value thats in the {userdir}/build.properties file?
edit-------------
ive been playing with the properties-maven-plugin plugin but i seem to not be able to get it to fire. i put this in my parent pom
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<version>1.0-alpha-2</version>
<executions>
<execution>
<id>read-properties</id>
<phase>initialize</phase>
<goals>
<goal>read-project-properties</goal>
</goals>
</execution>
</executions>
</plugin>
but when it builds, it does not fire. if im reading http://maven.apache.org/maven-1.x/reference/properties.html right it should find the build properties file in the ~/build.properties folder and go from there, but im not sure.
I think you are approaching this the wrong way around. Instead of having the build process bake the appropriate connection details into the JAR file you should instead have the program look for a configuration file at startup.
Typically, my hibernate based apps, will look for a file under %user.home&/.appname/config.properties and load DB credentials and other deployment specfic data from there. If the file is missing, a default version can be included in the JAR and copied to this location (on initial startup so you don't have to copy-paste the file to new systems) that is then edited with appropriate settings.
This way, you can use the same build to produce JAR (or WAR) files for test and production servers, the differences will be in the (presumably already deployed) configuration files. This also makes it possible to have multiple production deployments, each talking to a different database, without any complications in the build process.
You could use two plugins.
properties-maven-plugin
replacer
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<version>1.0-alpha-1</version>
<executions>
<execution>
<phase>initialize</phase>
<goals>
<goal>read-project-properties</goal>
</goals>
<configuration>
<files>
<file>{userdir}/build.properties</file>
</files>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>com.google.code.maven-replacer-plugin</groupId>
<artifactId>replacer</artifactId>
<version>1.5.2</version>
<executions>
<execution>
<phase>prepare-package</phase>
<goals>
<goal>replace</goal>
</goals>
</execution>
</executions>
<configuration>
<includes>
<include>target/**/*.*</include>
</includes>
<replacements>
<replacement>
<token>#ssoBetaUrl#</token>
<value>http://[anyURL]</value>
</replacement>
</replacements>
</configuration>
</plugin>