Trying out a new route...

[LievenDoclo]

As you've all noticed, there hasn't been a lot of movement in the Spring RCP codebase lately. But that doesn't mean we've been sitting on our butts (at least I haven't ).

There have been some things we were planning on changing in the current codebase, but the changes were of such magnitude, it would mean we'd have to rethink the entire system. Which I did.

I started with the existing codebase from the ground up (starting point was the ApplicationLauncher), changing the parts I wanted to change for a while now. Things like the Application.getInstance(), the service accessor pattern (ApplicationServices.getInstance()...) and the complexity of the configuration when starting an RCP application. And off course the fact that it had to be Spring 3. Wherever I could, I also adapted some of Bluebell's features, as some of them were quite nice (the OverlayService concept is a nice one).

The result came out quite nice (it only took me about a week) and now most of the core codebase has been ported (except for some non-urgent components, but those will be ported shortly). The simple sample works perfectly. Other samples will follow shortly.

The code is currently under the codename Valkyrie and is found on Gitorious (www.gitorious.org/valkyrie-rcp). Valkyrie is completely operational, but still lacks some critical elements in order to use it in production (unit tests being the most important one, I didn't make time to port those as well). Which brings up the question what to do next... As I see it, we have multiple options: we can port Valkyrie to Spring RCP (in effect, creating a 2.0 version, as this'll break about every RCP code out there) or let Valkyrie live on as a project on it's own (perhaps merging it with Bluebell?). In that case there the second question: what to do with Spring RCP?

Suggestions, ideas, comments?

[rdawes]

It sounds interesting. Just how dramatically different is it from current RCP code?

i.e. if we declare Valkyrie as 2.0, how much effort would be involved to actually port older 1.x code to 2.0?

[LievenDoclo]

Well, for one it uses the annotation-config system in Spring 3.0 in order to facilitate easier config through inheritance and overrides, and uses AOP compile-time weaving for Spring configuration of non-container managed beans, which in RCP tend to pop up easily (like programmatically created commands).
Normally views, binders and such shouldn't take too much effort in porting, but like I said, some things are gone, like the Application singleton, the ApplicationServices locator (now services are just injected using @Autowired or are already available as injected objects on superclasses), RCPSupport is gone (again, you can use injected services now).
The simple sample was quite easy to port, most of the issues were due to the use of the RCPSupport class. Most of the effort goes into setting up the @Configuration classes.
And then there's off course the package name change. I couldn't just use the org.springframework package for something not related to SpringSource .
I suggest you take a look at the simple sample, it nicely shows the new way of configuring and RCP.

[julio.arguello]

It will be a pleasure for me to adapt Bluebell to new Spring 3 approach.

Please, keep us well informed about new version publishing.

Lieven, you can contact with me at julio.arguello at gmail dot com.

[julio.arguello]

Lieven, take into account the followin link before integrating Bluebell OverlayService support:
http://jirabluebell.b2b2000.com/browse/BLUE-50

[LievenDoclo]

See it, implemented it . I'm on BlueBell trunk

[LievenDoclo]

And we're off... Most of the functionality has now been ported, next up is pulling some stuff out of the sandbox (some of it already has been) and looking into the integrations with VLDocking and others.
I'm even kinda surprised... The new version feels quicker.
My initial goal was no xml configs, but unfortunately, that was a no go. Unless someone can point me on how to map <context:spring-configured/> to an @Configuration class, we're stuck with a little XML. And so that no-one will share my pain, here's a hint: if you're including an @Configuration class into a Spring XML context file and your @Configuration class includes a BeanPostProcessor, don't expect it to work. It won't .
To end with a positive note, a screenshot attached.

[julio.arguello]

So your employing aspectJ weaving, sounds nice.

I think remaining XML is not a problem, the objetive is to reduce them not to kill them at all.

One question (may be to soon for it), how do you provide developers the oportunity to inject and employ their own services implementation?

[LievenDoclo]

I would've been nice, but it's not that bad, the remaining XML is something like 10 lines long, including a Spring Security AuthenticationManager .

Anyway, if you mean by injecting their own services, like a ComponentFactory, ApplicationWindowFactory, PageComponentPaneFactory, ... the answer is yes. You just subclass the default configuration and override the appropriate methods (in this case, componentFactory(), applicationWindowFactory(), pageComponentPaneFactory(), ...). As I said, ApplicationServices.getService(...) is no more, so injecting is used a lot more in Valkyrie (hence the need for the AspectJ weaving for non-Spring managed beans).

[julio.arguello]

I suggest you emplying the following approach. Does not need subclassing:
- Use @Resource annotation referencing "aliases".
- Define "aliases" referencing placeholders.
- Define placeholder values into a properties file located inside the jar file.
- Define a property placeholder configurer for unless this properties file (aka PPC)
- User can override default configuration employing prior PPC's.