Specify runner directory for pax:run [PAXCONSTRUCT-115]

[ops4j-issues]

Richard Wallace created PAXCONSTRUCT-115

There is currently no way to specify the directory that runner will put the runner/deploy-pom.xml and runner/target/pom-transformed.xml file into. You can change what Pax Runner uses as its base by passing a param, but that still leaves a runner directory in your project root directory where it should be (or you should have the option of) putting it into the target directory.

---

Affects: 1.4 Fixed in: 1.7.0 Votes: 1, Watches: 1

[ops4j-issues]

AaronZ commented

Note that you can always run pax:clean to remove the directory afterwards if you don't like it being there. You don't really want this directory to go away every time you run mvn clean install most likely.

[ops4j-issues]

Richard Wallace commented

Why wouldn't you want the directory to go away every time you run mvn clean? One of the expectations of maven users is that when you run a clean, any artifacts created during a build should be removed and the project put into a state such that it is no different than a fresh checkout from your scm.

[ops4j-issues]

Stuart McCulloch commented

Originally the runner directory was under "target", but several users pointed out the following use-cases which led to it being moved:

1) Upgrading bundles during development

This was raised during my first major OSGi tutorial involving pax-construct, when I was explaining how OSGi lets you upgrade bundles without restarting.

Almost all the developers did the following:

• mvn clean install
• launch the application with "pax:provision" (alias of "pax:run")
• modify one of the bundles
• mvn clean install
• attempt to upgrade the bundle in the OSGi console

blam, the OSGi framework throws up all sorts of errors because you've just wiped out the runner working directory (for many developers "mvn clean install" is an instinctive reflex - you can't get them to install without clean)

2) Lack of Maven artifact caching in pax-runner

Previous releases of pax-runner do not cache downloaded artifacts in the local Maven repository (I believe a feature request was raised for this, but I don't know if it's been implemented). This means that if you don't have the Equinox / Felix / KF framework artifacts in your local Maven repository, or have them referred to in your project POMs so that Maven will cache them, then pax-runner will (re-)download them every time you wipe the runner working directory.

For users with limited bandwidth this is a big deal - moving the pax-runner working directory out of "target" and using the option to keep framework bundles around between runs means you can run offline as long as your project bundles and their dependencies are in your local Maven repository (which for most Maven projects will be true).

For both these reasons the default "pax:run" working directory location will remain outside of "target", but I'm not adverse to allowing users to configure this :smile:

[ops4j-issues]

Richard Wallace commented

Ok, I see where you're coming from now. You're looking at it as more of an interactive tool that a developer will use to do manual tests and other things. Whereas I'm looking at it as a build artifact as a result of integration tests. I agree these should have different working directories. For integration tests I'd hate to have my manual test environment that I've customized and added data to to much up my integration tests which expect as close to a clean slate as possible. But if it is configurable, we can all get what we want. :smile:

[ops4j-issues]

Stuart McCulloch commented

Add support for this in 1.5