Hey all,
I've got two questions.
1) What's up with formatting on trunk? For example, in the geoserver-trunk/pom.xml and geoserver-trunk/web/pom.xml, everything seems pretty funky starting right around line 157. Also in GeoserverDataDirectory.java, there are strangely indented lines floating around. Is there an official policy about formatting? I'd *love* to just hit "ctrl-f" in eclipse and make it all look real pretty, but that makes it impossible for me to use '$svn diff' effectively. Is there something auto-formatting the code that's doing something screwy? Alternatively, is this problem isolated to me? Anyone else have strangely formatted trunk code?
2) I've found a couple of bugs on the trunk.
For example, in GeoserverDataDirectory.java on lines 75 and 86 there are a pair of if-clauses which check for data directory over-ride information. In both of these if-clauses control returns from the method before the 'locator' static object has been initialized. I added the line:
loader = new GeoServerResourceLoader( dataDir );
right before the 'return dataDir' calls on 92 and 81 and my problems with using -DGEOSERVER_DATA_DIR=... were fixed. What's the etiquette for committing these kinds of fixes? I'm guessing that for a fix such as the above, a message to the list might be enough. For something more major, clearly some kind of consensus needs to be reached. Am I in the right ballpark?
Thanks,
--saul
Hi Saul
1) Some formatting is wonky and really hard to read, other formatting is wonky but readable. I would say fix up the unreadable code if you need. I guess that now we are switching to 1.4 (trunk) it could be a good time for auto formatting. I will bring it up in the meeting.
2) Just send the patch to a comitter (me if you want) and we will look at it, test it, and put it in. And give you a "thanks" =)
Brent Owens
(The Open Planning Project)
Saul Farber wrote:
Hey all,
I've got two questions.
1) What's up with formatting on trunk? For example, in the geoserver-trunk/pom.xml and geoserver-trunk/web/pom.xml, everything seems pretty funky starting right around line 157. Also in GeoserverDataDirectory.java, there are strangely indented lines floating around. Is there an official policy about formatting? I'd *love* to just hit "ctrl-f" in eclipse and make it all look real pretty, but that makes it impossible for me to use '$svn diff' effectively. Is there something auto-formatting the code that's doing something screwy? Alternatively, is this problem isolated to me? Anyone else have strangely formatted trunk code?
2) I've found a couple of bugs on the trunk.
For example, in GeoserverDataDirectory.java on lines 75 and 86 there are a pair of if-clauses which check for data directory over-ride information. In both of these if-clauses control returns from the method before the 'locator' static object has been initialized. I added the line:
loader = new GeoServerResourceLoader( dataDir );
right before the 'return dataDir' calls on 92 and 81 and my problems with using -DGEOSERVER_DATA_DIR=... were fixed. What's the etiquette for committing these kinds of fixes? I'm guessing that for a fix such as the above, a message to the list might be enough. For something more major, clearly some kind of consensus needs to be reached. Am I in the right ballpark?
Thanks,
--saul
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Saul Farber wrote:
Hey all,
I've got two questions.
1) What's up with formatting on trunk? For example, in the geoserver-trunk/pom.xml and geoserver-trunk/web/pom.xml, everything seems pretty funky starting right around line 157. Also in GeoserverDataDirectory.java, there are strangely indented lines floating around. Is there an official policy about formatting? I'd *love* to just hit "ctrl-f" in eclipse and make it all look real pretty, but that makes it impossible for me to use '$svn diff' effectively. Is there something auto-formatting the code that's doing something screwy? Alternatively, is this problem isolated to me? Anyone else have strangely formatted trunk code?
Yes! I would be in full support of automated code formatting. We could do something similar to geotools and have it run as part of the maven build.
2) I've found a couple of bugs on the trunk.
For example, in GeoserverDataDirectory.java on lines 75 and 86 there are a pair of if-clauses which check for data directory over-ride information. In both of these if-clauses control returns from the method before the 'locator' static object has been initialized. I added the line:
loader = new GeoServerResourceLoader( dataDir );
right before the 'return dataDir' calls on 92 and 81 and my problems with using -DGEOSERVER_DATA_DIR=... were fixed. What's the etiquette for committing these kinds of fixes? I'm guessing that for a fix such as the above, a message to the list might be enough. For something more major, clearly some kind of consensus needs to be reached. Am I in the right ballpark?
I changed this recently, the fix sounds straight forward. You can throw it in jira if you want as a 1.4.0 fix as it is a pretty cruicial one.
-Justin
Thanks,
--saul
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:1004,44ce372f80361425493344!
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
Justin Deoliveira wrote:
Saul Farber wrote:
Hey all,
I've got two questions.
1) What's up with formatting on trunk? For example, in the geoserver-trunk/pom.xml and geoserver-trunk/web/pom.xml, everything seems pretty funky starting right around line 157. Also in GeoserverDataDirectory.java, there are strangely indented lines floating around. Is there an official policy about formatting? I'd *love* to just hit "ctrl-f" in eclipse and make it all look real pretty, but that makes it impossible for me to use '$svn diff' effectively. Is there something auto-formatting the code that's doing something screwy? Alternatively, is this problem isolated to me? Anyone else have strangely formatted trunk code?
Yes! I would be in full support of automated code formatting. We could do something similar to geotools and have it run as part of the maven build.
2) I've found a couple of bugs on the trunk.
For example, in GeoserverDataDirectory.java on lines 75 and 86 there are a pair of if-clauses which check for data directory over-ride information. In both of these if-clauses control returns from the method before the 'locator' static object has been initialized. I added the line:
loader = new GeoServerResourceLoader( dataDir );
right before the 'return dataDir' calls on 92 and 81 and my problems with using -DGEOSERVER_DATA_DIR=... were fixed. What's the etiquette for committing these kinds of fixes? I'm guessing that for a fix such as the above, a message to the list might be enough. For something more major, clearly some kind of consensus needs to be reached. Am I in the right ballpark?
I changed this recently, the fix sounds straight forward. You can throw it in jira if you want as a 1.4.0 fix as it is a pretty cruicial one.
Well, Saul has commit right now, so he can just do it. The etiquette is to send a mail to the list and then just commit. If JIRA helps you out, like if there's some bug you discover but don't have a chance to fix yet, then put it in JIRA. I try to put as much as possible in JIRA, but skip it when it's small and it'd just be a pain. But JIRA also automatically sends an email to the list, so you can report there in lieu of sending an email. And when we've got two branches going, be sure to make the fix on trunk and stable branch.
best regards,
Chris
-Justin
Thanks,
--saul
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
I can do one better, here is an improvement proposal.
http://docs.codehaus.org/display/GEOS/GSIP+2+-+Automated+Code+Formatting
-Justin
Andrea Aime wrote:
Justin Deoliveira ha scritto:
Saul Farber wrote:
Hey all,
I've got two questions.
1) What's up with formatting on trunk? For example, in the geoserver-trunk/pom.xml and geoserver-trunk/web/pom.xml, everything seems pretty funky starting right around line 157. Also in GeoserverDataDirectory.java, there are strangely indented lines floating around. Is there an official policy about formatting? I'd *love* to just hit "ctrl-f" in eclipse and make it all look real pretty, but that makes it impossible for me to use '$svn diff' effectively. Is there something auto-formatting the code that's doing something screwy? Alternatively, is this problem isolated to me? Anyone else have strangely formatted trunk code?
Yes! I would be in full support of automated code formatting. We could do something similar to geotools and have it run as part of the maven build.
2) I've found a couple of bugs on the trunk.
Heh, +1. Where is the rest of the PSC?
This is something that needs to be voted.
Cheers
Andrea
!DSPAM:1004,44ceff9f141731804284693!
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
Justin Deoliveira ha scritto:
I can do one better, here is an improvement proposal.
http://docs.codehaus.org/display/GEOS/GSIP+2+-+Automated+Code+Formatting
The proposal should contain also what kind of coding convention you
would like to enforce.
Here is my suggestion: plain old java formatting rules 
Personally I'd like to see the code wrapped at 100 columns instead of 80,
but that's just me.
Moreover, we must turn off jalopy javadoc comment formatter since it breaks
as soon as the html is the comment is invalid with nasty error messages (aka,
difficult to say what was wrong).
In parallel, I'd say we should dump an Eclipse code formatting template so
that developers can format also without the build (I'm assuming the most of
us are using Eclipse, feel free to dump settings for other ide too).
Cheers
Andrea
Andrea Aime wrote:
I have added your suggestions to the page; I would like to see the complete package covered in this proposal:
- jalopy settings configured as you suggest (attached to page?)
- eclipse formating.xml (attached to page?)
- plan to update the developers documentation
Perhaps producing and attaching the files is too much for just a proposal, we are probably just seeking the go ahead. I assume when
accepted the proposal would be tracked by Jira? Or would we like to produce a jira for a feature request, have it go through proposal, and marked
WONT FIX, or IN PROGRESS depending?
(Perhaps these details are in Chris Holmes email + pages I still need to read)
Jody
Justin Deoliveira ha scritto:
I can do one better, here is an improvement proposal.
http://docs.codehaus.org/display/GEOS/GSIP+2+-+Automated+Code+Formatting
The proposal should contain also what kind of coding convention you
would like to enforce.
Here is my suggestion: plain old java formatting rules
Personally I'd like to see the code wrapped at 100 columns instead of 80,
but that's just me.
Moreover, we must turn off jalopy javadoc comment formatter since it breaks
as soon as the html is the comment is invalid with nasty error messages (aka,
difficult to say what was wrong).
In parallel, I'd say we should dump an Eclipse code formatting template so
that developers can format also without the build (I'm assuming the most of
us are using Eclipse, feel free to dump settings for other ide too).
Cheers
Andrea
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
agreed, 80 columns will drive people nuts. Please, 100 minimum.
I like your idea Andrea about also having an eclipse formatter
Brent Owens
(The Open Planning Project)
Andrea Aime wrote:
Justin Deoliveira ha scritto:
I can do one better, here is an improvement proposal.
http://docs.codehaus.org/display/GEOS/GSIP+2+-+Automated+Code+Formatting
The proposal should contain also what kind of coding convention you
would like to enforce.
Here is my suggestion: plain old java formatting rules
Personally I'd like to see the code wrapped at 100 columns instead of 80,
but that's just me.
Moreover, we must turn off jalopy javadoc comment formatter since it breaks
as soon as the html is the comment is invalid with nasty error messages (aka,
difficult to say what was wrong).
In parallel, I'd say we should dump an Eclipse code formatting template so
that developers can format also without the build (I'm assuming the most of
us are using Eclipse, feel free to dump settings for other ide too).
Cheers
Andrea
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Yeah, I'm for 100 to. Go ahead and put it on the proposal.
Note that we need to pass GSIP 1 before we can vote on GSIP 2.
Brent Owens wrote:
agreed, 80 columns will drive people nuts. Please, 100 minimum.
I like your idea Andrea about also having an eclipse formatter
Brent Owens
(The Open Planning Project)
Andrea Aime wrote:
Justin Deoliveira ha scritto:
I can do one better, here is an improvement proposal.
http://docs.codehaus.org/display/GEOS/GSIP+2+-+Automated+Code+Formatting
The proposal should contain also what kind of coding convention you
would like to enforce.
Here is my suggestion: plain old java formatting rules
Personally I'd like to see the code wrapped at 100 columns instead of 80,
but that's just me.
Moreover, we must turn off jalopy javadoc comment formatter since it breaks
as soon as the html is the comment is invalid with nasty error messages (aka,
difficult to say what was wrong).
In parallel, I'd say we should dump an Eclipse code formatting template so
that developers can format also without the build (I'm assuming the most of
us are using Eclipse, feel free to dump settings for other ide too).
Cheers
Andrea
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:1003,44d0bb10289551410093335!
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org