I am fairly new to Maven, so maybe there are things that I simply don't know the correct way of doing things. However, we did "Mavenize" one project, and we simply found that it wasn't worth the effort.
We had a strong Ant build process and things were working very well there. The idea to Mavenize came from above. We rearranged our directory structure, but then realized that we were doing a few things that weren't quite standard. Getting these to work took a lot of time and effort. It involved modifying some code and changing the way we deployed. We had times when we were sure everything was okay with our Maven build, but then testing found holes that we didn't realize were there. After three weeks, we finally got the Maven build working.In the end, we have angry developers, a steep learning curve to learn how to work on a project that developers knew in and out, and a build process that isn't much better than what we had. As a result, we have decided not to Mavenize all of our projects. All new projects will use Maven. Some of the simpler projects may be mavenized, but we'll carefully evaluate them. That doesn't mean we didn't learn some neat tricks in the process. The biggest concerns having project "A" build a jarfile that project "B" requires. In the pre-Maven days, that meant checking in that built JAR into Subversion, then using svn:export to pick up that jar from the other project. Checking in JARs several times a day into our Subversion repository proved difficult in both process and room. Now that we have a Maven repository, we now use the deploy:deploy-file mojo to deploy that Jar to our Maven repository. If the receiving project is a Maven project, we can now pick it up using the standard dependencies methods in the pom.xml, and we are converting many of these dependent projects into Maven because here's a real advantage Maven does have for us. And for the few dependent projects that we cannot easily Mavenize, I now use Ant's <get> task to download the jars from the Maven repository. It isn't as clean as the way Maven does it, but it has proven easier to do than to Mavenize these difficult projects. So Mavenizing old projects isn't just a blanket thing to do. You have to evaluate what you have now, and what you expect to gain with Maven. Some projects are pretty straight forward, but if you have an older project with a complex build process, and a build process that fairly rigorous, moving to Maven simply doesn't buy you all that much. On Sun, Feb 22, 2009 at 9:04 AM, Steve Cohen <sco...@javactivity.org> wrote: > I am considering"Mavenizing" a pre-existing project. > > This project consists of a Web Application (WAR file) and a server side JAR > module, built from several Eclipse projects, some of which are dependencies > of both modules, as well as many third party jars, both open source (many of > which themselves use Maven, of course) and proprietary. > > Current build process is very rudimentary. The Eclipse projects do not > currently use Maven naming standards for directories. To do builds, the > simple Eclipse Export menu options are currently used. Deployment is manual > and there are some annoying manual post-export tasks that must be run. > Version control uses subversion, including a big ugly "project" containing > static copies of binary jars. These are my main reasons for considering > conversion to Maven. > > Questions: > > 1. Are there articles around detailing "war stories" about making the kind > of move I am contemplating? I would like to read such before I get started. > I have just purchased Maven: The Definitive Guide, and while the > information there is very good, it tends to assume a start from scratch. I > would like to keep the history in the Subversion respository if possible. > > 2. Would I be better served by renaming directories at the start to Maven > "Convention over Configuration" standards or by overrriding the defaults all > the way down the line? > > 3. Would I be better off building a local network repository containing both > the open source and proprietary code needed or would it be better to create > a local repository only for the proprietary stuff and get the open source > stuff from a remote repository. > > Thanks. > > Steve Cohen > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- -- David Weintraub qazw...@gmail.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
