Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 25498 invoked from network); 30 Oct 2002 15:35:01 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 30 Oct 2002 15:35:01 -0000 Received: (qmail 17384 invoked by uid 97); 30 Oct 2002 15:35:27 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 17323 invoked by uid 97); 30 Oct 2002 15:35:26 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 17286 invoked by uid 98); 30 Oct 2002 15:35:26 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-ID: <003801c28029$b6a498d0$0200a8c0@spiritsoft.com> From: "James Strachan" To: "Jakarta Commons Developers List" References: <017501c2800f$b1abdb50$b4c8c8c8@octovma> Subject: Re: [latka][anteater][jelly] possible integration... (was Re: Latka & Anteater) Date: Wed, 30 Oct 2002 15:33:34 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N From: "Vincent Massol" > Cactus can use any JUnit test runner. Thus it should be able to use the > exsiting JellyUnit tags with no problem. However, before running the > tests there needs some preparations to make everything automatic: > - packaging the application as a war or ear > - configuring the container > - starting it > - deploying the app in it > - stopping it > > These could be easily achieved through a combination of Ant and Jelly > tags, potentially used in a Cactus Tag library which would make the > whole thing easier and more coherent to use? Sounds good to me. The war/ear would be generated by the build process I guess. Different tests may want to configure the container, start it, deploy app, stop it in multiple times. e.g. to test the same war or ear on different deployment configurations, containers or platforms. So deploying artifacts should be part of the test case; whereas the war or ear should be part of the build process shouldn't it? James ------- http://radio.weblogs.com/0112098/ __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com -- To unsubscribe, e-mail: For additional commands, e-mail: