I don't consider this overly negative, but I am curious what the build patterns are.
Anyway, I really don't care one way or another, I just think that at this point, without more user feedback, and comments, I don't see one way as more standard than the other. It is like saying that potato chips are better than ham. (If you've been following the Jakarta commons/general lists, I would point out this is like a "bike shed" problem.) Once we have a config file, this all becomes moot. > -----Original Message----- > From: Ian MacLean [mailto:[EMAIL PROTECTED]] > Sent: Friday, May 03, 2002 11:13 AM > To: Scott Hernandez > Cc: [EMAIL PROTECTED] > Subject: Re: [nant-dev] Task Assembly Loading [snip] > I'm still not convinced that its a good idea to put those Tasks in the > build directory. If someone really needs to do it they can add the path > to the config file. I'm not sure that its a common enough usage pattern > to warrant making it the default. Is it likely that people will > implement tasks for a single project only ? The other issue is that if > you have a very big tree with lots of build files calling each other it > could become difficult to determine which tasks are loaded at any given > time. ie BuildFileA calls buildFileB which loads some tasks out of its > basedir and then calls BuildFileC which uses those tasks. However a > different path thru the dependency hierarchy could mean that > buildFileB doesn't get called and those tasks never get loaded causing > BuildFileC to fail. A contrived example I know. What I'm getting at is > that the set of available tasks should really be determined when nant > loads rather than changing as various other build files are called. It > just seems to be adding complexity without gaining much that you can't > do in other ways. > > I apologise if this seems overly negative. I'm just wary of adding > uneeded complexity _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] _______________________________________________ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
