Re: Fixing some naming inconsistencies in Ivy
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] To: Ant Developers List dev@ant.apache.org 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 [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. 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: [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/
Re: Fixing some naming inconsistencies in Ivy
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 [EMAIL PROTECTED] To: Ant Developers List dev@ant.apache.org 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 [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. 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fixing some naming inconsistencies in Ivy
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/
Re: Fixing some naming inconsistencies in Ivy
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]
Re: Fixing some naming inconsistencies in Ivy
On Sun, Mar 30, 2008 at 7:27 PM, Peter Reilly [EMAIL PROTECTED] 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 [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] -- 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
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. 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
On 29/02/2008, 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. +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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fixing some naming inconsistencies in Ivy
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 ? 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fixing some naming inconsistencies in Ivy
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/
