Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <47D04A86.6090300@cheiron.org>
Date: Thu, 06 Mar 2008 20:48:22 +0100
From: Mark Brouwer <mark.brouwer@cheiron.org>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Re: Outstanding ClassDep issues
References: <47BC9CB5.7080406@cheiron.org> <47CDB435.9020707@cheiron.org>
 <64efa1ba0803061116x6fe36d92x6f2eed7b3d6cf467@mail.gmail.com>
In-Reply-To: <64efa1ba0803061116x6fe36d92x6f2eed7b3d6cf467@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Patrick,

Patrick Wright wrote:
> Hi Mark
> 
> The main problem I've seen with ASM (as an end-user of libraries in
> which it is used) is that the ASM team makes breaking API changes even
> within minor releases. This causes no end of heartache if you inherit
> an ASM dependency, at runtime, from two different libraries. The
> workaround in that case is to use something like JarJar, which munges
> package names to produce unique versions of the library. If you're
> using ASM standalone it shouldn't be an issue, unless, again, other
> dependencies cause a different version to land in your classpath. I've
> run into this issue with ASM more than once just in the last
> half-year. OTOH, it's a well-regarded library for what it does.

Thanks for mentioning and warning. This is certainly something to 
consider if ClassDep would depend on ASM. I expect the usage of ClassDep 
mainly to be at build time but in case of Ant you never know what people 
put in the Ant lib directory.
-- 
Mark