You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by Karen Schaper <Ka...@danzas.com> on 2003/01/02 17:35:54 UTC

Upgrade to Ant 1.5

I have upgraded to ant1.5 and some parts of my build script are not working

I am getting the following error message

Unable to load dependency analyzer:
org.apache.tools.ant.util.depend.bcel.AncestorAnalyzer

Is there a list of what needs to be modified when upgraded to ant 1.5 from
ant 1.4?

Thanks

Karen

-----Original Message-----
From: Bwana McCall [mailto:bwanamccall@yahoo.com]
Sent: Thursday, October 17, 2002 4:22 PM
To: Ant Users List
Subject: RE: Looking for a Build Philosophy


A great thread indeed!  I too have been challenged with the CM role at our
company and am looking for ideas on improving our existing philosophy.  Much
of
what was said is what we strive to do including:

* Nightly Builds (with automated tests + junit/winrunner reports)  "Who
broke
the build??"  Usually the topic of conversation if someone failed to
properly
compile and integrate their code before commiting to the baseline.  This, in
my
opinion, is a must have for any dev shop.
* Unit and Integration Testing Processes. (+1 for Continuous integration!
I've
just read about this and am really interested)  This is an area where we are
currently lacking and what Im striving to improve.  Many of our developers
are
different backgrounds and use different techniques, so its going to be a
challenge to mold them all into something everyone can use.  I have
"forcing"
anything on anyone, and am always open to compromise on improving processes.
* Some kind of Source Control Process which will let you know where and why
a
code change was made.  Change Request, Defect/Issue Fix, Project Plan Task,
etc.  Anything unique identifier that you can link to that source code file.
Most tools include this (ClearCase does I know) but most dont.  We use CVS
and
I've had to write custom perl scripts to handle commit templates to feed our
bug tracking / project management systems with code change info.  This will
tie
Source Control into Project Management and help those in charge know what's
really going on and why.  Some may call it "Big Brother"'ish but too much
change is the #1 killer of software projects.

As was said on this thread, a lot of this is contingent on the size of your
project and development team.  I come from a heavy QA background (former
analyst/tester, now process engineer/CM) and that really helps with
maintaining
a high level of integrity with processes.  Our developers are resistant to
change which doesn't make my job any easier, but hey, if it weren't a
challenge, where's my motivation? :)

--- "Shackelford, John-Mason" <Sh...@ncs.com> wrote:
> You might consider using Cruise Control to automate builds. You can set
> Cruise Control to build after any check-in occurs and a specified idle
time
> on the source control has elapsed. It automatically sends emails to the
> build manager and offending developer whenever the build is broken. A
> servlet also gives a history of builds and check-ins. I found that this
tool
> radically altered the way developers in my group worked. Since everything
we
> did had such an obvious public impact right away (we built after any
> check-in and 15 minute idle) everyone was very alert to quality. When one
of
> us broke something it became a game to get the fix in before the next
build.
> I think CC is especially helpful on large teams (one project we used CC
for
> had 200 developers) as it makes everyone feel that their work is a vital
> part of the overall success of the project and that can only have a
positive
> impact.
>
> +1 for continuous integration
>
>
> John-Mason Shackelford
>
> Software Developer
> NCS Pearson - Measurement Services
> 2510 North Dodge St.
> Iowa City, IA 52245
> 319-354-9200x6214
> shacjo@ncs.com
>
>
>
****************************************************************************
> This email may contain confidential material.
> If you were not an intended recipient,
> Please notify the sender and delete all copies.
> We may monitor email to and from our network.
>
****************************************************************************
>
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>


=====
Bwana McCall
bwanamccall@yahoo.com
bwana@bwana.org | http://bwana.org
YIM: bwanadotorg / AIM: bwanadotorg

__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>