[Geoserver-devel] Jalopy still formatting whole source tree on build

GeoServer GeoServer Developer
1

Hey all,

So on my local GS 1.5.x tree jalopy is still formatting everything whenever I do a "clean install".

I believe this is because in the *module* poms, the following XML appears:

      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>jalopy-maven-plugin</artifactId>
        <executions>
          <execution>
            <goals>
              <goal>format</goal>
            </goals>
            <phase>install</phase>
          </execution>
        </executions>
      </plugin>

When I remove this code from the validation/pom.xml (for example) a 'clean install' does not format the source tree. A 'clean jalopy:format install' *does* do the formatting.

I seem to remember that jalopy formatting was supposed to be on the shoulders of a committer to run right before commit...did I miss some emails that changed this?

In any case, if it *is* supposed to fall to the personal responsibility of the committer, I suggest removing these lines from the module poms.

Assuming that's a desired goal, I'm happy to do this work.

--saul

2

Farber, Saul (ENV) ha scritto:

Hey all,

So on my local GS 1.5.x tree jalopy is still formatting everything
whenever I do a "clean install".

I seem to remember that jalopy formatting was supposed to be on the
shoulders of a committer to run right before commit...did I miss some
emails that changed this?

Well, the original intention of GSIP #2 was to have it automatic.
We had issues, so on the first implementation we disabled it.
Since now issues seems to be solved, it's back to being automatic.

This has been discussed in a IRC meeting, if my memory serves me
well, last week.

This ensures code is always properly formatted. We do believe otherwise
no one will use it. There is enough proof in the fact that in the
timeframe jalopy was available, almost no formatting took place,
and when we run it automatically, the first times it formatted
some hundreds of files.

We hope to keep a readable code base like this. If this cause you
any trouble, let us know.

Cheers
Andrea

3

FYI, due to problems with formatting in my environment I am figuring out
a way to turn off formatting in a maven settings.xml file. So if you
want saul you can use that to turn off default formatting if it is
causing issues for you. I will let you know when i am complete.

Andrea Aime wrote:

Farber, Saul (ENV) ha scritto:

Hey all,

So on my local GS 1.5.x tree jalopy is still formatting everything
whenever I do a "clean install".

I seem to remember that jalopy formatting was supposed to be on the
shoulders of a committer to run right before commit...did I miss some
emails that changed this?

Well, the original intention of GSIP #2 was to have it automatic.
We had issues, so on the first implementation we disabled it.
Since now issues seems to be solved, it's back to being automatic.

This has been discussed in a IRC meeting, if my memory serves me
well, last week.

This ensures code is always properly formatted. We do believe otherwise
no one will use it. There is enough proof in the fact that in the
timeframe jalopy was available, almost no formatting took place,
and when we run it automatically, the first times it formatted
some hundreds of files.

We hope to keep a readable code base like this. If this cause you
any trouble, let us know.

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

!DSPAM:1004,45de138e73861527717022!

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

4

Thanks andrea! clearly I have to do better about keeping up with the GS and GT IRC meetings.

The problems I'm having are that the first time jalopy is run on my freshly checked out source tree a number of files are formatted, and all the changes are either whitespace changes (not really a problem actually!) or foreign character changes (possibly a problem).

Here's an example:

$ svn diff src/main/java/org/vfny/geoserver/global/dto/LegendURLDTO.java
Index: src/main/java/org/vfny/geoserver/global/dto/LegendURLDTO.java

--- src/main/java/org/vfny/geoserver/global/dto/LegendURLDTO.java (revision 6210)
+++ src/main/java/org/vfny/geoserver/global/dto/LegendURLDTO.java (working copy)
@@ -12,7 +12,7 @@
  * legend.setWidth(72);legend.setHeight(72);legend.setFormat("image/png");
  * </code> </pre></p>
  *
- * @author Charles Kolbowicz, Institut de Recherche pour le D?veloppement
+ * @author Charles Kolbowicz, Institut de Recherche pour le D?veloppement
  * (IRD), 2004
  * @version $Id$
  */

So is the foreign character change there valid? Am I messing up someone else's character set by my probably not well-internationalized computer doing some formatting on someone's accent egue? (or is it an accent grave?)

One more question: There's a short-term problem here in that until every file has been jalopied once, my first compile will polute my project-wide 'svn diff' with a bunch of spurious diffs. As I come across these 'not-yet-jalopied' files should I commit them unchanged (except for the jalopying)?

For example, after a 'clean install' on a fresh checkout with no changes, I get the following:

$ svn diff | grep -v pom.xml | grep Index:
Index: test/src/test/java/org/vfny/geoserver/wms/responses/map/kml/KMLWriterTest.java
Index: main/src/main/java/org/vfny/geoserver/global/dto/LegendURLDTO.java
Index: main/src/main/java/org/vfny/geoserver/global/GlobalLayerSupertype.java
Index: main/src/main/java/org/vfny/geoserver/global/GeoServerFeatureLocking.java
Index: main/src/main/java/org/vfny/geoserver/config/CoverageConfig.java
Index: main/src/main/java/org/vfny/geoserver/ExceptionHandler.java
Index: main/src/main/java/org/vfny/geoserver/util/SLDValidator.java
Index: main/src/main/java/org/mortbay/start/Classpath.java
Index: wms/src/main/java/org/vfny/geoserver/wms/responses/map/kml/KMLWriter.java
Index: wcs/src/main/java/org/vfny/geoserver/wcs/requests/readers/DescribeKvpReader.java
Index: web/src/main/java/org/vfny/geoserver/config/web/tiles/taglib/ExtResInsertTag.java
Index: web/src/main/java/org/vfny/geoserver/action/ConfigAction.java
Index: web/src/main/java/org/vfny/geoserver/action/HTMLEncoder.java
Index: web/src/main/java/org/vfny/geoserver/action/validation/ValidationRunnable.java

Should I commit these slightly-formatted files?

Just curious about policy!

--saul

-----Original Message-----
From: Andrea Aime [mailto:aaime@anonymised.com]
Sent: Thu 2/22/2007 4:58 PM
To: Farber, Saul (ENV)
Cc: geoserver-devel@lists.sourceforge.net
Subject: Re: [Geoserver-devel] Jalopy still formatting whole source tree on build

Farber, Saul (ENV) ha scritto:

Hey all,

So on my local GS 1.5.x tree jalopy is still formatting everything
whenever I do a "clean install".

I seem to remember that jalopy formatting was supposed to be on the
shoulders of a committer to run right before commit...did I miss some
emails that changed this?

Well, the original intention of GSIP #2 was to have it automatic.
We had issues, so on the first implementation we disabled it.
Since now issues seems to be solved, it's back to being automatic.

This has been discussed in a IRC meeting, if my memory serves me
well, last week.

This ensures code is always properly formatted. We do believe otherwise
no one will use it. There is enough proof in the fact that in the
timeframe jalopy was available, almost no formatting took place,
and when we run it automatically, the first times it formatted
some hundreds of files.

We hope to keep a readable code base like this. If this cause you
any trouble, let us know.

Cheers
Andrea

5

Looks like you are having the same problem as I am Saul with the foreign
character ( thank goodness it isn't just me!! ).

Thinking about it I am tempted to say the culprit is the recent
subversion property changes. A couple of reasons make me think so:

1. The problem started occurring around the same time the property
changes were made
2. The problem occurred on my box and the build server at the same time
3. I have no problems formatting geotools source code, just geoserver.

-Justin

Farber, Saul (ENV) wrote:

Thanks andrea! clearly I have to do better about keeping up with the GS and GT IRC meetings.

The problems I'm having are that the first time jalopy is run on my freshly checked out source tree a number of files are formatted, and all the changes are either whitespace changes (not really a problem actually!) or foreign character changes (possibly a problem).

Here's an example:

$ svn diff src/main/java/org/vfny/geoserver/global/dto/LegendURLDTO.java
Index: src/main/java/org/vfny/geoserver/global/dto/LegendURLDTO.java

--- src/main/java/org/vfny/geoserver/global/dto/LegendURLDTO.java (revision 6210)
+++ src/main/java/org/vfny/geoserver/global/dto/LegendURLDTO.java (working copy)
@@ -12,7 +12,7 @@
  * legend.setWidth(72);legend.setHeight(72);legend.setFormat("image/png");
  * </code> </pre></p>
  *
- * @author Charles Kolbowicz, Institut de Recherche pour le D?veloppement
+ * @author Charles Kolbowicz, Institut de Recherche pour le D?veloppement
  * (IRD), 2004
  * @version $Id$
  */

So is the foreign character change there valid? Am I messing up someone else's character set by my probably not well-internationalized computer doing some formatting on someone's accent egue? (or is it an accent grave?)

One more question: There's a short-term problem here in that until every file has been jalopied once, my first compile will polute my project-wide 'svn diff' with a bunch of spurious diffs. As I come across these 'not-yet-jalopied' files should I commit them unchanged (except for the jalopying)?

For example, after a 'clean install' on a fresh checkout with no changes, I get the following:

$ svn diff | grep -v pom.xml | grep Index:
Index: test/src/test/java/org/vfny/geoserver/wms/responses/map/kml/KMLWriterTest.java
Index: main/src/main/java/org/vfny/geoserver/global/dto/LegendURLDTO.java
Index: main/src/main/java/org/vfny/geoserver/global/GlobalLayerSupertype.java
Index: main/src/main/java/org/vfny/geoserver/global/GeoServerFeatureLocking.java
Index: main/src/main/java/org/vfny/geoserver/config/CoverageConfig.java
Index: main/src/main/java/org/vfny/geoserver/ExceptionHandler.java
Index: main/src/main/java/org/vfny/geoserver/util/SLDValidator.java
Index: main/src/main/java/org/mortbay/start/Classpath.java
Index: wms/src/main/java/org/vfny/geoserver/wms/responses/map/kml/KMLWriter.java
Index: wcs/src/main/java/org/vfny/geoserver/wcs/requests/readers/DescribeKvpReader.java
Index: web/src/main/java/org/vfny/geoserver/config/web/tiles/taglib/ExtResInsertTag.java
Index: web/src/main/java/org/vfny/geoserver/action/ConfigAction.java
Index: web/src/main/java/org/vfny/geoserver/action/HTMLEncoder.java
Index: web/src/main/java/org/vfny/geoserver/action/validation/ValidationRunnable.java

Should I commit these slightly-formatted files?

Just curious about policy!

--saul

-----Original Message-----
From: Andrea Aime [mailto:aaime@anonymised.com]
Sent: Thu 2/22/2007 4:58 PM
To: Farber, Saul (ENV)
Cc: geoserver-devel@lists.sourceforge.net
Subject: Re: [Geoserver-devel] Jalopy still formatting whole source tree on build

Farber, Saul (ENV) ha scritto:

Hey all,

So on my local GS 1.5.x tree jalopy is still formatting everything
whenever I do a "clean install".

I seem to remember that jalopy formatting was supposed to be on the
shoulders of a committer to run right before commit...did I miss some
emails that changed this?

Well, the original intention of GSIP #2 was to have it automatic.
We had issues, so on the first implementation we disabled it.
Since now issues seems to be solved, it's back to being automatic.

This has been discussed in a IRC meeting, if my memory serves me
well, last week.

This ensures code is always properly formatted. We do believe otherwise
no one will use it. There is enough proof in the fact that in the
timeframe jalopy was available, almost no formatting took place,
and when we run it automatically, the first times it formatted
some hundreds of files.

We hope to keep a readable code base like this. If this cause you
any trouble, let us know.

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

!DSPAM:1004,45de1a0780769771116852!

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

6

Justin Deoliveira ha scritto:

Looks like you are having the same problem as I am Saul with the foreign
character ( thank goodness it isn't just me!! ).

Thinking about it I am tempted to say the culprit is the recent
subversion property changes. A couple of reasons make me think so:

1. The problem started occurring around the same time the property
changes were made
2. The problem occurred on my box and the build server at the same time
3. I have no problems formatting geotools source code, just geoserver.

The plot thickens. I'm wondering why a simple change such as native eol enforcing
can wreak havoc in charset management.
I'm cc'ing Martin since I've seen some commits of him on the gt2 svn that
were indeed svn property changes.
Martin, do you have any idea why Jalopy is screwing up formatting, and
replacing weird chars in place of é, é, ù and the like after I enforced
a svn:eol-style=native and the proper mime type on java files?

Cheers
Andrea

7

aaime a écrit :

Martin, do you have any idea why Jalopy is screwing up formatting, and
replacing weird chars in place of é, é, ù and the like after I enforced
a svn:eol-style=native and the proper mime type on java files?

I don't know. Usually the weird chars are caused by an encoding mismatch. They
happen when our source code is encoded in ISO-LATIN-1 while the tools (Jaloppy,
Eclipse, NetBeans, etc...) believe that it is UTF-8. The other way around (UTF-8
encoding while the tools believe ISO-LATIN-1) do not corrupt the files.

Most today Linux distribution use UTF-8 by default. Maybe for some reason
Jaloppy processed the Java source file as a kind of "binary" (I means a text
file with unknown properties like encoding) before the mime-type was set to
"text/plain", and as a text using the platform default encoding after the SVN
property was set? I really don't know how it could be, I'm just making some guess.

Maybe there is probably some place in Jaloppy configuration where we can specify
the encoding, so we should set it to ISO-LATIN-1.

Alternatively, we could switch all Geotools or Geoserver code base to UTF-8.
There is a tools on Linux doing exactly that (forgot the name, but I can search
for the command). Because UTF-8 is becoming the default on an increasing number
of stations, it may be a wise move to do soon or later anyway. If there is a PMC
vote for that, I can handle this move on the Geotools code base.

  Martin

8

...
Alternatively, we could switch all Geotools or Geoserver code base to
UTF-8. There is a tools on Linux doing exactly that (forgot the name, but I
can search for the command).

recode UTF-8 filename

Because UTF-8 is becoming the default on an
increasing number of stations, it may be a wise move to do soon or later
anyway. If there is a PMC vote for that, I can handle this move on the
Geotools code base.

note recoding the files to utf-8 will not fix the already weird up characters
but at least will let the codebase in a common encoding. I guess we'll alse
have to warn people to set its editor to utf-8 if it is not their default
(eclipse takes the system one by default)

it seems a reasonable approach though to ensure nobody's system locale
settings messes up the files.

Gabriel

  Martin

-------------------------------------------------------------------------
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