ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Danny Yates <da...@codeaholics.org>
Subject Re: [Proposal] Capture attributes in unknown namespaces
Date Fri, 25 Jun 2010 10:59:16 GMT
Yes, I nabbed an alternative logger from a similar project :-) Basically, it
outputs when a target starts and when it finishes, and for each task it
outputs [target/task] instead of just [task] so you can see what's going on.

I can't claim any responsibility for it though!


On 25 June 2010 11:48, <Jan.Materne@rzf.fin-nrw.de> wrote:

> btw - when using parallel executors the problem of parallel logging output
> must be resolved ;-)
>
> Jan
>
> >-----Urspr√ľngliche Nachricht-----
> >Von: Jan.Materne@rzf.fin-nrw.de [mailto:Jan.Materne@rzf.fin-nrw.de]
> >Gesendet: Freitag, 25. Juni 2010 12:46
> >An: dev@ant.apache.org
> >Betreff: AW: [Proposal] Capture attributes in unknown namespaces
> >
> >Other point: we have an implementation in the sandbox
> >https://svn.apache.org/repos/asf/ant/sandbox/parallelexecutor
> >
> >Maybe you could use some code ;-)
> >
> >
> >Jan
> >
> >>-----Urspr√ľngliche Nachricht-----
> >>Von: Dominique Devienne [mailto:ddevienne@gmail.com]
> >>Gesendet: Donnerstag, 24. Juni 2010 23:12
> >>An: Ant Developers List
> >>Betreff: Re: [Proposal] Capture attributes in unknown namespaces
> >>
> >>On Thu, Jun 24, 2010 at 2:50 PM, Danny Yates
> >><danny@codeaholics.org> wrote:
> >>> What would be kind of cool would be that if the parser
> >>encounters attributes
> >>> in a namespace that it doesn't recognise, then instead of
> >>ignoring them (as
> >>> it does now), it records them and makes them available
> >>through an API on the
> >>> Project and Target objects. This would allow the executor to
> >>inspect them.
> >>
> >>Something related to that was discussed in the past to allow arbitrary
> >>"cross-cutting" attributes to be added to tasks which wouldn't
> >>normally support them, typically in the context of adding global
> >>ant:if and ant:unless attributes (or maybe I just thought about it,
> >>I'm no longer sure ;)
> >>
> >>> I realise this is very specific to my parallel executor
> >>project, but I think
> >>> adding it would be a non-breaking change that wouldn't have
> >>any impact on
> >>> existing consumers of the API.
> >>
> >>True. But I'd be more in favor of an opt-in framework, where you
> >>explicitly tell Ant to record attributes from specific namespaces.
> >>From the list, I think other people also use "extra" markup in their
> >>builds for "external" tools, so in their case they don't need to
> >>record those attributes for examples.
> >>
> >>> What do you folks think?
> >>
> >>I think it's a good idea. There are design considerations like, should
> >>it be free form string=string recorded as-is, or should these
> >>attributes be processed like ordinary attributes Ant deals with to do
> >>property expansion and conversion to Java types (like boolean
> >>accepting "true"/"on"/"yes" as a true). For example, imagine you group
> >>your extra attributes into a DataType part of an AntLib bound to that
> >>extra namespace, the DataType could be instantiated "as usual" by Ant
> >>provided it looked at the UnknownElement specifically for a given
> >>namespace, and then the DataType is "bound" somehow to the task or
> >>type or target. That way everything is typed as usual, and could be
> >>made to reuse a lot of the existing code/facilities. See what I mean?
> >>--DD
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> >>For additional commands, e-mail: dev-help@ant.apache.org
> >>
> >>
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> >For additional commands, e-mail: dev-help@ant.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message