Injecting new life into Spring Rich Client

[LievenDoclo]

As you may have noticed, there has been little activity on Spring Rich Client. This is caused by many factors (mainly time related), but the engine is starting once again.

There are some things that are on the agenda:
- move away from SourceForge. SF has been our home since the beginning, but now it's becoming a burden (and a really slow one at that). Options on the table are moving to Google Code or GitHub, or finding a benefactor willing to give us a VPS to set up our own hosting (which would be great, yet slightly wishful thinking).
- migrate to Spring 3.0
- create a nice demo app

Some people have contacted me regarding becoming a developer on the project, which is great. Once we finished the move to our new home, wherever that may be, I'll contact each of them to get them on board.

It also seems that a lot of companies out there are using Spring Rich Client, more that we could've hoped for. As a complement to our effort: if you're using SRC, and you're happy with it, please send in a testimonial or feedback. Or even better, send in improvements (of which I'm sure there are).

[rdawes]

As you may have noticed, there has been little activity on Spring Rich Client. This is caused by many factors (mainly time related), but the engine is starting once again.

There are some things that are on the agenda:
- move away from SourceForge. SF has been our home since the beginning, but now it's becoming a burden (and a really slow one at that). Options on the table are moving to Google Code or GitHub, or finding a benefactor willing to give us a VPS to set up our own hosting (which would be great, yet slightly wishful thinking).
- migrate to Spring 3.0
- create a nice demo app

Some people have contacted me regarding becoming a developer on the project, which is great. Once we finished the move to our new home, wherever that may be, I'll contact each of them to get them on board.

It also seems that a lot of companies out there are using Spring Rich Client, more that we could've hoped for. As a complement to our effort: if you're using SRC, and you're happy with it, please send in a testimonial or feedback. Or even better, send in improvements (of which I'm sure there are).

I'm a little biased towards GitHub, simply because I prefer to use git. However, rather than go through an upheaval by switching VCS and requiring all the (already too busy?) developers to learn a new tool, Google Code may be a better option (especially if they will allow you to import the history).

Of course, it is largely trivial to import the history into github, if you clone the sourceforge repo using git-svn.

What I would like to see more coming from the companies (and others) that are using SRCP extensively is how they are solving deeper issues than just creating a form, etc.

Amongst those might be using docking frameworks extensively (and solving layout problems when displaying a new view - i.e which tab/dockable to add the view to), communicating between views or forms, using editors to show a particular object, etc, etc.

Also, for example, how do we deal with editors and getters and setters that might throw an exception? I suspect that that is not a true "getter/setter" pattern, but it is something that I need to deal with.

(My particular case has convenience methods for getting and setting specific fields from a larger piece of data. If it cannot parse the data correctly, it throws an Exception, which could be passed back to the user as an error message).

But thanks for kickstarting this discussion. I think Spring RCP is a great framework, and it would be a real shame to let it stagnate or bitrot.

[LievenDoclo]

GitHub would be my first option as well. Don't get me wrong, Subversion is still great, but it doesn't compare to the performance gain I get using git.

I tried once to migrate the Sourceforge SVN to GitHub, but due to the extreme slowness of SF Subversion, the migration still wasn't finished after 2 whole days...

Most companies using Spring RC are unfortunately bound by IP rights (or at least, so they claim), which sort of prohibit them of contributing in a meaningful way. I actually am planning on contacting Geertjan Wielenga (Netbeans RCP) to see how they got past that obstacle.

Your getter/setter case isn't all that non-trivial: people working with Hibernate can easily get exceptions on their getters due to unfetched lazy associations.

It's not the first time I tried kickstarting this, hopefully it's the last time

[rdawes]

I tried once to migrate the Sourceforge SVN to GitHub, but due to the extreme slowness of SF Subversion, the migration still wasn't finished after 2 whole days...

Did you try to get GitHub to do the migration, or did you do the git-svn clone yourself, and try to upload it?

I cloned it a while ago directly, and it wasn't THAT bad.

EDIT: I just tested it now from my (very underpowered VPS), and it was moving pretty quickly. Unfortunately, I don't have enough memory to do the repack at the end, so I killed it after several revisions.

[LievenDoclo]

I used GitHub's migration system. I haven't tried the git-svn clone method yet, I'll see if I can set up a VM environment to test this on.

[rdawes]

I used GitHub's migration system. I haven't tried the git-svn clone method yet, I'll see if I can set up a VM environment to test this on.

Yes, I just tried their bult-in svn import, and it failed because it took too long. But that was only after a half-hour or so, not two days. It's really not that difficult to do the basic import:

git svn clone https://spring-rich-c.svn.sourceforge.net/svnroot/spring-rich-c spring-rich-c

[johnny]

+1 for GitHub

[julio.arguello]

Hi,

I'm interesting on sharing my job at bluebell with Spring RCP:
http://code.google.com/p/bluebell/updates/list

However it's very hard for me to be a Spring RCP comitter since I spend too many time on my real job (that's the reason why bluebell has stopped last two-three months... ... and it's my intention to go on at September)

Bluebell is not a spring rich competitor, of course. It's a set of add ons over spring rcp infrastructure (for instance table binding, transparent vldocking addoption without configuration, plugabble substance integration out of the box, jide OSS components integration...), that's why I think my work could be helpful.

Good luck!!

[morb]

An important step would alse be to move the "Spring Richclient Reference Guide" into a wiki. Then everyone can contribute and the project gets more attractive with a better guide.

[LievenDoclo]

Sigh... the svn clone did work, unfortunately, it took over that what I was trying to avoid: the CVS legacy of Spring RCP. As some of you have noticed, the trunk doesn't hold the main codebase, it's in a subdirectory under trunk. Urgh... Trying to clone that specific directory came up blank, as the migration tool happily selects the top directory anyway. 1 for Subversion, 0 for Git... I could put up the codebase as is, but then we lose the commit history.
Not sure either whether we should migrate the tags as well.
At least the github account has been made: http://github.com/springrichclient