Hi Bob, a few weeks ago I was asked about the Jmol binary release Maven Central (https://mvnrepository.com/artifact/net.sourceforge.jmol/jmol). Are you okay if I pick this up? I will likely have to write some patches, which would be nice after so many years.
I would really appreciate it if you would contribute that.
Egon, Bob - if this is still on the table I would like to help, and I have some concrete evidence of the downstream cost plus an offer of legwork.
Worth adding to the picture: Spencer Bliven, who published 14.31.10 back in October 2020, still has Maven Central access for the project and has offered to cut a new release. So between the three of you the permissions already exist - the gap is time and the publishing step, not authorisation.
Where things stand today: Central is still at
net.sourceforge.jmol:jmol14.31.10, published October 2020. Jmol itself is at 16.4.1. Nothing newer exists on Central under any coordinate.The effect downstream is not abstract, and I am on the receiving end of it twice over: I work on BioJava, and our
biojava-structure-gui- including the current 7.2.6 - pins that exact 2020 build, so everyone using our Jmol integration is on a six-year-old Jmol. We cannot move that pin forward because there is nothing newer on Central to point it at. In my own application I gave up waiting and vendored a 19 MB Jmol.jar into the repository, which I will now carry in git permanently. It is also why testing a newer Jmol against the bug I reported in #640 meant doing that same dance again rather than just bumping a version.Two details that may save whoever does the work some time:
tools/jmol-sonatype.xmlin the source tree already does this job. It reads the version out ofJmol.propertiesand fills intools/pom.xml.template, and that template is character-for-character the pom sitting on Central as 14.31.10. So the machinery worked; it stopped being run. What changed underneath it is that Sonatype retired OSSRH in favour of the Central Portal, and the bundledmaven-ant-tasks-2.1.3.jarpredates that. Updating that step is the actual task, not building a publishing process from scratch.The published 14.31.10 pom declares no dependencies, which is consistent with Jmol.jar being self-contained - so there is no dependency graph to untangle. The flip side of that shading is worth noting, because it is biting people: #637 reports Jmol bundling
uk.ac.ebi.beam1.3.4 and colliding with CDK 2.12, with the reporter stripping the library out of Jmol.jar by hand. I hit the same shape of problem from the other side - when I ranmvn install:install-fileon Jmol.jar to vendor it, Maven picked up the shadedjna-inchipom carried inside the jar and tried to resolve its1.4-SNAPSHOTparent, which of course fails. Any Central release should ship a hand-written descriptor rather than whatever is embedded in the jar.If it is useful, I am happy to update
tools/jmol-sonatype.xmlfor the Central Portal and test it against a staging repository so that nothing is published until you say so, and hand it back as a single step to run at release time. Bob, Egon and Spencer would keep the credentials and the final say. And if Spencer is able to cut 16.4.1 from the existing script in the meantime, that alone would close a six-year gap while the Portal migration is sorted out properly.Have there been any progress in this matter?
Is there any support I can offer?
Last edit: Amr ALHOSSARY 2026-08-31
Not that I know of. It would be great if someone took care of this
generally.
On Mon, Aug 31, 2026, 5:03 PM Amr ALHOSSARY amr-alhossary@users.sourceforge.net wrote:
Related
Bugs: #635