UMLGraph
UMLGraph copied to clipboard
dspinellis
Upload latest version to maven central, for automatic dependency management
The latest version of umlgraph on Mavencentral appears to be 5.6.6: https://mvnrepository.com/artifact/org.umlgraph/umlgraph
It would be good to have the latest version available as a managed dependency via maven, jcenter, etc.
As workaround, I am currently considering to use the auto-compiled version from https://jitpack.io/#dspinellis/UMLGraph - a pretty interesting idea, to have a service that can automatically build jars for github software. But I'd rather have a signed version in a repository like maven.
Thank you for the nudge! Is there an easy way to address this? What precisely should I do? I can't see a login or upload button on https://mvnrepository.com/.
I haven't used this in a while, but if I remember correctly, the usual way to upload to mvnrepository is via Sonatype OSSRH: http://central.sonatype.org/pages/ossrh-guide.html You build, sign, and upload via maven. Then log into sonatype and publish the artifacts to maven if they look good.
I found my notes on that, thank you! It's a complex and time-consuming process. Don't hold your breath...
Please can I upvote this request? It saves a lot of time for my students on their Computer Science projects, thank you for a great tool.
@sgparry you should be able to rely on the jitpack version for such projects. There are instructions for gradle, maven, sbt on the page linked above. You can depend on a specific build, or on the master branch. Uploading to maven should be mostly a matter of digging up the right key to sign the build, and the credentials to upload to sonatype. Nexus is annoyingly complicated, unfortunately.
Further problems with the provided instructions.
- The Sonatype links to configure GPG signing of Maven artefact (e.g. this one) are dead
- An Sonatype document with similar content, which I located points to
hkp://pgp.mit.edu, which however fails when I try to retrieve my key.
Beware that you don't want to install your own Nexus, so no localhost:8081 there.
You will need to find your private GPG key (and there should be your public key there, too) - the private key by design should not be on any keyserver, you need to hold on to it yourself. I don't know the procedure for replacing a key, probably you need to file a ticket with sonatype then.
As I've switched to Gradle, I don't remember all the Maven details. These are the relevant lines from the last time I used Maven with Sonatype: https://github.com/elki-project/elki/blob/6f1d3995960e5ce3e468b1e9e8cf202263c12ba7/pom.xml#L329-L373 https://github.com/elki-project/elki/blob/6f1d3995960e5ce3e468b1e9e8cf202263c12ba7/pom.xml#L402-L407
You will still need to put the sonatype username and password into a (not uploaded!) configuration file, probably settings.xml for maven, in the maven config folder (not the project folder).
But that part pretty much just worked for me. What I always found much more tiresome is a) to get the jar files look exactly right for sonatypes liking, and b) the annoying Nexus web interface where you need to re-login all the time, locate the latest "staging" repository, click a dozen times to even just see if all the files are there that should be there, and then eventually "release" the staging version (of course you are supposed to first check that the staging repository works). That is all "step 9" in the dzone instructions.
Judging from the last archive.org capture of the "dead link" above, these appear to be the current instructions for Maven: https://central.sonatype.org/pages/apache-maven.html
@kno10 Ah, I figured out there was something wrong with them, thank you for the additional hints! It should have been an easier process. Maybe I should also switch (yet again) to Gradle.
The current instructions pointed by @kno10 seem to be clearer than the alternative, so I'm following these. I thought I would avoid the annoying Nexus web interface, if I automated the process.
Got hit by an unmet dependency on tools.jar, which doesn't exist in my current JDK. Waiting for this to be resolved in this year's GSoC. Giving up for the time being. WIP left on an issue-46 branch.
Waiting for tools.jar will not solve this. The underlying problem is that the JavaDoc API was compeltely changed. So it won't work with a newer JDK than 8, until it is largely rewritten.
So you'd need to build with and old Java 8. They will not restore backwards compatibility for the never-official javadoc doclet api.
I had begun working on the new JavaDoc classes, but didn't get too far yet, because literally everything changed in JavaDoc. https://github.com/kno10/UMLGraph/commits/java11
Thank you, yes, I know. Over the following months I will be mentoring a Google Summer of Code project to address these issues. So, the "waiting" is waiting for the project to finish.
Oh, I see. I thought it was a GSoC project at the JDK side. It makes perfect sense to have this as GSoC here. I didn't expect GSoC to still even consider such smaller projects worth supporting. Please point out the java11 branch I began to this student, I think it already has 50% of the work done; but its usually the small details were it gets complicated. I'm happy to see someone else work on that, because I have so many other things with higher priority.