Mojo RPM Plugin

install/deploy error "java.io.IOException: File ... does not exist"

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Cannot Reproduce
  • Affects Version/s: 2.0.1
  • Fix Version/s: None
  • Component/s: rpm
  • Labels:
    None
  • Environment:
    java version "1.6.0"
    OpenJDK Runtime Environment (build 1.6.0-b09)
    OpenJDK 64-Bit Server VM (build 1.6.0-b09, mixed mode)
  • Number of attachments :
    0

Description

When the maven-rpm-plugin is run, and an as-yet-unknown error is present which causes rpmbuild to fail, the maven-rpm-plugin swallows the error, and instead returns the next error along, the error that the RPM file does not exist.

What the plugin should do instead is tell the end user what rpmbuild said, so they can respond to the error message and fix it, instead of being forced to guess the error.

The full trace looks like this:

[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error installing artifact: File /home/chandler/minfrin/src/code/trunk/statement/statement/target/rpm/statement/RPMS/noarch/statement-0.0.3-SNAPSHOT20100405200626.noarch.rpm does not exist
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error installing artifact: File /home/chandler/minfrin/src/code/trunk/statement/statement/target/rpm/statement/RPMS/noarch/statement-0.0.3-SNAPSHOT20100405200626.noarch.rpm does not exist
at org.apache.maven.plugin.install.InstallMojo.execute(InstallMojo.java:143)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
... 17 more
Caused by: org.apache.maven.artifact.installer.ArtifactInstallationException: Error installing artifact: File /home/chandler/minfrin/src/code/trunk/statement/statement/target/rpm/statement/RPMS/noarch/statement-0.0.3-SNAPSHOT20100405200626.noarch.rpm does not exist
at org.apache.maven.artifact.installer.DefaultArtifactInstaller.install(DefaultArtifactInstaller.java:119)
at org.apache.maven.plugin.install.InstallMojo.execute(InstallMojo.java:105)
... 19 more
Caused by: java.io.IOException: File /home/chandler/minfrin/src/code/trunk/statement/statement/target/rpm/statement/RPMS/noarch/statement-0.0.3-SNAPSHOT20100405200626.noarch.rpm does not exist
at hidden.org.codehaus.plexus.util.FileUtils.copyFile(FileUtils.java:1003)
at org.apache.maven.artifact.installer.DefaultArtifactInstaller.install(DefaultArtifactInstaller.java:98)
... 20 more

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Graham Leggett added a comment -

It looks like plugin cannot predict the name of the RPM file produced.

The file it is looking for, and the file that is produced have different names. The difference seems to be in a timestamp:

[minfrin@257233-app1 statement]$ ls -al /home/chandler/minfrin/src/code/trunk/statement/statement/target/rpm/statement/RPMS/noarch/statement-0.0.3-SNAPSHOT20100405202256.noarch.rpm
rw-rr- 1 minfrin minfrin 19894663 Apr 5 15:23 /home/chandler/minfrin/src/code/trunk/statement/statement/target/rpm/statement/RPMS/noarch/statement-0.0.3-SNAPSHOT20100405202256.noarch.rpm
[minfrin@257233-app1 statement]$ ls -al /home/chandler/minfrin/src/code/trunk/statement/statement/target/rpm/statement/RPMS/noarch/statement-0.0.3-SNAPSHOT20100405202253.noarch.rpm

The file the plugin is looking for ends in "56", while the actual file ends in "53".

Show
Graham Leggett added a comment - It looks like plugin cannot predict the name of the RPM file produced. The file it is looking for, and the file that is produced have different names. The difference seems to be in a timestamp: [minfrin@257233-app1 statement] $ ls -al /home/chandler/minfrin/src/code/trunk/statement/statement/target/rpm/statement/RPMS/noarch/statement-0.0.3-SNAPSHOT20100405202256.noarch.rpm rw-r r - 1 minfrin minfrin 19894663 Apr 5 15:23 /home/chandler/minfrin/src/code/trunk/statement/statement/target/rpm/statement/RPMS/noarch/statement-0.0.3-SNAPSHOT20100405202256.noarch.rpm [minfrin@257233-app1 statement] $ ls -al /home/chandler/minfrin/src/code/trunk/statement/statement/target/rpm/statement/RPMS/noarch/statement-0.0.3-SNAPSHOT20100405202253.noarch.rpm The file the plugin is looking for ends in "56", while the actual file ends in "53".
Hide
Permalink
Graham Leggett added a comment -

Further digging, if you attempt to force "uniqueVersion" off from the command line, the feature seems to switch itself back on when the rpm plugin kicks in:

mvn -DuniqueVersion=false install

Show
Graham Leggett added a comment - Further digging, if you attempt to force "uniqueVersion" off from the command line, the feature seems to switch itself back on when the rpm plugin kicks in: mvn -DuniqueVersion=false install
Hide
Permalink
Graham Leggett added a comment -

Downgrading from v2.0.1 to v2.0-beta-4 works around the problem.

Show
Graham Leggett added a comment - Downgrading from v2.0.1 to v2.0-beta-4 works around the problem.
Hide
Permalink
Brett Okken added a comment -

My guess is that this was introduced with MRPM-62. Though I am surprised that I have never seen this problem.
What version of maven are you using?
Are you using older hardware (or virtual hardware)?

Further digging, if you attempt to force "uniqueVersion" off from the command line, the feature seems to switch itself back on when the rpm plugin kicks in:

Are you saying this because of the timestamp at the end of the filename? If the release attribute is not configured manually, one is generated from the project version (and modifiers)[1]. Using the timestamp at the end of the release allows rpm to honor maven's SNAPSHOT concept.

[1] - http://mojo.codehaus.org/rpm-maven-plugin/ident-params.html#release

Show
Brett Okken added a comment - My guess is that this was introduced with MRPM-62 . Though I am surprised that I have never seen this problem. What version of maven are you using? Are you using older hardware (or virtual hardware)? Further digging, if you attempt to force "uniqueVersion" off from the command line, the feature seems to switch itself back on when the rpm plugin kicks in: Are you saying this because of the timestamp at the end of the filename? If the release attribute is not configured manually, one is generated from the project version (and modifiers) [1] . Using the timestamp at the end of the release allows rpm to honor maven's SNAPSHOT concept. [1] - http://mojo.codehaus.org/rpm-maven-plugin/ident-params.html#release
Hide
Permalink
Brett Okken added a comment -

Try adding the following configuration in your pom:

 
    <plugin>
        <artifactId>rpm-maven-plugin</artifactId>
        <configuration>
            ...
	    <version>${rpm.version}</version>
	    <release>${rpm.release}</release>
            ...
        </configuration>
    </plugin>
Show
Brett Okken added a comment - Try adding the following configuration in your pom: <plugin> <artifactId> rpm-maven-plugin </artifactId> <configuration> ... <version> ${rpm.version} </version> <release> ${rpm.release} </release> ... </configuration> </plugin>
Hide
Permalink
Graham Leggett added a comment -

Will try it tonight.

From what I can see, it looks like the effective filename of the artifact is being calculated twice, and as the timestamp moves between these two events, two different filenames are generated.

rpmbuild is asked to generate a file with timestamp A, while later on, maven is asked to copy the file, but the name is regenerated with timestamp B and the error "file does not exist" results.

I suspect maven-rpm-plugin isn't respecting the timestamp conventions, as timestamps are turned off for this (multi-module) project. The only timestamp that appears in the build is the module that produces the RPM. All other jars have no timestamps.

Show
Graham Leggett added a comment - Will try it tonight. From what I can see, it looks like the effective filename of the artifact is being calculated twice, and as the timestamp moves between these two events, two different filenames are generated. rpmbuild is asked to generate a file with timestamp A, while later on, maven is asked to copy the file, but the name is regenerated with timestamp B and the error "file does not exist" results. I suspect maven-rpm-plugin isn't respecting the timestamp conventions, as timestamps are turned off for this (multi-module) project. The only timestamp that appears in the build is the module that produces the RPM. All other jars have no timestamps.
Hide
Permalink
Brett Okken added a comment -

Changing summary to indicate this is a install/deploy problem, not a problem with detecting errors from rpmbuild.

Show
Brett Okken added a comment - Changing summary to indicate this is a install/deploy problem, not a problem with detecting errors from rpmbuild.
Hide
Permalink
Graham Leggett added a comment -

I tried to change the subject of the bug earlier, but the "edit" button is missing from the JIRA left menu.

Show
Graham Leggett added a comment - I tried to change the subject of the bug earlier, but the "edit" button is missing from the JIRA left menu.
Hide
Permalink
Brett Okken added a comment -

From what I can see, it looks like the effective filename of the artifact is being calculated twice.

I agree that is what appears is happening. However, I cannot reproduce the issue. Can you attach the generated spec file and a debug (-X) log from an error run?

I suspect maven-rpm-plugin isn't respecting the timestamp conventions... All other jars have no timestamps.

The timestamp is just part of the rpm "release" or "build" portion of the (rpm) version. This is done so that subsequent SNAPSHOT builds can use RPM's upgrade command to install the newer SNAPSHOT. When rpmbuilds the file, it names it following rpm convention. The maven-rpm-plugin just looking for the file at that expected location. At that point it is just given to maven and maven will rename it on install/deploy to follow maven's naming conventions.

Show
Brett Okken added a comment - From what I can see, it looks like the effective filename of the artifact is being calculated twice. I agree that is what appears is happening. However, I cannot reproduce the issue. Can you attach the generated spec file and a debug (-X) log from an error run? I suspect maven-rpm-plugin isn't respecting the timestamp conventions... All other jars have no timestamps. The timestamp is just part of the rpm "release" or "build" portion of the (rpm) version. This is done so that subsequent SNAPSHOT builds can use RPM's upgrade command to install the newer SNAPSHOT. When rpmbuilds the file, it names it following rpm convention. The maven-rpm-plugin just looking for the file at that expected location. At that point it is just given to maven and maven will rename it on install/deploy to follow maven's naming conventions.
Hide
Permalink
Brett Okken added a comment -

Are you still experiencing this problem? If so please attach the requested information (generated spec file and a debug (-X) log from an error run). Thanks.

Show
Brett Okken added a comment - Are you still experiencing this problem? If so please attach the requested information (generated spec file and a debug (-X) log from an error run). Thanks.
Hide
Permalink
Brett Okken added a comment -

Given the lack of feedback, I am closing as Cannot Reproduce. Please re-open if still experiencing this issue and able to provide the necessary details.

Show
Brett Okken added a comment - Given the lack of feedback, I am closing as Cannot Reproduce. Please re-open if still experiencing this issue and able to provide the necessary details.
Hide
Permalink
Stefan Norberg added a comment -

I get this error when building a -SNAPSHOT rpm as a primary artifact without specifying a <configuration><release>-tag. It seems that the rpm-plugin generates a new timestamp in the install phase, and is not reusing the timestamp from the package phase?

I workaround is to specify the <release>, but since it fails without it, it seems to be a bug.

Let me know if you need further help, info to nail this bug.

Thanks,
Stefan

Show
Stefan Norberg added a comment - I get this error when building a -SNAPSHOT rpm as a primary artifact without specifying a <configuration><release>-tag. It seems that the rpm-plugin generates a new timestamp in the install phase, and is not reusing the timestamp from the package phase? I workaround is to specify the <release>, but since it fails without it, it seems to be a bug. Let me know if you need further help, info to nail this bug. Thanks, Stefan
Hide
Permalink
Stefan Norberg added a comment - - edited

btw, a good workround is to specify <release>$

{rpm.release}

</release> as you suggested above.

Show
Stefan Norberg added a comment - - edited btw, a good workround is to specify <release>$ {rpm.release} </release> as you suggested above.
Hide
Permalink
Stefan Norberg added a comment -

Brett - I found what was causing this issue. I accidently had

<executions>
<execution>
<goals>
<goal>attached-rpm</goal>
</goals>
</execution>
</executions>

instead of rpm when building a rpm main artifact....

So, not a bug.

Show
Stefan Norberg added a comment - Brett - I found what was causing this issue. I accidently had <executions> <execution> <goals> <goal>attached-rpm</goal> </goals> </execution> </executions> instead of rpm when building a rpm main artifact.... So, not a bug.

People

  • Assignee:
    Brett Okken
    Reporter:
    Graham Leggett
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: