ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: Improt task and project basedir
Date Sat, 11 Jan 2003 12:20:23 GMT


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                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message