daff
daff copied to clipboard
package daff for java/maven
Daff is written in a language (haxe) that can produce native code in several languages. This is handy, but even handier if that code gets packaged up and released for whatever package manager that language community uses. Daff has so far been packaged for javascript/npm, ruby/gem, python/pypi, and php/composer. For java, a .zip is available, but it'd be more useful if daff were packaged for maven. There's a starting point mentioned in #39.
Most recent java zip was in https://github.com/paulfitz/daff/releases/tag/v1.3.16 and was generated using make java
and make release
@paulfitz Could you mention where to find the Java release in the README? Your library is very useful!
I am using this package in a project for a client and I need it on Maven Central.
I found a straightforward tutorial on how to publish it: How to publish a Java library to Maven Central - Complete Guide
The tutorial describes how to automate everything with GitHub actions. So you only have to do this once.
And in order to save you time I also prepared the pom.xml:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>io.github.paulfitz</groupId>
<artifactId>daff</artifactId>
<version>1.3.48</version>
<packaging>jar</packaging>
<name>daff</name>
<description>data diff</description>
<url>https://paulfitz.github.io/daff/</url>
<developers>
<developer>
<name>Paul Fitzpatrick</name>
<email>[email protected]</email>
<url>http://paulfitz.github.io</url>
</developer>
</developers>
<licenses>
<license>
<name>MIT License</name>
<url>https://mit-license.org/</url>
<distribution>repo</distribution>
</license>
</licenses>
<scm>
<url>https://github.com/paulfitz/daff</url>
</scm>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>3.4.1</version>
<executions>
<execution>
<id>attach-javadoc</id>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<version>3.2.1</version>
<executions>
<execution>
<id>attach-source</id>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.jreleaser</groupId>
<artifactId>jreleaser-maven-plugin</artifactId>
<version>1.3.1</version>
<configuration>
<jreleaser>
<signing>
<active>ALWAYS</active>
<armored>true</armored>
</signing>
<deploy>
<maven>
<nexus2>
<maven-central>
<active>ALWAYS</active>
<url>https://s01.oss.sonatype.org/service/local</url>;
<closeRepository>false</closeRepository>
<releaseRepository>false</releaseRepository>
<stagingRepositories>target/staging-deploy</stagingRepositories>
</maven-central>
</nexus2>
</maven>
</deploy>
</jreleaser>
</configuration>
</plugin>
<plugin>
<groupId>org.kordamp.maven</groupId>
<artifactId>pomchecker-maven-plugin</artifactId>
<version>1.9.0</version>
</plugin>
</plugins>
</build>
</project>
You will need Maven and the following project structure:
daff/
pom.xml
src/
main/
java/ (what java.hxml currently calls java_bin)
Thank you for writing daff!
Thanks @mardukbp. Do you think you could push your proposal through to the point of making a pull request with a tested workflow? It may be a while before I can get to it myself.
Yes, I can do almost everything. But I need your help with a couple things.
Create an account on Sonatype and a dummy GitHub repository
According to the guide you have to create an account on Sonatype and then create a Jira ticket.
Then you need to create a dummy GitHub repository named as the ID of the Jira ticket, just to verify that you are the owner of your GitHub account.
Create GPG keys
All artifacts published to Maven Central must be signed. You have to generate a keypair and publish the public key to a key server.
Create GitHub secrets
Since the artifacts will be signed and deployed by a GitHub action it needs the keys from the keypair and the login credentials for Sonatype. In total you have to add 5 secrets to your GitHub account:
- Public key from the keypair
- Private key from the keypair
- Passphrase of the keypair
- Sonatype user
- Sonatype password
I can prepare the YAML file for GitHub, modify the Makefile to create the directory structure and copy the .pom file and create a pull request :)
@paulfitz I just submitted PR #192. I implemented the make target java_package
that generates a Maven project and packages the Java classes in a jar. It is self-contained, you do not need to install Maven. Only JDK 8 is needed. I noticed that you are not using GH actions, but rather deploy using make. The PR contains the instructions for deploying with Maven. Feel free to implement the corresponding make target ;)
@paulfitz I just submitted PR #192. I implemented the make target
java_package
that generates a Maven project and packages the Java classes in a jar. It is self-contained, you do not need to install Maven. Only JDK 8 is needed. I noticed that you are not using GH actions, but rather deploy using make. The PR contains the instructions for deploying with Maven. Feel free to implement the corresponding make target ;)
Thanks @mardukbp ! I appreciate you following through.
There are no github actions because they didn't exist during the main period I worked on this repo. I'd be happy to see a workflow added. For your PR, I think you should just replace any existing java build, since it will be a bit confusing to have two and I have no attachment to the existing one.
Is there a way to avoid adding all the mvnw
code to daff? I'd much rather install something from a trustworthy source than review and eventually maintain vendored code.
@paulfitz Done. Now there is only the make target java
. I also removed Maven wrapper. Maven has to be installed using apt, brew, etc.
The GitHub workflow is in the guide I linked to above. Once the deployment is working from your machine, it is only a matter of migrating the configuration of JReleaser to GitHub, i.e., defining the corresponding secrets.
@mardukbp I think I may have made a release. Not entirely sure how to check :-)
It's here! However, the version is wrong (<version>${revision}</version>
) and it was not recognized. My bad. The good news is I found a better way to do it (#194). Deploying the same version should work, since there is no previous version (I think).