Alexey Solofnenko wrote:
I have added a pseudo task <use> that looks like:
<use file="../commons.xml" basedir=".." prefix="ics"/> <use generator="jython:genant.generate" file="JBuilder_project.jpx" some-generator-parameter="XXX"/> <!-- can generate other <use> tasks -->
Now all targets and properties in commons.xml can be referenced by using
"ics." prefix.
This is something I've wanted to add to import for some time now, so that all properties and tasks created there are prefixed and thus collisions don't happen. This is a nice feature IMHO to have, and an important one.
The prefix can be empty, but in that case the include is treated as "local", so it cannot be included anywhere else.
Like the <import/> now, right?
The targets can be overwritten (very useful with build generators). There is
an example:
<target name="new:precompile"
depends="old:precompile,other-project.do-something">
<xslt in="${error-file}" out="${error-output}"
style="${ics.error-xsl}"/>
</target>
This happens with <import/> now too. The old: target is called
importedbuildname.target
<snipped-preprocessor-tasks/>
My impression is that your system basically works in a very similar manner to <import/>, but has two features that <import/> lacks:
- property renaming - property rebasing
Since you have already done this, please pardon my ignorance on the implications these have. I tried to understand your comments on this but your knowledge on the difficulty of these two tasks is so greater than mine that it's not easy for me to fully understand.
From my read of your comments, it seems that there are some issues with these tasks, that have since prevented me from trying it in the first place:
- property renaming:
- properties that are loaded from external files are not prefixed * This can be fixed by setting a value in the base
propertyHelper that prefixes all preperties set.
This would be controlled by the Import task. - each build file is given a prefix, and the same build file can
be included with different prefixes from different files * This would just need a change in the circular reference
resolution to not skip same imports with different prefixes. - property rebasing:
- for a property in place of path list another property is
created with all elements are rebased, because the original
property can be used as a string somewhere else * How do you know if a property has to be rebased?
I would not even try to rebase simple string properties. - for a normal property in place of location, another rebased
property is created for the same reason* But this ties us to "magic name" attributes...
- a property being rebased that starts with another property,
that property is rebased as well * If a property uses a rebased property, it doesn't need itself
rebasing, no?For rebasing, I'm not that sure it's worth the effort, though it seems interestig. My current take with it is that I always use the ${ant.file.buildfile} property to "base" the properties correctly. Also, I want to retain the possibility of accessing the "originating" basedir, so that has also to be taken into account.
Given the above, ATM I'm tending to think that the easiest effective course of action is to:
* add the prefixing possibility to imported stuff
* make ${currentprojectname. basedir} be resolved relative to the
basedir of the current projectcurrent
* mark projects that are designed to be imported as importable="true"--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
