Kai Kreuzer

The Eclipse Plugin Build Nightmare

Posted on October 12, 2007

A couple of weeks ago, I was still naive. Having build an Eclipse RCP application it was easy to use the PDE tools "product export" or the "Build all" of an update site project to build and distribute our application. Ok, I had to fiddle around a bit with the right dependency settings for my product definition, but it was all no rocket science.

Now all that was left was to include this build in our continuous integration server. My primitive belief was that there should be a simple API access to immitate the "button click" that I usually did manually. I could not have been more wrong.

I had my first doubts after it took one of our most gifted developers a couple of weeks to perform this job for our proprietary environment. Clearly I blamed our environment and could have bet that it is all so much simpler with any common CI system.

It was just until this week at the Eclipse Summit Europe that again had to revise my opinion on things: No matter who I talked to, nobody ever found a quick and easy solution for building their plugins. There is no stable solution for Maven, the PluginBuilder does not relief from intensive maintenance and even the official Eclipse projects do not have any common ground to "build" on. What explains why you can hardly find any snapshots published to an update site...

The Eclipse Foundation has already identified this as a "pain point" and apparently at least the documentation has already improved with the Europa release. Let's hope that there will be also more improvements on the tools side to make this task something that does not hinder us from being productive for weeks.

RAP as the next GWT?

Posted on October 11, 2007

One of the projects I recently got to know about is the Rich Ajax Platform (RAP). So far I was never very interested in frameworks around Ajax, but being an Eclipse RCP developer, RAP really caught my eye. It has a similar approach like the Google Web Toolkit (GWT): The application is developped purely in Java and it is automatically "converted" into a web application by the toolkit.

One big difference is that RAP actually mimes the SWT API - so in principal, all you have to do to make your Eclipse RCP application a RAP application is to replace your dependency declaration from the standard Eclipse SWT bundles to the RAP bundles. Hence there is no new API to learn and code can be easily exchanged between SWT and RAP applications.

While GWT produces lots of Javascript code to actually run most of the logic in the web browser, RAP keeps the logic inside Equinox on the server. The web browser mainly serves as a "terminal" to display the UI and to receive and send events. Although the project is still in an early stage, it is already working quite nicely as one can see at http://eclipsediscovery.yoxos.com/discovery/rap.

I am sure that this project can be of great help to quickly build complex and interactive user interfaces on the web. This can be so much more productive than working with classic web frameworks with Ajax packages on top...

Doing IT the Eclipse Way

Posted on October 10, 2007

Having joint a BoF session with Naci Dai (member of the WTP project mangement committee) tonight, I now have a clearer view on what is special about the Eclipe community. Being initiated by a big company like IBM obviously helped to provide a sustainable and solid foundation for the whole community. There are for example strictly enforced processes - like how to become a committer to an Eclipse project. Only developers who have proven to deliver quality code by regularly contributing to newsgroups or BugZilla are elligible to be suggested as a new contributer. Not even a company that sponsers a project has the right to bypass this process.

Also, there is a long process for new project approvals - it usually takes several month before a project even gets into the incubator. All of this ensures that the community is composed of motivated AND talented people - which results in a pretty good quality of the Eclipse ecospace.

Although there are strict processes to comply with, the internal project organisation is left to the projects and leaves a lot of flexibility. This is important for the agile self-organisation of the teams and clearly works out quite well - as long as the projects are kept small.

The clear message is that Eclipse does not want to be SourceForge - nobody should simply come along and "dump" some code, but the contributors are expected to be sustainable - which might explain the fact that merely about 1% of the committers are students. An astonishingly low figure! So Eclipse is really backed by companies sponsoring the developments by dedicating staff members to the projects.

Every employer of a committer must sign an IP agreement that the code that is contributed is automatically under the Eclipse license. Interestingly, Google is one of the few companies who does not sign these agreements, such that there are no Eclipse committers from Google. It seems that "don't be evil" does not automatically translate into "be good". At least it shows that Google sees the Eclipse community as some kind of competition to their own initiatives. Interestingly, at the Eclipse Summit you can find many flyers from google about the summer of code etc. How did they get there? Seems that Eclipse is not totally unimportant for Google...

Some Thoughts on the Open Financial Market Platform

Posted on October 10, 2007

Yesterday I attended a Symposium about the Open Financial Market Platform (OFMP) at the Eclipse Summit Europe in Ludwigsburg. This platform is an Eclipse project proposal which is based on an inhouse solution that has been developped by a project team in a bank.

The Symposium had an interesting setup - besides the project team that contributed about 25% of the participants, another 60% were committers of other projects or commercial products that partly offered to bring in their know-how and make sure that OFMP one day nicely integrates with their project. The rest of the crowd were about three people - including me.

The objective of the Symposium was to define what services could be defined and in which direction the project should move, so that it is interesting for the community. But wait - which community? The participants of the Symposium were not the target audience - these should be people from the financial industry that want to solve similar problems and therefore could benefit from the work done by the initiators. So clearly, at least I should be part of the targeted community, right? Unfortunately, the built solution is a mid-office deal processing platform, which does not really have much in common with the Asset Management solutions that we at Odyssey are dealing with. Besides, the OFMP is supposed to be a modular set of OSGi bundles that offer reusable services. The current implementation is a monolithic EAR, though. Even worse, it has not been build for easy customization, the services have not yet a clearly defined contract and they depend on a specific data model with a DAO persistence layer. I bet my feedback didn't help motivating the OFMP team too much.

Do not get me wrong, I very much honor the commitment that the team shows. Maybe it is merely my nature to be doubtful or maybe I have already seen too many initiatives failing...
To sum up the critical factors that I see in the way for a success of OFMP:

The effort of migrating a JEE EAR application to modular OSGi services is easily underestimated.
The proprietary data format should be replaced by a standardized solution like FpML. That is planned, but again, this is a lot of effort that does not bring any benefit to the initiator.
The solution has not yet proven to be reusable. There should be at least a handful banks that have already adopted the solution, before other banks will have trust that they could also benefit from it. Sadly however, the initiators do not even know a potential next victim.
To give a direction to the project, business analysts are needed as otherwise there will be a superb technical infrastructure , but no services that use the real-world problems of the banks. But how to get business people abord an Eclipse project? Any chance that they spend their precious time being surrounded only by geeks? I am sure that that will be a challenge...
The initiator, being asked what they would like to see being contributed to the project by others, so that they themselves can benefit (isn't that their motivation after all?), couldn't tell a single feature (besides improving and bug fixing some of the existing code). Does that mean that the solution is already full-fledged? Rather not - instead I see the risk that they quickly loose the (financial) interest in the project and stop supporting it.

Anyhow, I am looking forward to see OFMP evolve and I wish the team that none of my fears come true!

Has OOD failed?

Posted on July 3, 2007

Inspired by some sessions at the TSSJS, I spent some thought on the "old school" object oriented design programming model. It appears to me that, although we are all using object oriented languages like Java, the core idea of object orientation has somewhat failed without anybody actually admitting it. Here are the arguments that should make you think about it:

The original idea (at least how it is introduced to beginners) of OO is to create real-life "stuff" in software, like a library, books, etc. - nowadays referred to as the domain model. In reality, the domain model is often less than 10-20% of your codebase - the major part are "abstract" infrastructure elements like facades, notifiers, providers, factories, services, etc. Although people will argue that these also have an equivalent in the real-world, one cannot really disguise the very technical concepts that lie within them, which seem to be rather forced into an OO shape.
For many people it has become a best practice to design an anemic domain model. This really makes objects lifeless as all logic is taken away from them and they degrade to pure data containers.
From other classes that still contain logic, AOP tries to squeeze out the cross-cutting pieces, like logging, transaction handling, etc. This functionality is then instead kept in aspects (does anybody really dare to call them objects?) that are attached to the outside of the objects like contagious pimples. (Don't get me wrong - I like the idea of AOP very much!)
Having internal states of objects results in a bad memory footprint, so to be scalable we prefer having stateless services without any internal state.
Passing objects via method invocation might work for some internal classes, but on the SOA-enabled systems, we are passing XML data structures to remote stateless services.
Public constructors are outdated, better use factories instead, or - even better for decoupling - a Spring container that handles this for you.
The object-relational mapping stays a nightmare, despite Hibernate and JPA. JDBC result sets still appear to be an adequate solution, especially if one only needs a few fields from a long list of records.
Business logic as the core part of the software needs to be quickly adaptable to new business requirements. Therefore it is taken out from the objects and moved somewhere else, e.g. in a rule repository (e.g. VisualRules, jRules or any kind of script) where it can be replaced or updated without recompilation and redeployment. Another option is to call it service orchestration and call global functions (web services) in a procedural manner driven by a BPEL file.

Object orientation doesn't seem to match the needs of todays challenges anymore - and it feels as if we stick to it because nothing better has yet been found. It will be interesting to see how dynamic languages might help moving software development into a new dawn.