I am already using maven-dependency-plugin to inject some externally built dependencies in the WAR artifact during the prepare-package phase. It works well because I don't want those dependencies to be part of the code base the WAR is made out of.
The next thing I would like is to do something like a file dump of svn info (which lists basic versioning info, such as the versioning branch, latest revision etc) and have that file included in my webapps dir so that it can be visible in the deployed application. Of course, I can write a script in half a dozen languages to do this but I would like to do it completely inside Maven. I have been successful thus far in my CI efforts to contain all the tasks in the universe of maven plugins, which is nice.
I am aware of maven-scm-plugin but I am not sure it does what I need.
Related
Is it possible to deploy arbitrary zip archive artifacts to Nexus through Maven as snapshots?
We have a build step that is not supported through any application-specific Maven plugin. Instead, our full build and deployment process is as follows:
1) Maven POM compiles the Java component of the build, using Jenkins.
2) Shell script calls create a deployable artifact shell scripts were wrapped around calling a code generation application, which are then zipped up into an archive by the application itself. I need these artifacts deployed to Nexus as both snapshots, and as releases as appropriate.
I tried using the maven-assembly-plugin however this assumes that the plugin itself is creating the zip archive, not simply deploying an archive that was produced by some other method.
I would prefer to do this within Maven since our Nexus settings and credentials are already within the environment and do not need to be passed manually on the command line. Using the Nexus UI for this is not a viable option since this needs to be part of a standard build-deploy-test process, which may happen many times per day, for a couple dozen applications.
For completeness, I'm answering my own question (oh bother...)
I resolved this issue by using the maven-assembly-plugin, which allows you to define arbitrary artifacts, and deploy them (snapshots or releases) to Nexus. The assembly plugin uses a bill of materials (src.xml) that defines the exact contents of the artifact (either including or excluding files, directories, changing file permissions, etc). This can also be used for creating Java uber jars, but it appears that using the Maven Shade Plugin is the preferred method for creating uber jars.
Maven Assembly Plugin main webpage
I have a java application.
I can run the Maven Release task which will do some nice things for me:
Change Version number from 1.0.0-SNAPSHOT to 1.0.0
Increment the version number in my pom to 1.0.1-SNAPSHOT
Tag the release in source control
Upload the resulting package to my maven repository
I'd like to take things a step further. I have some post-build steps that I'm currently doing manually.
Update the launch4j configuration xml file with the appropriate version
Wrap the resulting jar in an executable using launch4j
Copy the resulting EXE into a package directory
Copy several supporting files into the package directory
Zip the package directory up
Email the package to my testers.
Eventually I'm going to have the additional task of building an installer leveraging the package directory.
I don't know that maven or ant are the right tools for automating my remaining 6 tasks, but it looks like either one or a combination of both could potentially accomplish what I need.
I could probably write a batch file or a simple perl script to do these things quicker than figuring out how to do them, but I would prefer to keep things as standard as possible so that I'm not taking on the additional responsibility of supporting a hack of a release process perpetually.
It seems to me that these are tasks that might not be standard part of build/release, but are commonly seen enough that there should be a best/most common practice for accomplishing them.
I would suggest to use the maven-assembly-plugin as well as the maven-launch4j-plugin during your build.
Update the launch4j configuration xml file with the appropriate version
put a placeholder into the configuration xml and let maven replace it during the
the build.
Wrap the resulting jar in an executable using launch4j
use the launch4j-maven-plugin to create the executable.
Copy the resulting EXE into a package directory
I would suggest to put the resulting artifact into a repository manager instead
of a separate folder, cause in Maven all artifacts are stored within
a repository. It might be necessary to setup your own repository manager
(Artifactory, Nexus, Archiva).
Copy several supporting files into the package directory
Using them as resources (src/main/resources) they will be copied
automatically.
Zip the package directory up
Use the maven-assembly-plugin to create a resulting zip file.
Email the package to my testers.
You can use a CI like Jenkins etc. to send the final mail or
you can take a look into maven-changes-plugin which might be solution.
This means all your mentioned steps can be handled by Maven during a usual build. This means in the end you can use the maven-release-plugin to produce a full release which contains all the above steps and produces all the wished artifacts.
If I were you, I would try a combination of the following:
Maven release plugin, unless it is not flexible enough for SCM related processes. If using SVN as SCM, I would use directly SVNKit(inside a custom Maven plugin), if flexibility is a concern.
Maven launch4j plugin.
Maven assembly plugin
Maven Ant Run plugin and/or one or more in-house Maven plugins for the remaining tasks.
I have an Ant script for automating a few tasks that are not build related by mainly as updates to the EAR file. These include calling SoapUI exe for some web services, unpacking the EAR file modifying a few classes and repacking it.
Now, for some reason I would like to do the same using maven scripts. From going through Stack Overflow and maven tutorial, I find that this can be replicated using Ant plugins inside maven. Also, I could not find direct substitutes for unpacking the EARs or calling executables in maven. This scripts will not have anything to do with the standard build process that maven is meant for and only caters to some cleanup or update of already deployed EAR.
So how do I go about this? Use Ant plugins inside maven or is there a better maven way to do this?
Thanks,
This may be an incomplete answer but -
Maven is more of a framework and it's going to want to build your application. What it will not do is modify source. It will process source files (.java, .ear, whatever) and put them in a target/ directory. Of course anything is possible (re: hackable) but this is off the rails as far as Maven is concerned if you want in place modification of source - besides, isn't the point of source that it's source, and if you're automating a task that should be part of your build, deploy, startup, etc.?
Maven resource filtering is how to process a source file and stamp dynamic information into your resources.
If you can provide more information regarding how you are processing your .ear files exactly you can possibly put together the pieces in the Maven process resources phase using existing plugins. Worst case you can write your own plugin.
We have a web application in which we are using Ant as a build tool. There is a urgent requirement to create web services (API) and this will be a separate project. For now, to make it available to our customers we have decided to use our web application and remove all unnecessary files (like velocity files, properties, xml etc) and make a jar of it. This jar will be used in our web service project.
In Maven, I want to checkout my web application svn branch, compile it, make a single jar of it and add as a dependency in my project. Is this possible? If yes, then please show me the way.
I'm new to Maven please explain your answers with more detail.
Thanks.
Short Answer
Get your .war deployed into a Maven Repository (local or remote) from your ant build
Child Projects will embed your .war as a dependency, creating a war with your custom services + your original .war file
It is advised that those Child Projects turn into an Archetype, so creating custom services gets easier
Long Answer
From your SCM, you could modify your build.xml file and use Maven Tasks for Ant.
In particular, the install and deploy examples are helpful in order to guide you on deployment your .war into a Maven repository (local or remote)
Then, a .war artifact (when accessible from a Repository) is able to be consumed from other .war applications.
Look into the maven-war-plugin Overlays Feature. In particular, this answer offers you more advice:
combine different maven web-projects into a single project
Other than that, I suggest you could also combine with Maven Archetypes (they're now easier than ever), so you could create skeleton projects for your webservices, already depending on this .war dependency.
Every time I make a new proper project using Maven hosted on Github I have to go look at either one of my own old projects and copy the pom file or I go find a project that I think does a good job and copy there POM file. Then I have to go search and replace things like project name... etc.
Now Maven has a solution to this through archetypes but I have yet to see one that is modern enough such that it:
Uses the release plugin and deploys to SonaType Central Maven reop.
Connects to Github (meaning the scm connections and release plugin work do the right thing)
Makes all three jar artifacts (sources, javadoc, and regular jar)
I have contemplated make some giter8 templates but was hoping somebody already did something like this (most of the g8 templates are for sbt).
You can use com.jcabi:parent:pom which does exactly what you need and many more. It deploys to Sonatype, defines common dependencies with versions, pre-configures most popular plugins, and defines a few useful profiles.
This article explains more: Don't Repeat Yourself in Maven POMs; Use Jcabi-Parent
You could have a look at the parent pom released by Sonatype. It's intended to be used as a parent pom for projects that deploy to oss.sonatype.org (which may or may not be promoted to Maven Central).
When the sonatype-oss-release profile is enabled, it will ensure that sources and javadocs are built. It also includes an example of the <scm> pom element.
It turns out its incredible easy to create your own maven archetype.
Just make a generic project with stuff you like to use
In the project directory run mvn archetype:create-from-project
Generally Maven guesses the right things to make variable but if not you just edit the Velocity templates.
Install your archetype locally with mvn install
To use your new archetype: mvn archetype:generate -DarchetypeGroupId=com.mygroup -DarchetypeArtifactId=my-archetype
Now the only caveat is that there is not very good doc on the web that I could find on the archetype system. Like its unclear what variables you have available to you for Velocity (although most of them are obvious).
http://maven.apache.org/archetype/maven-archetype-plugin/create-from-project-mojo.html