> > 1) I prefer <taskpath> to <loadtasks> because the name hides the > > implementation (I shouldn't care when the task gets loaded). > but you do want those tasks loaded at that point - it would > be useful to > have it log which tasks its found for debugging purposes.
OK. I get it. Loadtasks is a better name. > > > 2) I see Tomas echoes my concern in spades. "so what" if it's > > Ant-like and klunky. It's just another tool. It doesn't > preclude the > > <taskpath> and the config file approaches. It just adds > flexibility > > at the core. > I think Tomas and I agreed that taskpath/loadtasks is the same as > taskdef - but using the nant model - unless I misread his post. What > does taskdef give you that the taskpath proposal doesn't I think tomas was saying there's no gain in losing taskdef, only loss, like my point. > > > 3) I (think I) understand you config file description, Ian. > It still > > doesn't address the issue of having myTasks.dll versions > per project. > but the taskpath proposal does Really? A single, centralized config file would handle all my projects' quirky requirements. I didn't get that from your schema. I still think it's easier in some case to handle it on a project by project basis and taskdef does that for me. /jean ------------------------------------------------------- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ _______________________________________________ Nant-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-users
