On 10/26/07, Jacob Grydholt Jensen <[EMAIL PROTECTED]> wrote: > > On 25/10/2007, Peter Reilly <[EMAIL PROTECTED]> wrote: > > > > 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. > > The semantics of this is unclear to me. Do you want the sub-projects > to use the reference defined in the main-project or do you want them > to override the reference? > > I would prefer if we could come up with a scheme where we do not rely > on too much magic with regards to the implicitly assigned settings id. > I suggest the following: > > - if no id is specified in a settings task then the default will be > assigned. This default is of course the one used in any resolve or > retrieve tasks without explicit ids. > > - a new override attribute on the settings task determines what > happens if an id is not unique. The override attribute can be one of > "true | false | notallowed" with notallowed being the default. The > meaning of this attribute should be: > - notallowed : an error is raised if a settings has already > been defined with this id > - true : the current settings will take precedence over any > previously defined setting with this id > - false : the current settings will not override a previously > defined setting with this id > > Using this attribute the subprojects can be specified with: > > <project> > > <ivy:setting override="false"../> > <ivy: ...> > </project> > > > WDYT?
I like your proposition, it let users do whatever they want, with a default behavior failing early enough for the users to take action upon what they really want. If the failure clearly document how this can be handled (namely the three options for override + choosing another id in the main project to avoid id conflict) I think it's a very good solution. Xavier /grydholt > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
