Most people think of fun things to do on their three day weekends. Things like getting a babysitter and seeing a movie with your spouse, going to a birthday party, getting some car maintenance done, or taking the kids to the playgrond. Me? I spent this weekend forking an existing open source project.
The particular project I forked was six different code bases from Kirill Grouchnikov relating to the Flamingo Widget Library and the Substance Look and Feel. However, there was no drama like what went on with Hudson and Jenkins. Kirill (the principal and basically sole developer) instead has decided to end his support for the project. Something about Android having a better growth potential and that his work on the Android Market paying his rent/mortgage I’m sure. He seems pretty determined about this, because he has even rejected some pull requests for some very specific null pointer checks. In his response he has practically asked that the project be forked, so I am testing the waters.
There are a few things to consider when one is forking a project. The first is the the license terms. Kirill licensed his projects under the 3-clause BSD license . This license allows forking with basically two restrictions (my understanding in layman’s terms, I am not a lawyer though I play one when reading GrokLaw): (a) credit where credit is due and (b) pick a new name. So I’ve come up with some names for my forks of the projects.
- Halberd – another middle ages weapon with three sharp points, just configured differently.
- Insubstantial – A play on substance. Really the UI widgets should be insubstantial and fall away leaving only the data and user interaction.
- Peacock – Another colorful bird.
- plaf-(widget|plugin) – I’m just being lazy here. (Pluggable) Look and Feel.
The next question is releases and maintenance plan. For now I am synchronizing all of the release numbers to 6.2. There are some null pointer fixes in the forks for substance, flamingo, and plaf-widget. I intend to only do bug fixes and minor alterations for this release. Any new features will wind up in a 7.0 release. At my day job we have code for rounded window pane corners. If that winds up in a public repository it will be in the 7.0 release, these are the sorts of feature adds that are not going into bug fix releases.
Next this fork gives me a chance to do other tweaks that match my whims. For my day job we have a need to see these libraries in a Maven repo, so to that end I have migrated the build system to Gradle, am building the git repo on a CloudBees instance, and I have a Sonatype account to post the libs on their OSS repository. Details and experiences will be in another blog post.
The other tweak has to do with the infamous EDT checks Kirill installed into Substance. I have decided to add system properties to control the logging of the errors and the throwing of exceptions separately. By default violations will be logged to
System.err, but no exception will be thrown. You’re free toggle either one of them (
insubstantial.logEDT as Booleans). I was going to leave them both turned on, until I discovered that Kirill’s own unit tests for Flamingo violate the rules. The whole EDT issue is worthy of its own blog post/diatribe.
For those who are interested, the maven repository groupId is
com.github.insubstantial. The code is at https://github.com/Insubstantial. I have this set up as a group at github. So patches are welcome, and so are collaborators.