Just in case anyone is still interested, I have started an ensj (Ensembl Java API) project at sourceforge, using the latest version of the ensj-core project as the root of the fork. It fixes at least one bug with using the java API on hg19, and makes some improvements to the code for compatibility with java 1.6.
There are another few thousand changes I could make, but I’m just working on it slowly, if at all.
I’m not intending to support this full time, but interested parties are welcome to join the project and contribute, making this a truly open source version of the ensembl interface. That is to say, community driven.
Ensembl isn’t interested in providing support (they no longer have people with the in-depth knowledge of the API to provide support), so please don’t use this project with the expectation of help from the Ensembl team. Also note that significant enhancements or upgrades are unlikely unless you’re interested in contributing to them! (I have my own dissertation to write and am not looking to take this on as a full time job!)
If you’re interested in using it, however, you can find the project here:
and a few notes on getting started here and here. I will get around to posting some more information on the project on sourceforge web site when I get a chance.
Some days you celebrate the little victories, other days, you celebrate the big ones.
Today, I get to celebrate a pretty significant victory, in my humble opinion: I managed to get the ensembl java API to compile and generate a fully operational
battle station jar file that works with my Java code.
I know, it doesn’t sound like such a big deal, but that means I worked out all of it’s dependencies, managed to get all of it to compile without errors and THEN managed to fix a bug. Not bad for a project I thought would take months. In fact, I’ve even made some significant upgrades, for instance, it now creates a java 1.6 jar file, which should run a bit faster than the original java 1.4. I’ve also gone through and upgraded some of the code – making it a bit more readable and in the java 1.6 format with “enhanced loops”. All in all, I’m pretty pleased with this particular piece of work. Considering I started on friday, and I’ve managed to make headway on my thesis project in the meantime, I’d say I’m doing pretty well.
So, as I said, I get to celebrate a nice little victory…. and then I’ll have to immediately get back to some more thesis writing.
For posterity’s sake, here are the steps required to complete this project:
- Get the full package from the Ensembl people. (They have a version that includes the build file and the licence for the software. The one I downloaded from the web was incomplete.)
- Get all of the dependencies. They are available on the web, but most of them are out of date and new ones can be used.
- Figure out that java2html.jar needs to be in ~/.ant/lib/, not in the usual ./lib path
- Fix the problem of new data types in AssemblyMapperAdaptorImpl.java. (It’s a 2 line fix, btw.)
- Modify the build.properties file to use the latest version of the mysql API, and then copy that to the appropriate ./lib path.
- Modify the build.properties file to reflect that you’re generating a custom jar file.
- Modify the build.xml to use java 1.6 instead of 1.4
- Figure out how to use the ant code. Turns out both “ant build” and “ant jar” both work.
- Note, the project uses a bootstrap manifest file which isn’t available in the source package on the web. If you use that code, you have to modify the build.xml file to generate a custom manifest file, which is actually pretty easy to do. This isn’t required, however, if you have the full source code.
When you write it out that way, it doesn’t sound like such a big project does it? I’m debating putting the modified version somewhere like sourceforge, if there’s any interest from the java/bioinformatics community. Let me know if you think it might be useful.