Maven does several things... one of which is building, but the other
is to
gently (OK, maybe not THAT gently) push users to adhere to standards.
It is
not by accident that non-standard behaviors are untenable. The
standard in
this situation you describe is to use the maven-release-plugin. I know, I
know... doco sucks - we're working on it.
See below - I think the design of the release plugin is inadequate
Before you think this this is an isolated weakness on the part of Maven,
note that this kind of push is happening all over, and once you learn the
standard you see how nice it is to be able to go to any project built
with
Maven and be able to use and navigate through it. This is a similar
thought
behind Ruby on Rails, and clones like Trax... convention over
configuration.
I understand that - those are the reasons I chose maven to begin with.
In fact, for the past 9 years I've been developing build systems
designed on that exact premise, except that I haven't really pushed it
out onto people outside my organisation (see
http://www.cg-soft.com/tools/build/, even if it's somewhat dated by now,
I still use that system)
Nevertheless, it only works if the convention is useful and correct. If
the convention is flawed, then you need a way to fix it or work around
it. For now, I'm working around it by simply not using it. Someday, I
hope I can start using it, because the stuff I'm doing now isn't so hot.
Users shouldn't HAVE to know that in your super-special build system,
they
have to type "mvn install -DmyVersion=1.0-alpha-1-SNAPSHOT" to use it.
There are ways around that particular issue (for example, placing that
-D into the wrapper script which invokes maven), but those are besides
the point.
Here is what I do not like about the process implied by the release
plugin. Perhaps I'm not understanding all aspects of it, and perhaps I'm
just smoking dope, but here's what I see:
In order to use the release plugin, I have to decide to go for it, and
call a particular source tree releasable. This may sound trivial, but it
isn't. How do I decide that?
Say I have a QA department, and they tell me: "looking good", so I
release. I go through the motions, but now I need to have faith that the
actual release build is going to be exactly equivalent to the builds QA
used to say "looking good". Trouble is: we're not a faith based
organization. I need to -prove- that it -is- the same - AND I need to
prove it not just to my satisfaction, but to the satisfaction of any
pointy-haired boss that feels the need for some hands-on auditing. That
is actually very hard to do in real life projects. The simple fact of
removing the -SNAPSHOT from version numbers may have all sorts of side
effects - if only by removing any hope of doing binary checksums of the
build products - something you can't really do anyway, since way too
many processes insert useless timestamp info all over the place.
The only way I know of doing this is to produce release candidates that
look exactly as if they were the actual release, and keep building new
ones until QA says it's good. They then use that exact build.
Essentially, manage releases by access control, not by naming.
So I guess the solution is to continually run the release plugin to
generate various new versions with new build numbers, feeding a constant
stream of release candidates to QA. And that's where I hit the second
snag, which may be easy to fix, but it isn't clear at all from the
documentation. The release plugin needs to work non-interactively -
otherwise I'd be sitting there doing nothing else but maven builds.
The third snag is that I need to have a way to explain it how to use
perforce, and in a way that matches the way we are using perforce in
this shop. I guess I can live with the constant automatic checkouts and
checkins of pom.xml files, but I'm not sure how this affects developers...
Finally, I need to integrate maven into a larger system - until the day
comes when maven knows -everything- about -everything-, simply working
on the premise that maven is the ultimate controller is not helpful.
--
cg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
