ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <j_a_fernan...@yahoo.com>
Subject RE: [DISC] Aspect types was [DISC] Aspect implementation
Date Sun, 03 Jun 2001 11:45:26 GMT
> From: Peter Donald [mailto:donaldp@apache.org]
>
> Hi,
>
> At 07:41 PM 6/2/01 +1000, Conor MacNeill wrote:
>
> For ages I have been trying to figure out a clean way to do
> preferences. In
> many ways preferences is a specialized form of templating .. namely if
> attribute foo not set and we have preference set for it then
> we set it.
> This could be done as a preference easily enough (something
> that gets hold
> of task model + task instance before execute() is called on task).
>
> +1 on Preferences == Aspect
>

Should this be considered an Aspect on the Tasks or on
Project/ProjectHelper?
One feature of Preferences is that one does not need to define them on every
use. They get applied depending on the concreate user environment (who the
user is, for example).

So that looks more like an aspect to be applied at the level of the
ProjectHelper. They will be specified independently of whatever project I am
loading (in principle), so how can they be assuciated to the project. They
may also define the proference for other aspects (like "run this task on
debug mode"), without the need to modify the buildfile themselves (which may
be a shared resource). We still can use whatever syntax for declaring and
parameterizing aspects that we want.

	<aspect name="preferences" .... />

	<preference>
		<task name="javac">
			<attribute name="deprecation" value="false"/>
			<!-- Magic properties -->
			<attribute name="compiler" value="${build.compiler}"/>
		</task>

		<task name="*" >
			<!-- Seting aspect debug mode on ALL tasks -->
			<attribute name="ant:debug" value="true" />
		</task>
	</preferences>

Or something like that. My point here is that it is up to the preference
aspect to define whatever syntax to express how preferences are defined.

> I am not sure - I think there should probably always be an
> aspect handler
> for it. However we could define a NoopHandler that would be
> installed for
> certain predefined aspects by default (much like DefaultListener is
> installed as ProjectListener by default).
>

> >Any thought about aspects applied to either target or
> project elements?
>
> It could be useful to have the adapter between
> tasks/target/project and
> ProjectListener as an aspect. But that is more a programatic advantage
> rather than advantage to build file users ;)
>

See my example above.

Jose Alberto


Mime
View raw message