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>
Related
I'm new to Apache Maven and would like to know a way to create a windows cabinet file as part of the maven build life cycle.
I was hoping there would be a plugin for the task, but can't seem to locate one.
Help appreciated.
Edit: It looks like the Ant Cab task relies on a dependency that no longer exists. Other resources point to using a Cab creator written in Java, the lcab tool if you're on Linux, or makecab.exe on Windows. Another option would be to use a zip file, which is more widely supported.
What you're looking for the AntRun plugin for Maven, which will then give you access to the Ant Cab task.
Here is an untested example of what you would add to your POM in the plugins section:
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<id>ant-example</id>
<phase>prepare-package</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<cab cabfile="target/example.cab" basedir="deploy/folder"/>
</tasks>
</configuration>
</execution>
</executions>
</plugin>
I have a Maven assembly that after unpacking the tar, creates three directories
each containing a /lib directory. So e.g.
folder1/lib
folder2/lib
folder3/lib
Currently, I am packing a same .jar in each of these /lib directories. Since this is a waste of space, I was wondering if I could have just one copy of that .jar and create something like a symlink for other two locations that could reference that .jar?
Thanks!
Here is my solution with maven-antrun-plugin for very similar situation. Zookeeper dependencies are previously placed into ${basedir}/target/package/lib by maven-dependency-plugin. Now I'm creating symlinks for all libraries into ${basedir}/target/package/lib/zookeeper/lib which point 2 dirs upper.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<id>prepare-delivery</id>
<phase>package</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<target>
<!-- Prepare zookeeper layout. -->
<mkdir dir="${basedir}/target/package/lib/zookeeper/lib"/>
<apply executable="ln" dir="${basedir}/target/package/lib/zookeeper/lib" relative="true">
<arg value="-s"/>
<srcfile prefix="../../"/>
<targetfile/>
<fileset dir="${basedir}/target/package/lib" includes="**"/>
<mapper type="identity"/>
</apply>
</target>
</configuration>
</execution>
</executions>
</plugin>
Plugin management for antrun is set as following:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.8</version>
</plugin>
I believe this is unsupported in Maven packaging and assembly. Another Stack Overflow question from just a year ago asked the same thing and got the "unsupported" answer. And there have been two JIRAs on this feature (at least) that have been open for quite some time: one for the assembly plugin and one for Plexus components. I would say this the odds of this ever being directly supported are not good.
Just FYI, if I say "source project," I'll be refering to the project that assembled the tar. If I say "destination project," I'll mean the one unpacking the tar. This is assuming you have Maven projects on both sides- if that assumption is wrong, you should rely on command line utilities to do the tar-ing or untar-ing for you.
Since it sounds to me like you are unpacking the tar in the context of a Maven build, there are ways of working around this. As far as I know, the best solution if symlinking is important to you is to use either the junction plugin, the exec-maven-plugin, or the maven-antrun-plugin.
The junction plugin has the advantage of being portable, even on Windows. The problem is the project doing the unpacking must have explicit knowledge of the structure of the original structure of the tar, which is generally not desirable as it will now have to be updated should the intended symlinking that is changed. The plugin also seems to be pretty unmaintained, so there's that.
The exec plugin will allow you to call commandline utilities or scripts to do your linking, but you will have to toy with profiles to get crossplatform capabilities. The best benefit of doing it this way is that the project doing the unpacking is completely agnostic of the original structure of the tar. The details of the mechanism are in the question from a year ago that I mentioned above.
For my project, I am probably going to use antrun for Ant's symlink task- it is possible to have Ant record all symlinks to a file on the source side, and then package that file along with Maven. The receiving project can then check for the file and recreate its symlinks. This allows the symlinking intended for the tar distribution to be changed from its source project with no changes on the destination project. My project only supports OS X and Linux, so this is acceptable- you will need to decide which is best for you.
In either case, you will unfortunately have a situation where the project doing the unpacking must have knowledge about the way the tar was before being packed.
You can use symlink task/goal of ant-run plugin
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.8</version>
<executions>
<execution>
<phase>package</phase>
<configuration>
<target>
<symlink link="folder2/lib/${project.artifactId}-${project.version}.jar"
resource="folder1/lib/${project.artifactId}-${project.version}.jar"/>
<symlink link="folder3/lib/${project.artifactId}-${project.version}.jar"
resource="folder1/lib/${project.artifactId}-${project.version}.jar"/>
</target>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
If you want the symlinks to have relative path, you can give relative path in resource like below
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.8</version>
<executions>
<execution>
<phase>package</phase>
<configuration>
<target>
<symlink link="folder2/lib/${project.artifactId}-${project.version}.jar"
resource="../../folder1/lib/${project.artifactId}-${project.version}.jar"/>
<symlink link="folder3/lib/${project.artifactId}-${project.version}.jar"
resource="../../folder1/lib/${project.artifactId}-${project.version}.jar"/>
</target>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
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>
i have seen this question, but the answer doesn't quite explain the technique.
I run my application from the target directory after maven is run on the server.
I have a folder (/src/main/webapp/WEB-INF/scripts) which once after maven is run is copied to the target directory (/target/[project]/WEB-INF/scripts).
I need to make sure all of the files within this directory (recursively) receive executable permissions.
How can I achieve this without ant?
You can try to do the put the assembly-plugin into the pre-package phase and copy the files to the target/classes/... folder (i'm not sure about the exact name of the folder) and during the copy via the assembly-plugin you can change the permissions. Tha the war plugin will pickup the files and will package them into the war. I'm not sure if this works perfectly. I never tried that.
You can use the "exec-maven-plugin" with "chmod" executable at "prepare-package" stage in your pom.xml:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>${org.codehaus.mojo.version}</version>
<executions>
<execution>
<id>chmod</id>
<phase>prepare-package</phase>
<goals>
<goal>exec</goal>
</goals>
<configuration>
<executable>chmod</executable>
<arguments>
<argument>+x</argument>
<argument>${project.build.directory}/[project]/WEB-INF/scripts/myscript.sh</argument>
</arguments>
</configuration>
</execution>
</executions>
</plugin>
It worked for me. I wanted to put the exec permission on a binary copied from source to target/classes.
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>