> -----Original Message----- > From: Peter Reilly [mailto:[EMAIL PROTECTED] > Sent: jeudi 25 octobre 2007 14:31 > To: [email protected] > Subject: Re: ivy:configure and ivy:settings again... > > 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. >
The problem that I see to implement that is that will actually depends if the user transfer the ids or not. And that might be counterintuitive for the users that doesn't put an id... Gilles > > > > /grydholt > >
