Mailing-List: contact torque-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Torque Developers List" <torque-dev@db.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Date: Mon, 15 Oct 2007 08:14:16 -0700
From: "Brendan Miller" <bmiller@dotster.com>
To: Apache Torque Developers List <torque-dev@db.apache.org>
Message-ID: <20071015151416.GA9929@localhost.localdomain>
In-Reply-To: 
 <8F5843B903F59D4C8C6806BB49A39119046EAFF4@dukece-mail3.dukece.com>
References: <470DA831.5050400@backstagetech.com.au>
References: <470DC0E2.8090002@tewisoft.de>
References: <20071011130822.Y51886@minotaur.apache.org>
References: <4710D7CF.5050305@apache.org>
References: <8F5843B903F59D4C8C6806BB49A39119046EAFF4@dukece-mail3.dukece.com>
Subject: Re: torque 3.3 schedule
User-Agent: Mutt/1.5.11
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Disposition: inline

On Mon, Oct 15, 2007 at 10:27:07AM -0400, Greg Monroe wrote:
> FWIW, I'm -0.25 on integrating it into the Runtime jar 
> for this version. 
> 
> Mostly because of possible support issues around having
> an old version of Village in the classpath with new code
> in the Torque jar.  This probably won't be a developer
> problem because Maven, et al, handle the dependencies. 
> But I can see it happening on established production 
> servers where removing old jars are often forgotten.
 
Allow a humble user to chime in on this--our process is ant-driven
(not maven) and uses build.xml to copy the correct jars from our own
repository of jars against we have tested our application to the correct
production location.  Obviously, we would intend to remove village.jar
once it was part of the torque runtime, but we could forget, the script
could go whack, a server could get missed, etc.

So good point.

Brendan


---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org