Part of my day I’m working on some cool OSGi server stuff. While doing this I came across a few issues with PDE. Mostly they are around launching and self-hosting.
As with all my Open Source engagements, I just don’t stop after reporting them. I also take the time to analyze them and provide patches for them. Why? Well, it saves me a lot of time in the end because I don’t need to live with workarounds. 🙂
Here is a list of patches produced so far for Eclipse PDE 3.6:
- Bug 314619 – [patch] org.eclipse.equinox.app is not started when using Eclipse Application launcher
- Bug 315039 – [patch] Eclipse launch configuration should inherit properties from target platform
- Bug 315061 – [patch] Should read start levels from bundles.info of target platform when launching Eclipse application
- Bug 320763 – [patch] SelfHostingProfile needs environment properties
Now, thanks to Eclipse it’s also possible to easily share the patches with you. Just point your Eclipse 3.6 installation to my p2 repository (http://eclipseguru.org/) and install “EclipseGuru’s Patches for PDE“.
There is only one guy in the universe that – despite traveling a lot recently – can deliver two tutorials on the same day at the same time.
I’m wondering now if modeling solved the problem of cloning. Anyway, I just registered today to be there and watch that happening. 🙂
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.
I previously blogged about this. It wasn’t possible to select EPL as your project license when hosting your project at Google Code. Yes, no typo … it wasn’t.
They changed their mind. Hooray!
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. 😐