On Mon, 11 Sep 2006, Matt Benson <[EMAIL PROTECTED]> wrote: > Looks like this chain got out of hand and killed the discussion.
Might be related to the Subject line ;-) > But we need consensus here on what to do before 1.7 final ships. Yes. We don't need consensus on how to deal with newConditionOfTheWeek before the release, but on the use of DynamicElement in ConditionBase. I don't have any problem with ConditionBase (or AssertTask) not extending Task, BTW. > Background: My assertion is that we should no longer allow the > proliferation of addNewConditionOfTheWeek() methods on > ConditionBase; my (unorthodox as usual) solution was to allow > business as usual in ConditionBase first: check for explicitly named > addFoo() methods, then check for def'd conditions with > add(Condition). I'd hope that this was enough. > The modification is to then implement DynamicElement in > ConditionBase so that when the first two introspection methods fail; > ConditionBase's DynamicElement implementation searches for a > matching condition by prepending the > antlib:org.apache.tools.ant.taskdefs.condition ns to the element > name and searching the Project's ComponentHelper for the > corresponding definition. Cool, but maybe too complex for this problem. > Peter's suggestion to define as many conditions as we > can competes with an earlier imperative to add new > conditions only to the new condition antlib mentioned > above. Can't we have them both? Add them to the new antlib and define them inside of defaults.properties? Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
