----- Original Message ----- From: "Conor MacNeill" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, January 16, 2001 02:37 Subject: Re: ant 1.3 ? ant 2.0? timeline
> I have a multithreading implementation just waiting to go in. I > would like to rework the System.out stuff for that, so I'm interested in > what Steve Loughran is thinking there. I'm not having many profound thoughts. I put a few hours in over the weekend on a task intended to import SDL/WSDL and generate java, C#, whatever, using a factory of registered handlers, with a callout to the C# proxy generation app the only implementation I have to hand. With that much overengineering going on already, reworking how things got logged would have been excessive :-) As far as my thinking goes -some kind of interface for logging that can be passed to helper classes without them needing to know the whole structure of ant is nice, it should even provide some isolation of tasks for 2.0 changes. Indeed, it would even be a start to being able to invoke tasks from things other than the Ant framework (such as at install time) The interface should wrap the log() methods, and have a method -PrintStream getPrintStream() so that anyone who wants the print stream should get it -but it doesnt have to be System.out any more. (even though it will usually be so) The rest of the interface can look like Thomas Christen's design, which specified an interface for logging and showed where it could go in Task. I'd have Project implement the interface too, and in fact it could provide the default implementation (which hands events off to the registered logger). We'd need to change LogOutputStream and LogStreamHandler so that they would take a Logger interface as a parameter, rather than a Task. With Task implementing Logger old code would still work (with a recompile). Alternatively we could cut and paste to a new LoggerOutputStream class which the -now signature unchanged- LogStream classes could hand off to. That would be a more risk averse form of change, which adds to the code base but breaks less stuff. To date I am still passing Task references around, even two deep into execution classes. That works, but it is kind of inelegant. It reminds me too much of how in MFC even things like toolbars have code in them that assumes the existence of a current document and other 'truths' that are occasionally wont to change, and when they do everything just stops working. -Steve
