ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeffrey Blattman <jeffrey.blatt...@gmail.com>
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)?)
Date Thu, 28 Jun 2007 21:59:58 GMT
xavier & gilles,

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.

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 ...

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 <gscokart@gmail.com> 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 <xavier.hanin@gmail.com>:
>> > On 6/25/07, Jeffrey Blattman <jeffrey.blattman@gmail.com> wrote:
>> > >
>> > > see inline ...
>> > >
>> > > Xavier Hanin wrote:
>> > > > On 6/25/07, Jeffrey Blattman <jeffrey.blattman@gmail.com> 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:xavier.hanin@gmail.com]
>> > > >> >> Sent: lundi 25 juin 2007 16:47
>> > > >> >> To: ivy-user@incubator.apache.org
>> > > >> >> 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 <gscokart@gmail.com>
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
>>
>
>
>

Mime
View raw message