Re: build system - status of filtering

[Nicola Ken Barozzi]

Stefano Mazzocchi wrote, On 12/03/2003 11.51:
Nicola Ken Barozzi wrote:

Stefano Mazzocchi wrote, On 11/03/2003 19.53:

Christian Haul wrote:

...

Strangely enough, a quick look at blocks-build.xsl seems to indicate
that files in the conf directory are filtered. Hints anybody?


Yes. the <filter> indications are now located in a build.xml file 
located inside the block. Unfortunately, it seems that ant is not 
able to retain the scope of those tasks when setup in a nested 
antcall target, even if intra-vm.


<antcall> actually works like <ant>, and is completely reentrant.
...


Right now I do the following:

build.xml:

  <ant inheritAll="true" inheritRefs="false" target="main" 
antfile="blocks/database/build.xml"/>
  <copy filtering="on">
   ...
  </copy>

and  blocks/database/build.xml contains:

  <target name="main">
   <filter token="db_url" value="${webapp.samples.database.url}"/>
  </target>
but the filtering doesn't work. 
Correct.

I suspected this was because ant scopes 
the filter instantiations and removes them when exiting a subcall. Am I 
wrong?
<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.

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.

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.

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.

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

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.

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.

--
Nicola Ken Barozzi                   [EMAIL PROTECTED]
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------