Return-Path: Delivered-To: apmail-jakarta-ant-user-archive@apache.org Received: (qmail 5909 invoked from network); 1 Jul 2002 21:00:41 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by 209.66.108.5 with SMTP; 1 Jul 2002 21:00:41 -0000 Received: (qmail 9867 invoked by uid 97); 1 Jul 2002 21:00:48 -0000 Delivered-To: qmlist-jakarta-archive-ant-user@jakarta.apache.org Received: (qmail 9836 invoked by uid 97); 1 Jul 2002 21:00:47 -0000 Mailing-List: contact ant-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Users List" Reply-To: "Ant Users List" Delivered-To: mailing list ant-user@jakarta.apache.org Received: (qmail 9775 invoked by uid 98); 1 Jul 2002 21:00:47 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Message-ID: <20020701210036.76682.qmail@web13405.mail.yahoo.com> Date: Mon, 1 Jul 2002 14:00:36 -0700 (PDT) From: Diane Holt Subject: RE: testing for update on filter file To: Ant Users List In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Rating: 209.66.108.5 1.6.2 0/1000/N X-Spam-Rating: 209.66.108.5 1.6.2 0/1000/N --- Dominique Devienne wrote: > A lot of the other examples you cite could be handled by keeping state > in between invocations, I save state in (generated) properties files, then do checks on their current value vs. their previous value. In the old days, when I had a modified , I did it with, eg: Nowadays, in order to avoid having to have a modified Ant, I'd do it using /, then test on the prop that set/didn't set -- but I still prefer the earlier way. > I take your point that it can't easily be added everywhere, but that > doesn't mean it should be precluded. Except that then you get into having yet more to learn and remember about which tasks do what for you, and which don't. And not just for the person who writes the Ant files, but for the people who just run them as well -- and that's where I think it could lend itself to being confusing (and potentially risky [ie., bogus build results]), unless the behaviour was consistent across tasks, and for all (or at least most) contingencies. > And finally, to come back on my gripe, if we do have to rely on other > tasks to do this kind of explicit file dependencies, then why do we > always have to fragment our builds into these small targets with > complex dependencies setting properties instead of clean conditional > execution!?!?!? I was told it's to avoid scripty builds, and that > smarts should be built-in to the task, and you just shot me back that > justification in the face. That's because I'm one of the people who agrees with you :) I'm not against "scriptiness" at all. In fact, I think not allowing for it actually makes Ant more difficult to use. When I put together a build process, I want it to be as straightforward as possible for the people who have to use it directly -- ie., developers who run it over and over all day. Ideally, all they should ever need to do is run 'tool-name'. That's not always going to be possible, since there'll likely always be some additional things they need to learn about and make sure they do to get the results they're after -- but the fewer of those things, the better. To achieve that could (and more often than not usually does) mean having a fair amount of complexity "under the covers" -- but that's okay, since the end result is that then the users of the process don't have to deal with those things. Of course, if you can make it so it's simple from both sides, all the better -- but I'm not sure adding certain "convenience" functionality to some tasks and not others would necessarily be moving in that direction. As it is now, there's not as much consistency between tasks (even just for things like names for attributes that mean the same thing) as there should be, so introducing inconsistent behaviour between similar tasks (eg., and ) seems like it'd only lead to additional confusion. Diane ===== (holtdl@yahoo.com) __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- To unsubscribe, e-mail: For additional commands, e-mail: