Yeah I am pretty sure this is normal. There is no feedback but as far as I
know the template does take hold.
On Sun, Aug 29, 2010 at 6:25 PM, Tara Athan wrote:
> I imported formatting.xml at the Windows>preferences>Java>Formatter
> dialog, and that seemed to work OK. At least , the result looks
I imported formatting.xml at the
Windows>preferences>Java>Formatter dialog, and that seemed to
work OK. At least , the result looks similar to the screenshot in the
guide. But in the Windows>preferences>Java>Code Template
dialog, when I import codetemplates.xml, nothing seems to happen.
Tara
There are two files; one for templates and one for formatting.
Jody
On 30/08/2010, at 4:27 AM, Tara Athan wrote:
> I am trying to follow these instructions
> http://docs.codehaus.org/display/GEOT/5.1.1+Coding+Conventions#5.1.1CodingConventions-Eclipse
>
> But after importing codetemplates.xml I
I am trying to follow these instructions
http://docs.codehaus.org/display/GEOT/5.1.1+Coding+Conventions#5.1.1CodingConventions-Eclipse
But after importing codetemplates.xml I still have the default templates.
This is what appears in my codetemplates.xml file
LOGGER.log(Level.FINER, ${exception_va
Jody Garnett ha scritto:
> Daniele Romagnoli wrote:
>> Hi list,
>> some time ago I have noticed that the developers guide suggests to use
>> JALOPY for code formatting.
>> http://docs.codehaus.org/display/GEOT/5.1.1+Coding+Conventions
>>
>> Someone (^_^) told me that Jalopy has been abandoned and
Daniele Romagnoli wrote:
> Hi list,
> some time ago I have noticed that the developers guide suggests to use
> JALOPY for code formatting.
> http://docs.codehaus.org/display/GEOT/5.1.1+Coding+Conventions
>
> Someone (^_^) told me that Jalopy has been abandoned and (with
> eclipse) we should use t
Hi list,
some time ago I have noticed that the developers guide suggests to use
JALOPY for code formatting.
http://docs.codehaus.org/display/GEOT/5.1.1+Coding+Conventions
Someone (^_^) told me that Jalopy has been abandoned and (with eclipse) we
should use the formatting rules available here:
http
Justin Deoliveira wrote:
Yeah i could try and give this a shot in my abundant spare time ;).
The fm branch has really only been out for a couple of weeks. And the
plan is to go like mad to get complex-features onto it and then a
quick easy merge onto main.
But if the test merge goes ok i woul
Yeah i could try and give this a shot in my abundant spare time ;). The
fm branch has really only been out for a couple of weeks. And the plan
is to go like mad to get complex-features onto it and then a quick easy
merge onto main.
But if the test merge goes ok i would be willing to change my
Justin Deoliveira wrote:
Changing vote to -1 until R&D branches come home.
Not sure I want wait, some of the RnD branches are out for a year
already. If you are still changing your vote you may wish to consider an
experiment to check what would happen.
Hmm, after thinking more about this I real
Changing vote to -1 until R&D branches come home.
Hmm, after thinking more about this I realize that I will probably get
screwed if we go forward with formatting now. I think the gain of having
6 months of work come back home smoothly outweighs the need for
consitency at the moment.
I know t
Martin Desruisseaux wrote:
Cory Horner a écrit :
Martin: +1 (if sun convention)
I'm rather hesitant. I need to try on existing code and see what the
result looks like. I'm more confortable with Dave's position (run
Jaloppy for new code).
Understood, but that does not solve my basic problem -
Cory Horner a écrit :
Martin: +1 (if sun convention)
I'm rather hesitant. I need to try on existing code and see what the result looks like. I'm more
confortable with Dave's position (run Jaloppy for new code).
Martin.
---
This SF
Cory Horner wrote:
Justin Deoliveira wrote:
I thought i would trudge through the email and sum up peoples votes on
this issue.
Justin: +1
Jody : +1
Chris: +1
Martin: +1 (if sun convention)
Dave: -1 (+1 for new code)
Cory: +1
+1
---
Justin Deoliveira wrote:
I thought i would trudge through the email and sum up peoples votes on
this issue.
Justin: +1
Jody : +1
Chris: +1
Martin: +1 (if sun convention)
Dave: -1 (+1 for new code)
Cory: +1
---
This SF.Net email is sponso
I thought i would trudge through the email and sum up peoples votes on
this issue.
Jody : +1
Chris: +1
Martin: +1 (if sun convention)
Dave: -1 (+1 for new code)
That is all i could find, I apologize if I missed anyone, please let me
know if i did.
I will take this opportunity to chime in wit
Here's an example (this is where it works):
A -> B -> C -> D
\
\
-> CA -> CB
All the commits are either all jalopied or all not-jalopied. CA/CB are
a branch.
In this case, I can compare A & CB and see the differences. I can also
compare C & CB and see whats
I am a big fan of code formatting, since it gives a consistent feel to
all the code, which to me makes it feel a lot more professional.
The primary complaint that I've heard is that a diff on code that
someone else formatted loses knowledge of what they've actually changed.
What I do in this
Martin Desruisseaux wrote:
Jody Garnett a écrit :
I would like to format up 2.2.x when it is released, and then stick
with it (aka format before every commit like the bad old days).
I have two issues with reformating:
1) We have at least two different coding rules in use. When we talked
about
Jody Garnett a écrit :
I would like to format up 2.2.x when it is released, and then stick with
it (aka format before every commit like the bad old days).
I have two issues with reformating:
1) We have at least two different coding rules in use. When we talked about
coding rule for the
who
Paul Ramsey wrote:
On Mar 10, 2006, at 2:11 PM, Jody Garnett wrote:
I would like to format up 2.2.x when it is released, and then stick
with it (aka format before every commit like the bad old days).
Just to confirm for people, autoformatting would mean that the
workflow would be:
svn
On Mar 10, 2006, at 2:11 PM, Jody Garnett wrote:
I would like to format up 2.2.x when it is released, and then stick
with it (aka format before every commit like the bad old days).
Just to confirm for people, autoformatting would mean that the
workflow would be:
svn update
svn comm
I know this is murder for a topic, but I would like to see us do
something or nothing.
I would like to format up 2.2.x when it is released, and then stick with
it (aka format before every commit like the bad old days).
-or-
I would like us to change our developers guide to agree with actual
p
23 matches
Mail list logo
