Nachträgliche manuelle Umbuchungen sind technisch völlig ausgeschlossen, da ein zentrales Rechenzentrum mit Warenwirtschaftssystemanbindung sämtliche Buchungsvorgänge vollautomatisch steuert.

Or in English:

Manual modifications afterwards are technically absolutely impossible, because we have a central data center with ERP system integration which controls every booking totally automated.

Alternative translation:

We don’t have control over our software. Sorry folks, you lost.

I get this sentence whenever I want to make a change to an already place order. For example, an item is on backorder and it just takes too long but there is a similar one available on stock. Actually I would expect the system to detect this before I place an order but that’s another story.

#onlineshop #eibmarkt #fail

But it’s that darn simple!

1. Checkout the library from source. You can use a well known tag/branch for this.
2. Get in touch with the maintainers and implement your modifications.
3. Build and release your modified version until a new official release is available.

There is one point in the blog the I don’t like at all. It’s yet again I hear the myth about automatically generating OSGi bundles from 3rd party libraries and how successful it is used in the SpringSource bundle repository. Folks, it might work for one 3rd party library but it will never work  in an automated way for all 3rd party libraries. There are just too many issues around OSGi-fying 3rd party libs which need to be addressed carefully. If the library deals with class loading you might be out of luck no matter how great your generated manifests look like. You need to modify your source code and/or patch the 3rd party library to make it work correctly. Even better, sometimes there are multiple ways to convert a 3rd party library into an OSGi bundle. A stubborn one-to-one conversion process cannot incorporate that. It may depend on your requirements and preferences.

The process is not finished with generating manifests. Be aware that this can cause broken bundles. Those issues are fixable. But this example shows that every library requires careful attention.

The Google Help Center says:

We’d like to see projects standardize on the most popular, time-tested ones. The selected licenses offer diversity to meet most developer needs.

The question to add EPL to that list came up a couple of times. In one of the discussions Greg Stein said:

[...] the Eclipse Public License has not really been adopted by the wider open source community. It is mostly being used just by one smallish corner: projects based on or around Eclipse.

That sucks, eh? But it gets worse.

I tried to make a reply using the web interface in that thread to make a comment about the license drop-down. For some reason it did not go to the list but directly to Greg. His response shocked me a little bit.

We only allow those eight licenses. If we find projects that are not licensed as described by the dropdown, then we will remove them.

Ok, back to SourceForge I guess.

From my experience the voting system is only one side. You also need to look at a flipside of a coin. Bugzilla votes are positive votes. They do not reflect ranking. It depends on many factors. For example, a smaller community can become more involved and push any Bugzilla issue up to the top. Even I used blogging in the past to push Bugzilla votes. But this doesn’t mean that Bugzilla votes are useless. They still help to classify the importance of a feature within certain parameters.

For this particular bug I also have a comment. The discussion about efforts, resource consumptions and openness in it is a good point. Everybody is allowed to sponsor an implementation of any feature and contribute it to Eclipse.org. Frankly, if I would sponsor a bunch of developers to implement features in Eclipse this would probably be number 10,001 on my list of 10,000 items. But this doesn’t mean that it will never happen. Get involved and start hacking. You’ll love it!

Sorry folks, with all due respect to model driven software engineering, but that’s totally non-sense. It’s all about developer productivity. The first object is always the hardest. But if you follow the right approach and build good APIs and use the right tools than it’s just a matter of minutes for every other domain object.

Don’t get me wrong. I also use EMF and I love it. But some statements are just plain wrong.

Well, the upgrade went really fine. I started it on Friday night, went to bed and woke up on Saturday with the update being done and successful. However, a lot of the ThinkPad software, although claiming to support Vista, stopped working. I could solve this mostly by just reinstalling it.

A few hours later I started the Eclipse WPF port. Unfortunately, I was much slower than the regular Eclipse Win32 version. Why? Well, I think it’s really an early access preview with the first goal of get everything working. Optimization can happen later and that’s ok. However, it doesn’t matter because Eclipse 3.3 M6 really exposes all the nice Vista features. Great job SWT team!!! I love your toolkit!

Anyway, after working for a couple of days with it I had to restore my XP image yesterday night. Sometimes it is really just one small issue or a combination of a few that influences your workflow in a way that you simply don’t want to go.

What makes this even worse is that it’s really closed development. I really wanted to report this, to make the people aware of the problem and to help debugging it. But other than a somewhat useless support form there is no way to inform the developers. The form is IMHO useless because after a few weeks (it were actually three weeks the last time I tried it) you get a replay that software support is only available during the first four weeks after purchase.

This is closed development – be stuck to your problems and wait for a future release that happens eventually. I wish companies would start learning from themselves each other. It really doesn’t have to be that way.

I had this blank windows problem before on another machine and it was a Swing/AWT application too. In fact, it’s a real pain and it only happens to Swing applications. Some weird thing the Sun JVM is doing with the graphics driver probably. Who knows. In such cases I honestly prefer SWT over everything else. It just works.

C:>java -version
java version "1.5.0_06" Java(TM) 2 Runtime Environment,
Standard Edition (build 1.5.0_06-b05)
Java HotSpot(TM) Client VM
(build 1.5.0_06-b05, mixed mode)

The last time, I could solve the problem by upgrading the graphic cards driver. But this time I’m already on the latest version.

So come on Sun guys. What to do? I already had an eight days email conversation with the Dell hotline. Maybe you can convince them to update the graphics driver for the Inspiron 6000 notebook. Or better, can you fix Swing?

BTW, I often read and hear in this discussion that SWT is not cross-platform. Come on guys, you can’t be serious. SWT is as cross-platform as Swing. Swing wouldn’t be possible without the native code that is integrated in every JVM and must be re-implemented on every platform the JVM supports. The same is true for SWT. The native part is just not hidden in the JVM.

A cursory look at the architectures of many of the top level projects (WTP, STP, TPTP, BIRT etc.) shows the lack of intra-project cooperation is resulting in frameworks that simply don’t integrate with one another in they ways we all want them to.

Honestly, I partly agree with John but more from a usability point of view. Ok, that’s another topic. But I think we have to remember that all these projects are very young projects compared to the Eclipse top level project itself. You can’t expect to get everything done in release 1.0, 1.5 or even 2.0. AFAIK the first goal was to successfully establish the projects on Eclipse.org and to create a vital user, developer and adopter community. With Callisto I’m expecting this goal marked as fixed.

I also agree that one of the next goals should be concentrating on areas where the projects can create more interoperability. But again, I have to remind that work on this topic has already started in the past. It’s is an ongoing long term goal that can’t just be solver over night or with the next release. For example, the common navigator framework and the tabbed properties view are two good solutions that were contributed to Eclipse as part of the initial WTP contribution and are now integrated into Eclipse 3.2.

On the other side, there are indeed examples of projects creating their own solutions to a very common problem that is better solved at a platform level. I accidentally came across such an issue on the weekend when I was talking to a guy on IRC. He just asked a question about a problem registering selection listeners to workbench parts. Well, I’m a curious guy and I was wondering why someone is watching part activation and registering selection listeners to every single workbench part when there is the workbench’s selection service. So I just asked him and we had a very interesting talk. During this conversation it came out that one Eclipse.org project was trying to create there own data binding framework. Well, that’s crazy and definitely not along the line of Eclipse.

But how to avoid this in the future?

In my opinion it’s all about communication, openness and transparency. This is the great advantage of open source development. But it can only be successful if it’s practiced by all involved parties. The issue above just turned out to be caused by a lack of openness and communication. They started developing their own data binding framework because they didn’t know about the JFace data binding framework. You now may ask why is this a problem of openness and communication? Let me explain.

Openness is not only about opening your software and your processes to a community. It’s also about opening yourself and your mind to the input from the community. The same goes for communication. Communication is not only about starting telling everybody what you are going to do but also about starting listening to the community what they do and what’s going on there.

Referring back to the post of John, he asks who is responsible for avoiding miss-interoperability at Eclipse. I think in the example above it’s hard to blame anybody. The project is really young and I bet due to the lack of communication the PMC didn’t know about this. I also don’t think that you ever can blame somebody specific for such issues. It’s the community including committers, leads, PMC members, Eclipse.org member companies and councils that has to demonstrate and practice their openness, transparency and communication skills.

Well, I’m referring to the BOF yesterday held by John Wiegand, Erich Gamma and IBM Rational. Jazz is a technology that wires all the processes, artifacts, policies and systems involved in software development into Eclipse.

It really simplifies the whole process greatly. It also uses ECF technology to enable live communication between developers. Other technologies involved where Tomcat, Cloudscape, EMF, GEF (Draw2D) and CruiseControl. They also explained that they imported tasks/bugs from Bugzilla. However, it’s not tight to these technologies because Jazz is extensible and everybody – commercial software vendors as well as open source developers – are invited to extend it and to integrate it with their technologies.

IMHO this is one of the key features of Jazz. Jazz doesn’t force you to throw away your existing systems. The demo they gave showed that Jazz will solve many, many issued that the Eclipse Platform and JDT developers currently have. No need to manually edit and update a milestone plan anymore, reports of your project health inside Eclipse, no need to leave Eclipse for working with Bugzilla, always recognize what your team is working on and instant “blaming” and reporting when a build fails and a lot more stuff.

Unfortunately, I didn’t have a camera with me. It’s just too much to describe. But there is one feature that I also like to introduce. You ever had the cased when working on a feature in your workspace and a bug comes in? Sometimes you have changes that you can’t commit at this time. But your workspace is not clean. What to do?

Usually, I create a second workspace for this but now guess how Jazz is handling this. It allows you to suspend your work. If you suspend your changes they are moved out of your workspace and your workspace is back in a clean state. You can now work on the bug and resume to your changes after that. I don’t know how they’ve implemented it but I think it can be done using storing diffs in a database.

According to Kai-Uwe Maetzel they are already self-hosting. But we should really NOT expect anything before the end of this year. John Wiegand mentioned that there eventually can be a technical preview ready by the end of this year but we can not expect it.

Although it’s based on open source technologies it is IBM Rational technology. But no decision has been made yet how this is going to be released. Hopefully, we will be able to use it in open source communities without paying for it. But believe me or not. I think Jazz will greatly influence the way how we develop software collaborated in teams.

Update (2006-03-23)

I met Jean-Michel Lemieux at the Hyatt Bar. He is one of the Team CVS guys in Ottawa and clarified things a little bit. I’m very thankful for his comments and insights. Jazz comes with its own SCM and tracking system. However, the demonstration showed that it comes with a clean migration path for existing technologies like Bugzilla and CVS.

This now happened to me with the Borland StarTeam integration. The developers adopted to the ResourceMapping support introduced in Eclipse 3.1. Actually this should bring the plug-in some benefits in handling model objects that are backed by multiple resources. That’s a great idea but now I’m stuck to Eclipse 3.1 and can’t use 3.2 M5 anymore because the package name of the Resource mapping support changed and the plug-ins can’t be started anymore due to a java.lang.NoClassDefFoundError: org...internal...mapping.ResourceMapping. This reduces the intendence of the adoption to absurdity. Even a match="greaterOrEqual" won’t help in this case.

Unfortunately, the StarTeam integration is closed source. Thus, I can’t go an fix this stupid error myself. I probably have to wait till long after Eclipse 3.2 has been released to get an updated.

And at the end? Nobody will get any benifits. Users are stuck to an older technology or need to drop the Team integration completely. The adopters appologize and may consider not adopting next time. And the developer will get no feedback about his API because there won’t be any volunteers anymore.

Update 2006-08-17:

I’ve written a plug-in for Polarion’s SVNImporter. It allows you the migrate from StarTeam to Subversion. The code is available here.

Trac is an enhanced wiki and issue tracking system for software development projects. Trac uses a minimalistic approach to web-based software project management.

I only had a quick look but this software is fascinating. It integrates software like Bugzilla and ViewCVS into a Wiki system. This allows one to use Wiki formattings, WikiWords and bug numbers inside commit comments. These commits are displayed as nice changesets (see example) including inlide diff. A roadmap is generated automatically from the ticket system with a nice progress bar (see here for an example).

Is great to see such software evolving. It allows you to focus on development and reduces the project management documentation overhead. Roadmaps, changelists and timelines are generated automatically. You don’t need to waste your time on formatting status reports.