Bug 963838 - %mvn_build macro cannot be used if reactor build contains module with packaging type "war"
Summary: %mvn_build macro cannot be used if reactor build contains module with packagi...
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: xmvn
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Mikolaj Izdebski
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-05-16 16:39 UTC by Severin Gehwolf
Modified: 2013-09-11 11:55 UTC (History)
4 users (show)

Fixed In Version: 1.0.0-2
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-09-11 11:55:01 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Severin Gehwolf 2013-05-16 16:39:05 UTC
Description of problem:
%mvn_build -f fails with

[ERROR] Failed to execute goal org.fedoraproject.xmvn:xmvn-mojo:0.4.1:install (default-cli) on project thermostat: Unable to find suitable installer to install project com.redhat.thermostat:thermostat-web-war, which has packaging type war -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException


Version-Release number of selected component (if applicable):
rpm -q xmvn
xmvn-0.4.2-1.fc19.noarch

How reproducible:
Always.

Steps to Reproduce:
1. Try to build any maven based project where at least one module has packaging type "war"
  
Actual results:
Entire build fails.

Expected results:
Successful build.

Additional info:
Looking at http://mizdebsk.fedorapeople.org/xmvn/site/howto/extend.html, it appears to be fairly trivial to support a web archives.

Maybe I can contribute such a WarInstaller class.

Are there any workarounds so that at least the rest of the reactor build does not fail? I'd like to use mvn_build since it gives us some nice goodies of pom mapping, installation, etc. But we can't use it since we'd like to build the war as a sub-package :(

Comment 1 Mikolaj Izdebski 2013-05-17 06:02:30 UTC
Currently XMvn has no support for war files. The reason is that current Fedora packaging guidelines doesn't mention how and where war files should be installed.

I think that first we should discuss details of packaging Java web applications at Java SIG and once there is a consensus adding war support to XMvn should be fairly simple.

(In reply to comment #0)
> Are there any workarounds so that at least the rest of the reactor build
> does not fail? I'd like to use mvn_build since it gives us some nice goodies
> of pom mapping, installation, etc. But we can't use it since we'd like to
> build the war as a sub-package :(

As a short-term solution you can tell XMvn to skip installation of the war artifact and install it manually, after %mvn_install:

%prep
...
# Skip automatic installation of the war module.
# It will be installed manually.
%mvn_package :thermostat-web-war __noinstall
...

%install
%mvn_install
# XMvn doesn't support war installation yet, so it needs to be
# installed explicitly.  See: rhbz#963838
install -m 644 path/to/the/*.war %{buildroot}war/target/location

Note that for the above workaround to work on F-19 you need xmvn >= 0.4.2-1.1 (available in buildroot override and submitted as an update, but F-19 is frozen now).

As a long term solution I think we should add packaging war files into Java packaging guidelines. After that I will be happy to add war support to XMvn.

Comment 2 Severin Gehwolf 2013-05-17 16:17:48 UTC
(In reply to comment #1)
> Currently XMvn has no support for war files. The reason is that current
> Fedora packaging guidelines doesn't mention how and where war files should
> be installed.

How about a new top level dir in /usr/share? Say /usr/share/java-webapps/%{name} :) Then teach jetty/tomcat et. al. to deploy webapps installed in that location.

> I think that first we should discuss details of packaging Java web
> applications at Java SIG and once there is a consensus adding war support to
> XMvn should be fairly simple.

Agreed.

> (In reply to comment #0)
> > Are there any workarounds so that at least the rest of the reactor build
> > does not fail? I'd like to use mvn_build since it gives us some nice goodies
> > of pom mapping, installation, etc. But we can't use it since we'd like to
> > build the war as a sub-package :(
> 
> As a short-term solution you can tell XMvn to skip installation of the war
> artifact and install it manually, after %mvn_install:
> 
> %prep
> ...
> # Skip automatic installation of the war module.
> # It will be installed manually.
> %mvn_package :thermostat-web-war __noinstall
> ...

Thanks! That was the nudge into the the right direction.

> Note that for the above workaround to work on F-19 you need xmvn >=
> 0.4.2-1.1 (available in buildroot override and submitted as an update, but
> F-19 is frozen now).

OK. Thanks, explicitly added a BR on >= 0.4.2-1.1

Package built in koji. That was a wrestle :)

> As a long term solution I think we should add packaging war files into Java
> packaging guidelines. After that I will be happy to add war support to XMvn.

OK, thanks!

Comment 3 Fedora Admin XMLRPC Client 2013-05-21 13:11:57 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 4 Mikolaj Izdebski 2013-09-11 11:54:07 UTC
Since version 1.0.0 XMvn is capable of resolving artifacts with arbitrary extensions, including "war".

Note that currently there is no configuration specifying what is the location of "war" files in Fedora, so maven-local still won't be able to resolve or install "war" artifacts.  For this to happen there needs to be a consensus in Java SIG where and how WAR artifacts should be installed.

Comment 5 Mikolaj Izdebski 2013-09-11 11:54:18 UTC
Fixed in xmvn-1.0.0-2

Comment 6 Mikolaj Izdebski 2013-09-11 11:55:01 UTC
I believe that this bug is fixed in xmvn-1.0.0-2,
which is available in Fedora Rawhide, so I am closing this bug now.

The build containing the fix can be found at Koji:
http://koji.fedoraproject.org/koji/buildinfo?buildID=463528

This bug was fixed in the next release of Fedora, and is not planned
to be fixed in the release it was filed against.  If you want this bug
to be fixed in updates for Fedora 19, please say so in a comment.
Otherwise you can update to the newer release of Fedora to get the fix.


Note You need to log in before you can comment on or make changes to this bug.