Hi Oleg, 2008/12/24, Oleg Gusakov <oleg.subscripti...@gmail.com>:
[SNIP] > I also respect the conventions, but in this particular case the convention > became counter-productive: I externalized all the messages into > Messages.properties file per package and have to modify this file all the > time. Since we are a community, these distortion rules should be discussed firstly on dev@, and not reverting a commit without communications. I don't say your arguments is bad, I just said we need to discuss it firstly. > If this file sits in the src/main/java/... package - it's one mouse click > in Eclipse to open it. If I move it to src/main/resources/.. - it becomes a > multi-click - one has to click as many times as there are members in the > package name, because Eclipse does not respect "flatten packages" preference > for "empty" packages, and folder without java files in it is treated as > "empty". So it's 5-8 code clicks instead on one. You could have the same reasoning about test cases... Maven is IDE independent and if you think you are not productive with Eclipse, let s change your IDE ;) > Again - conventions should promote development, not hinder it, every mouse > click matters. In this particular case I think we should modify the required > convention. We should promote the file system separation for real resources. So, what is a "real" resources for you? Messages.properties is a ResourceBundle ;) > And have a slack where they really are used during development, and > separation makes work harder, without a clear benefit. > > > > Also, I notified that some static final variables are not in upper > > case (ie AbstractAntTask) like defined in [2]. I know that Herv� tried > > to fix them. Could you take care of it in the future? > > > > > I certainly will take care of that in the future. Thanks, you could always run checkstyle to see full errors. > > Finally, I saw that all private variables start with a low line. I > > already used this rule in the past and I like this idea, but Maven > > projects don't use it. > > > > If you think that our convention [2] should be improved feel free to ask > on dev@ > > > > > I agree, will ask on the list. > > I think that being religious about small things is bad - let's respect the > spirit of the convention: being productive. And I don't see how making field I don't agree, the conventions are mainly for the maintenance and allowing devs (like me!) to understand new code more quickly. Let s reread the intro of our convention page: "The reasoning of these styles and conventions is mainly for consistency, readability and maintainability reasons." > visually different hurts - convention does not mandate any style here except > for common sense - name variables not like classes. Our convention is maybe not perfect and incomplete, and could be improve. IMHO we had this non official rule in the past: Maven devs look at existing code to find answers to theirs questions. [SNIP] > But again - let's discuss it. Thanks, the project will be stronger :) Cheers, Vincent
