ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominique Devienne" <ddevie...@gmail.com>
Subject Re: Ivy settings id (was Re: Merge 641903 from trunk to 1.7 branch?)
Date Fri, 28 Mar 2008 16:14:15 GMT
On Fri, Mar 28, 2008 at 10:31 AM, Xavier Hanin <xavier.hanin@gmail.com> wrote:
> On Fri, Mar 28, 2008 at 4:08 PM, Dominique Devienne <ddevienne@gmail.com>
>  > For the record, I think it's bad Ant style to use ids in tasks. [...]
>
>  I think we use that bad pattern. We've been wondering about the best form
>  settings should take for a while. It used to be a datatype in 2.0 alpha, but
>  we were running into trouble because a datatype has no lifecycle. Hence in a
>  discussion  Peter suggested to make it a task, using the id as we did before
>  for the datatype but with a default value:
>  http://markmail.org/message/52hqry734myzopts

Well, reading Gilles original issue, I agree with your answer Xavier.
The "Ant way"(tm) is to have both an id for the <settings> and a
settingsRef in <retrieve>.

The only reason you'd not have a settingsRef in <retrieve> was to be
BC with the deprecated <config> task, and only in this case would you
attempt to use a default id to lookup the settings type. If <config>
was never executed, i.e. you're not in BC mode, lacking a settingsRef
in <retrieve> should be an error right away, and you shouldn't even
try to lookup the "default" id.

If Ivy was designed like most Ant tasks, all 3 forms below would be equivalent:

<retrieve settingsRef="foo" />

<retrieve> <settings ... > ... </settings> </retrieve>

<retrieve> <settings refid="foo" /> </retrieve>

Where the nested settings is equivalent to the "foo" settings type not shown.

The original issue of not being able to error out right away when a
<settings> doesn't have an id is not really an issue IMHO. I'd be OK
with changing Ant to allow a method to be called on types so that they
can self-validate themselves (I also wished for such a method a long
time ago), to enable the failure right at the point of definition of
the type rather than at the point it's used (well, not used in fact,
if you remove the use of a "default" id...).

>  This works pretty well from a user point of view who don't really know if
>  it's a task or datatype and don't really care. Except that we run into this
>  bug, and this bad pattern. So, what would you suggest? Is there something we
>  could do better while still preserving the behaviour we have now?

Well, I don't quite agree here. Even though tasks and types are now
much closer in the core code, they still remain different concepts,
and are documented in separate sections of the manual. Types are data
containers, while tasks are "doers" or actions or verbs. You affect
the behavior of a task using inline stuff (attributes, nested
elements) which can be types, sometimes defined outside the task
itself and simply referenced by id, and the task shouldn't even be
aware whether the types are defined "locally" in the task, or outside.
In fact, you can even id a type defined "inside" a task, and reference
it later by id in another task.

Keeping task ids force the core Ant code to jump thru quite a few
hoops, which we'd better remove in fact... (but we don't for BC...) So
for new code like Ivy, an Ant sub-project even, to be using task ids
is not a good thing in my opinion.

So I suggest you put back settings as a type, only lookup a default id
when you know you are in BC mode (i.e. <config> was used), and
otherwise depend on normal uses and rules for ids and types, allowing
inline-nested definition of settings. Ant users are used to have to id
types they want to refer to in several tasks. Document it as such.
Error out in retrieve when so settings are specified, either inline or
by ref id.

My $0.02. --DD

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message