Is it possible to make jpostal available on maven repository?

[Noodle05]

Currently jpostal released as source code, it's hard to use it in any project. Is it possible to make it available on central maven repository?

[albarrentine]

Fine to publish it, though that may not make it much easier to install/use because of e.g. #3. As far as I can tell, most Java package managers need special coaxing to handle JNI libraries and java.classpath correctly, so it can't simply be included in a pom like a normal Java library and expected to work. If you use Gradle, this approach seems useful: https://github.com/cjstehno/coffeaelectronica/wiki/Going-Native-with-Gradle.

Generally I'm not a huge Java/JVM language user. For this binding, I'll maintain the JNI/C parts of the repo, but am very much relying on the community to help out with packaging, etc. Happy to merge pull requests if you want to give it a shot.

[Noodle05]

I agree, maybe add JNI library (not libpostal.so) into jar file itself? so reduce one dependency?

[albarrentine]

That should work.

Just before jpostal was released I was reading about packaging the native lib as part of a jar and came across this blog post, which might be useful (Github repo: https://github.com/adamheinrich/native-utils).

Also possibly of interest are the Gradle docs on publishing custom artifacts: https://docs.gradle.org/current/userguide/publishing_maven.html#sec:publishing_custom_artifacts_to_maven

[mkaranta]

I've been uploading to our internal third-party maven repo.
It's a simple one-liner in the main directory after the gradle build:
mvn deploy:deploy-file -DgroupId=mapzen -DartifactId=jpostal -Dversion=1.0 -Dpackaging=jar -Dfile=./build/libs/jpostal.jar -DrepositoryId=<repoID> -Durl=<repoUrl>

You can can specify whatever groupId, artifactId, and version you want but I think mapzen & jpostal make the most sense for the first 2.

[jonashartwig]

Hi, would have been nice to get the link to that maven repo if its public :)

[Radiergummi]

Since there hasn't been any activity here, and I was too bothered distributing the library alongside our application, I took up the chore of publishing it on Maven Central. You can find the package there:
https://central.sonatype.com/artifact/com.matchory.packages/jpostal

Since I don't have control of the mapzen.com domain, I took the liberty to rename the namespace to com.matchory.packages; the code is unmodified otherwise, including the license document. I also added open venues as the original developer and pointed the SCM links to this repository. However, if any of the maintainers are unhappy with the publication, reach out to me via email (my first name, "moritz", below our company domain).

This is the final grade file required for publishing, adapted from the Dockerfile:

import org.gradle.internal.jvm.Jvm

plugins {
    id 'c'
    id 'java'
    id 'java-library'
    id 'application'
    id 'signing'
    id 'maven-publish'
}

group = 'com.matchory.packages'
version = '1.0.0'

repositories {
    mavenCentral()
}


java {
    withJavadocJar()
    withSourcesJar()
}

sourceSets.main.java.srcDirs = ["src/main/java"]
sourceSets.test.java.srcDirs = ["src/test/java"]

model {
    platforms {
        x64 {
            architecture "x86_64"
        }
    }

    components {
        jpostal(NativeLibrarySpec) {
            binaries.all {
                def jvmHome = org.gradle.internal.jvm.Jvm.current().javaHome
                if (targetPlatform.operatingSystem.macOsX) {
                    cCompiler.args '-I', "${jvmHome}/include"
                    cCompiler.args '-I', "${jvmHome}/include/darwin"
                    cCompiler.args '-mmacosx-version-min=10.9'
                    linker.args '-mmacosx-version-min=10.9'
                    linker.args '-stdlib=libc++'
                } else if (targetPlatform.operatingSystem.linux) {
                    cCompiler.args '-I', "${jvmHome}/include"
                    cCompiler.args '-I', "${jvmHome}/include/linux"
                    cCompiler.args '-D_FILE_OFFSET_BITS=64'
                } else if (targetPlatform.operatingSystem.windows) {
                    cCompiler.args "-I${jvmHome}/include"
                    cCompiler.args "-I${jvmHome}/include/win32"
                } else if (targetPlatform.operatingSystem.freeBSD) {
                    cCompiler.args '-I', "${jvmHome}/include"
                    cCompiler.args '-I', "${jvmHome}/include/freebsd"
                }
                linker.args '-lpostal'  // Link with libpostal
            }
        }
    }
}

classes.dependsOn 'jpostalSharedLibrary'

application {
    applicationDefaultJvmArgs = ["-Djava.library.path=" + file("${buildDir}/libs/jpostal/shared").absolutePath]
}

dependencies {
    testImplementation 'junit:junit:4.+'
}

tasks.withType(Test) {
    systemProperty "java.library.path", file("${buildDir}/libs/jpostal/shared").absolutePath
}

artifacts {
    archives javadocJar, sourcesJar
}

publishing {
    publications {
        mavenJava(MavenPublication) {

            groupId = 'com.matchory.packages'
            artifactId = 'jpostal'
            version = '1.0.0'

            from components.java

            versionMapping {
                usage('java-api') {
                    fromResolutionOf('runtimeClasspath')
                }
                usage('java-runtime') {
                    fromResolutionResult()
                }
            }

            pom {
                name = 'jpostal'
                description = 'Java/JNI bindings to libpostal for fast international street address parsing/normalization'
                url = 'https://github.com/openvenues/jpostal'
                developers {
                    developer {
                        id = 'openvenues'
                        name = 'Open Venues'
                        url = 'https://github.com/openvenues'
                    }
                }
                licenses {
                    license {
                        name = 'MIT'
                    }
                }
                scm {
                    connection = 'scm:git:git://github.com/openvenues/libpostal.git'
                    developerConnection = 'scm:git:ssh://github.com/openvenues/libpostal.git'
                    url = 'https://github.com/openvenues/libpostal'
                }
            }
        }
    }

    repositories {
        maven {
            name = 'com.matchory.packages.jpostal'
            url = layout.buildDirectory.dir("repo")
        }
    }
}

signing {
    sign configurations.archives
    sign publishing.publications.mavenJava
}

javadoc {
    if(JavaVersion.current().isJava9Compatible()) {
        options.addBooleanOption('html5', true)
    }
}

[Radiergummi]

@ets could you at least add a little context instead of just silently closing this issue?

Are you okay with the package? Are you planning to publish your own? Would you like help with the publication?

[ets]

Hey @Radiergummi - I closed several issues that were opened 5+ years ago and have no PRs with the new label "stale". Your gradle publish task is a fine suggestion as far as it goes, but a viable PR would need to facilitate the actual building and distribution of a multi-arch fat jar. It looks like SQLite-jdbc does this using GitHub Actions. PRs welcome

[albarrentine]

a PR would be welcome but as a practice I prefer not to close issues unless it's an answered question or e.g. mis-reported memory leaks/crashes, etc. It doesn't have to be inbox zero, as it were. It's fine to have open issues on a project and when perusing other open-source work that's one of the things I look at for caveats, bugs, performance issues, etc. Not all issues that have been open for several years are necessarily without activity. Sometimes they came during a busy season for me or another maintainer and weren't answered, people hit the old issue when searching for their error, realize it's not a solved problem and scratch their own itch. If there's an issue with the PR or it breaks compatibility, etc. can always just close it and implement a different idea or make reviews/modifications, but I wouldn't close it unless it's no longer an issue or never was one.

[Radiergummi]

As a small update, perhaps; after spending a lot of time trying to make true multi-platform builds happen with Actions, we have updated our distribution of jpostal to include pre-built binaries for both libpostal and the JNI bindings for linux/amd64, linux/aarch64, and macOS/aarch64, as well as a small JNILoader that will automatically load the appropriate libraries for the runtime platform.
This works reasonably well for now, and if I ever have a bored junior with too much joy in his life, we'll get back to compiling the bindings in the workflow again.

In addition, I updated to Gradle 9 and Java 21, and extended the GitHub Actions workflow to handle the full release workflow to Central.

I'll chime back in with a PR once we're past the duct tape stage, but if anyone else is looking to use jpostal now, feel free to pull com.matchory.packages.jpostal:2.0.0. The sources live in matchory/jpostal.