On 10/06/07, Roland Weber <[EMAIL PROTECTED]> wrote:
Hi Daniel,
>> update
>> properties files with the version number during release builds,
>
> If you could elaborate a bit more on your idea, I'm gonna think about it. I
> solved a similar problem at work and probably can find a solution faster.
The goal of version detection is to log in debug output which
versions of the various modules are in the environment. The
basic approach would be to package a version.properties file
with each module (in different packages), then hard-code a list
of modules in a version-detection class.
An alternative might be to use the svn revision - there would then be
just one number to worry about.
I'm doing this for the nightly JMeter builds.
[See nightly target in build.xml for the details]
My trickiest requirement for version detection is the following:
if somebody downloads one of our source builds and re-builds it
locally instead of using the release JAR, that has to show up
in the version log. The most likely reason for a local build are
changes to out classes, and we should be aware of that fact when
asked to give support.
Would it not just be simpler to ask for the MD5 of the jar(s) if you
suspect that a local version has been created?
Indeed, why not generate the MD5s and log them in the debug output?
To achieve that with Ant, I would use a <copy> task with filters
on the properties files. I think Maven has a step prepare-source
in which to do such things. I would hard-code a version number
SNAPSHOT in the build.xml and override that from the command line
or in a local build.properties when doing a release build.
If someone did a local build bypassing Ant, the properties would
either be missing, or they would show the unreplaced filter tags.
A local build using Ant would show version SNAPSHOT.
What's to stop them using the release identifier?
I don't doubt that Maven can copy and filter properties files as
well as Ant can. But if Maven gets the version from the pom.xml,
which is shipped set to the release version, that wouldn't be
enough.
One option is to keep not only the version, but also a build
timestamp in the properties files. Then we could see from the
timestamps which modules are release JARs and which aren't.
Yes, that would be safer.
But MD5 hashes would work just as well?
S.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
