I want to deploy a war that I have created using maven to wildfly using the wildfly-maven-plugin.
The final name of the war is something like: my-war-1.0.war
The war also contains a jboss-web.xml specifying the context root (e.g. /my-war)
Problem Description
If I now deploy the war to wildfly I will get a "my-war-1.0.war" deployment.
If I later want to deploy a new version (e.g. the war is now named my-war-1.1.war) I get a conflict as the context root is already known but the deployment has a new name.
Is there a way using the wildfly-maven-plugin to deploy a "my-war.war" instead?
I need to keep the original final build name inside the maven build for versioning and deploying to our nexus.
The simplest solution is to use the <finalName/> element on the <build/> configuration.
<build>
<finalName>${project.artifactId}</finalName>
</build>
You can use the maven war plugin to rename the final war. For Eg:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.6</version>
<configuration>
<warName>my-war</warName>
</configuration>
</plugin>
</plugins>
</build>
This will always generate the war with the name my-war.war in your "target" directory.
I found out that I can use the parameters <name/> and <runtimeName/> inside the <configuration/> of the maven-wildfly-plugin.
That way I can specify what the deployment should be called on the server and each time just replace it. It is important to have the two parameters end in ".war", otherwise you will get a 404 error.
Using this method I can keep the original name of the final build result containing the version (my-app-1.0.war) and archive it inside our internal nexus repository.
Related
I want to version my WAR to make DevOps lives easier, i.e.: foo-3.2.0.war. In pom.xml, I have:
<build>
<finalName>foo</finalName>
but also
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>${maven-war-plugin.version}</version>
<configuration>
<warName>${project.artifactId}-${project.version}</warName>
that imparts the current version in pom.xml to the WAR filename. So far, so good.
The problem becomes that the version is required in the URL when deployed to Tomcat. I want my application accessed thus: http://hostname:port/foo and not http://hostname:port/foo-3.2.0 (etc.) because I'd have to annoy my consumer with the version change.
Is it possible to work around this problem without just going back to an unversioned WAR file?
You can use ${project.artifactId}##${project.version} as naming scheme.
The part after ## will not be part of the context name (cf. parallel deployment).
I am using the Maven WildFly plugin and have the following in my pom.xml (version is 2.0.1.Final and path points to a local WildFly 8.2.1.Final server).
<build>
<plugins>
<plugin>
<groupId>org.wildfly.plugins</groupId>
<artifactId>wildfly-maven-plugin</artifactId>
<version>${wildfly.version}</version>
<configuration>
<jboss-home>${wildfly.path}</jboss-home>
</configuration>
</plugin>
</plugins>
</build>
The application is getting deployed as localhost:8080/myArtifactId-myVersion which is expected as the default behavior is to use the WAR name. However, I want to change the context root so that the application is accessible via localhost:8080/ (i.e. I want a blank context root).
Method 1: Change the Pom Configuration
I can change the finalName build setting in my pom.xml as follows.
<build>
<finalName>newContextRoot</finalName>
</build>
This correctly updates the url to localhost:8080/newContextRoot. I then tried to change it to be a blank value.
<build>
<finalName></finalName>
</build>
However, this results in a Value must not be empty error in my IDE and when I try to build it fails, saying Error assembling WAR: A zip file cannot include itself.
Method 2: Change Plugin Configuration
Probably the better solution is to change the configuration of the Maven WildFly plugin itself. Under the <configuration> section, I can add the following.
<name>anotherContextRoot.war</name>
This correctly changes the url to localhost:8080/anotherContextRoot. So then I tried again to create a blank name as in the following.
<name>.war</name>
However, this results in an IllegalArgumentException: Empty name segment is not allowed for module.
Question
Does anyone know the appropriate way to make the context root blank? Thanks in advance.
I managed to figure this out. You do not need to do anything except add a jboss-web.xml file into the WEB-INF directory as follows.
<?xml version="1.0" encoding="UTF-8"?>
<jboss-web>
<context-root>/</context-root>
<default-encoding>UTF-8</default-encoding>
</jboss-web>
This sets the context root and overrides what the plugin was doing.
Hope this helps someone else.
If you save your war with the name ROOT.war and deploy it, WildFly will configure it as root application.
I am regularly deploying a Maven project to a Tomcat server, using Travis CI. My project is a web app, so I have configured my pom.xml for building a WAR file, instead of a JAR:
...
<packaging>war</packaging>
...
With Maven, I can generate a directory containing all the JavaDoc files for my project; Maven puts them in the target/site/apidocs directory. But then, when I deploy my project, Travis doesn't perform any mvn site phase so I don't have my JavaDocs on the server.
Should I edit my pom.xml so that Maven puts the JavaDoc files somewhere in the src directory (instead of target) or is there a way to package the JavaDoc files together with the WAR file? I thought that I could create a docs/ directory inside src/main/webapp/. Specifically: is it "good practice" to generate my JavaDoc in src instead of target? if not, how can I have a WAR file containing my JavaDoc?
What would you suggest is the best thing to do?
I already know how to generate a standalone JAR containing my JavaDoc files (see here), but this is not what I'm looking for.
Use the site plugin https://maven.apache.org/plugins/maven-site-plugin/ and the javdoc plugin https://maven.apache.org/plugins/maven-javadoc-plugin/usage.html.
Add the following to your pom.xml
<reporting>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<configuration>
<links>
<link>http://commons.apache.org/lang/api</link>
<link>http://java.sun.com/j2se/1.5.0/docs/api</link>
<link>http://this-one-will-not-work</link>
</links>
</configuration>
</plugin>
</plugins>
</reporting>
then mvn site:site your documentation will be in target/site you can also deploy it.
I need to share a feature with someone with whom I don't share a repository. Is it a good idea to just zip the maven artifact directory directory from my local maven repository and send it over ?
the directory has feature xml pom and jars. Is there a better way of doing this short of sharing a common central repository ?
For that i would use a KAR File, it's one of the recommended ways to provision karaf features, it will package your bundle, the feature and all dependencies in one archive there are two ways to generate kar files:
First one, you can generate using karaf itself:
karaf#root()> kar:create your-feature
The seconde one, you can generate the kar file using the following maven plugin with your project as a kar packaging.
<build>
<plugins>
<plugin>
<groupId>org.apache.karaf.tooling</groupId>
<artifactId>karaf-maven-plugin</artifactId>
<version>4.0.0</version>
<extensions>true</extensions>
</plugin>
</plugins>
</build>
Then you can just drop the kar archive at the deploy folder, or install it using the kar:install command.
For more informations check https://karaf.apache.org/manual/latest/kar
I am creating my own maven-environment-plugin that creates and bundle resources for a predefined folder structure for each environment defined in the configuration. The plugin is outputting the folder structure and resource in a zip file and placing it in the target folder.
Questions:
How can I make my plugin work like the maven-assembly-plugin so my output to target folder also ends up in my local repository when I use 'mvn install'?
Do I need to mark it or something? Its automaticallly doing it when the maven-assembly-plugin is used.
How does maven-assembly-plugin manage to make sure of this?
I am using mojo for my plugin development.
<plugin>
<groupId>dk.kmd.devops.maven.plugin</groupId>
<artifactId>envconfiguration-maven-plugin</artifactId>
<version>1.0.3</version>
<configuration>
<environments>
<environment>${env.local}</environment>
<environment>${env.dev}</environment>
<environment>${env.t1}</environment>
<environment>${env.t2}</environment>
<environment>${env.p0}</environment>
</environments>
<sourceConfigDir>${basedir}/src/main/config</sourceConfigDir>
<zipEnvironments>true</zipEnvironments>
</configuration>
<executions>
<execution>
<phase>generate-resources</phase>
<goals>
<goal>generateEnv</goal>
</goals>
</execution>
</executions>
</plugin>
You need to attach (that's the correct terminology in this case) the new artifact (the generated zip file) to the build as part of its official artifacts.
This is basically what the attach-artifact goal of the build-helper-maven-plugin does:
Attach additional artifacts to be installed and deployed.
From its official examples, the attach goal:
Typically run after antrun:run, or another plugin, that produces files that you want to attach to the project for install and deploy.
The another plugin in this case can be the plugin you developed. Hence there are two solutions to your case:
Configure this plugin to attach the generated artifact as a further pom.xml configuration, or
add to your plugin the functionality to automatically attach the generated file
The second case can be covered via Maven API, using the MavenProjectHelper and its attachArtifact method.
In your mojo, you can import is as a component via:
/**
* Maven ProjectHelper
*/
#Component
private MavenProjectHelper projectHelper;
Then use the aforementioned method:
projectHelper.attachArtifact(project, "zip", outputFile);
You should probably already have the required Maven dependency providing it, but just in case it would be this one:
<dependency>
<groupId>org.apache.maven</groupId>
<artifactId>maven-core</artifactId>
<version>3.3.9</version>
</dependency>
Note that the artifact will be attached to the build as an additional artifact via a classifier, that is, a suffix to the default artifact name differentiating it from the default artifact and making it unique as output of the build.
As a reference to real example and to further answer your (last) question, check this query on the GitHub maven-plugins repository, checking for the attachArtifact string, you will see it used in a number of Maven plugins, among which the maven-assembly-plugin, for example here in the AbstractAssemblyMojo class.