You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Xavier Hanin <xa...@gmail.com> on 2008/03/29 10:09:23 UTC

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 <xa...@gmail.com>
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

Posted by Xavier Hanin <xa...@gmail.com>.
On Sun, Mar 30, 2008 at 7:27 PM, Peter Reilly <pe...@gmail.com>
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 <xa...@gmail.com>
> wrote:
> > On Sat, Mar 29, 2008 at 9:55 PM, Stephane Bailliez <sb...@gmail.com>
> >  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@gmail.com>
> >  > > 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@ant.apache.org
> >  > For additional commands, e-mail: dev-help@ant.apache.org
> >  >
> >  >
> >
> >
> >
> >
> > --
> >  Xavier Hanin - Independent Java Consultant
> >  http://xhab.blogspot.com/
> >  http://ant.apache.org/ivy/
> >  http://www.xoocode.org/
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>


-- 
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

Posted by Peter Reilly <pe...@gmail.com>.
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 <xa...@gmail.com> wrote:
> On Sat, Mar 29, 2008 at 9:55 PM, Stephane Bailliez <sb...@gmail.com>
>  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 <xa...@gmail.com>
>  > > 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@ant.apache.org
>  > For additional commands, e-mail: dev-help@ant.apache.org
>  >
>  >
>
>
>
>
> --
>  Xavier Hanin - Independent Java Consultant
>  http://xhab.blogspot.com/
>  http://ant.apache.org/ivy/
>  http://www.xoocode.org/
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: Fixing some naming inconsistencies in Ivy

Posted by Xavier Hanin <xa...@gmail.com>.
On Sat, Mar 29, 2008 at 9:55 PM, Stephane Bailliez <sb...@gmail.com>
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 <xa...@gmail.com>
> > 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@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>


-- 
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

Posted by Stephane Bailliez <sb...@gmail.com>.
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 <xa...@gmail.com>
> 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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org