On Sat, Mar 29, 2008 at 9:55 PM, Stephane Bailliez <[EMAIL PROTECTED]> wrote:
> Xavier Hanin wrote: > > Just pinging about this e-mail, I've had no answer so far, I think I > can't > > make the choice alone, and we need to deal with that question before > > 2.0final to close IVY-297. So, anyone has an opinion about this: > > > > On Fri, Feb 29, 2008 at 12:31 PM, Xavier Hanin <[EMAIL PROTECTED]> > > wrote: > > > >> Hi, > >> > >> As reported by IVY-297, Ivy suffers from some name inconsistencies and > >> strange attribute names. Ivy 2.0 is a good opportunity to fix some of > >> them, since I think we can afford some more deprecation warnings. > >> > >> So I'd like to fix IVY-297 by marking allownomd as deprecated, and > >> providing a descriptor="required | optional" attribute. > >> > >> To go further, we could rename the attribute skipbuildwithoutivy in > >> buildlist in skipbuildwithoutdescriptor, or even better change it to > >> buildwithoutdescriptor="skip | fail | warn | tail | head", which wold > make > >> it both more readable and more powerful. > >> > s/buildwithoutdescriptor/missing-descriptor ? onMissingDescriptor ? I like onMissingDescriptor. > > imnotgenerallyabigfanofwordsgluedtogetherwithoutseparator when it it's > more then 2 words (onchange, on..) I'm not either, I think at the beginning I thought it was more in the spirit of Ant (where you have some examples like failonerror, preservelastmodified, ... Now we have some inconsistancies, using camel case in some cases, dash separator in others, nothing elsewhere. I don't really like those inconsistencies, but I'm not in favour of fixing them all for 2.0 (mainly for a question of delay). > OtherwiseThereIsCamelCaseButThisIsUglyTooForXml > > >> Another area where the name 'ivy' is used to talk about module > descriptors > >> in general is patterns. This lead to some strange settings, where you > give > >> an 'ivy' pattern to tell where the poms are. In this case I think we > could > >> support both 'ivy' and 'descriptor' (for resolver patterns for > instance), > >> since the use case for ivy files is still predominant, so I don't think > >> deprecating the old name would really be better. > >> > >> So, what do you think about these changes? > >> > I guess if you want to make it it's probably 2.0 or never... there's > already a lot of deprecated right now and it will get more difficult to > push them in later. > After all it's a 2.0 Agreed. Xavier > > > -- stephane > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
