You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Oleg Gusakov <ol...@gmail.com> on 2008/12/24 19:43:44 UTC
Re: Maven Code Convention
Brian E. Fox wrote:
>> 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.
>>
>
>
>> 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.
>>
>
> Oleg, I don't agree here. Resources belong in src/main/resources and not in java code. We can go round and round about good or bad conventions, but that's the maven convention and we should adhere to it.
>
Let me respectfully disagree: I used to work for a company where I was
responsible for productivity of hundreds of developers. If I would've
introduced a change where they have to do 5 mouse clicks instead of 1 -
I would be out of job the next day.
What I am trying to say - let's not be religious about this: conventions
are created to make life easier, not harder. Messages are clearly part
of the code, if I would have chosen java-based bundles, it wouldn't have
raised any questions. And the fact that I chose .properties does not
change that. It clearly does not lead to separation of purpose -
messages belong with the code and are always loaded into the same
classloader with the classes.
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"? :)
Thanks,
Oleg
Re: Maven Code Convention
Posted by Ralph Goers <ra...@dslextreme.com>.
On Dec 24, 2008, at 10:43 AM, Oleg Gusakov wrote:
>
>
> Brian E. Fox wrote:
>>> 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.
>>>
>>
>>
>>> 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.
>>>
>>
>> Oleg, I don't agree here. Resources belong in src/main/resources
>> and not in java code. We can go round and round about good or bad
>> conventions, but that's the maven convention and we should adhere
>> to it.
>>
> Let me respectfully disagree: I used to work for a company where I
> was responsible for productivity of hundreds of developers. If I
> would've introduced a change where they have to do 5 mouse clicks
> instead of 1 - I would be out of job the next day.
>
> What I am trying to say - let's not be religious about this:
> conventions are created to make life easier, not harder. Messages
> are clearly part of the code, if I would have chosen java-based
> bundles, it wouldn't have raised any questions. And the fact that I
> chose .properties does not change that. It clearly does not lead to
> separation of purpose - messages belong with the code and are always
> loaded into the same classloader with the classes.
>
> 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"? :)
>
>
Sure. That is where everyone is going to look for it and they won't be
able to find it if you don't put it there. I'm in full agreement with
Brian.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Code Convention
Posted by Arnaud HERITIER <ah...@gmail.com>.
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 <ol...@apache.org> wrote:
> Hi,
>
> 2008/12/26 Vincent Siveton <vi...@gmail.com>:
> > Hi Oleg,
> >
> > 2008/12/25, Oleg Gusakov <ol...@gmail.com>:
> >> Vincent Siveton wrote:
> >>
> >> > Hi,
> >> >
> >> > 2008/12/24, Oleg Gusakov <ol...@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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
..........................................................
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
...........................................................
Re: Maven Code Convention
Posted by Olivier Lamy <ol...@apache.org>.
Hi,
2008/12/26 Vincent Siveton <vi...@gmail.com>:
> Hi Oleg,
>
> 2008/12/25, Oleg Gusakov <ol...@gmail.com>:
>> Vincent Siveton wrote:
>>
>> > Hi,
>> >
>> > 2008/12/24, Oleg Gusakov <ol...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Code Convention
Posted by Vincent Siveton <vi...@gmail.com>.
Hi Oleg,
2008/12/25, Oleg Gusakov <ol...@gmail.com>:
> Vincent Siveton wrote:
>
> > Hi,
> >
> > 2008/12/24, Oleg Gusakov <ol...@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...
> 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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Code Convention
Posted by Paul Benedict <pb...@apache.org>.
I use hierarchical mode in Eclipse and it's a blast. I sympathize
towards anyone who feels conventions may slow them down, but Java
Resources shouldn't go into src/main/java because of a tooling
deficiency.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Code Convention
Posted by Oleg Gusakov <ol...@gmail.com>.
Vincent Siveton wrote:
> Hi,
>
> 2008/12/24, Oleg Gusakov <ol...@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 :)
We are selling developer productivity via convention, not convention by
itself. And I am 100% behind this statement: convention goes a long way
to 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.
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?
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.
Cheers,
Oleg
> About benefits, I could cite quality, maintenance, peer review and so on...
>
> Cheers,
>
> Vincent
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
Re: Maven Code Convention
Posted by Vincent Siveton <vi...@gmail.com>.
Hi,
2008/12/24, Oleg Gusakov <ol...@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...
About benefits, I could cite quality, maintenance, peer review and so on...
Cheers,
Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Code Convention
Posted by Oleg Gusakov <ol...@gmail.com>.
Brian E. Fox wrote:
>> Let me respectfully disagree: I used to work for a company where I was
>> responsible for productivity of hundreds of developers. If I would've
>> introduced a change where they have to do 5 mouse clicks instead of 1 -
>> I would be out of job the next day.
>>
>
> Btw, eclipse has tabs, last time I checked it was one click to switch a tab (even a key binding I bet), so really it's irrelevant where it is in terms of how many clicks it takes to edit the file.
>
A tab requires something to be first loaded into it, and - unless you
keep all your files always open, you'll have to navigate to it first. I
tend to keep only related files open and clean the mess from time to
time, so necessity to click through to the messages when i need to
add/modify them by far outweighs any advantages of separation. Which are
yet to materialize in this discussion. The filtering one: honestly - how
many developers filter their messages? And if majority don't - then it's
not a pattern to be automated; I don't argue the filtering of real
property files here. :) ?
Re: Maven Code Convention
Posted by Ralph Goers <ra...@dslextreme.com>.
On Dec 24, 2008, at 10:58 AM, Brian E. Fox wrote:
>> Let me respectfully disagree: I used to work for a company where I
>> was
>> responsible for productivity of hundreds of developers. If I would've
>> introduced a change where they have to do 5 mouse clicks instead of
>> 1 -
>> I would be out of job the next day.
>
> Btw, eclipse has tabs, last time I checked it was one click to
> switch a tab (even a key binding I bet), so really it's irrelevant
> where it is in terms of how many clicks it takes to edit the file.
In IntelliJ it is even less relevant. I can find any file with a quick
lookup.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Maven Code Convention
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
>Let me respectfully disagree: I used to work for a company where I was
>responsible for productivity of hundreds of developers. If I would've
>introduced a change where they have to do 5 mouse clicks instead of 1 -
>I would be out of job the next day.
Btw, eclipse has tabs, last time I checked it was one click to switch a tab (even a key binding I bet), so really it's irrelevant where it is in terms of how many clicks it takes to edit the file.
Re: Maven Code Convention
Posted by Barrie Treloar <ba...@gmail.com>.
On Thu, Dec 25, 2008 at 5:24 AM, Brian E. Fox <br...@reply.infinity.nu> wrote:
>
>>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"? :)
>
> Sure. What if you want to filter it? This is trivial if you have it in resources where it belongs.
>
While I'm not advocating storing this file in src/main/java I have
noticed with maven-eclipse-plugin that if the file was co-located with
the ResourceBundle class then Eclipse has an easier time with Source >
Find Broken Externalized Strings
And I think having a single message bundle makes this task easier too
(as I was getting false positives in 3.3.0 until I merged the bundles)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Maven Code Convention
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
>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"? :)
Sure. What if you want to filter it? This is trivial if you have it in resources where it belongs.