ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Rees <d.ree...@usa.net>
Subject Re: [DISC] XML issues
Date Wed, 11 Apr 2001 05:55:41 GMT
On Wed, 11 Apr 2001 14:44:55 +1000, Peter Donald wrote:

>At 08:48  9/4/01 -0700, David Rees wrote:
>>On Tue, 03 Apr 2001 22:10:57 +1000, Peter Donald wrote:
>>
>>>At 02:00  3/4/01 +0200, Stefan Bodewig wrote:
>>>>Peter Donald <donaldp@apache.org> wrote:
>>>>
>>>>> However it is at higher complexity build files (medium->high
>>>>> complexity) where the advantage would be shown. Mainly as it would
>>>>> allow core to be clean and handling of tasks predictable. For big
>>>>> build processes it would allow customisation without magic variables
>>>>> (ala GUMPs sysclasspath) and added value (ie assign fee: namespace
>>>>> to something specific to buisness).
>>>>
>>>>So you propose namespaces to make the "aspect" system pluggable, am I
>>>>getting this right?  You want a facility to say "I'll take
>>>>responsibility of all task attributes int the baz namespace"?
>>>
>>
>>I think the "simpler" alternative of introducing a context object with
>>sub-elements should also be kept for consideration. I think it would
>>easier for many to understand. Then taking control of logging is as
>>simple as replacing the logging object. It also moves the
>>logging/failure attributes out of Task, which I think is the right
>>thing to do.
>>
>>In terms of big build processes you could have a set of named contexts
>>defined to plug in and out.
>
>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.

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" />

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.

dave




Mime
View raw message