Morgan Schweers <email@hidden> wrote:
>At that point, you start needing some stuff like source checksums to
>see if anything per-jar has changed, if you want to make sure not to
>increment the version numbers.
Checksumming (or hashing) the source doesn't necessarily tell you if
anything in the corresponding jar has changed. Yes, there are many source
changes that result in jar changes. But that doesn't mean they all do.
Editing comments is the first source-change I can think of that may have no
effect on the class-file. It may, if you change @deprecated tags, but
mostly it won't. There are also code cleanups and normalizations that
might not change the class-files, though most will.
Also, there are non-source changes that don't change source, but do change
what's in the jars, such as different compiler options. So unless the
entire production pathway (which encompasses the production-tool options)
are identical from release to release, comparing source alone won't answer
the question of which jars changed between releases.
So in my book, if you want to manage deltas between jars, then you have to
operate on the immediate contents of those jars. That means the
class-files and resource-files, the jar manifests, and the in-jar directory
structure.
>I believe that's the problem facing the OP. Builds are done
>'clean-room' by a release engineer, and it would be nice if they only
>had to build the jars where things had changed. I don't know of any
>good release-engineer-focused solutions to this problem, and would
>love to hear of some.
The first thing to do is keep the prior release as the reference point.
>From that reference point, you can do all the rest of the release
management. If you don't have a reference point, then every release's
reference is the null set, so every release's delta is the release set.
Once you have the reference point, you compare the elements. As already
noted, comparing jars won't work. You have to compare their contents, but
you're only interested in a boolean or bivalent Yes/No answer to the
question of whether there's a difference or not.
There are different ways to get the answer. Hashes are one way. Comparing
files is another. This was already discussed so doesn't need rehashing.
You also have to look for changes in directory structure. This is easy if
you use fully qualified names within each jar.
Finally, you have to decide whether a removal is a change worth counting or
not. For example, suppose we had this in the first fruits.jar:
Banana.class, Lemon.class, Tangerine.class
and this in the second fruits.jar:
Banana.class, Tangerine.class
Assuming there are no other changes to any other class in fruits.jar, does
the removal of Lemon.class necessitate distribution of a new fruits.jar?
From a technical and operational standpoint, it doesn't. No other class
referenced Lemon.class, so its presence doesn't matter. We don't know just
by inspection why Lemon.class was present at first, only that it was.
However, if reflection is being used to produce a list of all classes in a
particular directory, and present that in a list to the user, then maybe
Lemon.class really DOES matter to the end-user.
The same thing can happen with resources, plugins, or any module or
component. That is, removal may or may not be significant to the
end-user's perception of a change. Only a human can decide the correct
answer.
You can clearly use Ant for doing this kind of release management. You
just have to use different Ant tasks than the ones normally used for
development. Or more specifically, you have to add a few tasks, mainly to
do the comparison between the reference point and the latest prospective
build-products, and then assemble the release-delta build-products (i.e.
the set of changed jars). I honestly don't think it's going to be
difficult to do, whether you use hashes or not.
One hurdle is mostly conceptual, and that's treating the reference point
(I.e. the prior release's jars) as a kind of "source item". It's clearly a
build-product from a prior generation, but it's not a build-product when
it's being used as a reference point. It's used to compare just-produced
build-products against, in order to create the new release's delta or
update-only set.
-- GG
_______________________________________________
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
This email sent to email@hidden
