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 Fri, 29 Jun 2007 08:25:47 GMT
On 6/28/07, Jeffrey Blattman <jeffrey.blattman@gmail.com> 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 <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
Creator of Ivy, xooki and xoocode.org
More about me: http://xhab.blogspot.com/

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