Another thing I don't understand about the current Ant. Why there are derivatives from ant and they are gaining popularity ? I am talking about gradle and easyant.
Gradle adds mutli project support, and easyant sets some conventions (I didn't use it). I am wondering what makes the author go with a new build system, if things like this can be done with antlib. And why would users switch to these systems. I like writing my custom tasks and wrap them in an antlib. But why others are not doing the same to add multi project support, or set some conventions ? Is there something wrong with antlib ? Would OSGI be more convenient and appealing for programmers to create and contribute their plugins rather than writing their own build system ? Derivatives of eclipse exists, but mainly they are just bundles of different plugins. Is this because it's OSGI ? This is really another reason that makes me think about forking ant beside introducing NIO2. I agree with Jesse, there's inconsistency dealing with different Resource. With regard to backward compatibility, It is good idea to keep it as "Nice to have", and try to maintain it as much as possible. The one thing I am confident it's critical, is the simplicity. For example, I came back to ant because I wanted to write a task that will be triggered when a file changes. I was not able to do this with gradle: http://forums.gradle.org/gradle/topics/runnig_task_programmatically probably it's a bit early to start thinking about a rewrite. But just to check available ideas. On Tue, Feb 14, 2012 at 2:35 PM, Bruce Atherton <br...@callenish.com> wrote: > > > On 2/13/2012 2:55 PM, Jesse Glick wrote: > >> On 02/13/2012 01:25 PM, Bruce Atherton wrote: >> >>> could Java 7 and NIO 2.0 be a good reason to create Ant 2.0? >>> >> >> While the new java.nio.file.* APIs are indeed valuable for a tool like >> Ant, I hardly think a fork or major rewrite is required to take advantage >> of them. As Stefan pointed out, it would be as easy as creating a new >> FileUtils subclass, and for now compiling it conditionally. >> > > Required, no. If there is not enough interest in creating an Ant 2 then > everything will be fine staying with Ant 1.x. We've been doing it through > massive changes in the Java libraries and we can keep doing it the same > way. If there aren't enough people interested in doing the work then we > should just drop it. > > But I've talked about a few of the advantages I see in dropping backward > API compatibility and doing a major refactoring. Let me list a few more. > > My biggest problem with Ant is the many ways that files are dealt with. It > is all over the map. This isn't anyone's fault, it happened because of > hysterical porpoises, but both our users and ourselves have to deal with > the fallout. > > Users have to deal with understanding the differences between paths and > filelists and filesets and dirsets and resources. They have to come to > grips with how <include> and <exclude> don't work like selectors. Filters > aren't much better since there are different ways that they can work. > > We have it a bit easier because under the covers most things have been > normalized. Resources, for example. But thanks to API compatibility that > brings its own problems. For example, we have two completely separate yet > very similar set of classes for Selectors, one for FileSelectors and one > for ResourceSelectors. Fix a bug in one, did you remember to fix it in the > other? Does it matter if users of the FileSelector APIs still have the bug? > > Or look at the utility classes. How many methods, or lines of extra code > in methods that should be relatively simple, are devoted to dealing with > edge cases and these hangers on from our past? > > All of these things were an itch bad enough that I started to scratch it, > but for now I won't be doing any coding at all for a while. Maybe, though, > there are others who are as bothered by these things as I am who are > looking for a scratching post. > > > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > >
