Mailing-List: contact ant-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ant-user@jakarta.apache.org
Date: Wed, 13 Jun 2001  8:14 -0500
From: "William Settle" <William.Settle@alltel.com>
To: "ant-user@jakarta.apache.org" <ant-user@jakarta.apache.org>
Subject: RE: Comparing Method signatures from one build to next
Message-ID: <20010613081525223-2cf3cb8b@alltel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Peter, you are correct in that I'm trying to build a change document during our
daily build to give our developers a "head's up" on what has changed.  

Diane, that would work if we only had a couple of SCM instances but there are
many different departments across our company (and country) using many different
SCM's (PVCS, Clearcase, CVS, VSS) which would make this task very difficult
using the various SCM tools, especially since there is no real standard with
labeling and promotion levels.  It has taken some time just to get them all to
label files that they want in our daily auto-build process.

The various groups do attempt to leverage other's work but as we all know,
interfaces do change as well as the common method signatures.

Since a particular group may have a "code freeze" before a product is released,
I jar up source, javadoc and runtime code in my daily builds so each group will
have all the source required to support a particular customer.  This allows each
group source access without having to install the SCM's on every computer in
every group.

My goal is to be able to compare runtime files, specifically, jar's, war's and
ear's and produce difference documents with what method signatures have been
changed or deleted at a minimum.

To do this I would have to iterate through the archive then use reflection to
gather class information for a particular build and create a persistent
object/method hierarchy somewhere (I'm thinking an LDAP tree).  Then I would
compare this to a previous build to get the changes.  Not a big job but still a
good bit of code to make it happen.

What this will give us is the ability to verify we didn't "break" an interface
or required API, even at the customer's site, if we made a change and shipped
them a new archive.

I have looked at Sitraka's JClass utility and it has some of the features I want
but is not 100% pure Java so it's out of the running.

Does anyone have any ideas on how to accomplish this task?

Thanks again,
Bill

-----Original Message-----
From: ant-user@jakarta.apache.org 
Sent: Tuesday, June 12, 2001 5:55 PM
To: ant-user@jakarta.apache.org
Subject: RE: Comparing Method signatures from one build to next


--- Peter  Vogel <pvogel@arsin.com> wrote:
> I think, actually, that Bill is trying to get more language-specific
> information than an SCM tool provides.
>
> That is, an SCM tool shows diffs, what Bill wants is the semantics
> behind the diffs, what classes are new/deleted, method signatures
> etc.

I meant as a starting point. First you'd capture the change submissions
for the day, then sort out the changes you were interested in (deleted
files, certain types of modifications to files, etc.) That's why I said
it'd be difficult to be specific without knowing which SCM he's using.
Either that, or I guess you could have every-other-day output trees and
compare them -- but that seems like you'd be wading through an awful lot
of stuff that hadn't changed, just to find the stuff that had.

Diane

=====
(holtdl@yahoo.com)


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year!  http://personal.mail.yahoo.com/