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
Date Sun, 10 Jun 2007 14:19:51 GMT
I'm pretty sure that the md5 approach is infeasible. the problem is that you
change the md5 hash of the jar as soon as you pack the md5 hash of the jar
into the jar, which is kinda recursive. You could let the people do a
hashing over their jar to see if they got the genuine version, but that a
bit much to ask from user of your library (I would be a bit set off when I
requested help and the first thing asked of me was the md5 hash of all the
jars used from this particular project).

I think what you want to have is simply a textfile per jar with version
information which contains among others buildtime, checkouttime/version,
cvs/svn tag/branch name if it was a release, maybe more. You could even
provide a Util which gathers together all those version file, and prints
them on the console, which can then easily be used to the list-members what
they are looking at.

just my 2 cents

Cheers,
Daniel

On 6/10/07, sebb <sebbaz@gmail.com> wrote:
>
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message