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.
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.
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.
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.
One of the simple options to solve the problem is to use a profile. its very
likely that custom built distributions are built with:
mvn package or mvn install
and not
mvn package -P release-profile
and you could still issue a warning in the pom as xml comment, to not do
that and giving the reasons. In the profile configuration can be whatever
change to the build procedure you'd like (version file, ant-style filtering
of classes or ressources, whatever). While it's not fail proof I think it
would solve the problem nicely and without requiring too much thinking
during the build process (which I definitely like: "did you do A before you
did B and shipped the thing to be dropped on production servers" immediately
followed by a wail of despair ;)
Would that solve the problem or is a more secure solution necessary?
Cheers,
Daniel
PS: you can also activate the profile with a system property. see here[1]
for more details.
[1]
http://maven.apache.org/guides/introduction/introduction-to-profiles.html
