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 c
Hi,
2008/12/26 Vincent Siveton :
> Hi Oleg,
>
> 2008/12/25, Oleg Gusakov :
>> Vincent Siveton wrote:
>>
>> > Hi,
>> >
>> > 2008/12/24, Oleg Gusakov :
>> >
>> > [SNIP]
>> >
>> >
>> >
>> > > Can you name one single reason why moving this file away and creating 6
>> > > additional folders on the way
Hi Oleg,
2008/12/25, Oleg Gusakov :
> Vincent Siveton wrote:
>
> > Hi,
> >
> > 2008/12/24, Oleg Gusakov :
> >
> > [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?
>
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-mai
Vincent Siveton wrote:
Hi,
2008/12/24, Oleg Gusakov :
[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
Benjamin,
Benjamin Bentmann wrote:
Oleg Gusakov wrote:
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,
2008/12/25, Benjamin Bentmann :
> Hm, using either the hierarchical mode in combination with the "Fold empty
> packages" preference or the flat mode in the package explorer works for me
> with Eclipse 3.4.1.
>
> From my experience for flattening to work properly, Eclipse needs to ignore
> the ".s
Hi,
2008/12/24, Oleg Gusakov :
[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
Hi Oleg,
2008/12/24, Oleg Gusakov :
[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
Oleg Gusakov wrote:
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 "fla
I'm working on open-sourcing an annotation-based solution for
externalizing messages. I hope this is an opportunity to get some
quick feedback. Please let me know if I'm out-of-line.
Example Workflow:
Create an interface to hold messages. Annotate the methods with the
text of the default trans
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
On Thu, Dec 25, 2008 at 5:24 AM, Brian E. Fox 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 i
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 n
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
>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
>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 be
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/... p
>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
>c
Vincent,
Vincent Siveton wrote:
Hi,
All Maven subprojects respect (AFAIK) the common directory structure
[1] of Maven. IMHO Maven sell speech is about convention, and Maven
should be the first place where it would be applied. There is nothing
about properties files in our convention [2], but I
20 matches
Mail list logo
