Actually, if you don't have a strong build process, you need one -- Maven or no Maven. Builds should be automatic and repeatable. If I gave you the same source code, you should produce the same build. It's bad enough keeping track of actual coding errors, but when you might introduce bugs simply because of a manual build process, you're in trouble.
We use Hudson for continuous build integrations. Every time someone checks in new code, we automatically build and test. It doesn't matter if a developer is simply fixing a spelling error in a readme document, or restructuring the entire foundation of the project: We build. And, our official build process is available for the developers to use. When an official build fails, the "It worked on my machine" excuse doesn't cut it. The developer not only has to build it in his Eclipse environment, but also has to run our build scripts to prove to me that it actually works. Since you don't have a build process, creating one using other tools like Ant or simply moving to Maven really doesn't make too much difference now. As you said, you don't need third party jars in Subversion if you use Maven. It might be worth moving to Maven just to have a solid build process. You should also look at continuous build systems like Hudson or CruiseControl. On Mon, Feb 23, 2009 at 11:11 AM, Steve Cohen <[email protected]> wrote: > Unfortunately, you guys may be talking me out of mavenizing rather than into > it. :-( > My situation is a bit different than what is described. > > There are only two or three real "developers" in my project and they work on > separate applications with very little sharing between them - and I am one > of them, the one most involved in coding, in fact. I'm not an SCM guy per > se, though automated builds have always been an interest of mine. > Nonetheless I recognize the third-party-jars-in-svn thing as an > anti-pattern, and would like to move toward a truly automated build. (As I > indicated in my original post, we don't even use Ant here - we use Eclipse's > built-in Export to build - and even THAT was a big step forward for this > team). But a local, networked M2 repo is going to run up against all sorts > of security minefields. > > So I would like to explore a somewhat different path: > > 1) abandon any thought of a local repository for now. Too many > political/bureaucratic issues. Each developer could download maven and the > m2eclipse plugin himself and build a local repository of things needed. > > 2) create a POM in an SVN branch and develop automated maven-based builds > using developer-local repos. If builds break, devs can update their repo. > > 3) as this becomes general, down the road, if and when the need for a local > repo is perceived, only then take that step. > > Does this kind of plan make any sense to you guys? > > Jon Georg Berentsen wrote: >> >> +1 >> >> -----Original Message----- >> From: Samuel Langlois [mailto:[email protected]] Sent: 23. februar 2009 >> 16:11 >> To: [email protected] >> Subject: Re: Mavenizing existing project >> >> >> >> >> >>>> >>>> 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? >>>> >>> >>> Yes. >>> >>> This is the way I recommend myself. >>> >>> There are two ways you can do this... >>> >>> 1. Make the changes in trunk, and keep the existing build process >>> functional >>> while you change everything... this allows you to ignore maven until >>> >> >> you >> >>> >>> get >>> everything perfect. >>> >>> 2. Make the changes in a branch and merge them back when you're >>> >> >> ready... >>> >>> >> >> I agree you should follow the Maven "happy path". >> >> I migrated a big several-million-LOC project from Ant to Maven, and I >> chose >> a 3rd way, somewhat in-between. >> The trick is to keep the trunk as it is, so that people can still work >> with >> Ant as they are used to, and to perform the migration in a branch. >> In the branch, you commit only your pom.xml files and an empty folder >> structure. Every time you need some files from the trunk, you use >> svn:externals to make a kind of 'dynamic link' inside your SVN >> repository. >> Typically, your svn:external will look like this: >> module/submodule/src/main/java http://repo/trunk/module/submodule/src >> This way, you can quietly migrate without bothering anyone. >> >> When the migration is ready, you also need to make a shell script that >> will >> copy the pom.xml from the branch to the trunk and move all source >> folders in >> the right place. >> Similarly, you can prepare and test this script quietly on your side >> without >> impacting developers. >> >> The migration itself is then just a matter of minutes, while the script >> is >> run and you commit everything. >> >> That was a little more work for me, but not having 40 stuck developers >> on my >> back while I was performing the migration was priceless :-) >> >> Hope this will help you >> >> Samuel >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- -- David Weintraub [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
