ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wannheden, Knut" <>
Subject RE: Project.toXML() ?
Date Mon, 18 Nov 2002 11:43:16 GMT

From: Yyy Xxx []
> Costin Manolache <> wrote:
> > Dominique Devienne wrote:
> >> I'm amazed how a DOM-based ProjectHelper always gets dismissed
> >> when it's clearly the ideal solution to provide serialization back
> >> to XML from the original XML (among other things):
> >Ant1.5 supports pluggable ProjectHelpers, and nothing stops you from 
> >creating a DOM-based one.
> Are there any articles, tutorials or examples on writing custom
> ProjectHelpers?  I've looked through the code and, with all due
> respect, the ProjectHelpers look like an afterthought hack.

No, I don't think there are any other documents than the code (the two
classes you've looked at).  You can always search the archives and you could
also look at the SAX2 based ProjectHelper in the embed proposal (browse the
Ant CVS).

I have created a ProjectHelper aswell, but it only subclasses the default
ProjectHelperImpl and overrides parse(Project, Object) where it essentially
creates the buildfile from a template before calling super.parse(Project,

> I'd like to read build.xml from an InputStream (originating 
> in a JAR). 
> Ant seems to be very file based wrt configuring projects.  Static
> methods of the ProjectHelper takes an explicit File object and have a
> comment about custom ProjectHelperImpls needing to propogate this for
> backwards compatability.  I don't understand this comment in the
> context of custom helpers.

I have asked the same question a couple of times before (take a look at and  And,
indeed, it seems like at least some committers feel like the File parameter
should be replaced with an Object parameter, but it still needs to be
changed.  I suggest you open a feature request if it's really important to

> The interface which customer helpers should implement is not 
> clear cut.
>  Both ProjectHelper and ProjectHelperImpl contain static methods and
> ProjectHelperImpl extends ProjectHelper (instead of implementing it). 
> ProjectHelperImpl seems to do double-duty as a file reader and an XML
> SAX handler.  It's not clear how to redirect the input source in a
> custom helper subclass while reusing the parsing capability of
> ProjectHelperImpl.

Yes, I think that's somewhat dubious, too.  What I did was to subclass the
ProjectHelperImpl.  But that might not work in your case...  You could
always open a feature request and propose a implementation with clearer
separation of concerns. ;-)



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message