ant attribute names are case insensitive. I do not like long attribute names - although I have created a fair few my self. Peter
On Sun, Mar 30, 2008 at 4:59 PM, Xavier Hanin <[EMAIL PROTECTED]> wrote: > 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/ > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]