Bug 1012059 - jar file installed as pom, causes installation failure
jar file installed as pom, causes installation failure
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: xmvn (Show other bugs)
20
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Stanislav Ochotnicky
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-25 11:48 EDT by Robert Rati
Modified: 2013-09-27 07:18 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1012913 (view as bug list)
Environment:
Last Closed: 2013-09-27 07:18:49 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Proposed patch (616 bytes, patch)
2013-09-26 02:30 EDT, Mikolaj Izdebski
no flags Details | Diff
Corrected patch (617 bytes, patch)
2013-09-26 02:32 EDT, Mikolaj Izdebski
no flags Details | Diff

  None (edit)
Description Robert Rati 2013-09-25 11:48:13 EDT
Description of problem:
A POM artifact that calls the assembly plugin to generate a jar file results in the jar file getting installed as the pom file, and when the pom file attempts to be copied xmvn files with a:

java.nio.file.FileAlreadyExistsException

Version-Release number of selected component (if applicable):
xmvn-0:1.0.2-2.fc21.noarch

How reproducible:
100%

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
Comment 1 Mikolaj Izdebski 2013-09-26 02:22:52 EDT
This is not a bug in XMvn.
It is a bug in Maven Jar Plugin.
Reassigning.

Reproducer:
$ cat <<EOF >pom.xml
<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>org.fedoraproject.xmvn.it</groupId>
  <artifactId>rhbz1012059</artifactId>
  <version>1.0.0-SNAPSHOT</version>
  <packaging>war</packaging>
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-jar-plugin</artifactId>
        <executions>
          <execution>
            <id>jar</id>
            <phase>package</phase>
            <goals>
              <goal>jar</goal>
            </goals>
          </execution>
  	</executions>
      </plugin>
    </plugins>
  </build>
</project>
EOF

$ mkdir -p src/main/webapp/WEB-INF

$ touch src/main/webapp/WEB-INF/web.xml

$ mvn clean install

Actual results:
1) JAR file is installed with "war" extension:
[INFO] Installing /home/kojan/git/xmvn/rep/target/rhbz1012059-1.0.0-SNAPSHOT.jar to /home/kojan/.m2/repository/org/fedoraproject/xmvn/it/rhbz1012059/1.0.0-SNAPSHOT/rhbz1012059-1.0.0-SNAPSHOT.war
2) WAR file is not installed at all

Expected results:
Both JAR and WAR files are installed with correct extensions
Comment 2 Mikolaj Izdebski 2013-09-26 02:30:22 EDT
Created attachment 803249 [details]
Proposed patch
Comment 3 Mikolaj Izdebski 2013-09-26 02:32:02 EDT
Created attachment 803251 [details]
Corrected patch
Comment 4 Michal Srb 2013-09-27 02:47:58 EDT
In reproducer, you are binding both jar and war plugins to the same phase of a build lifecycle. Since jar plugin is executed after war plugin it sets the project's main artifact. You can try to run jar plugin in prepare-package phase (or explicitly specify maven-war-plugin after the jar plugin in your pom file). Only war file will be installed and I think it's a correct behavior. I don't consider it a bug in maven-jar-plugin. Reassigning back to XMvn.
Comment 5 Mikolaj Izdebski 2013-09-27 03:01:18 EDT
(In reply to Michal Srb from comment #4)
> In reproducer, you are binding both jar and war plugins to the same phase of
> a build lifecycle. Since jar plugin is executed after war plugin it sets the
> project's main artifact. You can try to run jar plugin in prepare-package
> phase (or explicitly specify maven-war-plugin after the jar plugin in your
> pom file). Only war file will be installed and I think it's a correct
> behavior. I don't consider it a bug in maven-jar-plugin. Reassigning back to
> XMvn.

My reproducer doesn't even use XMvn, so this has nothing to do with XMvn.

Multiple plugins can be bound to the same phase, that's not a problem. And this problen is reproducible even if you bind JAR and WAR plugins to different phases. This really is a problem in Maven JAR Plugin.
Comment 6 Michal Srb 2013-09-27 03:33:15 EDT
(In reply to Mikolaj Izdebski from comment #5)
> My reproducer doesn't even use XMvn, so this has nothing to do with XMvn.

This bug is about hadoop failing to build, so XMvn is not out of the game.

> Multiple plugins can be bound to the same phase, that's not a problem. And
> this problen is reproducible even if you bind JAR and WAR plugins to
> different phases. This really is a problem in Maven JAR Plugin.

I am not saying it's not possible, but could you please provide such a reproducer where you bind jar plugin before war plugin and wrong artifact end up being installed? Otherwise if you specify jar plugin after war plugin project's  main artifact will be set to jar file. That's how maven-jar-plugin behaves and I don't want to change this behavior, at least not without discussing it with upstream. And moreover, I really don't consider it a bug, maven just doesn't protect you from misconfiguring of your project.

And I think you're missing one important detail here. Speaking of hadoop bug now. That one jar set as a main artifact of pom-only project should be build, but it's not supposed to be installed. XMvn should, in my opinion, check if packaging type is "pom" and if it is, then install only pom file and all attached artifacts, but not the main one. At least that's what maven-install-plugin does, if I remember correctly.
Comment 7 Mikolaj Izdebski 2013-09-27 07:18:49 EDT
(In reply to Michal Srb from comment #6)
> This bug is about hadoop failing to build, so XMvn is not out of the game.

Ok. I will file a separate bug report.

Closing this as WONTFIX. Described behavior of XMvn is expected.

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