Hi, 2008/12/26 Vincent Siveton <vincent.sive...@gmail.com>: > Hi Oleg, > > 2008/12/25, Oleg Gusakov <oleg.subscripti...@gmail.com>: >> Vincent Siveton wrote: >> >> > Hi, >> > >> > 2008/12/24, Oleg Gusakov <oleg.subscripti...@gmail.com>: >> > >> > [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: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
