Making it a separate AntLib makes a lot of sense to me too. So yeah, (3) is the way to go, OTOH I'm not convinced it should be a fully separate project within or outside the ASF.
I can foresee the not too distant future when these Ant sub-projects will start having dependencies between each other, so compiling them would either require (Maven + ibiblio (or an ASK equivalent)) or have the sub-project check in the JARs they depend on (Uhhh!). What I had in mind was more an antlibs/ sub-dir in Ant, which the Ant build file could easily recurse into to build once it's own build is complete. I already have the extension to subant to dynamically infer the build order to use to call the sub-projects in a flexible way (all you need is some XML file stating the sub-project's dependencies). This model also allows to gradually move existing optional tasks out of the main Ant src/ tree into their own AntLib (once we've switched to SVN and can *move* files around the repo ;-) --DD > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Friday, September 17, 2004 7:07 AM > To: [EMAIL PROTECTED] > Subject: AW: Where should the dotnet sandbox go? > > On the same reasons I would say (3). Especially we had spoken about > breaking Ant into modules and moving to SVN ... (last year at your home, > Stefan :) > I think a new subproject would be the right place because Ant targets a > development > with Java while these new tasks targets a development for .NET. > Same as on Log4J/Log4C/... all under the logging-project, but individual > subprojects. > ... and ... why do we have a top level project ;-) > > Itīs ever the same if a committer has an idea about an addition to Ant. > So the only way is to ask the rest of committers. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
