Intellij IDEA artifact 'XXXX:war exploded' has invalid extension - maven

Every time I make even the tiniest change to my POM Intellij removes the .war extension for my exploded artifact in the Project Structure output directory setting. This causes an error in Intellij's Run/Debug configuration:
Artifact 'XXXX:war exploded' has invalid extension.
In order to resolve the issue I must manually override the Project Structure output directory setting. Every time I make even the tiniest change to the POM I must go back to the Output directory setting and manually append ".war" to the end of the Output directory setting. This is getting very old and frustrating.
e.g. I must change this:
E:\workarea\enterp\application\target\application
to this:
E:\workarea\enterp\application\target\application.war
If I manually set the Maven WAR plugin outputDirectory configuration as follows, this does not help at all:
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>${maven.war.plugin.version}</version>
<configuration>
<!-- Output directory of artifact:war exploded keeps losing the .war extension -->
<outputDirectory>${project.build.directory}.war</outputDirectory>
</configuration>
</plugin>
How can I resolve this problem?
EDIT:
Here's the complete build config:
<build>
<!-- Maven will append the version to the finalName (which is the name
given to the generated war, and hence the context root) -->
<finalName>${project.artifactId}</finalName>
<plugins>
<!-- Compiler plugin enforces Java 1.6 compatibility and activates annotation
processors -->
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>${maven.compiler.plugin.version}</version>
<configuration>
<source>${maven.compiler.source}</source>
<target>${maven.compiler.target}</target>
</configuration>
</plugin>
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>${maven.war.plugin.version}</version>
<configuration>
<!-- Output directory of artifact:war exploded keeps losing the .war extension -->
<outputDirectory>${project.build.directory}/${project.artifactId}.war</outputDirectory>
<!-- Java EE 7 doesn't require web.xml, Maven needs to catch up! -->
<failOnMissingWebXml>false</failOnMissingWebXml>
</configuration>
</plugin>
<!-- The WildFly plugin deploys your war to a local WildFly container -->
<!-- To use, run: mvn package wildfly:deploy -->
<plugin>
<groupId>org.wildfly.plugins</groupId>
<artifactId>wildfly-maven-plugin</artifactId>
<version>${version.wildfly.maven.plugin}</version>
</plugin>
</plugins>
</build>
SECOND EDIT:
I discovered that one solution is to append ".war" to ${project.artifactId} in the build configuration, e.g.:
<finalName>${project.artifactId}.war</finalName>
and remove outputDirectory from the plugin configuration. So the build config should look like this:
<build>
<!--
Maven will make finalName the name of the generated war.
NOTE: Output directory of artifact:war exploded keeps losing the .war extension
http://youtrack.jetbrains.com/issue/IDEA-86484
http://youtrack.jetbrains.com/issue/IDEA-95162
The solution is to append ".war" to ${project.artifactId}, below:
-->
<finalName>${project.artifactId}.war</finalName>
<plugins>
<!-- Compiler plugin enforces Java 1.6 compatibility and activates annotation
processors -->
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>${maven.compiler.plugin.version}</version>
<configuration>
<source>${maven.compiler.source}</source>
<target>${maven.compiler.target}</target>
</configuration>
</plugin>
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>${maven.war.plugin.version}</version>
<configuration>
<!-- Java EE 7 doesn't require web.xml, Maven needs to catch up! -->
<failOnMissingWebXml>false</failOnMissingWebXml>
</configuration>
</plugin>
<!-- The WildFly plugin deploys your war to a local WildFly container -->
<!-- To use, run: mvn package wildfly:deploy -->
<plugin>
<groupId>org.wildfly.plugins</groupId>
<artifactId>wildfly-maven-plugin</artifactId>
<version>${version.wildfly.maven.plugin}</version>
</plugin>
</plugins>
</build>
DISCLAIMER: If you use this workaround just be aware that when you deploy an unexploded WAR artifact the file name will be named XXXX.war.war. It works -- I deployed the artifact as a WAR file in Intellij -- but it's ugly.
INFO [org.jboss.as.server.deployment] (MSC service thread 1-7) JBAS015876: Starting deployment of "XXXX.war.war" (runtime-name: "XXXX.war.war)"
If someone can tell me how to configure the Intellij project to work with Maven to select one or the other finalName values depending on whether I'm deploying a WAR file vs. exploded artifact then this question will be sufficiently answered.
<!-- Exploded artifact -->
<finalName>${project.artifactId}.war</finalName>
<!-- WAR file (unexploded) artifact -->
<finalName>${project.artifactId}</finalName>

There's a way to fix this in IntelliJ, without changing your pom.xml file(s), by adding an artifact with a reference to the exploded war (or in my case, the exploded ear) and it won't get stomped every time IntelliJ re-imports the maven pom(s). Here's how:
Stop/undeploy your current artifact deployment
Edit your run config, and in the Deployment tab, remove the current exploded war/ear artifact
Open the project's Artifacts settings and add a new artifact
Use the plus button to add a new war or (in my case) ear exploded artifact
Give it a name, then edit the Output directory to add the appropriate extension (.war or .ear)
In the Output Layout section where you see <output root>, use the plus button to add an Artifact
Select the desired exploded artifact
Edit your run config again, and in the Deployment tab, add the new workaround exploded artifact
Thanks to Nikolay Chashnikov for describing this in his comment on the bug report

Actually, you should leave the finalName attribute alone, otherwise you'll get the problems you describe. Rather, you should change the config for the maven war plugin to use the webappDirectory like this:
<plugin>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<webappDirectory>${project.build.directory}/${project.artifactId}.${project.packaging}</webappDirectory>
<failOnMissingWebXml>false</failOnMissingWebXml>
</configuration>
</plugin>

If we are talking about WAR inside EAR there is another way to resolve your problem by using correct configuration inside maven-ear-plugin. WAR pom.xml should be left as is, without any changes, but EAR pom.xml should contains something like this. (please, pay your attention to <unpack>${unpack.wars}</unpack>)
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ear-plugin</artifactId>
<version>2.9</version>
<configuration>
<version>6</version>
<defaultLibBundleDir>lib</defaultLibBundleDir>
<generateApplicationXml>false</generateApplicationXml>
<archive>
<manifest>
<addClasspath>true</addClasspath>
</manifest>
</archive>
<modules>
<webModule>
<groupId>com.test.app</groupId>
<artifactId>test-app-war</artifactId>
<unpack>${unpack.wars}</unpack>
</webModule>
</modules>
</configuration>
</plugin>
and then you can add profiles default and debug for proper artifact assembling.
<profiles>
<profile>
<id>default</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<unpack.wars>false</unpack.wars>
</properties>
</profile>
<profile>
<id>debug</id>
<activation>
<property>
<name>debug</name>
</property>
</activation>
<properties>
<unpack.wars>true</unpack.wars>
</properties>
</profile>
</profiles>
use debug profile inside IntelliJ IDEA for expanding wars and default profile for building artifacts in command line or CI (default profile would be active if no profile were provided, so your build will works as previously).
With this solution HotSwap and resources updates works as expected.
Hope this helps.

I think it's the same as this question: IntelliJ Artifact has invalid extension
Add a .war extension to the output directory as shown in my answer: https://stackoverflow.com/a/25569266/968988

Related

Maven - How to extract a dependency inside another ZIP dependency?

I have a maven project.
Inside that project, I have a .zip dependency that carries a jar and I need to extract that jar out of the zip dependency and have maven use the jar as a dependency. I can currently download and unpack the zip but, cannot figure out a way to add the unpacked jar as a dependency for the project during the build process.
Here is what I'm currently doing for unpacking:
<dependency>
<groupId>com.bar</groupId>
<artifactId>foo</artifactId>
<version>${foo.version}</version>
<type>zip</type>
</dependency>
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>unpack</id>
<goals>
<goal>unpack-dependencies</goal>
</goals>
<phase>validate</phase>
<configuration>
<includeGroupIds>com.bar</includeGroupIds>
<includeArtifactIds>foo</includeArtifactIds>
<outputDirectory>${basedir}/target</outputDirectory>
<type>jar</type>
</configuration>
</execution>
</executions>
</plugin>
I read up on some other posts that you could try adding the jar to the class path using this.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<additionalClasspathElements>
<additionalClasspathElement>${basedir}/target</additionalClasspathElement>
</additionalClasspathElements>
</configuration>
</plugin>
Even doing so I was still unable to reference the packages in foo.jar in my project.
Can someone help me?
For maven to use it without subtly breaking stuff elsewhere, you must install the jar into your local repository.
I would suppose that a combination of unpacking the zip file in target/ and then invoking install:install-file on the resulting jar could do what you need. I asked some years back how to integrate that in a normal build - you might find the answer relevant. Multiple install:install-file in a single pom.xml
Let's assume that, after unpacking the zip, you have foo.jar in your module's target folder: ${project.build.directory}/foo.jar
Having this in place, you can then declare a System Dependency pointing to that jar, e.g.
<dependency>
<groupId>foo</groupId>
<artifactId>foo.jar</artifactId>
<systemPath>${project.build.directory}/foo.jar</systemPath>
</dependency>
Tip: if you dont want to delete/re-download the jar each time you do a clean (some IDE will complain the the jar is not always present) just download it once in the ${project.basedir}.
To download the jar once, you can put your "unpack" execution in a profile that gets activated only when the jar is missing.
<profiles>
<profile>
<activation>
<file>
<missing>${project.basedir}/foo.jar</missing>
</file>
</activation>
...
</profile>
</profiles>
Some time ago, I've faced the same problem. I had a zip file as my dependency, and during the build process I need to extract it and separate the content inside my generated package.
I don't know what are you using to deliver your project, but at that time I've used the maven-antrun-plugin
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>2.6</version>
</plugin>
With this, I've used the tag unzip inside my target configuration. As you can see here or here. I just don't recommend you to use the task tag as they're using, you'd better prefer the target tag.
Hope it helps you.

Using profiles to exclude WAR modules from 'mvn install'

My parent pom defines 7 modules, 5 of which are dependency jars, and two are wars that depend on those jars.
Question: Is it possible to use maven profiles (or another solution) to define which modules are included when mvn install is run against the parent pom to exclude the two war packages?
I would then like to have a different profile (or another solution) to package the two wars. If that profile is run, the dependency jar modules should be rebuilt and installed only if they are missing from the repository.
You could use the build-helper-maven-plugin in your parent pom.xml file to create a new property based on the packaging (at runtime it would change from pom for the parent, to jar and war for the modules). This new propery could then be used to skip the maven-install-plugin dynamically.
A simple example:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.10</version>
<executions>
<execution>
<id>build-helper-regex-is-packaging-war</id>
<phase>validate</phase>
<goals>
<goal>regex-property</goal>
</goals>
<configuration>
<name>only.when.war.is.used</name>
<value>${project.packaging}</value>
<regex>war</regex>
<replacement>true</replacement>
<failIfNoMatch>false</failIfNoMatch>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-install-plugin</artifactId>
<version>2.5.2</version>
<configuration>
<skip>${only.when.war.is.used}</skip>
</configuration>
</plugin>
Doing so, the dynamic ${only.when.war.is.used} property would be set to true only when project.packaging would have value war and as such effectively skip the maven-install-plugin executions via its skip option.
You could then move this behavior to a profile and have different settings for jar and war, keeping them in a common place: the root pom.xml, thanks to their dynamic behavior.
Concerning the ability to detect whether an artifact has already been installed or not, there is no such an option on the official plugin documentation and I don't think you could have such a behavior by simply using the plugin.
You could however use the maven profile activation mechanism in case a file is missing (the installed file) and activate the profile accordingly.
You could have in a dynamic way (based only on standard properties) the following approach:
<profiles>
<profile>
<activation>
<file>
<missing>${settings.localRepository}/${project.groupId}/${project.artifactId}/${project.build.fileName}.${project.packaging}</missing>
</file>
</activation>
...
</profile>
</profiles>

Why would a maven-war-plugin generate a JAR instead of a WAR?

I am following this Contract first using CXF tutorial and while the resulting pom.xml generates sources and even completes build successfully, it fails to create a WAR file.
Instead, it creates a JAR file.
My understanding is that the part in the pom.xml that's responsible for creating the WAR is:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.1.1</version>
<configuration>
<outputDirectory>D:/path/to/profile/autodeploy</outputDirectory>
</configuration>
</plugin>
I don't see any <goal> or <execution> element there (unlike in the build-helper-maven-plugin one), but I also understand that with this plugin this is implied as even the official usage page demonstrates:
<project>
...
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.4</version>
<configuration>
<webappDirectory>/sample/servlet/container/deploy/directory</webappDirectory>
</configuration>
</plugin>
</plugins>
</build>
...
</project>
So... what am I missing?
What could possibly explain a maven-war-plugin that behaves in unexpected way like this and produces a JAR instead of a WAR by default?
Is there a way to force it to produce a WAR?
packaging should be as below.
<packaging>war</packaging>
if it won't help then try binding your plug-in configuration with a lifecycle phase.
in your project definition , please check if packaging is missing or not , it should be some thing like this .
<groupId>some.groupid</groupId>
<artifactId>My Web Application</artifactId>
<version>0.0.1</version>
<packaging>war</packaging>
<description>My First Web Application</description>
By default maven war plugin binds to package phase of the lifecycle ,so its important that we should mention the type of packaging we want once the build is done.
I would like to suggest to have a look at the Maven specs for war plugin.

Use Maven to Copy Files to WEB-INF Before WAR is Packaged

I have two servlet config files in my webapp, one for our normal environment (Heroku) and the other for WebLogic. I have a Maven profile for our WebLogic builds that should copy "servlet-context.xml.weblogic" to "servlet-context.xml". Everything appears to be working, except that the copy takes place AFTER the war file is built, so the correct servlet context doesn't get included in the package. What is the right build phase to use in the maven-antrun-plugin to get the copying done correctly?
Here is the relevant section of my POM.xml file:
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<phase>test</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<move
file="${project.build.directory}/${project.build.finalName}/WEB-INF/spring/appServlet/radio-context.xml.weblogic"
tofile="${project.build.directory}/${project.build.finalName}/WEB-INF/spring/appServlet/radio-context.xml"/>
</tasks>
</configuration>
</execution>
</executions>
</plugin>
This fails with the following error:
Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.3:run (default) on project radio: An Ant BuildException has occured: Warning: Could not find file C:\workspace\radio\target\radio-1.0.0-BUILD-SNAPSHOT\WEB-INF\spring\appServlet\radio-context.xml.weblogic to copy. -> [Help 1]
However, if I change the <phase> to package, the copy works, but after the war is built.
Any help would be appreciated.
As a reference, this page lists the Maven lifecycle phases.
The key phases you need to think about in your build are:
process-resources - where most of the files are placed into ${project.build.directory}
package - this is the phase where the WAR is built
BUT...
Looking at the documentation of the WAR plugin, the copying of WAR resources to ${project.build.directory}/${project.build.finalName} occurs in the war:war goal, which executes in the package phase also.
So let's take a step back. What you want to achieve is to use a different radio-context.xml file depending on your profile. Perhaps a better approach would be to configure the WAR plugin differently in your weblogic profile.
Have a separate webapp resource directory for your weblogic, put your custom radio-context.xml file in there, and only include that directory in the weblogic profile. e.g.
<project>
...
<profiles>
<profile>
<id>weblogic</id>
...
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.2</version>
<configuration>
<webResources>
<resource>
<directory>src/main/webapp-weblogic</directory>
</resource>
</webResources>
</configuration>
</plugin>
</plugins>
</build>
</profile>
</profiles>
</project>
Try using process-resources, this copies your file before the war is built.

change deployed artifact name based on profile

I have in a web application's pom file, a build profile, which does some necessary things (in my code) for qa testing.
I have this code on svn and this code is compiled in Hudson, which deploys artifacts in nexus..
Hudson has two jobs, one for qa profile (-P qa) and one for customers.
What i need is that i change in my qa profile the artifact's name during deploy phase, so that nexus has two different war files, one for qa and one for customer.
I use (after Google search) the following which looks like it does nothing in hudshon!
<profile>
<id>qa</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-deploy-plugin</artifactId>
<version>2.5</version>
<configuration>
<classifier>qa</classifier>
</configuration>
</plugin>
</plugins>
</build>
</profile>
any ideas someone?
You actually need to set the "classifier" configuration option on the plugin that's building the package that's being deployed: maven-(ear|ejb|jar|rar|war|shade)-plugin:
For instance, to build a WAR with a qa classifier, you would do the following:
<profile>
<id>qa</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.1.1</version>
<configuration>
<classifier>qa</classifier>
</configuration>
</plugin>
</plugins>
</build>
</profile>
Also, instead of setting the classifier you could set any of the following (most default to project.build.finalName, so setting that property updates many of these):
General
project.build.finalName
War Plugin
warName
Ear|Jar|Rar|Shade Plugin
finalName
EJB Plugin
jarName
One final note: I never realized this before, but looking over the documentation, it looks like the RAR plugin doesn't support the "classification" option. Shade does support the classifier concept, but does it via the "shadedClassifierName" property.

Resources