Fixing some naming inconsistencies in Ivy
|
View:
New views
9 Messages
—
Rating Filter:
Alert me
|
 |
Fixing some naming inconsistencies in Ivy
by Xavier Hanin
::
Rate this Message:
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. 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? Xavier -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/ |
|
|
Re: Fixing some naming inconsistencies in Ivy
by Xavier Hanin
::
Rate this Message:
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@...> 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. > > 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? > > Xavier > > Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/ |
|
|
Re: Fixing some naming inconsistencies in Ivy
by Gilles Scokart
::
Rate this Message:
On 29/02/2008, Xavier Hanin <xavier.hanin@...> 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. > +1 > 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. > +1 > 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. ??? I don't know. > > So, what do you think about these changes? > > Xavier > > > -- > Xavier Hanin - Independent Java Consultant > http://xhab.blogspot.com/ > http://ant.apache.org/ivy/ > http://www.xoocode.org/ > -- Gilles Scokart --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: Fixing some naming inconsistencies in Ivy
by Stephane Bailliez-3
::
Rate this Message:
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@...> > 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. >> imnotgenerallyabigfanofwordsgluedtogetherwithoutseparator when it it's more then 2 words (onchange, on..) 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 -- stephane --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: Fixing some naming inconsistencies in Ivy
by Xavier Hanin
::
Rate this Message:
On Sat, Mar 29, 2008 at 9:55 PM, Stephane Bailliez <sbailliez@...>
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@...> > > 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@... > For additional commands, e-mail: dev-help@... > > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/ |
|
|
Re: Fixing some naming inconsistencies in Ivy
by Peter Reilly-2
::
Rate this Message:
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@...> wrote: > On Sat, Mar 29, 2008 at 9:55 PM, Stephane Bailliez <sbailliez@...> > 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@...> > > > 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@... > > For additional commands, e-mail: dev-help@... > > > > > > > > > -- > Xavier Hanin - Independent Java Consultant > http://xhab.blogspot.com/ > http://ant.apache.org/ivy/ > http://www.xoocode.org/ > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: Fixing some naming inconsistencies in Ivy
by Xavier Hanin
::
Rate this Message:
On Sun, Mar 30, 2008 at 7:27 PM, Peter Reilly <peter.kitt.reilly@...>
wrote: > ant attribute names are case insensitive. Yes, but documentation use them in some form, and I wonder how many people change the case from what is documented. BTW, we could make Ivy support for attributes case insensitive too. > > I do not like long attribute names - although I have created > a fair few my self. Same for me :-) Xavier > > Peter > > > > On Sun, Mar 30, 2008 at 4:59 PM, Xavier Hanin <xavier.hanin@...> > wrote: > > On Sat, Mar 29, 2008 at 9:55 PM, Stephane Bailliez <sbailliez@...> > > 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@...> > > > > 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@... > > > For additional commands, e-mail: dev-help@... > > > > > > > > > > > > > > > > -- > > Xavier Hanin - Independent Java Consultant > > http://xhab.blogspot.com/ > > http://ant.apache.org/ivy/ > > http://www.xoocode.org/ > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/ |
|
|
|
|
|
Re: Fixing some naming inconsistencies in Ivy
by Xavier Hanin
::
Rate this Message:
I've fixed IVY-297 with the changes suggested for allownomd and
skipbuildwithoutivy. I've also opened IVY-789 to support descriptor as a more generic name for module descriptor patterns in resolvers configuration. Xavier On Mon, Mar 31, 2008 at 1:43 PM, Maarten Coene <maarten_coene@...> wrote: > I like the enumeration syntax, like descriptor="required | otpional", it's > much more readable and it will probably allow us to have less attributes on > some of the tasks. > > Maarten > > ----- Original Message ---- > From: Xavier Hanin <xavier.hanin@...> > To: Ant Developers List <dev@...> > Sent: Saturday, March 29, 2008 10:09:23 AM > Subject: Re: Fixing some naming inconsistencies in Ivy > > 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@...> > 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. > > > > 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? > > > > Xavier > > > > > -- > Xavier Hanin - Independent Java Consultant > http://xhab.blogspot.com/ > http://ant.apache.org/ivy/ > http://www.xoocode.org/ > > > > > > > ____________________________________________________________________________________ > Looking for last minute shopping deals? > Find them fast with Yahoo! Search. > http://tools.search.yahoo.com/newsearch/category.php?category=shopping > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/ |
| Free Forum Powered by Nabble | Forum Help |