cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: build system - status of filtering
Date Wed, 12 Mar 2003 16:27:00 GMT
Nicola Ken Barozzi wrote:

> <ant> calls another Ant on that build. When it's finished, it closes it.
> In pseudo-code:
>  Vector filters;
>  new Ant(true, false, main, "blocks/database/build.xml");
>  copy( "on", ...);
> And in Ant(...)
>  Ant(...){
>    filters = new Vector();
>    filters.add(new Filter(...));
>  }
> As you see, <ant> creates another Ant object. Everything that happens 
> there does not influence the caller.

Yes, that's what I figured.

> If you want to do it, make the sub-build write the infos in a fiule, and 
> have the original build pock them up. Not pretty, but since Ant has not 
> decided to have "returns" from subbuilds, it's the only way to do 
> exactly what you want, the way you want.

I don't see how this can possibly work for filters. but anyway.

>>>> the ideal solution would be to give its block the ability to define 
>>>> its own build customizations, but ant doesn't have this 
>>>> 'inheritance' concept :/
>>> It does (at least in the version Cocoon is using IIRC), it's called 
>>> <import>
>> Uh, awesome, didn't know that.
> It was inserted in Ant after being made for and used in Centipede.

Ah, ok.

>>> Make a base-block-build.xml file, with the basic block build stuff, 
>>> and in every block build do a import of that file.
>> Really? Supercool!!! that would allow us to trash the XSLT generation 
>> of the uber-block-build. Is there documentation for the behavior of 
>> that task? Is it on 1.6-dev only? grrr, again dependent on unreleased 
>> stuff.
> 1.6 only. Yes, there is documentation in Ant CVS, and it has been 
> building with Gump for quite some time now.

ok, I'll check that.

>> Why do we always have to have needs that are on the bleeding edge!! :(
> Because we do things on the bleeding edge.

yeah, well, to bad we are on the bleeding edge on every possible aspect. 
well, at least nobody can say open source copies instead of innovate :)

>>> You can also redefine targets, and call the original targets by 
>>> prepending "projectname." to the target (where projectname is the 
>>> actual project name of the base build).
>> Don't get it. Can you elaborate more?
> If I define the target "mytarget" in importedbuild.xml, and import that 
> in build.xml, I can of course call mytarget from build.xml.
> Then I want to add things to it, so I can redefine it. If I simply 
> create a target named "mytarget" in build.xml, that one takes 
> precedence. Exactly like when I redefine a method in a class that 
> extends another one.
> Now, let's say that importedbuild.xml had a project name="importedbuild".
> I can call the original mytarget in the redefined one as 
> "importedbuild.mytarget"
> in build.xml
> <target name="mytarget" depends="beforetarget,
>                                  importedbuild.mytarget,
>                                  aftertarget"/>
> So I can easily "decorate" the original target I imported.

Ah, it's like calling super() in constructors?

>> anyway, thanks much for this info, it's really helpful.
> I hope so. It's all part of the things that came from Centipede to make 
> Ant better. We now have proposed Centipede to Ant, and I have high hopes 
> that we can get a nice act together.

Good luck :)


View raw message