On 6/28/07, Jeffrey Blattman <[EMAIL PROTECTED]> wrote:
xavier & gilles,
Hi Jeffrey,
Thanks for your feedback!
i still prefer:
<ivy:settings/> == configure default instance w/ file ${ivy.settings.file}
<ivy:settings file="123.xml"/> == configure default instance w/ file
"123.xml"
<ivy:settings id="abc"/> == configure instance "abc" w/ file
${ivy.settings.file}
<ivy:settings id="abc" file="123.xml"/> == configure instance "abc" w/
file "123.xml"
leave ivy:configure as-is, no changes. don't allow nested ivy:settings.
use references to settings IDs instead of nesting (settingsId="...").
just my $0.02. i realize i don't have the background w/ the project to
see the whole picture like you folks.
It seems that users are not keen of the nested settings. I think it's mainly
due to the habits of the configure task. For people new to Ivy I don't know
what they will think, but it seems that referring to settings as a datatype
and comparing it to a fileset or path would help some of them to consider
nested settings for scoping as interest. Indeed if you consider that the
resolve task requires a settings in the same way the javac task requires a
classpath, you can easily understand that you can either define the settings
before with an id and reuse it in several ivy tasks requiring a settings, or
define it nested in the resolve task. I really like this idea, and I think
new users which are already familiar with Ant could pretty easily understand
it.
Now the problem (if we can call that a problem) is that we have an installed
user base for who we would like to give an easy migration path. And for
them, as you confirm, using settings as a task (which can then use a default
identifier for implicit scoping) is preferred. That's why I thought that
keeping the configure task, and enabling scoping in this task as a new
feature, could help old users keep their habits, while people comfortable
with datatypes would prefer the use of ivy:settings, clearly explained and
understood as a datatype (with the comparison to path). But this has the
drawback of giving 2 ways to do the same thing, which is not a very good
idea. Indeed, even for the tutorials we will have to make a choice, and
which one will we choose?
It's not easy to make a good choice :-)
and, just throw out another option, here's a flip on gilles' first
thoughts ...
<ivy:settings file="foo.xml">
<ivy:antask .../>
<ivy:antask .../>
<ivy:antask .../>
</ivy:settings/>
:)
this would actually be more convenient that having ivy:settings nested
within ivy:anytask, because you can have as many anytask's inside the
settings as you wish. if the settings are nested, then you have to call
them out for each anytask
Interesting, but I don't think it would be that useful, since the call to
ivy tasks are often separated by other tasks. Moreover I think that using
the task container to embed a settings is only a hack, and correct me if I'm
wrong, Gilles, but I think even you were only proposing this as a way to do
something for which you were not convinced yourself :-).
Anyway, thanks for your suggestion Jeffrey, we appreciate users who take
part in these discussions, it's the best way to get a tool well suited to
users expectations!
Xavier
...
caveat: i'm not an ant expert so i don't really understand if this works
/ makes sense.
Xavier Hanin wrote:
> On 6/27/07, Gilles Scokart <[EMAIL PROTECTED]> wrote:
>>
>> Last night I was insomniac and I realized that a task can be put as a
>> child of an other task. Parallel does that. When looking at ant
>> source, I have seen that there is an interface TaskContainer. So
>> making that id of <settings> optional, and allowing <settings> as a
>> child of any ivy task is thus possible.
>>
>> Now, did we want that, that's an other issue!
>>
>> I think Xavier gave the right rational to move to a datatype.
>>
>> I understand also the fact that users would expect that <setings
>> file="...."/> defines a default settings. However, this kind of
>> structure might be 'counter intuitive' for the people that are more
>> confortable with datatype.
>>
>> I also fully agree with Jeffrey when he say that we should not have
>> two methods to do the same thing.
>>
>> Moreover, deprecating something is never user friendly.
>
>
> +1
>
> So, I start to think like Xavier that we should maybe keep configure.
>>
>> What do you think about :
>> <ivy:configure file="..." [settingsId='...']/>
>> (or did you preffer <ivy:configure file="..." [id='...']/>)
>
>
> I think we should better use settingsId, because we had trouble using
> id as
> an attribute (can't remember exactly why, but there's an issue in JIRA
> asking to use id for cachepath where we justify why it's not a good
> idea).
>
> And is we want we could still add :
>> <ivy:anytask ....>
>> <ivy:settings file="..."/>
>> </ivy:anytask>
>> As an alternative to
>> <ivy:configure settingsId='...'/>
>> <ivy:anytask settingsRef='...'>
>> </ivy:anytask>
>>
>> I know that would make two ways to do the same thing but that kind of
>> alternative is ususal in ant.
>
>
> You use ivy:settings and not ivy:configure in the first case, is it
> intentional? Anyway, I agree that this kind of alternative is not
> unusual in
> Ant, and I like the implicit scoping it provides. Now will it be easy to
> provide this implicit scoping using a task container? I don't know how
it
> works, but the task container will have to set the settingsId in the
> nested
> configure task before executing it. I guess this is possible, but we
> should
> check before if it's what we want.
>
> If some Ant folks are listening, your input would very valuable IMO.
> But we
> are on the user list, maybe this should go to the dev list (where I
think
> more Ant folks are listening)? I'll cross post this message to see if
> we get
> more opinions on the other list.
>
> Xavier
>
> Gilles
>>
>>
>> 2007/6/25, Xavier Hanin <[EMAIL PROTECTED]>:
>> > On 6/25/07, Jeffrey Blattman <[EMAIL PROTECTED]> wrote:
>> > >
>> > > see inline ...
>> > >
>> > > Xavier Hanin wrote:
>> > > > On 6/25/07, Jeffrey Blattman <[EMAIL PROTECTED]> wrote:
>> > > >>
>> > > >> sorry if i'm lost a little, but this is what i'd expect as a
user
>> ...
>> > > >>
>> > > >> <ivy:settings/> assumes a default id of "ivy.instance" (or
>> whatever),
>> > > >> and any other task that takes a settingsId assumes a default of
>> > > >> "ivy.instance" if it's not specified.
>> > > >>
>> > > >> and of course, <ivy:settings id="X" file="..."/> is valid, and
>> any
>> > > other
>> > > >> task that takes a settingsId attr , and uses "X" will use the
>> settings
>> > > >> defined by the associated ivy:settings.
>> > > >>
>> > > >> this is what is intuitive from a user's perspective, so it'd be
>> good if
>> > > >> there'd by a way to make the code work like this.
>> > > >
>> > > >
>> > > > Thanks for your feedback Jeffrey.
>> > > > I agree with your feeling, the problem is that the only way to do
>> what
>> > > > you
>> > > > want is to define ivy:settings as a task. And if it's a task, you
>> > > > can't use
>> > > > it with the following syntax:
>> > > > <ivy:resolve>
>> > > > <ivy:settings file="">
>> > > > </ivy:resolve>
>> > > > which has the advantage of making scoping obvious (with no need
>> for
>> an
>> > > > id).
>> > > >
>> > > that is interesting, but i would have never thought to try that.
for
>> me,
>> > > it is more intuitive to do it w/ references ...
>> > >
>> > > <ivy:settings id="x" file="..."/>
>> > > <ivy:resolve settingsId="x"/>
>> > > > So my proposition is to keep the configure task (which would
>> behave
>> > > > exactly
>> > > > as you expect from the settings), and use settings only with an
id
>> or
>> > > > within
>> > > > a post settings task (as you would do with a fileset or any other
>> ant
>> > > > datatypes).
>> > > >
>> > > > Does it make sense?
>> > > i hope i am not insulting insulting anyone, but i get the feeling
>> that
>> > > might be over engineering to some degree. for users, it may be more
>> > > important, for a particular task, to have one obvious way to
achieve
>> it
>> > > as opposed to having multiple ways. then the user has to research
>> which
>> > > is better and why they should use one over the other.
>> > >
>> > > for example, is:
>> > >
>> > > /<ivy:resolve>
>> > > <ivy:settings file="">
>> > > </ivy:resolve>
>> > > /
>> > > solving a use case that can't be achieved via:
>> > >
>> > > /<ivy:settings id="x" file="..."/>
>> > > <ivy:resolve settingsId="x"/>
>> > > /
>> > > or is it just giving the user another way to do the same thing? if
i
>> was
>> > > a new user, i'd look at the ivy:settings and ivy:configure, and
have
>> to
>> > > do some reading to understand the difference between them.
>> > >
>> > > just my $0.02 ... hope this feedback is of some help.
>> >
>> >
>> > Yes it is. Feedback from users is the best way to achieve a good
>> product!
>> >
>> > I understand your point of view, maybe we should consider only one
way
>> and
>> > forget about embedding the settings (and thus use a task instead of a
>> > datatype). I think the original idea behind the datatype was
>> brought by
>> > people very comfortable with ant who didn't catch at first time the
>> relation
>> > between the Ivy tasks. There is no other ant task which are
>> dependent on
>> one
>> > another like that, using datatypes is more usual.
>> >
>> > I won't fight for the datatype, even if I find the solution
>> elegant, I'm
>> > used to the way the task work, and using an id for scoping is fine
for
>> me.
>> >
>> > Maybe we should start another thread to get more user feedback?
>> >
>> >
>> > regardless, your
>> > > project has been a life saver for us. thank you.
>> >
>> >
>> > Thanks a lot, it's the best reward we can get from the time we
>> invest in
>> the
>> > project!
>> >
>> > Xavier
>> >
>> >
>> > >
>> > > > Xavier
>> > > >
>> > > > Gilles Scokart wrote:
>> > > >> >
>> > > >> >> -----Original Message-----
>> > > >> >> From: Xavier Hanin [mailto:[EMAIL PROTECTED]
>> > > >> >> Sent: lundi 25 juin 2007 16:47
>> > > >> >> To: [EMAIL PROTECTED]
>> > > >> >> Subject: Re: Ivy settings management from Ant (was Re: can i
>> call
>> > > >> >> ivy:configure multiple times with different configuration
>> > > files(which
>> > > >> in
>> > > >> >> turn refers different ivy.xmls)?)
>> > > >> >>
>> > > >> >> On 6/25/07, Gilles Scokart <[EMAIL PROTECTED]> wrote:
>> > > >> >>
>> > > >> >>> I think I was not clear in my explanations, sorry.
>> > > >> >>> What I would like to have is :
>> > > >> >>>
>> > > >> >>> - When deprecated <configure> is used, no scoping is
>> > > >> >>> available. settingsRef
>> > > >> >>> in task doesn't make sense
>> > > >> >>>
>> > > >> >> Does it mean that if you use settingsRef in a task it will
>> raise
>> an
>> > > >> error?
>> > > >> >> Even if you use settingsRef="ivy.instance"? I thought the
call
>> to
>> > > >> >> configure
>> > > >> >> with no id was equivalent to <ivy:settings
>> id="ivy.instance"/>.
>> Is
>> > > it
>> > > >> >> right?
>> > > >> >>
>> > > >> >
>> > > >> > Currently on the trunk, yes, you are right. I just said
>> that it
>> > > >> didn't
>> > > >> make
>> > > >> > sense, so for me it could raise an error or we could keep the
>> current
>> > > >> > behaviour. I'm too tired today to say which approach I would
>> prefer.
>> > > >> >
>> > > >> >
>> > > >> >> - When a <settings> is defined, id='...' is mandatory. And
an
>> error
>> > > >> (with
>> > > >> >> a
>> > > >> >>
>> > > >> >>> clear message) is triggered when a task try to use the
>> settings
>> > > >> >>> 'ivy.instance' (implicitely or or not) and this instance was
>> > > created
>> > > >> >>>
>> > > >> >> with
>> > > >> >>
>> > > >> >>> a
>> > > >> >>> <settings> without id.
>> > > >> >>>
>> > > >> >> Sorry, I'm not sure to fully understand this point. Do you
>> mean
>> > > that:
>> > > >> >> <ivy:settings />
>> > > >> >> <ivy:resolve settingsRef="ivy.instance" />
>> > > >> >> will raise a clear error, saying that the id is mandatory in
>> > > >> settings?
>> > > >> >>
>> > > >> >> In this case, what happen if you do this:
>> > > >> >> <ivy:configure file="ivyconf.xml"/>
>> > > >> >> <ivy:resolve />
>> > > >> >> <ivy:settings file="ivysettings.xml" />
>> > > >> >> <ivy:resolve settingsRef="ivy.instance" />
>> > > >> >> ?
>> > > >> >> The first resolve should run ok with the settings loaded from
>> > > >> ivyconf.xml.
>> > > >> >> Then will the second resolve use the first settings loaded
>> with
>> > > >> configure,
>> > > >> >> the second one, or raise an error? My guess is that it will
>> use
>> the
>> > > >> first
>> > > >> >> settings. Am I right?
>> > > >> >>
>> > > >> >>
>> > > >> >
>> > > >> > Currently on the trunk, again you are right. But I'm not
>> sure it
>> is
>> > > >> > intuitive. I would prefer the second resolve call trigger an
>> error
>> > > >> saying
>> > > >> > that the ivy:settings must have an id.
>> > > >> >
>> > > >> >
>> > > >> >
>> > > >> > Gilles
>> > > >> >
>> > > >> >
>> > > >> >
>> > > >>
>> > > >
>> > > >
>> > > >
>> > >
>> >
>> >
>> >
>> > --
>> > Xavier Hanin - Independent Java Consultant
>> > Manage your dependencies with Ivy!
>> > http://incubator.apache.org/ivy/
>> >
>>
>>
>> --
>> Gilles SCOKART
>>
>
>
>
--
Xavier Hanin - Independent Java Consultant
Creator of Ivy, xooki and xoocode.org
More about me: http://xhab.blogspot.com/
