Using from Maven/Gradle/SBT about java-ipfs-http-client HOT 11 CLOSED

Hi,
any plan to publish this artifact to maven central?

Thanks
Bye
Piero

from java-ipfs-http-client.

How about hosting Maven artifacts on IPFS directly?

from java-ipfs-http-client.

Sure, I can do that if you would find it useful.

from java-ipfs-http-client.

Hi,
I added a pull request #3 for project mavenization.

Bye
Piero

from java-ipfs-http-client.

I don't normally use maven myself, but I'm very happy if someone else wants to take responsibility for pushing to maven central.

from java-ipfs-http-client.

publishing to maven-central might be difficult as the package/group is org/ipfs - but the website ipfs.org does not belong to ipfs ( correct @jbenet ? ) - maven-central enforces that you own the domain correlating to your group/package.
I am in the process of creating a kotlin library which then can also be consumed from java - I will make it compatible with jitpack.io so you can consume the lib with the same comfort as it would come from jcenter or maven central - would be great to know your use-cases ( which api endpoints do you use ) as I will begin with a small command subset as I think the API has to be streamlined ( ipfs/kubo#2803 )

from java-ipfs-http-client.

here the link to the java-api: https://github.com/ligi/ipfs-api-kotlin - you can already fetch it from jitpack

from java-ipfs-http-client.

I've been trying to incorporate java-ipfs-api into a maven library, and as of right now the only way to do so is to either include the IPFS.jar, Multihash.jar and Multiaddr.jar binaries (using Maven shaded JARs) or fork this repository and re-do the whole thing.

One of the principal problems is that the naming convention used, org.ipfs.api, is problematic in several ways: as @ligi points out, ipfs.org isn't the domain being used. Second, "api" is not the name of the JAR file produced (currently, it is IFPS.jar). Thirdly, Multiaddr.jar and Multihash.jar use the same domain naming convention (but use mixed case in the JAR filename).

I'd like to fix it, but renaming the libraries is touchy and I'd like @ianopolous or @jbenet to chime in before I sink any more time into it.

from java-ipfs-http-client.

I'm happy to change the package hierarchy to match some domain that IPFS controls for the sake of compatibility with Maven users. "io.ipfs" would be my first choice - it has the nice potential of serving artifacts directly through IPFS via the public gateway. Does that fit whatever requirements maven has? I can also switch to lowercase names.

from java-ipfs-http-client.

Good, io.ipfs makes sense. It makes things easier if names are as matchy as possible, though it can make it wordy. So, for clarity, I propose:
github.com/ipfs/java-ipfs-api is io.ipfs.api with the filename ipfs.jar
github.com/multiformats/java-multihash is io.ipfs.multihash with the filename multihash.jar
github.com/multiformats/java-multiaddr is io.ipfs.multiaddr with the filename multiaddr.jar

Code structure: the code for all three currently lives in org/ipfs/api, and for multihash and multiaddr this should be moved to `org/ipfs/multi[hash|addr].

Versioning: The current IPFS.jar doesn't incorporate version numbers, though release tags do exist (v0.4.3.1; also for multihash and multiaddr, v0.1). Since the names would change, and paths within, and required dependencies, this would mean a major version update, perhaps 1.0 for all three of them?

from java-ipfs-http-client.

Those names are all fine by me. I don't have a strong view on version numbers. For java-ipfs-api I've been tracking the IPFS version that it supports, but happy to move to semantic versioning or something else more conventional.

from java-ipfs-http-client.