hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Weber <ossf...@dubioso.net>
Subject Re: version detection ideas
Date Sun, 10 Jun 2007 13:18:12 GMT
Hi Sebastian,

>> 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.

The version detection must tell us that someone is using
httpnio.jar from release alpha5 with httpcore.jar from alpha4
and httpclient.jar alpha1. We need one number per module/jar.

The advantage of using "$Revision: 54395$" instead of "alpha1"
is that we don't need a build step to bring it into a property
file. But it doesn't address my trickiest requirement. If we
drop that requirement, revision numbers are a good option. If
we do have a build step, I'd prefer the more readable version.

> 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?

That requires us to have a suspicion in the first place, which
may take several round trips to build. Then we'd have to tell
people how to generate MD5s (minor problem if md5sum is installed,
but is it on a Windows box?). Last but not least, it assumes that
people know which JARs are actually picked up from the classpath(s).
But you are right, the trickiest requirement will be a rather
rare case. If all other requirements can be satisfied with a
simpler solution, this is an option to address the tricky one.

> Indeed, why not generate the MD5s and log them in the debug output?

Access the JAR file from somewhere in the classpath to generate
an MD5 sum at runtime? I don't think that's an option, and in
particular not for a class that's supposed to go into HttpCore.
File access and a cryptographic hash sum just for debug output?

>> 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'm not tryig to prevent anyone from deliberately stealing our
time. It's meant for folks that forget to tell us that they've
made local modifications, or think that their modifications are
not related to the problem, or that don't even know about the
modifications because somebody else gave them the JARs they
should use.

>> 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?

For MD5 hashing at runtime, see above. Putting an MD5 hash
into a property file within each JAR requires postprocessing
of the JARs. Oleg will like this idea no more than I do.

I'll reconsider whether the trickiest requirement is really
important enough to merit an extra step in the build. If not,
I will give the $Revision$ option careful consideration.

thanks and 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