ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 48754] Features to make it easy to create hierarchical / maintainable builds
Date Fri, 26 Feb 2010 18:16:25 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=48754

--- Comment #2 from Jon Cox <jcox-dated-1266352898.9c8d3f@experiments.com> 2010-02-26
18:16:19 UTC ---
(In reply to comment #1)
> What you describe sounds a lot like <include> of Ant 1.8.0, please take a look
> at it, it might be all you need.
> 
> WRT #ant - I didn't even know it existed.  It's likely that there are not too
> many IRC users around Ant.


The new <include> tag looks promising -- I'll check it out.

Here are some other things I did that would be nice to have in "standard ant":

I created some magical properties that are static with respect to 
the context in which they're evaluated (but implemented dynamically).
The net effect is that I've faked a static "scoped" definition for 
the following magical properties.  

Props related to targets/projects/tasks:
  *  ${this.target}              the current target name (e.g.: 'javac')
  *  ${this.target.description}  target description text (possibly undefined) 
  *  ${this.project}             the current project name (e.g.: 'myproj')
  *  ${this.task}                the current task name (e.g.: 'javac-project')

Props related to current build file dir:
  *  ${this.dir}           full dir parent pathname containing this build file
  *  ${this.dir.name}      leaf name of parent dir containing this build file

Props related to current build file name:
  *  ${this.file}          full pathname of this build file
  *  ${this.file.name}     leaf name of this build file (typically,
"build.xml")
  *  ${this.file.basename} basename of this build file (typically, "build").


This ends up being enormously useful because it means you can
cut/paste snippets of ant without modification.  Critically, 
because the interpolation of ${this.target}  and ${this.project}
is done immediately prior to the topological sort of targets,
all dependencies remain entirely *static*  the other this.XXX
variables are updated via a BuildListener  

Consider the following snippet from a sub-project in my build.
I can have the exact same blob of XML in project "moo" and "cow":

    <target name="javac-test"
            depends="javac"
            description="Compile Java 'test' classes in this subproject">
        <javac-project
            name="${this.project}" 
            src="test"/>
    </target>


Now my <javac-project> macro is fed  name="moo"  
when the blob of XML above is in the moo project,
and name="cow" when it's in the cow project!

Therefore, because I never end up repeating names
of things that can be known statically prior to 
the topological sort, my XML ends up being a lot
more reusable / cut-and-paste-able.  Extremely nice!


Let me know what you think.

            Cheers,
            -Jon


Side note:  it would be highly desirable if Ant gave the build listener 
a special event signifying that the topological dependency sort is
is about to happen... I had to kludge around that one.  Another nasty
bit was that the "dependencies" field in Target is private, yet there's
no way to remove dependencies (just add them).  That means that if you
want to do a  custom fixup of dependencies, you've got to resort to
introspection and the ugly field.setAccessible(true) trick.  It works,
but it's icky.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Mime
View raw message