well the thing about backward compatibility... as File is a subclass of Object, I guess that the parameter could be changed and a explicit downcast (where needed) would do. But if performance is a concern a new method would probably be better.
But otherwise sounds good! This will make a cleaner interface for people writing custom frontends as they can supply their own ProjectHelper and practically call it with any input. Just the ProjectHelper knows how to deal with it ;-) Cheers, -- knut > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Freitag, 26. Juli 2002 19:01 > To: Ant Developers List > Subject: RE: Embed Sandbox Proposal: HOWTO? > > > On Fri, 26 Jul 2002, Wannheden, Knut wrote: > > > >From your description it is not quite clear to me if your > new ProjectHelper > > is intended as a plugin for the oat.ant.ProjectHelper or as > a additional > > implementation of a ProjectHelper like > oat.ant.helper.ProjectHelperImpl. Or > > have you maybe even done both? > > It is a pluging for oat.ant.ProjectHelper, replacing the default > ProjectHelperImpl. > > ProjectHelper is the 'interface' ( well, base class ), > ProjectHelperImpl > is one implementation ( the default one ), PHI2 is an alternative one > ( and I hope default for next release ). > > > > If you're working on the oat.ant.ProjectHelper I have a > small change to > > propose: The parse(Project, Object) method allows a > ProjectHelper plugin to > > set up a Project from an arbitrary input, not just a File. > But the method > > is actually called from > oat.ant.ProjectHelper.configureProject(Project, > > File), which is the actual entry point. And this makes it > impossible to > > read from anything other than File. So if the File argument of > > configureProject() were changed into a Object argument, the > problem would be > > solved. > > I don't think we can change the File argument ( backward > compat :-), but > we can add a second configureProject with Object param ( that would be > backward compatible, and since it's abstract class not > inteface we could > still compile for both ). > > Seem like a good idea. > > I'm not sure what's the right procedure - since it's an API change to > a core ant class it may be a good idea to make a formal proposal. > But it's a pretty small change - so I can check it in and > wait for -1s. > > Costin > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
