At 11:58 20/3/01 -0800, David Rees wrote: >Actually, what I would like to suggest is that we reify the idea of a >"task context". I am still writing some notes on it, but the basic >idea is that you can define various aspects about how to call a task >or what to do if a task fails. You could then install a context at the >build file level, target level or task level.
+1 >You could reuse them as well using id/refid. no idea what this means ? ;) >I also like it because it better defines the contract between task and >environment for the task developer. It also seems as semi-natural >place for me to introduce my idea of a auto-Set (from a week or so >back) where the context can automatically call a task multiple times >for a set of parameters. It also allows a further level of >customization for the aggressive developer/user without changing the >"core". Yep it was what I was murmuring about a bit before. We have a number of aspects for each task; * logging * failure behaviour * classloader There are some "families" of tasks that may have other aspects * possibly input file aspect * possibly outout file aspect * possibly input package aspect * possibly input data aspect (ie data/properties set in context) * possibly outout data aspect The 2nd category whil eeasier for extremely convoluted tasks may not add anything to average case - so I am not sure that it is applicable. Interesting idea though. Cheers, Pete *-----------------------------------------------------* | "Faced with the choice between changing one's mind, | | and proving that there is no need to do so - almost | | everyone gets busy on the proof." | | - John Kenneth Galbraith | *-----------------------------------------------------*
