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 <xavier.hanin@(protected):
> On Sat, Mar 29, 2008 at 9:55 PM, Stephane Bailliez <sbailliez@(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 <xavier.hanin@(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: dev-unsubscribe@(protected)
> > For additional commands, e-mail: dev-help@(protected)
> >
> >
>
>
>
>
> --
> Xavier Hanin - Independent Java Consultant
> http://xhab.blogspot.com/
> http://ant.apache.org/ivy/
> http://www.xoocode.org/
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@(protected)
For additional commands, e-mail: dev-help@(protected)