ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject Re: [DISC] XML issues
Date Wed, 11 Apr 2001 06:51:57 GMT
At 10:55  10/4/01 -0700, David Rees wrote:
>>I am not sure why you think such a system would be simpler. Aspect based
>>systems are meant to be used to give fine grain separation of concerns. How
>>the  aspects are handled (ie Facilities in my terminology) is not set. In
>>essence what you propose is to reclump all aspects into one again and then
>>swap out facilities at runtime (ie essentially what Ant1 does with it's
>>magic properties/loggers).
>>
>>This of course fails to provide for large projects who want need the extra
>>flexibility to do their own thing. It also doesn't add anything on an
>>aspect based system because we could always directly configure facilities
>>to provide appropriate fgeatures (ie special ClassLoaderFacility for GUMP
>>builds, BlameFacility for Alexandria, DocFacility for AntDoc etc).
>>
>>So I can't see how it is simpler or more useful for the **users** (though
>>it would be simpler for us Ant developers).
>>
>
>I think are concepts are the same and its more of an API question
>rather than one of aspect orientation. As a big proponent and someone
>who has coded aspects into the compiler in those languages that I
>could (Smalltalk) I don't think I am arguing against aspects. In fact,
>in my experience, most aspect oriented solutions are not visible in
>the code at the point where they are used. Instead, they are
>installed/uninstalled as part of that classes configuration.

right. With this I agree - the namespaces proposal for aspect handling
should not pass in configuration data for the Facility (or AspectHandler).
However I see the namespaced attributes to be parameters relevent to a
particular task.

So you would set up the Facility somehow and then install it. Each task
however could pass parameters to facility to be handled. (ie
log:level="verbose").

>What I am suggested is that context represents this API for
>installing/uninstalling aspects. As that they are explicitly supported
>in the API.
>
> I see the logfile attribute being on a LogContext element like:
>
><Context id="detailed">
>  <LogContext name="current" logfile="log.txt" />
></Context>
>
>and I think you see it as a namespace delimited attribute (right?) on
>the task itself:
>
><Copy log:file="log.txt" />

Not really - I would see file="log.txt" a configuration of the Facility
rather than a task specific parameter. 

>
>I prefer the former approach because (IMO)  it makes easier to
>install/uninstall whole approaches for running tasks:
>
><Project context="detailed" ... />
><Copy context="ignoreMost" ... />
>
>Now that I have looked at a possible API for what I suggest, I do
>agree that it may not really be simpler for the user since the basic
>user will not even be aware that namespaces are being used. However, I
>do think the flexibility for installing/uninstalling whole contexts is
>key and I am not sure how you propose to handle that from an XML api
>perspective.

If I understand you correctly you are proposing a generalized version of
recorder task that can configure any facility rather than just logging? If
so then I like that idea and I think namespaces are othogonal to it
(assuming we make a clear distinction between task-specific parameters and
global Facility parameters). I had assumed we would continue to use the
command line for these things but I guess your approach is much better.

Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*


Mime
View raw message