Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@jakarta.apache.org Received: (qmail 66363 invoked by uid 500); 6 Jun 2001 17:04:21 -0000 Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk Reply-To: ant-dev@jakarta.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 66298 invoked from network); 6 Jun 2001 17:04:15 -0000 Message-ID: <20010606170417.91647.qmail@web9303.mail.yahoo.com> Date: Wed, 6 Jun 2001 10:04:17 -0700 (PDT) From: Roger Vaughn Reply-To: rvaughn@pobox.com Subject: Re: Configure->Template->Build To: ant-dev@jakarta.apache.org In-Reply-To: <3.0.6.32.20010607012047.0099ce30@mail.alphalink.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N --- Peter Donald wrote: > At 07:48 AM 6/6/01 -0700, Roger Vaughn wrote: > >Ok, I'll accept that. It just seems that the disc. > >has turned to "is it right or not". Peter *seems* > to > >argue that is "wrong" or "bad" > > projectref as described by Jose *is* wrong ;) > projectref as originally > defined is right (and needed). I could again argue about the use of "wrong", but I'll leave it. I hear your central argument, that Jose's interpretation affects the core. I'm not sure I really agree, but I'm not in a position to know for sure, not having done the background work - and not being on the line for delivering it. Assuming it is as you say, I have to agree in principal - the change to the core should cause you to approach it more cautiously. I still don't say it's "wrong" - core changes in the past and I'm sure in the future have/will make Ant more usable. > theres plenty of examples - I agree 100% with need. > I was ... *educated* > ... about it's usefulness recently. It is how the > functionality is provided > that is the tickler. I have no problem with that. > in my eyes templates will be 90% for people like you > and not of real use to > novices or small/simple projects. Accepted. Unfortunately, novices are often given this task. :-) Not much we can do about that, though. And I can't *count* the number of companies/projects I have seen with NO formal build process. Because of that, I'm a bit torn. I'm half of a mind to claim that making a build tool more accessible to novices would be a good thing. Perhaps more projects would adopt a real build cycle then. But then I cynically think that most people wouldn't change their ways no matter what. And "simple build tool" might very well be an oxymoron. > >the Java. However, as Jose pointed out, there is a > >huge danger of Ant fragmenting into a different > local > >"dialect" for every project out there. > > I am not sure that is a bad thing ;) I tend to think it is, as it reduces the ability to reuse/share work between projects. This may be less of an issue than I think, as the same people who would share work will likely collaborate or take their templates with them anyway. > >I also think > >external templating (or configuration) carries a > much > >greater potential for abuse from careless > programmers > >(which Peter is concerned about) than do most > >potential new Ant features. > > could you clarify? Sure. As I mentioned previously, external templating gives you at least three languages to learn and work with - the "generator" language (which the template is expressed in), the template language (which the template expresses), and the Ant language itself. A build engineer will be involved in all three - ideally, a build writer will only need to know the template language. Necessarily, there is more to learn and understand - and use properly. There are more chances to make mistakes - and not just based on feature count, but on syntax count. Ant has one syntax. This little scenario has at least two (Ant and generator). Assuming you use XSLT as your generator language, you have a whole can of worms just in that one piece. It seems many people have a hard time learning how to use XSLT effectively, and some just refuse to touch it. It is a difficult language to master. Because of this, I would expect people to make more mistakes - and more severe ones - in it than they would in Ant itself, since Ant has been designed from the start to be easily accessible. > I don't think generators/guis should be fezzing with > template files. The > templates are written by experts who presumably know > what they are doing > and can work better in a XML editor (or text > editor). Oh, absolutely. Generators should never work with the template language. My point is just that by saying "you must use templates to achieve functionality X", we cut off a whole class of problems that require functionality X from the people who would use the GUI tools. Also, I can guarantee that if and when templates are supported, *some* generator *somewhere* will generate everything into its own proprietary template implementation. I *don't* think that is a good thing. But can or should we prevent it? Probably not. > possibly but that makes everyone pay for the power > regardless of whether or > not they use it. Personally I would like to have if > tasks for use in > templating. Providing this feature would inevitably > lead to misuse by users > who shouldn't be using it. So while it would be nice > for me to use, it > would cause pain to less experienced users, thus I > would never support it's > inclusion in core. I'm going to fall on the other side of this fence every single time. I have the same argument with many of the core Java language decisions. I cannot agree with a tool builder trying to protect people from themselves. To me, "someone will misuse it" is not a valid argument. *No matter what* you provide, someone will misuse it. I will always argue for providing functionality for those who can use it, and letting those who would create their own messes deal with them. Every tool, every language has a learning curve. If you haven't prepared adequately to use it, then you should not be using it - yet. That's not the fault of the tool. Now, this doesn't mean I espouse chaos. Yes, Ant should follow good design principles, and yes, Ant should allow for clean build implementations - without extraordinary effort on part of the build writers. There are a handful of tools (not necessarily build tools, and not Perl ;-)) that *force* you to follow flawed principles, and this, obviously, none of us want Ant to be. Ant should allow people to write elegant, correct scripts, plain and simple. IMHO, if this means a few people can (not must) abuse that functionality, so be it. And yes, I like Perl. Sure, you can write bad code in it, but it doesn't force you to. __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/