hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Weber <ossf...@dubioso.net>
Subject version detection ideas (was: Re: publishing sources to the maven-repo)
Date Sun, 10 Jun 2007 11:30:50 GMT
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.

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.


> The simple truth is that I'm very
>> unlikely to ever learn Maven well enough to come to like it :-)
> 
> I spoke the same words some time ago ;)

My two current job responsibilities are one non-coding project,
and one where a demo is coded using an Eclipse-based tool and
nobody but me cares about a decent build process at all. I sure
won't learn Maven in-depth on private time ;)

cheers,
  Roland

---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org


Mime
View raw message