That is really cool. Very useful. Are you going to push through the zip plugin and war plugin changes?
>>>>> On Mon, 05 Apr 2004 12:15:40 +0200, Maczka Michal <[EMAIL PROTECTED]> said: >> -----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] -- ===================================================================== Jeffrey D. Brekke [EMAIL PROTECTED] Wisconsin, USA [EMAIL PROTECTED] [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
