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]
