On Monday 19 July 2010 20:45:48 Matt Benson wrote: > On Jul 19, 2010, at 4:12 AM, Nicolas Lalevée wrote: > > On Friday 16 July 2010 18:07:57 Matt Benson wrote: > >> On Jul 16, 2010, at 8:25 AM, Nicolas Lalevée wrote: > >>> Hi, > >>> > >>> I did some other experiment with the groovy frontend to ant > >>> recently. And I > >>> would like to be able to make a groovy build file import an xml > >>> build file > >>> and vice versa. > >>> > >>> As far as I can tell, in order to do this, a simple change would be > >>> needed in > >>> ImportTask. Rather than doing this in importResource: > >>> > >>> helper.parse(getProject(), importedResource); > >>> > >>> we would do something like: > >>> > >>> ProjectHelper subHelper = > >>> ProjectHelperRepository.getInstance().getProjectHelperForBuildFile( > >>> importedResource); > >>> > >>> // push current stacks into the sub helper > >>> subHelper.getImportStack().addAll(helper.getImportStack()); > >>> subHelper.getExtensionStack().addAll(helper.getExtensionStack()); > >>> getProject().addReference(ProjectHelper.PROJECTHELPER_REFERENCE, > >>> subHelper); > >>> > >>> subHelper.parse(getProject(), importedResource); > >>> > >>> // push back the stacks from the sub helper to the main one > >>> getProject().addReference(ProjectHelper.PROJECTHELPER_REFERENCE, > >>> helper); > >>> helper.getImportStack().clear(); > >>> helper.getImportStack().addAll(subHelper.getImportStack()); > >>> helper.getExtensionStack().clear(); > >>> helper.getExtensionStack().addAll(subHelper.getExtensionStack()); > >>> > >>> > >>> For the little tests I have done with the groovy frontend, it seems > >>> to work > >>> quite well. > >>> > >>> Actually it seems so simple that I am wondering if I might have > >>> missed some > >>> side effect. Did I ? > >> > >> I suppose it's possible you missed something, but it seems okay. If > >> it were me, I might work out a way to make the subHelper send its > >> imports/extensions directly back to the top-level ProjectHelper > >> rather than so much clearing and replacing, but I'll admit to being > >> somewhat paranoid. > > > > I think I got paranoid too but the other way: I didn't want to > > change the API > > of ProjectHelper that might be implemented around the world and bring > > backward compatibility issues. > > I didn't actually pick up on where there was an actual API change? > Being backward-compatibility-obsessed as a project, we should expand > rather than change our APIs...
If you add a function to an extendable class, like a public setImportStack(Vector), it is possible to break an extending class which already defines a setImportStack(Vector) as private. This is really unlikely to happen. But who knows. Furthermore considering the story about the zip task fixed by a thread local faced by Stefan. I always considered that kind of change safe. Now it seems to me that classes are not that much change safe than interfaces. I think it is OK to "extend" the API to add features, like we did with the support of extension point. But as we can avoid it here, I prefer to do so. Nicolas > > -Matt > > > Thanks for the review, I will commit that probably with some > > additionnal unit > > tests. > > > > Nicolas > > > >> -Matt > >> > >>> At least the unit tests showed me that I did nothing that wrong. > >>> > >>> Nicolas > >>> > >>> -------------------------------------------------------------------- > >>> - > >>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > >>> For additional commands, e-mail: dev-h...@ant.apache.org > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > >> For additional commands, e-mail: dev-h...@ant.apache.org > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > > For additional commands, e-mail: dev-h...@ant.apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
