Any Progress Report?

[jfcone]

I use WinCVS Client but have been unable to connect to this project's CVS. I'd appreciate any WinCVS configuration help from anyone who knows how to use it to connect to this project's CVS. However, I can see by browsing the CVS online that a lot of work is going on in this project.

Is there any time frame as to when a first Release Candidate might be published? At least an architectural design document?

Thanks.

[Keith Donald]

I'd suggest downloading Eclipse 3.0 and working with it to checkout the project module from CVS. There is a eclipse .project file that allows you to import the entire module as an eclipse project for easy browsing.

Here's the CVS info from memory:

Host: cvs.sourceforge.net
Repository path: /cvsroot/spring-rich-c
User: anonymous
Connection type: pserver

As far as project status, here is a repost from TSS detailing our latest work and where we're headed:
------------------------------------

The Spring rich client project is progressing aggressively. We are in the process of developing a specific initial release plan now, as well as extending our sample application to demonstrate new features (such as security/remoting integration). We are currently targeting an initial release candidate by the mid/end September timeframe between Spring 1.1 and 1.2.

spring-richclient offers the following capabilities TODAY:

- A generic application shell with well-defined points for customization within the app's lifecycle. Out of the box support for managing multiple application windows, application views, and GUI command bars is provided, all configurable conveniently via a Spring application context.

- A powerful GUI action/command framework that builds on Swing's base action infrastructure. Support for actionable commands, targetable commands, toggle commands, and command groups are provided. Command configuration is externalized (fit for internationalization) and extremely simple. Unique features include support for command interceptors, parameters, and automatic updating of attached controls in response to command property changes (for example, if you add new command to a command group, and that group is visually realized by a displaying menu, toolbar, and popup menu, all three GUI controls will be updated for you in a single call - dynamically.)

- A powerful Swing data-binding, validation, and form framework. Various domain object strategies (javabean, hashmap, etc.) can be used to bind backing domain objects to form GUI controls. No more repetitive manual bindings (e.g manual copying data from the controls to the business objects); instead you get automatic data binding, type conversion, validation, and as-you-type validation results reporting, including auto-enablement of guarded controls such as a form "finish" button in response to validation of declarative rules associated with your domain objects. Additional capabilities include support for buffered form models (to defer commits to the backing business layer - for example, if the user "Cancels" a form edit), metadata-driven control selection (for example, controls bound to Enum properties are by default combo-boxes, Spinners are produced for Integer/Date properties with ranges), and support for compound forms that span multiple pages (supporting wizards).

- Various convenient support classes for dialogs, wizards, tables (multi-column sorting provided out of the box), messages, lists/filtered lists, and image/icon management.

By the release candidate we plan to provide these additional capabilities:

- Support for declarative application "page configurations", where a page configuration defines the layout of the main application window area. You'll be able to define which application views (panels) should be displayed on the page, and how those views should be positioned.

- Support for dockable, stackable views; we're working to integrate with & help improve upon available docking solutions within the open source community.

- Client/server remoting integration with Hessian, and security integration with Acegi (all new features illustrated by our sample app.)

It should be an exciting next few months for spring-richclient, definitely!

Just a few other notes on the spring-richclient subproject:

In general, we look to apply familiar design patterns leveraged in core Spring, and we strive to follow Spring conventions as much as possible. The framework makes heavy use of programming to interfaces, template method, and the core IoC/dependency injection support. We're also leveraging the new method injection support within the framework, and keen on applying the new AspectJ integration. In general we're are always looking for innovative ways to leverage the container in standalone applications!

I would also like to add the rcp framework is somewhat unique as it was designed first-and-foremost as a shell for a generic rich client application, with specific supplimental support packages addressing requirements typical of rich client apps. This makes it considerably lightweight. In typical Spring fashion, you pick and choose what you need based on your requirements, and we work to simplify the integration of the best of what's out there (and innovate where gaps exist.)

[Martin Kersten]

Are there any ideas of how this may fit the Eclipse Rich Client Platform? I was amazed currently, when taking a look at the RCP of Eclipse. They had much process in the area. I am currently porting a maintainance application from a true plugin to a stand-alone application using the RCP platform. Maybe Spring can contribute some usefull solutions to it, too.

[snpe]

Donald,
Is there any documenatation for spring rich client ?

regards

[Keith Donald]

Technically speaking, Eclipse RCP is built on JFace/SWT and Eclipse's plugin model, while SpringRich is built on Swing and Spring's core container. Philosophy wise, SpringRich's focus is much more on data-centric enterprise apps (and hence provides a lot of value in regard to forms creation/data-binding/validation/integrating with a domain model/number of remoting approaches and other j2ee technologies), while Eclipse has traditionally been used for more IDE-type apps and thus provides more capabilities in that respect. We don't really aim to compete with the Eclipse platform; and while there is overlap, you won't find us developing a docking framework, for example. On the other hand, we'll certainly partner with existing docking solutions to offer a integrated 'one-stop-shop' for building rich clients on the Swing platform, with core Spring facilitating a good deal of that integration. In general we're trying to be much lighter weight--integrating small, useful rich-client-related libraries where they make sense, and innovating where gaps exist, with the goal of making it easy to build Swing-based apps much quicker than typically possible, and in a much more maintainable fashion...

[Keith Donald]

Snpe,

Currently the best documentation is the petclinic sample. We're working on extending this to support more complex use cases, to demonstrate more capabilities of the framework. It is also a priority of ours to have a getting-started guide complete by our release candidate. In fact, I can say we won't release anything until we have that.

[msauer]

I'd suggest downloading Eclipse 3.0 and working with it to checkout the project module from CVS. There is a eclipse .project file that allows you to import the entire module as an eclipse project for easy browsing.

Here's the CVS info from memory:

Host: cvs.sourceforge.net
Repository path: /cvsroot/spring-rich-c
User: anonymous
Connection type: pserver

Has anyone gotten this to work? I am getting "can not connect to host" errors. I would really like to try this out.

[jdigger]

{snip}
Has anyone gotten this to work? I am getting "can not connect to host" errors. I would really like to try this out.

Works fine for me. Can you connect to the CVS server normally, without Eclipse?