My opinion : - We have to follow what we promote (conventions more particularly). - Our conventions can evolve, and we have to ensure that above all, they are improving teams productivity (it's a too important problem in java before others like consistency, readability and maintainability).
My 2 cents Cheers Arnaud On Fri, Dec 26, 2008 at 7:51 PM, Olivier Lamy <[email protected]> wrote: > Hi, > > 2008/12/26 Vincent Siveton <[email protected]>: > > Hi Oleg, > > > > 2008/12/25, Oleg Gusakov <[email protected]>: > >> Vincent Siveton wrote: > >> > >> > Hi, > >> > > >> > 2008/12/24, Oleg Gusakov <[email protected]>: > >> > > >> > [SNIP] > >> > > >> > > >> > > >> > > Can you name one single reason why moving this file away and > creating 6 > >> > > additional folders on the way that would not exist otherwise is > >> beneficial? > >> > > Without using the argument "it's a convention"? :) > >> > > > >> > > > >> > > >> > As said, that is truly what we (Maven and devs) are selling... > >> > > >> > > >> Please regard this as "let's make it better" discussion, not as "I am a > >> smart ass" discussion :) > > > > Sure! As I already said in this thread, our conventions or processes > > could always be improved and I am always happy to participate into > > these kinds of discussions. My point was that we are a community and > > in my mind, if a dev wants to change team's rules or conventions, he > > should explain firstly. My time is counted and yours too (each click > > counts) I can't read under commit messages and I prefer to ask > > directly dev@ with this thread. So we don't play to ping-pong (read > > do-revert-do...) - win win approach. > > > >> We are selling developer productivity via convention, not convention by > >> itself. And I am 100% behind this statement: convention goes a long way > to > > > > Not sure to understand [1] and [2] as you said. > > > >> ensure uniformity, standardization and all the good things you mention > >> below. But the tricky part is that convention is a "best practice" > approach > >> - it does guarantee that following it, developers will be able to spend > less > >> time on routine, mundane tasks and dedicate more time to real creative > work. > > > > Agree but IMHO the Maven project (and sub projects) needs to follow > > the best practises recommended by Maven, but maybe I am the only one > > to think about that... > > No, I agree with you. > IMHO, we have to follow what we recommend ! (I don't really like the > french proverb : "do what I say but don't do what I do" :-)). > Same for the code style, we have defined one too (checkstyle files, > formatters configuration file for ide). > Ok it can be very long to discuss and a very passionate debat ! But we > have convention and this is very important in a team to follow this ! > Everybody in a team must be able to fix as fast as possible in all > projects. And if all projects are different this won't be fast. > I think all is explained here [1]. > > -- > Olivier > > [1] http://maven.apache.org/background/philosophy-of-maven.html > > > > >> In this particular case - I compare the "creativity" of clicking mouse > 8 > >> times instead of one with the advantages the separation gives me. The > real > >> advantage of keeping messages separate would be the ability to ship them > out > >> for translation. > >> > >> But what if I keep messages in Messages.java bundle instead of > >> Messages.properties one? Should these be separated as well - technically > >> they are resources and belong to resource folder? > > > > I guess src/main/java, but good question! > > > >> So I still think it's a moot point, but if people on this list think > that > >> separation is a must, of I will - of cause - follow. > > > > The consensus in this thread seems to follow our conventions, but if > > you want an official response, you could always start a vote about > > rule distortions for mercury. > > > > Cheers, > > > > Vincent > > > > [1] > http://maven.apache.org/guides/getting-started/index.html#What_is_Maven > > [2] > http://maven.apache.org/guides/getting-started/index.html#How_can_Maven_benefit_my_development_process > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- .......................................................... Arnaud HERITIER 12 guidelines to boost your productivity with a Java software factory - http://tinyurl.com/56s9tw .......................................................... OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .......................................................... ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ...........................................................
