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: [email protected]
For additional commands, e-mail: [email protected]
