pod-jackdbd-jsoup

Babashka pod for parsing HTML with jsoup.

How to use it?

Use the binary file for your OS/architecture

If you want to load a version of this pod that was registered on the Pod registry (see below to know what registered means in this context), you can do it using the qualified keyword of this pod.

(require '[babashka.pods :as pods])
(pods/load-pod 'com.github.jackdbd/pod.jackdbd.jsoup "0.3.0")

Whether the pod is registered or not, you can always load it with this method:

1. Download the archive (e.g. .zip) containing the pod binary for your OS/architecture from a GitHub release.
2. Extract the binary from the archive (e.g. unzip it).

And either (option A):

1. Move the binary to your BABASHKA_PODS_DIR.
2. Load the pod using its file name.

(require '[babashka.pods :as pods])
(pods/load-pod "pod-jackdbd-jsoup")

Or (option B):

1. Move the binary whenever you want on your filesystem.
2. Load the pod using its file path.

(require '[babashka.pods :as pods])
(pods/load-pod "/path/to/pod-jackdbd-jsoup")

Use the uberjar

In case the pod wasn't compiled for your combination of OS/architecture, you can still use it with this method:

1. Download the uberjar from a GitHub release.
2. Load the pod using its file path.

(require '[babashka.pods :as pods])
(def uber-file "path/to/pod-jackdbd-jsoup.jar")
(pods/load-pod ["java" "-jar" uber-file])

See also examples/jsoup.bb.

Development

The file devenv.nix declares a developer environment for this project. This file is used by devenv to create such environment. If you don't use devenv you can ignore this file, or use it to understand which dependencies are required by this project.

This project uses a bb.edn file to define a few Babashka tasks. You can type bb tasks to view them.

Linux binary

If you are on Linux, you can compile a statically-linked binary using this Babashka task.

bb build:binary

You can double check that the binary is statically linked using one of the following commands.

ldd target/pod-jackdbd-jsoup
objdump --dynamic-syms target/pod-jackdbd

Namespace dependency graph

Release management

Each push to main triggers a deploy to Clojars. These versions will have a semver range (e.g. 1.2.3).

When you are on main and you are ready to make a release, run this command:

bb release

After each successful deploy to Clojars from main, a release on GitHub Releases will be created.

Each push to canary triggers a deploy to Clojars. These versions will have a semver range, a suffix and a counter incremented automatically (e.g. 1.2.3-RC.1, 1.2.3-RC.2). I don't do snapshot versions because I think they are a bad idea. I consider each version published to Clojars an immutable artifact and I never overwrite it.

When you are on canary and you are ready to make a pre-release, run this command:

bb prerelease

After each successful deploy to Clojars from canary, a pre-release on GitHub Releases will be created.

Important

A deploy on Clojars and GitHub Releases do not imply that the pod is registered on the Pod registry. At the moment, this last step must be done manually.

Registering the pod on the Pod registry

The CI/CD pipeline takes care of creating a GitHub release that includes the following assets:

• Binary executables for Linux, macOS and Windows.
• An uberjar (the same one which is published to Clojars).
• A manifest.edn that can be used register the pod on the Pod registry.

Download the manifest.edn and make a PR on the Pod registry following these instructions.

Note

Every pod version has its own manifest.edn.

Once the PR on Pod registry gets merged, the pod version will be considered registered and users will be able to load it using the qualified keyword for the pod and the desired version, instead of having to download the binary from a GitHub release.

Credits

This project was inspired by jaydeesimon/pod-jaydeesimon-jsoup.