ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <nicolas.lale...@hibnet.org>
Subject Re: Import and project helpers
Date Tue, 20 Jul 2010 07:36:16 GMT
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-unsubscribe@ant.apache.org
> >>> For additional commands, e-mail: dev-help@ant.apache.org
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> >> For additional commands, e-mail: dev-help@ant.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> > For additional commands, e-mail: dev-help@ant.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message