On 10/25/07, Jacob Grydholt Jensen <[EMAIL PROTECTED]> wrote:
> On 25/10/2007, Peter Reilly <[EMAIL PROTECTED]> wrote:
> > 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
>
> Sub-projects may be setup in various ways. Could you give more details
> on the use case you are considering? I would think that if both the
> main-project (I assume you are talking about just one main-project)
> and the sub-projects are explicit about which ivysettings they are
> referring to, then there would be no ambiguity. Therefore, the
> sub-project could inherit the main-projects references without
> problems. I am not an ant expert, so there could be subtleties that I
> am not aware of.
The case was checking if the default ivy setting has already been set.
<ivy:setting ../> -- default id
.
.
<ivy:setting ../> --- this causes an error as <ivy:setting> has
already been called.
To do this, the code is using ant references.
now:
subproject:
<project>
<ivy:setting ../>
<ivy: ...>
</project>
should work as sub-projects should always be buildable.
If the main project has set the ivy setting
<project>
<ivy:setting.../>
<dowloand stuff>
<subant>
<sub-projects list>
<subant>
</project>
the code in the subprojects would whine as the ivy:setting has already
been set.
Peter.
>
> /grydholt
>
