From: "Erik Hatcher" <[EMAIL PROTECTED]> Erik, I think you are right on the money. I firmly believe ANT must provide a container that is extensible and that can allow ANT to grow in directions not forseen today. There have been lots of interest on using ANT beyond Java project building. And there is an enourmous potential right there.
This is why I want the container core to be as agnostic about the tasks in use as possible. Ideally, the container should treat the ANT core tasks (including <property>, <taskdef>, <antlib>) no different than any other tasks. They will be loaded from an ANT library just as anything else. The same container, used for a different purpose, can be started by loading a different initial library, for example (or a reduced library, limiting what the buildproject can do). The container, in this regard, just provides a set of services available to everyone on the same footing. A task that defines things can use a registration service to register and manage visibility rules in a consistent manner. So, the same registration infrastructure available to register a task, is available to register a "script", probably in a different namespace but following the same accessability rules. The same applies to execution environments: the namespace for properties and datatypes. Any task that access it or declares things on it will follow the same clear set of rules, including visibility, accessability, being precluded by an existing definition, etc. Jose Alberto > > ----- Original Message ----- > From: "Peter Donald" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Saturday, October 20, 2001 8:47 PM > Subject: Re: [Ant2] scoping of properties > > > > Thats an interesting question. Should the container or the task implement > > policy? Container implementing it is useful because that means it has > > complete control over it and tasks always behave consistently. The > > disadvantage being that you may sometimes want inconsistencies. > > Definitely an interesting topic. These are the same concepts that generated > the J2EE container specifications. The container provides several implicit > services which implement policy that previously required hand-coding and > careful attention to detail (@see: distributed transaction processing, role > based security, JNDI, JMS, and so on, and now being overlayed by things like > SOAP). > > Certainly EJB, JMS, JNDI, etc are not needed in many applications, but when > they are it sure is nice to have them simply handed to you on a silver > platter with no questions asked. > > How does a J2EE container address inconsistencies in people desiring to go > "outside the box" and do things their own way? It doesn't stop them, it > just makes it more difficult by things going against the grain not being > considered "best practices". JSP allows folks to write scriptlets all over > the place and blur together what should be layered as model, view, and > controller. Nothing should stop folks from doing silly stuff, but when > silly stuff is done with powerful tools it becomes readily apparent that > something silly is being done. Sun spends a lot of effort to communicate > best practices in its Java technologies. Why don't they just "force" users > to do things that way instead? (I argue that flexibility is left there for > future possibly unforeseen extensibility - why close doors and shut off > options when its not necessary, just advise against out-dated methodologies) > > I'm not sure if I provided any useful view to this thread, but hopefully > there is some synergy between Ant's target/task "container" and other > "container" concepts in the Java world. > > Erik > >
