----- Original Message ----- From: "Karney, Steve" <[EMAIL PROTECTED]>
> Personally, I think this is a waste of time. Trying not to step on egos or > insult anyone but, I mean it is configurable as it is and will be if this > change is made. So why bother. Precisely. > *Someone* is going to have to change his/her > modus-operandi if you change this or not. A seemigly harmless change in Ant 1.4.x where debug=false was changed to mean -g:none from -g:lines,source prompted users to ask why their jar files started getting smaller 'suddenly' (as in when they upgraded). If we change this now because of this new request, we would have to field questions like "Why are my jar files bigger in size now - my manager will not let me upgrade unless I find the root cause. Will you please help?" We have made it configurable; we have documented it. So, why bother? > If you want debug code just add an extra line to turn on the feature. > > If the change is made, people who do not want debug code will have to add a > line to turn it Off. > > That being said, what is the cost of making this change to the code base > including all associated testing of the change. I think there are other > issues that could be addressed. > > What is the point? <don't answer that> 8-) > > Just my nickels worth. > > thanks, > -SK > > -----Original Message----- > From: Ken Wood [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 05, 2002 4:24 PM > To: Ant Developers List > Subject: Re: Request: Change <javac> debug default to "on" > > > Rather than debate it, why not ask the folks > on ant-users list to vote for or against the proposed > change in default behavior? > > Us developers are notorious for thinking we know > what the user wants... and being wrong. Why spend > days debating the merits of changing the default when > we can ask the users how they feel? > > Personally, I don't put much merit to any argument that > says we can't make a change because build files would > have to change. > > Every time I switch to a new version of Ant, I'm switching > to take advantage of some new capability. So, I gotta > change my build files anyhow. I just don't buy the 'build > files' argument... > > Joseph Dane wrote: > > > "Magesh Umasankar" <[EMAIL PROTECTED]> writes: > > > > > A change to the existing behavior of <javac> practically > > > means a rewrite of *every* ant build file out there. > > > > Well, maybe if "every" is defined to mean "every buildfile except > > mine", since I do not personally rely on the default behavior, and I > > don't see how this change would force me to change my buildfiles. > > > > > By making this change, we are forcing every build file > > > to be rewritten to retain existing, and in most cases, > > > accepted behavior, when an ant upgrade is made. > > > > Again, "every"? > > > > It has already been demonstrated the javac task *has* changed in > > previous releases of Ant. Where was the widespread confusion and > > panic? > > > > > How is its effectiveness reduced? You can still > > > configure it the way you want it to behave - just > > > because you don't like the default doesn't make it > > > any less effective. > > > > Not to me personally, since I don't rely on the defaults. But the > > intent behind the proposal, at least as I understood it, was to reduce > > confusion in *new* projects and users. I can absoluetly see the > > benefit to this population, and I can't see how they are being served > > by a decision to retain the status quo. > > > > It all boils down to cost/benefit. Clearly, I understated the cost > > with my initial "no brainer" response, but I still think that the > > benefit to the Ant user population (present and future) outweighs the > > cost. > > > > Anyhow, that's my 2c. > > > > -- > > > > joe > > > > -- > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
