ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <xavier.ha...@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:39:14 GMT
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
>



-- 
Xavier Hanin - Independent Java Consultant
Manage your dependencies with Ivy!
http://incubator.apache.org/ivy/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message