> From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED] > > > Take the following > > > > <blah> > > <a/> > > <b/> > > </blah> > > > > Now lets assume it has two adds. The first run we we look up > Role1 for "a" > > and it is found and so we add the reult instance to adder 1. We > look up "b" > > in Role1 but it is not found, we do find it in ROle2 and thus > we add the > > instance to adder 2. > > > > Now some outsider comes along and registers a new type of Role1 > named "b" > > (which is easy to do by just dropping librarys in right place). > Now when user > > reruns tasks both "a" and "b" will be added to adder1. > > > > Well, this is one reason I do not like auto-installation of > libraries. One should declare > the libraries that one want to have available to the build. As > with java extensions > when you allow auto-installation, the result is unpredictable behaviour. > > As for clashes, there are several things that need to be done: > > 1) Buildfiles should execute on a stable environment i.e., no auto-install > but all libraries (appart from core) should be declared on the buildfile. >
This doesn't really solve the problem, just makes it less likely to happen. Which just makes having to declare stuff an inconvenience. The real solution is 2) and 3) below. Perhaps a good compromise would be no auto-install and an <import-all/> task. > 2) The container should detect clashes by looking at all possible > role registries > that may apply. This can be done quite efficiently. > Definitely a good thing - the container should bail on a clash. > 3) A clash resolution mechanism should be provided, posibly using > aspects to > indicate the expected role to be used in a particular occurrance. Its really up to the user (build file writer) to sort out the ambiguity. There's not much Ant (configurer, aspect, or otherwise) can do except try to guess. Better to provide a simple way for the user to specify exactly what type they intend to be used. That is, the user needs be able to specify for an element, both a role name, and a type name. Perhaps by using a qualified name "role.type", or perhaps using a role attribute. Providing a role name would be optional, provided the type name is unambiguous. Adam -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
