hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Mueller" <...@digitalstrider.com>
Subject Re: version detection ideas (was: Re: publishing sources to the maven-repo)
Date Sun, 10 Jun 2007 12:33:16 GMT
> 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?


PS: you can also activate the profile with a system property. see here[1]
for more details.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message