On Tue, Mar 11, 2008 at 10:58 PM, Chris Russell <[EMAIL PROTECTED]>
wrote:
> Hello,
>
> I've had good success deploying my application to a single oc4j instance
> using 'mvn install'.
>
Sounds like you're using a sledge-hammer to crack a peanut.
There are at least three lifecycles in maven: build, clean, and site.
The clean lifecycle has only one phase: "clean"
The reporting lifecycle has two phases: "site" and "site-deploy"
The build lifecycle has many phases: "validate", "compile", "test",
"package", "install", and "deploy" are just some of the well known ones.
When you specify a phase as a goal for the maven command, maven will invoke
all of the previous phases in the lifecycle.
The ... section in the pom defines the default
binding of plugins to phases in the lifecycles, and you can add bindings of
other plugins to phases using the and sections of the
pom. When binding a plugin to a lifecycle phase it helps to understand what
the different phases are designed to achieve:
The "package" phase of the build lifecycle is designed to package up the
artifact that you have built.
The "install" phase of the build lifecycle is designed to install the
packaged artifact into your local maven repository cache.
The "deploy" phase of the build lifecycle is designed to deploy the packaged
artifact to it's remote maven repository.
I said that I thought you were using a sledge-hammer to crack a peanut
because what I fear you are doing is configuring the maven-install-plugin to
copy the packaged artifact to your oc4j server _instead of_ the local maven
repository cache. That would be a bad thing as now any other maven projects
that depend on your artifact will fail their builds.
I hope that what you have done is bind another plugin to the install phase
so that the artifact still ends up in the local maven repository cache. That
would be less bad.
However, what I would do would be something completely different. I would
not bind the plugin you are using to copy the packaged artifact to any phase
at all, I would just invoke that plugin directly. Then I could use profiles
to configure that plugin for each of the servers that it will be deploying
to.
For example, if I was using the antrun plugin, I would have profiles that
define the deploy locations for each of the oc4j servers that I want to
deploy to (or if that's just an url, I'd use a command line property) then I
could do
mvn install
which would package up the artifact and install it into the local repository
followed by
mvn antrun:run -PtestServer
if I was using profiles or
mvn antrun:run -Doc4jDeployUrl=...
I could even do both in one go:
mvn install antrun:run -PtestServer
If you really want to bind the plugin to the install phase, I would do that
in the profiles using unique execution id's, that way you could just specify
all the profiles for the servers to deploy to, for example
mvn install
would just install to local repository
while
mvn install -PdevServer -PtestServer
would install to local repo, development server and test server!
-Stephen