RE: Using Maven on a very large integration project - how far can Maven go?
dependency groupIdplexus/groupId artifactIdplexus-runtime/artifactId version1.0/version typezip/type /dependency I think this would be very useful for what I am planning to do with Maven. I like the concept. Once you finish testing it, I'd be very interested in testing it out on my project. Michael -- This E-mail is confidential. It may also be legally privileged. If you are not the addressee you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return E-mail. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using Maven on a very large integration project - how far can Maven go?
Tomasz Pik wrote: if war plugin finds 'war' dependency then un-war it and merge content of dependency war into created war. At least web.xml files should be merged together, probably more descriptor files too - but this may be done as postGoals. I don't think that merging web.xml or other files is a good idea. The logic for that has a good chance of becoming obscure and fragile. I would just make the dependant project files override the dependencies files. Simpler more predictable... R. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Using Maven on a very large integration project - how far can Maven go?
-Original Message- From: Rafal Krzewski [mailto:[EMAIL PROTECTED] Sent: Thursday, April 08, 2004 9:54 AM To: Maven Users List Subject: Re: Using Maven on a very large integration project - how far can Maven go? Tomasz Pik wrote: if war plugin finds 'war' dependency then un-war it and merge content of dependency war into created war. At least web.xml files should be merged together, probably more descriptor files too - but this may be done as postGoals. I don't think that merging web.xml or other files is a good idea. The logic for that has a good chance of becoming obscure and fragile. I would just make the dependant project files override the dependencies files. Simpler more predictable... R. I agree in 100%. That's what I did in my version. For the people which were intersted in this functinality: I won't manage to push it to CVS before holidays (no time) I pratically finshed zip plugin which pacakes all project resources into zip files and merges the content of multiple zips (declared as dependencies_. I just gave it to somebody for testing (I still have some problems with resource filtering) and when I'll be sure that it works I can add it to CVS. Anybody opposes to add this funcionality to RC3? With this plugin I am able(will be able) to keep in local repositoriy zip files which contains even such artifacts like JRE/JDKs, Java Service Wrapper files etc and only compose those artifacts for particual application. (To Jason)I belive it will be easy to construct plexus runtime using this techniue. Pratically no java nor jelly code is needed. I mean just something like: dependencies dependency groupIdplexus/groupId artifactIdplexus-runtime/artifactId version1.0/version typezip/type /dependency dependency groupIdplexus/groupId artifactIdplexus-startup-scripts-win32/artifactId version1.0/version typezip/type /dependency dependency groupIdplexus/groupId artifactIdplexus-jws-win32/artifactId version1.0/version typezip/type /dependency dependency groupIdjre/groupId artifactIdjre/artifactId version1.4.2/version typezip/type /dependency . /dependencies Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Using Maven on a very large integration project - how far can Maven go?
Michael, 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. 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. Eric Pugh -Original Message- From: Michael Mattox [mailto:[EMAIL PROTECTED] Sent: Monday, April 05, 2004 1:04 AM To: Maven Users List Subject: Using Maven on a very large integration project - how far can Maven go? I've used ANT on several projects in the past, and have had my eye on Maven for a year now. I am now working on a large project that is mostly integration. That is to say we are working with a few software editors (a webmail application and a chat application) to integrate them into our customers portal architecture. Each software editor is modifying their applications to support new requirements, and we're writing a relatively small amount of code to integrate them. For example, the webmail application has an API which uses HTTP to return XML data. We're writing a protocol adapter to exposure their API as a web service. We're also writing some protocol adapters that will be deployed on their servers. So far, I've set up a multi-project build for our source code. I created a common project, and then mail chat directories. Under each I have several projects for each application. I've found a lot of resources on doing this and it was relatively easy to set up and it's working great. From the top level I can do the multi-project build. My problem is I'm not sure how to proceed with the integration part using Maven. I have a couple needs: 1 - I need to deploy to the integration team our entire source code tree, along with the deliveries from our partners (the companies that make mail chat). The integration team is willing to install Maven, and they also use ANT. So my current thinking is to structure the tree like this: - extern (for deliveries from our partners) - mail - a standalone application - a webapp - chat - static HTML - a web app - a standalone application - our source tree - mail - a JAR to be deployed to the mail standalone app - a JAR to be deployed to the mail webapp - chat - a JAR to be deployed to the chat standalone app - a JAR to be deployed to the chat webapp - an EJB to be deployed to another server Does Maven have functionality to take the applications from our partners (in extern) and combine them with our JARS? Like copying all this to another top level directory, maybe install? I know I can do it with ANT, but I'm curious if Maven offers an added value here. 2 - The mail chat apps use WebSphere Tomcat, and databases Oracle MySQL. I'm currently working on install procedures. Using Tomcat for an example, should I put tomcat under the extern/chat tree? Or should integration install their own tomcat and then copy the files from the chat project to the appropriate tomcat directories? The integration team wants to do it like this, where they reassemble the parts themselves (using my maven project). That way they know what they have (official Tomcat release, etc.). On the other hand, the mail chat companies want to deliver a complete package that is tested and they know it works. For example, what if the mail application uses a modified Tomcat? In that case we'd have to use their Tomcat instead of installing a new one. This complicates the packaging a bit. Thank you for taking the time to read this long mail, and if you have any ideas please let me know. I've heard from a few people that Maven works great for simple JAR projects but it falls apart for complicated projects like this. I want to prove them wrong! In the worst case I can have Maven call ANT tasks. My goal is that the integration team gets our code from CVS and types a single command to build, test, and package our project. I think it's an aggressive goal but I'm certainly going to try. Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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. Thanks, Michael -- This E-mail is confidential. It may also be legally privileged. If you are not the addressee you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return E-mail. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Using Maven on a very large integration project - how far can Maven go?
-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 groupIdfoo/groupId artifactIdfoo-webapp/artifactId version1.0/version typewar/type /dependency dependency groupIdfoo/groupId artifactIdfoo-configuration-for-node-X/artifactId version1.0/version typezip/type /dependency dependency groupIdtomcat/groupId artifactIdtomcat/artifactId version4.1.27/version typezip/type /dependency dependency groupIdtomcat/groupId artifactIdtomact-admin/artifactId version4.1.27/version typewar/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]
RE: Using Maven on a very large integration project - how far can Maven go?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, April 05, 2004 3:10 PM To: Maven Users List Subject: Re: Using Maven on a very large integration project - how far can Maven go? That is really cool. Very useful. Are you going to push through the zip plugin and war plugin changes? I haven't been thinking about that but if somebody will find it useful I can certainly do that. I should not have any problems with creating zip plugin. It's bit more difficult with war plugin but doable. The idea is that when war plugins finds any dependency of type war it should un-war it (unzip :) and use files which were stored there as sources for building new war file. I have it working but it's rather a quick hack then release quality. But I can try to improve it if somebody will be interested. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using Maven on a very large integration project - how far can Maven go?
Maczka Michal wrote: I haven't been thinking about that but if somebody will find it useful I can certainly do that. I should not have any problems with creating zip plugin. It's bit more difficult with war plugin but doable. The idea is that when war plugins finds any dependency of type war it should un-war it (unzip :) and use files which were stored there as sources for building new war file. I have it working but it's rather a quick hack then release quality. But I can try to improve it if somebody will be interested. Hmmm, maybe something like this: if war plugin finds 'war' dependency then un-war it and merge content of dependency war into created war. At least web.xml files should be merged together, probably more descriptor files too - but this may be done as postGoals. Michal Tomek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
