On 08.07.2010 10:30, Marc Guillemot wrote:
Mark Thomas wrote:
...
JavadocType (versionFormat) -> currently 539 failures
Not sure what exactly you are proposing here. Could you clarify?
I mean the format of the @Version JavaDoc tag what Konstantin Kolinko
has started to fix:
http://tomcat.markmail.org/thread/bfry4x5gwbhezo6x
...
Additionally it seems that you pay attention at some warnings emitted by
your IDE. It would be interesting to express these rules as checkstyle
(or whatever) rule that can be checked automatically. Can you list the
Eclipse style warnings you try to fix?
Just the standard Java compiler warnings.
is there an agreement among the committers for that? ;-)
I would be cautious with Eclipse warnings. Some of them don't make sense
(or at least not alone like "Serializable class without
serialVersionUID") and others have pros and cons (like removing the
"else" when the "if" ends with a return)
I agree that coherent code style is only cosmetic in a first time as it
doesn't change the resulting byte code. Nevertheless it makes easier to
concentrate on the important things: the code content, without being
distracted by the form. Therefore it helps to find real problems and
make easier to compare files, apply patches, ...
But it makes it harder to back-port changes. I'm not against cleaning up
the code, we just need to be aware of the consequences of doing so.
Two solutions for easy back ports
1) never make change, neither yet, nor in the future and keep
everything, even if dirty
2) apply clean style rules on all maintained code versions
Of course I prefer (2) ;-)
Not so sure. Often code history is important and you compare older code
revisions to new ones. Big style changes or cleanup makes this hard.
I'm +1 to style cleanup in general, because there are quite some old
files that are ugly and hard to read. But I wonder whether we are maybe
now coming closer to the point, where we will only backport bug fixes
from TC 7 to 6 and 5.5. My impression is, that we did quite some feature
backporting the last months and 6 should really reach feature maturity
now at patch level 28.
If so, it could make sense to only clean up the TC 7 code base.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
