Re: Java-dev Digest, Vol 1, Issue 178

• Subject: Re: Java-dev Digest, Vol 1, Issue 178
• From: Russell Gold <email@hidden>
• Date: Fri, 10 Dec 2004 09:55:10 -0500
• Delivered-to: email@hidden
• Delivered-to: email@hidden

If you have version-numbers (or even just serial build-numbers) in each
jar's manifest, then you can use that. You simply extract it from each jar
previously released, and compare it to the one extracted from the
just-built corresponding jar. If they differ, then the jar changed, which
implies something inside the jar changed. If nothing inside the jar
changed, then the build-numbers will be the same, and you don't have to
redistribute that jar to customers who already have it. (I prefer the term
build-number over version-number, when it's used in this way. That leaves
marketing to decide what "version-number" values are, and what they mean.)

You could probably write a shell script that extracted a manifest from a
previously released jar, grepped for its build-numbers, and then compared
that to the one from the current build. Nor is it difficult to write in
Java, as an Ant task, and since you already use Ant, I think that's the
better approach. First, though, you might want to look for an Ant task
that already does something like this. Release management is not outside
Ant's capabilities.

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden

• Prev by Date: RE: Versioning Java Applications
• Next by Date: Shark: profiling time traces
• Previous by thread: Re: ANN: webkitjava project on sourceforge
• Next by thread: Shark: profiling time traces
• Index(es):
  • Date
  • Thread