> -----Original Message-----
> From: Michael MATTOX [mailto:[EMAIL PROTECTED]
> Sent: Monday, April 05, 2004 11:59 AM
> To: [EMAIL PROTECTED]; Maven Users List
> Subject: RE: Using Maven on a very large integration project - how far
> can Maven go?
>
>
> > I think your overall approch is on target. One of the
> things I have found
> > easier when deploying to containers is to have Tomcat as
> part of CVS.. It
> > gives you a lot more control over what the Tomcat
> environment looks like,
> > isn't too large, and reduces variables.
>
> I agree in principle. The problem is it's not practical to
> put WebSphere or
> Oracle in CVS. So what I was thinking was to divide the
> containers into two
> categories:
>
> - versioned in CVS - for unstable, lightweight containers
> only. For example
> tomcat.
>
> - an install procedure using official releases. This would
> be for Oracle,
> MySQL, WebSphere.
>
> Tomcat can fall into either category, and I prefer the
> second. But I'm open
> to suggestions.
>
> > Also, as far as the merging of jars, anything you can do in Ant,
> > you can do
> > in Maven, as Maven supports all ant tasks. Here is an article
> > that gives a
> > simple example of calling the <echo/> task from Ant in Maven:
> > http://www.onjava.com/pub/a/onjava/2004/03/17/maven.html.
>
> This is a worst case, call the ANT target. But with Maven's
> Jelly scripts I
> wasn't sure if it'd be better to do something with ANT or Jelly.
>
I am using quite different technique. I keep Tomcat and such as zips in my
maven repository.
For example in case of Tomcat I have removed most of the files and I keep
only those files which are really needed to run it in a zip file in local
repository.
Then I have POM fragments like:
<dependencies>
<dependency>
<groupId>foo</groupId>
<artifactId>foo-webapp</artifactId>
<version>1.0</version>
<type>war</type>
</dependency>
<dependency>
<groupId>foo</groupId>
<artifactId>foo-configuration-for-node-X</artifactId>
<version>1.0</version>
<type>zip</type>
</dependency>
<dependency>
<groupId>tomcat</groupId>
<artifactId>tomcat</artifactId>
<version>4.1.27</version>
<type>zip</type>
</dependency>
<dependency>
<groupId>tomcat</groupId>
<artifactId>tomact-admin</artifactId>
<version>4.1.27</version>
<type>war</type>
</dependency>
</dependencies>
and plugins which are creating application which are a merger of tomcat
zip/wars (possibly many wars)/zip with configuration settings.
As the result I get another zip (ready to use application) which is zipped
and installed in my local repository.
Using this technique I am for example easily enable to use different version
of tomcat (just need to edit my POM to change it)
or have many configuration (for many customers) of the same application. But
I am _always_ using local repository for keeping and exchaing artifacts
between projects.
Even artifacts like tomcat (zip) or configuration files.
I have created maven zip plugin which puts to zip archive all the files
declared as resources in POM and which is also able to merge many zips into
one.
I am also using my own version of war plugin in which I can declare
dependencies on other wars and just replace some configuration files.
So I have one base war file and couple of its mutations for various
environments: for testing
(e.g. against different databases), for various production environment (in
my case we use the same wars with different configuration setting for
different customers).
Michal
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
