ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles Scokart" <gscok...@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 Wed, 27 Jun 2007 09:27:07 GMT
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.

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='...']/>)

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.

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