Hi, I don't know what his experience is but I can tell you that the following things are the things that I always get told about ant in large builds.
* lack of templating (with it all these conditional arguements go away) * multiple scanning - scanning over the filesystem is slow - especially when you do it multiple times - should do it once and cache it (Some people have suggested in a separate autoconf style system). * lack of support for adhoc environment discover processes - essentially autoconf combined with generic scripting support to "find stuff" And there is one more point that I seemed to have forgotten aswell ;) At 04:13 16/5/01 -0400, Jesse Tilly wrote: >Peter, > >I cannot draw from the years of experience you have had. While I am a part >time configuration manager, it is not my title nor my "day job" and I have >only been involved with these concepts for about 4 years. What your >experience could bring to Ant is valuable so I have a few questions, if you >don't mind: > >Given Ant's current state, how would you address conditional processing? > >If given the choice between continuing the use of XML or moving to another >description language, which would you choose for Ant? > >Given this scenario: > >Company/group starts work on a somewhat interdependent set of projects that >all culminate into a final web application. This application is >distributable (meaning it can be hosted from multiple sites globally) and >consists of Java (RMI, JNI, EJB, servlets, JSP), HTML/PHP/ASP, graphics, and >a database schema. > >What tool would you begin using to build, deploy and distribute this >application? Would Ant factor in at all? Why or why not? > >For everyone else, Peter obviously brings up the main point in any project: >what problem are we solving. I do not like to be considered closed or >elitist when discussing design and I'm my colleagues would not like to be >described this way, either. However, the gauntlet has been thrown. When >someone of Peter's experience level describes the tool as incapable of use >beyond small projects I, like everyone else, would like to know what >particular points are lacking. Defining the problem and "contract" (a term >Roger and Peter have both used quite accurately) is key to Ant2. Is it key >to Ant now? I don't know. > >To help you understand why I question these things, Peter, let me explain my >dilemma. The more Ant begins to aggregate ad-hoc solutions into its core, >the less manageable it becomes. I'm sure you're aware of this in projects >for which you've managed the configuration. However, another dynamic takes >place. The more "useable" it becomes, the less likely the perceived better >solution will be adopted. We witness this everyday in technology. Everyone >wants to use what works and what works now. > >I hoped (and was rewarded) that my statement would begin a discussion from >the primary developers of Ant and provide a forum for drawing out my main >concern: is Ant doomed? Hopefully, Peter, your answers to my question will >help me (and others who are interested) find out where Ant stands in the >real-world. Thanks for your time in advance. > >Jesse > >> -----Original Message----- >> From: Peter Vogel [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, May 16, 2001 1:49 PM >> To: '[EMAIL PROTECTED]' >> Subject: RE: if and unless attributes for all Tasks >> >> >> Heh! Well said Roger! The "we don't think its a good >> idea, so Ant won't include it" is one of the reasons I >> am hesitant to recommend Ant, despite the great leaps forward >> that have happened since I started following ant at 1.1. >> >> I've been architecting builds for over a decade now, using >> a variety of tools (Make, Cons, Perl wrapped around Make, ant, >> etc.) and there are some fundamental capabilities that are >> *necessary* to ensuring reproducible builds (which is the >> whole point of CM) which Ant simply lacks, environment >> encapsulation being one of them, a cleaner way of >> doing conditionals being another. >> >> I'm a big proponent for a framework that is *simple* when >> it can to be simple, and which makes complexity readable >> when complexity is needed. The whole concept of "write a >> task to do that" while cool for certain things, is fundamentally >> broken for fundamental things like conditionals, etc. >> Conditionals in build files are a fact of life in today's >> cross-platform software systems, and even in some that aren't >> cross platform, but which need to be configurable at >> build time. >> >> That said, Ant is still a pretty cool tool, and I use it when >> its appropriate, but I do get pretty annoyed by the "we're >> smarter than you" attitude from many of the ant development >> community that seems to consider anything that smacks of >> "complexity" as evil. Go design an ant-based build of a >> system consisting of 2M lines of code that produces 4 different >> products with 90% of the components being shared across those >> products and then tell me what features should or should not >> be in the product. >> >> -Peter >> -- >> Peter A. Vogel >> Manager+consultant, Configuration Management >> Arsin Corporation, Professional Services >> http://www.arsin.com >> >> >> >> > -----Original Message----- >> > From: Roger Vaughn [mailto:[EMAIL PROTECTED] >> > Sent: Wednesday, May 16, 2001 7:42 AM >> > To: [EMAIL PROTECTED] >> > Subject: RE: if and unless attributes for all Tasks >> > >> > >> > --- Jose Alberto Fernandez <[EMAIL PROTECTED]> >> > wrote: >> > > How understandable build files will be depend on our >> > > choices. If I write >> > > targets where every <task> has a different if/unless >> > > condition, what does >> > > that tell me about the readability of the build >> > > file. It looks like >> > > spaggetti code to me. I think the granularity is too >> > > low. By having >> > > if/unless at <target> level, you still can write >> > > spaggetti code, but it will >> > > make you think: "Do I really need to do it this >> > > way?" And that is what makes >> > > code understandable and maintainable, you have to >> > > stop and think. >> > >> > You can obsfucate anything if you try. For instance, >> > it is entirely possible to specify one task per >> > target, and link them all up with dependencies. We >> > don't do that because it's harder to understand. But >> > it's certainly a simpler, more declarative model than >> > multiple sequential tasks per target. >> > >> > I'm going to come out on the side of more features, >> > more power, and more flexibility every single time. >> > There is always some rube who is going to program >> > himself into a real mess, but I don't think that's >> > sufficient excuse to deny others of us flexible tools. >> > FWIW, I feel exactly the same way about Java vs. C++, >> > even though I do the majority of my work in Java these >> > days. >> > >> > BTW, I'm still hoping for mutable properties (or >> > perhaps a separate set of variables.) ;) Used >> > *judiciously*, they can, in certain situations, >> > simplify scripts quite a bit. Now, if someone goes >> > wild and creates what you describe above, well then, >> > that's his fault, not mine. This isn't a support >> > organization, so I don't think protecting users from >> > themselves should be the team's first concern. >> > >> > There's a certain arrogance here that's frequently >> > annoying. The refrain "we don't think you should do >> > that, so Ant won't include it" is heard pretty >> > frequently. I understand reluctance to implement >> > difficult or basis-shattering features (like >> > templates), but for simple things, I just don't get >> > it. Come on guys, be open to new ideas and different >> > ways of doing things. If anyone finds this insulting, >> > well, I'm sorry, but that's what I see. >> > >> > roger >> > >> > >> > __________________________________________________ >> > Do You Yahoo!? >> > Yahoo! Auctions - buy the things you want at great prices >> > http://auctions.yahoo.com/ >> > >> > > Cheers, Pete *-----------------------------------------------------* | "Faced with the choice between changing one's mind, | | and proving that there is no need to do so - almost | | everyone gets busy on the proof." | | - John Kenneth Galbraith | *-----------------------------------------------------*
