how about this?
|_ <maven.home>
|_ plugins
|_ j2ee
|_ build.xml
|_ default.properties
|
|_ tomcat
| |_ build.xml
| |_ default.properties
|
|_ weblogic
| |_ build.xml
| |_ default.properties
|
|_ jonas
| etc........
The j2ee default.properties has some property that identifies which server
plugin (which build.xml) to delegate to. This can be overridden by individual
projects to enable different projects to deploy to different servers. Does this
fit with the maven plugin model?
Each server has its own plugin build.xml containing a set of standard targets e.g.
war-deploy
war-update
war-reload
war-undeploy
ear-deploy
ear-update
ear-reload
ear-undeploy
......
in addition each plugin target could have additional targets to perform server
specific actions.
[EMAIL PROTECTED] wrote:
> Ant 1.5 has some deployment tools as well. The plan was was to look at how
> this was happening in Ant, and see if we could use that. I noticed a
> patch/rfe today for Orion in the deployment tools.
>
> If cactus has some of this worked out already, how does it fit with the Ant
> 1.5 serverdeploy tasks?
>
> I had envisioned deployment as either part of the j2ee plug-in, or if it's
> lots of appserver specific stuff, in an appserver plug-in, e.g. Tomcat has
> their own ant tasks for management.
> --
> dIon Gillard, Multitask Consulting
> Work: http://www.multitask.com.au
> Developers: http://adslgateway.multitask.com.au/developers
>
>
>
>
> "Vincent
>
> Massol" To: "'Turbine Maven Developers List'"
>
> <vmassol@octo. <[EMAIL PROTECTED]>
>
> com> cc:
>
> Subject: RE: j2ee component deployment
>
> 05/22/02 02:32
>
> AM
>
> Please respond
>
> to "Turbine
>
> Maven
>
> Developers
>
> List"
>
>
>
>
>
>
>
>
>
> Yes, this is (almost) what Cactus is doing. In short Cactus provides
> several already made Ant scripts ready to use to perform deployment to
> different application servers (WL 6.1, Orion 1.4, Orion 1.5, Tomcat 3.x,
> Tomcat 4.x, etc).
>
> Jeff and I were wondering how we could integrate this with Maven. It
> could be done either through a Cactus plugin I guess but that would
> probably not be the best approach as packaging / deploying is useful in
> itself, even without Cactus tests.
>
> So I'm in favor of a deployment plugin in Maven. One of the nice thing
> the Cactus Ant scripts have (I think ) is the in-place deployment, i.e.
> you can specify any directory and the scripts will package and deploy a
> fully working application and associated application server
> configuration file in that directory.
>
> I would be in favor of having this feature in that plugin.
>
> -Vincent
>
>
>>-----Original Message-----
>>From: Nathan Coast [mailto:[EMAIL PROTECTED]]
>>Sent: 21 May 2002 14:09
>>To: maven dev
>>Subject: j2ee component deployment
>>
>>Hi,
>>
>>looking at the build-j2ee.xml, there are targets to automate the
>>
> assembly
>
>>of war
>>and ear files. Are there any plans to provide automation of the
>>deployment /
>>updating of these assembled components within j2ee containers?
>>
>>e.g. ear files to common j2ee servers - weblogic, websphere, jboss.
>>similarly
>>war files to tomcat etc.
>>
>>This would presumably require an extension of project.xml to describe
>>which
>>container was in use and properties specific to those containers -
>>location,
>>username, password etc.
>>
>>This could lead the way to automating the testing of new builds within
>>
> the
>
>>deployment environment.
>>
>>1) build / assemble
>>2) unit test
>>3) deploy
>>4) tests against deployed environment.
>>
>>Might make sense to leverage the new support for j2ee deployment to
>>
> common
>
>>containers in available in ant 1.5.
>>
>>Cheers
>>Nathan
>>
>>
>>--
>>To unsubscribe, e-mail: <mailto:turbine-maven-dev-
>>[EMAIL PROTECTED]>
>>For additional commands, e-mail: <mailto:turbine-maven-dev-
>>[EMAIL PROTECTED]>
>>
>
>
>
> --
> To unsubscribe, e-mail: <
> mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <
> mailto:[EMAIL PROTECTED]>
>
>
>
>
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
