Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <43726AF3.7000707@arielpartners.com>
Date: Wed, 09 Nov 2005 16:32:35 -0500
From: Craeg Strong <cstrong@arielpartners.com>
Organization: Ariel Partners, LLC
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317)
MIME-Version: 1.0
To: Ant Developers List <dev@ant.apache.org>
Subject: Re: PROPOSE: Property Trace Facility For Ant?
References: <43719F02.6050704@arielpartners.com>
 <255d8d690511090705q34733b3pbc8c1a88e23bfcd@mail.gmail.com>
In-Reply-To: <255d8d690511090705q34733b3pbc8c1a88e23bfcd@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dominique Devienne wrote:

>So obviously I'm +1 on adding such a facility, but implementing it the
>way you propose is indeed disruptive.
>
>Alternate impls (disclaimer: I'm just thinking aloud here...) might be:
>
>1) Add categories to log messages. You could then change the log
>statements in property-related tasks (and in Project) to use this new
>"property" log category, and add a switch to the launcher to allow
>saying -verbose:property or -debug:property and get only these
>particular log messages.
>  
>
Cool!  Continuing this thought experiment, what about enhancing 
BuildListener like so:

    /**
     * Signals that a property has been set.
     *
     * @param event An event with any relevant extra information,
     *              for example, the name of the property and whether
     *              the property was set successfully or was an ignored 
override.
     */
    void propertySet(PropertyEvent event);
   
    /**
     * Signals that a property has been retrieved, for example,
     * the text "I am using the ${foo} property" in an echo task
     * could trigger this event.
     *
     * @param event An event with any relevant extra information,
     *              for example the name of the property.
     */
    void propertyGet(PropertyEvent event);

You could have PropertyHelper fire the propertyGet event in 
replaceProperties(), for example.

The issue with these events is the same one you normally have with 
exceptions.
That is, at the time an exception is thrown deep in the guts of a 
program you typically don't have enough context.
Here in replaceProperties() we don't have a reference to the calling 
Task, only the Project.

The typical solution for exceptions is to cascade them up the chain, 
either directly or within an enclosing Exception.

A similar approach for events might be to simply accumulate the 
propertyGet events within the scope of the PropertyHelper and then
print them out later in the taskFinished() event message.  
Alternatively, we don't worry about the loss of context,
relying on the surrounding taskStarted/taskFinished events to provide 
the context-- as long as there are not multiple threads going on.

What do you think? 

--Craeg


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