Sent from my [rhymes with myPod] ;-)
On 23 Feb 2009, at 20:51, Steve Cohen <[email protected]> wrote:
David Weintraub wrote:
Actually, if you don't have a strong build process, you need one --
Maven or no Maven. Builds should be automatic and repeatable.
Thanks. You are preaching to the choir, friend. I'm usually the
one preaching automated builds (and I'm in fact an Ant committer)
but I've never been on a team this small before and I'm the junior
member of the team in terms of seniority, but not in terms of
experience. I could easily stay with what we've got because our
developers basically don't work together (on what I do, I'm a team
of one as far as coding is concerned), but it isn't good practice
and too much rests in my own head. This is my motivation for making
a switch. Since I'm most likely NOT going to get to build a team-
wide (much less enterprise-wide) repo, this is in fact my main
reason for wanting to introduce Maven at this point.
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.
Yup - fortunately, a small team lets you get away with such
sloppiness but I know it's bad practice.
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.
Yes. That's my point. Thanks.
You should also look at continuous build systems like Hudson or
CruiseControl.
We're probably too small for those sorts of systems.
I run Hudson on my home computer. seriously, if you have either a good
ant build or a good maven build, setting up Hudson is a 5min no brainer
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?
---------------------------------------------------------------------
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]
