Hey all,
So I'm fixing a bug in the TextFeatureInfoResponse class, and I noticed that the class was very poorly formatted. Mis-indentations, etc. I was in an anal mood, so I created an eclipse template file for formatting geoserver code, and figure that folks who were:
* Using eclipse
* Bothered by bad code formatting/indentation
might be willing to fix a file or two using the template.
Is this an ok thing to do, in the absence of a full jalopy-based code-formatting maven-integrated system? It's a little one-off-ish, but at least it lets people do this to scratch their itches and not force a big change on the whole codebase all at once.
Heck, if everyone using eclipse just formats classes as they bugfix them, we'd be done in a month. No jalopy required!
So I have two real questions:
1) Should I commit this geoserver-eclipse-format.xml file?
2) Should I commit a formatted version of TextFeatureInfoResponse.java (and should I continue to commit formatted class files in the future?) Clearly the format commit and the bugfix commit will be separate commits.
--saul
I would like to have the file, even if just attached to a wiki page.
Jody
Hey all,
So I'm fixing a bug in the TextFeatureInfoResponse class, and I noticed that the class was very poorly formatted. Mis-indentations, etc. I was in an anal mood, so I created an eclipse template file for formatting geoserver code, and figure that folks who were:
* Using eclipse
* Bothered by bad code formatting/indentation
might be willing to fix a file or two using the template.
Is this an ok thing to do, in the absence of a full jalopy-based code-formatting maven-integrated system? It's a little one-off-ish, but at least it lets people do this to scratch their itches and not force a big change on the whole codebase all at once.
Heck, if everyone using eclipse just formats classes as they bugfix them, we'd be done in a month. No jalopy required!
So I have two real questions:
1) Should I commit this geoserver-eclipse-format.xml file?
2) Should I commit a formatted version of TextFeatureInfoResponse.java (and should I continue to commit formatted class files in the future?) Clearly the format commit and the bugfix commit will be separate commits.
--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
I would be all for any type of formatting. The only issue I have with
formatting is that it kind of throws people who are on a branch off.
When they go to merge back in they will undoubtedly end up with a huge
number of conflicts.
Right now, I think the ows4 branch is the only branch that is really out
of sync with trunk. And that branch wont really be svn mergable back
anyways.
The eclipse template could work but I think I would be more for jalopy
integrated into the build system.
-Justin
Saul Farber wrote:
Hey all,
So I'm fixing a bug in the TextFeatureInfoResponse class, and I noticed
that the class was very poorly formatted. Mis-indentations, etc. I was
in an anal mood, so I created an eclipse template file for formatting
geoserver code, and figure that folks who were:
* Using eclipse
* Bothered by bad code formatting/indentation
might be willing to fix a file or two using the template.
Is this an ok thing to do, in the absence of a full jalopy-based
code-formatting maven-integrated system? It's a little one-off-ish, but
at least it lets people do this to scratch their itches and not force a
big change on the whole codebase all at once.
Heck, if everyone using eclipse just formats classes as they bugfix
them, we'd be done in a month. No jalopy required!
So I have two real questions:
1) Should I commit this geoserver-eclipse-format.xml file?
2) Should I commit a formatted version of TextFeatureInfoResponse.java
(and should I continue to commit formatted class files in the future?)
Clearly the format commit and the bugfix commit will be separate commits.
--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,4586d3a874521336712104!
--
Justin Deoliveira
jdeolive@anonymised.com
The Open Planning Project
http://topp.openplans.org
I think we have some netbeans users too. Any way to port the formatting over to that IDE?
Brent Owens
(The Open Planning Project)
Justin Deoliveira wrote:
I would be all for any type of formatting. The only issue I have with
formatting is that it kind of throws people who are on a branch off.
When they go to merge back in they will undoubtedly end up with a huge
number of conflicts.
Right now, I think the ows4 branch is the only branch that is really out
of sync with trunk. And that branch wont really be svn mergable back
anyways.
The eclipse template could work but I think I would be more for jalopy
integrated into the build system.
-Justin
Saul Farber wrote:
Hey all,
So I'm fixing a bug in the TextFeatureInfoResponse class, and I noticed that the class was very poorly formatted. Mis-indentations, etc. I was in an anal mood, so I created an eclipse template file for formatting geoserver code, and figure that folks who were:
* Using eclipse
* Bothered by bad code formatting/indentation
might be willing to fix a file or two using the template.
Is this an ok thing to do, in the absence of a full jalopy-based code-formatting maven-integrated system? It's a little one-off-ish, but at least it lets people do this to scratch their itches and not force a big change on the whole codebase all at once.
Heck, if everyone using eclipse just formats classes as they bugfix them, we'd be done in a month. No jalopy required!
So I have two real questions:
1) Should I commit this geoserver-eclipse-format.xml file?
2) Should I commit a formatted version of TextFeatureInfoResponse.java (and should I continue to commit formatted class files in the future?) Clearly the format commit and the bugfix commit will be separate commits.
--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,4586d3a874521336712104!
I've attached it to the GSIP #2 wiki page.
Here: http://docs.codehaus.org/download/attachments/59203/geoserver-eclipse-format.xml
--saul
Jody Garnett wrote:
I would like to have the file, even if just attached to a wiki page.
Jody
Saul Farber ha scritto:
Hey all,
So I'm fixing a bug in the TextFeatureInfoResponse class, and I noticed that the class was very poorly formatted. Mis-indentations, etc. I was in an anal mood, so I created an eclipse template file for formatting geoserver code, and figure that folks who were:
* Using eclipse
* Bothered by bad code formatting/indentation
might be willing to fix a file or two using the template.
Is this an ok thing to do, in the absence of a full jalopy-based code-formatting maven-integrated system? It's a little one-off-ish, but at least it lets people do this to scratch their itches and not force a
I've just committed the jalopy formatter support into 1.4.x (just to try
it out).
Unfortunately it breaks every time it tries to format the WFS module with a null pointer exception. I've already seen this in the past,
some little glitches in javadoc comments and jalopy breaks to pieces...
Sob... Marco Hunsiker told me months ago that the new commercial
version would have had a special license for open source projects,
I've written again to him lately but got no answer...
Anyways, for anybody willing to try it out, first go into the maven
module and build it, then use mvn jalopy:format on whatever module
you like.
If we can't solve issues in a few days I'm simply going to remove
the jalopy support again. In fact I guess all current geoserver
developers do use eclipse at the moment, so I'm not going to hang
myself on this.
Cheers
Andrea