The issue to us was fairly simple: We had a working build process. The developers knew the project. Everything was fine and dandy. We moved to Maven and lost three weeks of work. Developers don't understand the new process as well as the old process, we've fallen behind schedule.
We had a strong build process. Granted, we spent a long time working with Ant to make the process strong and stable, but moving to Maven wouldn't give me back the time we spent. Maven gave us a standard way we setup a project, so developers will be familiar with it, but we already had that. Yes, new developers will have to learn the quirks, but now the current developers are stuck learning the new Maven way in a project they knew backwards and forwards. So, where did moving to Maven in this particular project benefit us? Was it worth the bad will generated? Was it worth the time we took which could have been spent doing actual coding? In our evaluation, the costs outweighed the benefits. We didn't get a better build process out of it. It didn't make our project easier to work with. And, it ended up costing us a lot of time and effort. We aren't abandoning Maven. We are still using it for new projects. We are still moving some older projects off of our old system and onto Maven. Sooner or later, those older projects we decided not to move to Maven will be "rearchitected". At that time, we'll probably insist they convert over to Maven. On Mon, Feb 23, 2009 at 11:19 AM, Jon Georg Berentsen <jon.georg.berent...@objectware.no> wrote: > > > -----Original Message----- > From: David Weintraub [mailto:qazw...@gmail.com] > Sent: 23. februar 2009 16:58 > To: Maven Users List > Subject: Re: Mavenizing existing project > > "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." > >>Why was this a bad thing? > > > "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." > >> Again, why was this bad? > > "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." > >>Not good. But the time spent will pay off. And 3 weeks is normal for å >>enterprise project. > > "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." > >>Yes. Maven is a complex thing to learn, but it is better than anything I have >>seen. > > > 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 > > > --------------------------------------------------------------------- > 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
