On 10/25/07, Xavier Hanin <[EMAIL PROTECTED]> wrote:
> On 10/25/07, Jacob Grydholt Jensen <[EMAIL PROTECTED]> wrote:
> >
> > > The situation now is that :
> > > - ivy:settings is a datatype, for which the documentation say that the
> > id is
> > > mandatory.
> > > - ivy:configure is documented as deprecated (and print a warning message
> > if
> > > you use it). It actually register it as an ivy:settings with the id
> > > ivy.instance.
> > > - All other ivy task have an optional settingsRef attribute. When it is
> > not
> > > specified, the settings ivy.instance is used (or a default one if none
> > > exists)
> > >
> > >
> > > Now, the bug in the tutorial.
> > >
> > > Here is an exctract:
> > > <ivy:settings file="${ivy.settings.dir}/ivysettings.xml" />
> > > <target name="resolve" description="--> retreive dependencies with
> > ivy">
> > > <ivy:retrieve/>
> > > </target>
> > >
> > > This actually fails because the retrieve task will use the default
> > > settings. Indeed, the ivy:retrieve will use the settings with the id '
> > > ivy.instance', which doesn't exist!
> > > Because ivy:settings is a datatype, he can not check that an id is
> > defined
> > > (even if the intention was to make it mandatory).
> > >
> > > To fix it I will add the id="ivy.instance".
> >
> > Okay I tried the tutorial yesterday and opened IVY-629 since I
> > observed this behaviour. Without the id, ivy will just use the default
> > settings from the ivy.jar as explained by Xavier.
> >
> > > But, are we happy with this?
> > > - Can we generate an error if no ids are given?
> >
> > I would like the following:
> >
> > - if the user provides no ivysettings, a default setting is read
> > from the ivy.jar and assigned the default id. I think this is how ivy
> > works today.
> > - if the user provides exactly one ivysettings without an id, the
> > default id is assigned to the ivysettings behind the scenes.
> > - if the user provides more than one ivysettings without an id, it
> > is considered an error
>
Mmm, what about sub-projects ?
Each subproject may want to define it's own ivy env, but also
inherit the main-projects other references.
Peter
>
> This sounds like a good approach, could we do that with a datatype?
>
> Xavier
>
> > - Should we un-deprecate ivy:configure for the users that don't want to
> > use
> > > multiple settings?
> >
> > I agree with Xavier that it would be unwise to continue to support two
> > different ways of setting up ivy.
> >
> > /grydholt
> >
>
>
>
> --
> Xavier Hanin - Independent Java Consultant
> http://xhab.blogspot.com/
> http://ant.apache.org/ivy/
> http://www.xoocode.org/
>
