Issue when project directory is on a different filesystem than /tmp

[michael.stella]

When I run 'mvn package', I get the trace below. I found out why too
- whatever is trying to move the .apk into the /tmp directory is
trying to do with with a hard-link. Since my build directory is not
on the same filesystem as /tmp, this fails.

I'm not sure what part would cause this, as I haven't looked into the
source very closely yet.

Cheers for writing it though, I was using Shane Isbell's stuff as
well, but I agree with your reasons for this project existing. And
yours has been easier to use with the brand-new m5-rc14 release of
Android :)

Let me know if you need anymore info.

- Michael

[INFO] Trace
java.lang.RuntimeException: could not rename the file /home/mstella/
work/maven-android/target/maven-android-sample.apk to /tmp/maven-
android-sample.apk30860.tmp
at
com.totsp.mavenplugin.android.PackageMojo.addFilesToExistingZip(PackageMojo.java:
86)
at com.totsp.mavenplugin.android.PackageMojo.execute(PackageMojo.java:
71)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:
447)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:
539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:
480)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:
459)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:
311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:
278)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:
143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
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)

[Charlie Collins]

On Feb 13, 4:09 pm, "michael.stella" <goo...@thismetalsky.org> wrote:
> When I run 'mvn package', I get the trace below.  I found out why too
> - whatever is trying to move the .apk into the /tmp directory is
> trying to do with with a hard-link.  Since my build directory is not
> on the same filesystem as /tmp, this fails.

I think I know why this might be happening, a temp file is created to
add files to the APK, that is probably not using
java.io.tmpdir at the moment, and needs to be made more robust.
Adding this to the issue tracker now.

> I'm not sure what part would cause this, as I haven't looked into the
> source very closely yet.
>
> Cheers for writing it though, I was using Shane Isbell's stuff as
> well, but I agree with your reasons for this project existing.  And
> yours has been easier to use with the brand-new m5-rc14 release of
> Android :)

Thanks. I just started looking at the new release last night, need to
get that in ASAP too (adding that to the tracker also).

[Charlie Collins]

Should be fixed in new snapshot, please try it out to make sure (using
buildDir now for tmp file creation location - rather than the default
File.createTempFile - which used java.io.tmpdir - so that should have
worked anyway, but buildDir should solve this).

[michael.stella]

On Feb 14, 8:48 pm, Charlie Collins <charlie.coll...@gmail.com> wrote:
> Should be fixed in new snapshot, please try it out to make sure (using
> buildDir now for tmp file creation location - rather than the default
> File.createTempFile - which used java.io.tmpdir - so that should have
> worked anyway, but buildDir should solve this).

Yep, it works great now, thanks :)