Committing ServiceUI

[Mark Brouwer <ma...@cheiron.org>]

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
spaces.
-- 
Mark

Re: Committing ServiceUI

[Mark Brouwer <ma...@cheiron.org>]

Dan Creswell wrote:

>> 1) I propose them to be merged (at least for the time being).
>>
> 
> Why do you want to merge them?  What are the benefits and the costs?
> How might this be linked to how we ship stuff in the future?

Hi Dan,

The code contribution of ServiceUI is only the source and some
package.html files, no build files, no specifications, no test
framework. So if we want to work on them it is probably easier to
include them as part of the source tree of the JTSK. That is for the
benefits ;-) the cost I haven't thought of.

I think you know I'm was all for repackaging the JTSK code as I have
expressed in the past, although there was one blunt remark of Bob that
made me thinking for a while:

"Decomposing the starter kit into a bunch of independent distributions
with independent releases is an utter waste of time and will just
complicate life, IMO. (-17) I'd much rather see our (limited) energy
spent on adding useful fixes and functionality."

And while there will be a day Bob is proven all wrong, I must agree that
at this point in time where we have no certainty about the number of
helping hands I would rather go for the pragmatic approach of just going
forward ASAP without to much work up-front.

So for now I turned to the dark side, but in my opinion I expressed "at
least for the time being". And as an aside, maybe ServiceUI is a good
API to have as part of the Platform haven't made up my mind about that
one yet.
-- 
Mark

Re: Committing ServiceUI

[Dan Creswell <da...@dcrdev.demon.co.uk>]

Mark Brouwer wrote:
> 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).
> 

Why do you want to merge them?  What are the benefits and the costs?
How might this be linked to how we ship stuff in the future?

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

Re: Committing ServiceUI

[Gregg Wonderly <ge...@cox.net>]

Mark Brouwer wrote:
> Gregg Wonderly wrote:
>> If we are going to change to some standard, perhaps it would be best 
>> to find an indentations engine which uses a configuration file, and 
>> then use that to change the indenttation appropriately.  Then, post 
>> that configuration file on the river SVN or somewhere accessible so 
>> that others can run it against their sources and hopefully end up with 
>> a common base from a diffs perspective.
> 

> IMHO extra pre/post processing steps result in more troubles, or it
> should be integrated as part of the build process. I was a long time
> supporter of a commercial indentation program (the free ones well they
> ...) but with each new language feature something changed in a way that
> all the formatting started to change too and even bug-fixes had this
> effect sometimes.
>
> The only thing what works is a simple uniform style, and converting a
> tab to 8 spaces has no effect on the current formatting effective for
> the JTSK code.

I was referring to do this exactly once, using a configuration file that would 
create the proper formatting.  This way, I can take my source base and run it 
through the same engine, and then when I start working on patches, the diff 
results will be the real differences.

And, this means that I could continue to edit with tabs in my source, and use 
the engine to convert to whatever style is used in River to recast my source for 
the purpose of creating diffs.

> BTW Gregg do you or anyone else have an opinion about ServiceUI in the
> same branch as the JTSK, effectively merging the two.

I'm undecided.  From a simple perspective, one source tree is good.  How you 
build that tree into jars and do testing is a separate issue I think.

Gregg Wonderly

Re: Committing ServiceUI

[Mark Brouwer <ma...@cheiron.org>]

Gregg Wonderly wrote:
> Bob Scheifler wrote:
>>> 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.
>>
>>
>> Fine with me.
>>
>>> 2) If we are going to merge we should have a uniform way of dealing with
>>>    indentation otherwise it will get messy.
>>
>>
>> You won't find 100% consistent style within the JTSK code.
>>
>> We should get the initial code in as-is without any changes first.
> 
> I started the discussion about reformatting code, so let me add another 
> thought.  I'm interested in being able to leave my editor configuration 
> in my IDE alone and be able to make changes and get reasonable diffs 
> against the river project.
> 
> If we are going to change to some standard, perhaps it would be best to 
> find an indentations engine which uses a configuration file, and then 
> use that to change the indenttation appropriately.  Then, post that 
> configuration file on the river SVN or somewhere accessible so that 
> others can run it against their sources and hopefully end up with a 
> common base from a diffs perspective.

Hi Gregg,

IMHO extra pre/post processing steps result in more troubles, or it
should be integrated as part of the build process. I was a long time
supporter of a commercial indentation program (the free ones well they
...) but with each new language feature something changed in a way that
all the formatting started to change too and even bug-fixes had this
effect sometimes.

The only thing what works is a simple uniform style, and converting a
tab to 8 spaces has no effect on the current formatting effective for
the JTSK code.

BTW Gregg do you or anyone else have an opinion about ServiceUI in the
same branch as the JTSK, effectively merging the two.
-- 
Mark

Re: Committing ServiceUI

[Gregg Wonderly <gr...@wonderly.org>]

Bob Scheifler wrote:
>> 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.
> 
> 
> Fine with me.
> 
>> 2) If we are going to merge we should have a uniform way of dealing with
>>    indentation otherwise it will get messy.
> 
> 
> You won't find 100% consistent style within the JTSK code.
> 
> We should get the initial code in as-is without any changes first.

I started the discussion about reformatting code, so let me add another thought. 
  I'm interested in being able to leave my editor configuration in my IDE alone 
and be able to make changes and get reasonable diffs against the river project.

If we are going to change to some standard, perhaps it would be best to find an 
indentations engine which uses a configuration file, and then use that to change 
the indenttation appropriately.  Then, post that configuration file on the river 
SVN or somewhere accessible so that others can run it against their sources and 
hopefully end up with a common base from a diffs perspective.

Just a thought...

Gregg Wonderly

Re: Committing ServiceUI

[Mark Brouwer <ma...@cheiron.org>]

Bob Scheifler wrote:

>> Not totally clear from your response is though whether you think we
>> should enforce one policy and what it should be.
> 
> I personally see little value in systematically redoing the style
> of the initial code contributions.  Having an agreed upon style
> is good, but I can't comment on "enforce", not knowing what is meant.

I hope it was clear from my posting that I was only referring to the
indentation aspect of all style aspects there are out there. I think it
is not very hard to change all leading tabs to 8 spaces, it is a rather
trivial operation, especially compared to another large operation we
face in the future (i.e. changing some of the namespaces).

"Enforce" meant what is supposed to mean "to carry out effectively", so
that would mean in a friendly, cooperating community as ours that if we
notice people use tabs where they should use spaces we gently tell them
to stop doing that.
-- 
Mark

Re: Committing ServiceUI

[Bob Scheifler <Bo...@Sun.COM>]

Mark Brouwer wrote:
> I agree as I assume your reason for that is that otherwise it will be
> harder for you, me and others to merge our modifications that have been
> developed against JTSK 2.1 with the current indentations?

More to just generally have the original code in place to verify changes
against, but sure.

> Not totally clear from your response is though whether you think we
> should enforce one policy and what it should be.

I personally see little value in systematically redoing the style
of the initial code contributions.  Having an agreed upon style
is good, but I can't comment on "enforce", not knowing what is meant.

- Bob

Re: Committing ServiceUI

[Mark Brouwer <ma...@cheiron.org>]

Thanks Bob,

Bob Scheifler wrote:

> We should get the initial code in as-is without any changes first.

I agree as I assume your reason for that is that otherwise it will be
harder for you, me and others to merge our modifications that have been
developed against JTSK 2.1 with the current indentations?

Not totally clear from your response is though whether you think we
should enforce one policy and what it should be. Knowing you I don't
dare to infer anything from you mentioning the Utopian 100% consistency
not achieved by the JTSK code ;-)
-- 
Mark

Re: Committing ServiceUI

[Bob Scheifler <Bo...@Sun.COM>]

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

Fine with me.

> 2) If we are going to merge we should have a uniform way of dealing with
>    indentation otherwise it will get messy.

You won't find 100% consistent style within the JTSK code.

We should get the initial code in as-is without any changes first.

- Bob