Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 1870 invoked from network); 6 Jan 2003 22:28:10 -0000 Received: from exchange.sun.com (192.18.33.10) by daedalus.apache.org with SMTP; 6 Jan 2003 22:28:10 -0000 Received: (qmail 1067 invoked by uid 97); 6 Jan 2003 22:29:30 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 1051 invoked by uid 97); 6 Jan 2003 22:29:30 -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 1039 invoked by uid 98); 6 Jan 2003 22:29:29 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-ID: <20030106222810.38194.qmail@web12407.mail.yahoo.com> Date: Mon, 6 Jan 2003 14:28:10 -0800 (PST) From: Morgan Delagrange Reply-To: morgand@apache.org Subject: Re: cvs commit: jakarta-commons-sandbox/jelly project.xml To: Jakarta Commons Developers List In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N --- dion@multitask.com.au wrote: > Morgan Delagrange wrote on > 07/01/2003 09:03:08 AM: > > > It makes some sense, but I don't see that it's > > necessarily useful. In six weeks, will anyone > care > > about 1.0-beta-4-SNAPSHOT? If the release JARS > for > > beta 1, 2, and 3 are out there, it's pretty > obvious > > that we're working on the next version, whatever > that > > number might be. > > In six weeks, maybe not. But for now it helps > understand what build the > timestamped jars come from. Especially on ibiblio > where we need to prune > things sometime. > > > If the tags are dependent on SNAPSHOT, and we're > in > > heavy development with no compatibility on a > released > > version, I think it makes sense for the release > > version of Jelly to be SNAPSHOT as well. If I > want to > > test a tag against a new version of Jelly I can > just > > type: > > > > maven clean jar:install > > Use: > > maven clean jar:install-snapshot > > This does the copying for you. Aha, I don't think that target is documented: http://jakarta.apache.org/turbine/maven/reference/plugins/java/goals.html That's a big help. I'm not sure all those versioned snapshots pay off in the end, but it looks like I can safely ignore them for now. Thanks! > Since Maven depends on commons-jelly-SNAPSHOT.jar to > really test against a > recently built snapshot, you should copy the jar > into the $MAVEN_HOME/lib > directory too. Ugh, I didn't think of that. Danger, better classloader isolation required! - Morgan ===== Morgan Delagrange http://jakarta.apache.org/taglibs http://jakarta.apache.org/commons http://axion.tigris.org http://jakarta.apache.org/watchdog __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- To unsubscribe, e-mail: For additional commands, e-mail: