hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: version detection ideas
Date Sun, 10 Jun 2007 14:04:20 GMT
On 10/06/07, Roland Weber <ossfwot@dubioso.net> wrote:
> 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.

OK, I see. But you could use the current revision in each jar in the build.

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

Since they must have Java, one could provide a Java md5 utility...

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

Not sure I understand the objection...
It would only need to be done once per jar, and only if debug was enabled.

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

OK, understood; that simplifies matters.

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

Agreed there's no point adding the MD5 to existing jars.
[Indeed adding a property file to the jar will change the MD5 of the jar.]

I was referring to the MD5 ideas mentioned above.

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

You need a file that is updated for every release that you make.
[Which is one reason why I used svnant for nightly builds]

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

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