Because I am still looking forward to testing CDK against the latest Classpath 0.20, I downloaded cacao 0.94-1 for Debian sid, then tried to compile CDK with it: JAVA_HOME=/usr/lib/jvm/cacao ant -Dbuild.compiler=gcj clean test-all But that hangs at some point with zero load. I have no idea what is going on there.
Free at last! Well, not quite yet, but close enough anyway: my PhD contract has ended; last friday was my last working day, which my collegues and I celebrated with a visit to Nijmegen oldest bar, In de Blauwe Hand . But I still have my manuscript to finish. This formally ends a period of almost 12.5 years at the Radboud University Nijmegen. Starting last monday I’m at home, trying to get things finished as soon as possible.
While waiting for a Dragon calculation to finish (it does not work for molecules with more than 300 atoms!), I updated CDK’s build.xml to support gjdoc. The build script is now able to compile the custom doclets we use for creating the src/*.javafiles and others from the Java source files. And using gij I could also run CDK’s 1688 JUnit tests!
One of the Classpath developers pointed me to their CVS statistics when I asked them how actively their project is currently developed, i.e. the number of active developers. The pages are generated with StatCVS, and I ran it one the CDK too. I knew I did a lot of work on the CDK, but never realized that 62.7% of the commits were mine! Keep in mind, though, that a lot of these commits are for code maintainance!
For some weeks now I have been thinking about bug 1309731: “ModelBuilder3D overwrites Atom IDs”. The ModelBuilder3D is a complex piece of source code, reusing many other parts of the CDK, including atom type perception. Somewhere in October, however, I found that Taverna could not create 3D models and convert these into reasonable CML because the Atom ID’s were messed up. So the question is, where did the ModelBuilder3D do this?
I reported earlier that the CDK has been updated in CVS to use CML from the new Jumbo 5.0. The transition actually involved a lot of changes in the CDK, some I would like to address in the following comments. One thing is that CML write support (not reading!) uses the new Jumbo library which requires Java 1.5. Thus, if Java 1.5 is not available, then CML writing should not be compiled. This is how this is done.
Tobias commited Jumbo 5.0 to CDK CVS, so that the CDK is now again up to date with the latest CML library. Note that Jumbo 5.0 requires Java 5.0. At first all JUnit tests seems to work, but apparently the CML2Writer tests were skipped because they were only run when Java 1.4 was found. I updated the test for the a appropriate Java version, and then it turned out that most tests fail.
The code clean up after CDK’s interfaces transition is in progress, and two CDK modules are now independent of the data module. After doing the core module , the standard was next, and I finished this yesterday. The dependencies in CVS now look like (click it to get a larger view): IMAGE LOST This UML diagram was made with Umbrello, and the source is in XMI in CVS.
Stefan has done an excellent debugging week on JChemPaint, while I have been late with a 2.1 release. Anyway, I’ve just uploaded a Java 1.4 compiled JChemPaint 2.1 series release. I was told the (reported) bug count is down to one, so I expect to see the next stable branch to be released soon (2.2 series). But what after JChemPaint 2.2 gets released? Will a 2.3 developers branch be opened?
Some weeks back there was the CDK5AW , the CDK 5th anniversiry workshop. A small group of international open source chemo-, bioinformatics software developers met, among which two from Sweden. It was then decided to generalize their work resulting in Bioclipse: https://www.bioclipse.net/ It’s heavily using the Eclipse Rich Client Platform , making additional plugins trivial.