From dev-return-87058-apmail-ant-dev-archive=ant.apache.org@ant.apache.org Mon Jul 30 21:17:15 2012
Return-Path:
X-Original-To: apmail-ant-dev-archive@www.apache.org
Delivered-To: apmail-ant-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
by minotaur.apache.org (Postfix) with SMTP id 350D6D9F2
for ; Mon, 30 Jul 2012 21:17:15 +0000 (UTC)
Received: (qmail 39527 invoked by uid 500); 30 Jul 2012 21:17:15 -0000
Delivered-To: apmail-ant-dev-archive@ant.apache.org
Received: (qmail 39464 invoked by uid 500); 30 Jul 2012 21:17:14 -0000
Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe:
List-Help:
List-Post:
List-Id: "Ant Developers List"
Reply-To: "Ant Developers List"
Delivered-To: mailing list dev@ant.apache.org
Received: (qmail 39454 invoked by uid 99); 30 Jul 2012 21:17:14 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 30 Jul 2012 21:17:14 +0000
X-ASF-Spam-Status: No, hits=1.0 required=5.0
tests=SPF_HELO_PASS,SPF_SOFTFAIL
X-Spam-Check-By: apache.org
Received-SPF: softfail (nike.apache.org: transitioning domain of nicolas.lalevee@hibnet.org does not designate 216.86.168.182 as permitted sender)
Received: from [216.86.168.182] (HELO mxout-07.mxes.net) (216.86.168.182)
by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 30 Jul 2012 21:17:05 +0000
Received: from [192.168.1.21] (unknown [77.192.12.208])
(using TLSv1 with cipher AES128-SHA (128/128 bits))
(No client certificate requested)
by smtp.mxes.net (Postfix) with ESMTPSA id ED56522E256
for ; Mon, 30 Jul 2012 17:16:41 -0400 (EDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Re: Modification of Ant API for AntDSL
From: =?iso-8859-1?Q?Nicolas_Lalev=E9e?=
In-Reply-To:
Date: Mon, 30 Jul 2012 23:16:39 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <36D0716C-78D6-4484-B9A7-4F89C0D046B8@hibnet.org>
References: <34A7A68A-B91F-4F07-AA80-C7EDEAC231D5@hibnet.org> <87a9ykf0st.fsf@v35516.1blu.de> <0664E258-D6BE-4906-9BEB-D85B3F976A8D@hibnet.org>
To: "Ant Developers List"
X-Mailer: Apple Mail (2.1084)
I have looked into the actual implementation details, actually I don't =
need much. So little that I have committed them, it will be easier to =
review, easier than writing about it in an email. If I can do this with =
a PropertyHelper, I'll revert and use the non intrusive way.
Nicolas
Le 28 juil. 2012 =E0 19:35, Nicolas Lalev=E9e a =E9crit :
> I think that I would like to change is the following point as =
documented in the header of the PropertyHelper class:
> "Object value seems valuable as outlined."
>=20
> Nicolas
>=20
> Le 28 juil. 2012 =E0 19:20, Nicolas Lalev=E9e a =E9crit :
>=20
>>=20
>> Le 28 juil. 2012 =E0 15:54, Stefan Bodewig a =E9crit :
>>=20
>>> On 2012-07-28, Nicolas Lalev=E9e wrote:
>>>=20
>>>> I start to like what I am doing which the AntDSL so I would like to
>>>> modify a little bit the Ant API so I can avoid doing so work =
around.
>>>=20
>>> Sorry, I haven't found the time to play with it.
>>=20
>> No worry.
>> Though some completely subjective opinion on the "look&feel" of the =
language will be appreciated :)
>> Anyone ? this is usually a subject for troll :)
>> =
http://svn.apache.org/viewvc/ant/sandbox/antdsl/trunk/test/build.ant?view=3D=
co&revision=3D1362284&content-type=3Dtext%2Fplain&pathrev=3D1362284
>>=20
>>>=20
>>>> In AntDSL, I have introduced an expression language so do some =
basic
>>>> computing: some math, some logical computation and string =
manipulation
>>>> for now. It is intended to replace the property expansion in =
strings.
>>>=20
>>>> Actually, the logical computation is already implemented in Ant: =
the
>>>> Conditions tasks. So I have used them for the if/unless attributes =
of
>>>> the target. I would like to take it back into Ant: [1]. I don't =
intend
>>>> to replace the existing if/unless, just offer new Java API to =
Target.
>>>=20
>>> I think the props Antlib can already do quite a bit of this.
>>=20
>> Actually I work at different level. See below.
>>=20
>>>> I would also like to be able to have expressions in task
>>>> attributes. But Ant assumes these are always Strings. As far as I =
can
>>>> tell, there are two places where it is assumed and it would be
>>>> changed: RuntimeConfigurable and IntrospectionHelper. I have been =
able
>>>> to work around RuntimeConfigurable and provide my own
>>>> implementation. But IntrospectionHelper is final.
>>>=20
>>> AFAIR this is not totally true, PropertyHelpers can return Objects =
and
>>> they get picked up in the approriate places. It is true that
>>> PropertyHelpers are the only way to generate non-String values =
outside
>>> of IntrospectionHelper, though. This is rather limiting.
>>=20
>> I am not sure property helper will do the proper job. I have to admit =
I don't know them much, but as far I can tell, they are sort of String =
parsers. With Antdsl, the parser has already done the job, I get an =
instance of the "thing to evaluate", an AntExpression, which can wrap a =
Condition for instance.
>> So when building an UnknownElement, my project helper cannot call =
RuntimeConfigurable#setAttribute(String, String) like =
ProjectHelper2.ElementHandler.onStartElement() does, I need a =
RuntimeConfigurable#setAttribute(String, AntExpression). Thus I would =
like to introduce a RuntimeConfigurable#setAttribute(String, Object).
>>=20
>> I have also an issue with macros which implement DynamicAttribute. =
But actually for AntDSL I think the best would be to reimplement the =
macros, since I am experimenting getting rid of the property expansion, =
and thus probably name them differently, "function" probably.
>>=20
>>>> I have not a patch to suggest, but I think the change would =
probably
>>>> be about introducing an interface Evaluable, change everywhere from
>>>> String to Object, and when we try to get the value of the =
attribute,
>>>> if Evaluable call eval(), otherwise call .toString().
>>>=20
>>> Do you see any chance to unify this with PropertyHelpers?
>>>=20
>>>> The changes I suggest should obviously be backward compatible.
>>>=20
>>> Not so obvious to me. Aren't there any APIs that return String but
>>> would return Object with your changes?
>>=20
>> I think that the API are already returning Object, which is cool. But =
I would need setter of Object.
>>=20
>> Thank you for your feedback.
>>=20
>> Nicolas
>>=20
>>=20
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>> For additional commands, e-mail: dev-help@ant.apache.org
>>=20
>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>=20
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org