You get something like this:
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.
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
I came across this couple of times before and I always wanted to blog about it. In my daily work life I see many developers which just don’t get Open Source. For example, some discover issues in libraries they use. But they don’t fix them. They don’t even inform the maintainers of a library. Yet others have a great new use-case to address. Again, the library doesn’t support it. Thus, they write a great deal of new code to address their issue and eventually run into new ones (for example, see this thread).
But it’s that darn simple!
- Checkout the library from source. You can use a well known tag/branch for this.
- Get in touch with the maintainers and implement your modifications.
- Build and release your modified version until a new official release is available.
There is a nice SpringSource blog about their plans for building OSGi applications. Actually, it’s more an advertisment for their tool called bundlor which basically has the same purpose as bnd but is implemented in a different way.
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.
I’m hosting some projects over at Google Code. As part of the project setup you can select a license from a drop-down list. Apparently, the list is limited to eight licenses. The EPL is not it this list.
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.
Recently, an interesting question came up in bug 35973. Do Bugzilla votes really reflect the real interest of the broader community in a single feature? Continue reading