river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Brouwer <mark.brou...@cheiron.org>
Subject Committing ServiceUI
Date Mon, 16 Apr 2007 08:48:30 GMT
I assume the source code from Sun is coming in any moment, and I guess 
before actually checking in the ServiceUI code it is a good moment to 
have a discussion about where in SVN we are going to commit the code and 
to have a discussion about ... tabs and indentation.

1) Are we going to put the ServiceUI code in the same branch as the JTSK
    code, effectively merging the JTSK project and the ServiceUI project.

2) If we are going to merge we should have a uniform way of dealing with
    indentation otherwise it will get messy. ServiceUI has an
    indentation of 4 spaces, no usage of tabs. JTSK code has an
    indentation of 4 spaces and tabs are used where there is a multiple
    of 8 leading spaces.

    If both projects are not going to be merged it is doable to continue
    with the styles as they are at this moment, although I'm not in favor
    of that.

My personal opinions are:

1) I propose them to be merged (at least for the time being).

2) We adopt the ServiceUI indentation style for all code as part
    of the Apache River project [1]. I don't want to start the debate
    again but I think there were a few good argument for using spaces
    (it is not my personal style so I'm compromising here too ;-), so
    please don't attack me as being a zealot of this style)

[1] according to the coding conventions of Sun
http://java.sun.com/docs/codeconv/html/CodeConventions.doc3.html#262 the
indentation style of ServiceUI is in line with the Sun conventions as
the conventions state: "Four spaces should be used as the unit of
indentation. The exact construction of the indentation (spaces vs. tabs)
is unspecified. Tabs must be set exactly every 8 spaces (not 4)" so
there is no requirements that a multiple of 8 leading spaces should be
indented with a tab, only that if a tab is used it represents exactly 8

View raw message