The default installDir for zipUrlInstaller (java.io.tmp) is inapproriate for some platforms (e.g. Mac OS)

Why wouldn't we simply install the ZIP/TGZ file to something like $

/org/codehaus/cargo/installs and then unzip it to $

in the Maven2 plugin?

The local maven repo is not just some temporary storage area, it's something that Maven uses. We can't/shouldn't put any random file there.

... and why not $HOME/.cargo/installs ?

That would work, I guess. I was suggesting java.io.tmp just because that's the current default. I was thinking we shouldn't change too much.

So, current ideas:

1) Put the ZIP/TGZ into $

, but extract to $

. Good sides: resembles the existent for the installation directory
. Bad sides: only solves for Maven
2) Use $

/.cargo/containers
. Good sides: solves on all platforms
. Bad sides: if the user's profile is network-copied (for example, some Windows profile setups), this will make profile sizes and transfer times get longer

And, refused ideas:

1) Putting them into $

. Bad sides: is against Maven guidelines, only solves for Maven

I think we should start with separating where the zip files is stored and where the container installation is unpacked. The exact location for the zip file could be changed later on, but I suggest we use java.io.tmpdir for now as that's how it works in 1.0.x.

This separation will greatly simplify the work of implementing CARGO-449 I think.

So you would suggest the installDir to be suppressed and replaced with downloadDir and extractDir, for example? And yes, it would greatly simplify CARGO-449

I was rather thinking that installDir could stay and be what it says, the installation directory i.e where the container is unpacked (with a default in target for the maven plugin and maybe the existing java.io.tmp for everything else like Java API and ant). And then we add a new downloadDir param.

So, for CARGO-449 (which only makes sense for the maven plugin), the downloadDir would be set to the artifact location in the local repo by the plugin.

I think we should try to change as little as possible from a user perspective and aim at being backwards compatible.

Well, it can stay the same as well. My perspective that since the semantics behind is different, the name should change as well -this way, people will have compile errors from the beginning and check the documentation to see what has changed.

Proposed patch:

• Create two attributes, downloadDir and extractDir
• Deprecate installDir
• When installDir is set, show a warning and set both downloadDir and extractDir

For documentation update:

• https://docs.codehaus.org/display/CARGO/Installer
• https://docs.codehaus.org/display/CARGO/Maven2+Plugin+Reference+Guide
• https://docs.codehaus.org/display/CARGO/Maven2+Plugin+Tips
• https://docs.codehaus.org/display/CARGO/Deploying+to+a+running+container
• https://docs.codehaus.org/display/CARGO/Functional+testing
• https://docs.codehaus.org/display/CARGO/Starting+and+stopping+a+container

So, when installDir is set, downloadDir is set to that value and extractDir is set to installDir/something?

Regarding default values, they have to be different for Ant and Maven, at least when it comes to extractDir (which should below the build directory for Maven).

You're right... Here is the updated documentation:

Proposed patch:

• Create two attributes, downloadDir and extractDir
  • Default value for downloadDir = $ {java.io.tmpdir}/installs
    ** Default value for extractDir = ${java.io.tmpdir}

    /installs for the Java API and ANT tasks, $

    {project.build.directory}

    /cargo/installs for the Maven2 plugin

• Deprecate installDir
• When installDir is set, show a warning and set both downloadDir and extractDir

For documentation update:

• https://docs.codehaus.org/display/CARGO/Installer
• https://docs.codehaus.org/display/CARGO/Maven2+Plugin+Reference+Guide
• https://docs.codehaus.org/display/CARGO/Maven2+Plugin+Tips
• https://docs.codehaus.org/display/CARGO/Deploying+to+a+running+container
• https://docs.codehaus.org/display/CARGO/Functional+testing
• https://docs.codehaus.org/display/CARGO/Starting+and+stopping+a+container

Documentation update OK.

Testing the current defaults for configuration home and container home, I get this result for a project with JBoss:

target/cargo/configurations/jboss51x
target/cargo/installs/jboss-5.1.0.GA

The extracted installation path seems to contain the file name. Wouldn't it make more sense if we used the container id here as we do for the configuration? Or would there be problems if a different zip is specified but the same container id is kept?

Well... We would have to complexify a bit: currently, the ZipUrlInstaller extracts to the <specified dir>/<zip name>; if we want to have the container name (and it's only possible on Maven2) we'd need another setter.