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. I suspected this was because ant scopes the filter instantiations and removes them when exiting a subcall. Am I wrong?
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.
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.
Why do we always have to have needs that are 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?
anyway, thanks much for this info, it's really helpful.
