Good point.. What keeps catching me on the line formatting is Eclipse.. I get into the habbit of hitting control-F, and while I don't mean to do it with my Turbine code, I occasionally do it.
I am not sure how to do a rollback, but it seems that since your TurbineXmlConfig idea is good, that might be the easiest path? Do you perform a rollback by getting the old code out and rechecking it in? I did think the funny logic on the extension was crummy, but I often don't think about actually adding more classes, although that would be the right way... I will add that as another code "smell" to look for. Eric -----Original Message----- From: Henning P. Schmiedehausen [mailto:[EMAIL PROTECTED] Sent: Saturday, June 07, 2003 4:26 AM To: [EMAIL PROTECTED] Subject: Re: cvs commit: jakarta-turbine-2/src/java/org/apache/turbine/util TurbineConfig.java [EMAIL PROTECTED] writes: Eric, can you please stop reformatting lines without good reason? We agreed to be somehow agnostic to line wrapping as long as they pass through checkstyle without error. As far as I can see, all of these public class Foo implement Bar, Baz { } public class Foo implement Bar, Baz { } public class Foo implement Bar, Baz { } do. This one don't: > -public class TurbineConfig > - implements ServletConfig, ServletContext, Initializable, Disposable > +public class TurbineConfig implements ServletConfig, ServletContext, Initializable, Disposable We are running checkstyle with linewrap == 80. So these lines will now show up. And we're adding unneccesary changes to the code which make it hard to track in the annotation view, who changed what. > - initParams.put(PROPERTIES_PATH_KEY, properties); > + if (properties.toLowerCase().endsWith(".xml")) > + { > + initParams.put(CONFIGURATION_PATH_KEY, properties); > + } > + else > + { > + initParams.put(PROPERTIES_PATH_KEY, properties); > + } > } I actually _hate_ checks like these. They lead to unplasant surprises. What if we get a third kind of configuration? Will we add more checks? Please make a TurbineXmlConfig which is derived from TurbineConfig and accepts an XML file. This shouldn't be too hard. If someone is using the standalone Turbine, he should be able to use the right configuration class. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/ Java, perl, Solaris, Linux, xSP Consulting, Web Services freelance consultant -- Jakarta Turbine Development -- hero for hire --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
