One of the things that always annoyed me about using Gradle as the build tool for the bnd workspace is the number of support files.
Then when you had to upgrade the Gradle version, it somehow always went wrong the first two times. There was also this overlap in properties in the
gradle.properties and the workspace properties that got too easy out of sync. Since I’ve got quite a few workspaces, that was kind of bugging me.
Now I rarely ever use Gradle from the command line, I rely on Github Actions to do the command line building and the rest is Eclipse. So I started wondering if I could just generate the Gradle boilerplate file on the fly? This led me terrible yak shaving, but it seems to work now. (I wonder if Yak shaving gets worse with age?) So let me share my travails to make you more productive.
The idea was to run
bnd from the command line:
- Read the workspace files, and
- Copy a (versioned) template from Github into the workspace
- support macros in the template
- copy properties from the workspace in template files
- start gradlew
$ ls <no gradle files> $ bnd buildtool $ ./gradlew --parallel build
Getting this to run locally was quite easy, see the
-buildtool instruction. To execute this instruction, I added a
buildtool command to
bnd. I created the first Gradle template. The template copying is controlled via a
tool.bnd file. You can preprocess macros, skip, or just copy files. Worked like a charm!
To a certain extent, I just moved the problem, now I had to run
bnd instead of Gradle …
Since it sounded interesting to have a Github Action that installs
bnd, I started out creating such a Github Action. However, installing the latest bnd was tricky since my
-buildtool instruction was of course in a snapshot, not yet in a release. And Maven, in its wonderful design, has no constant URL for the latest snapshot.
So I could copy the latest bnd in the repository for the action but that would add more work to a release, and that release work is already substantial not usually done by me. Wouldn’t it be nice if there was a tool that could install Java programs, on all platforms, directly from Maven, including from snapshots?
Anyway, one of these things was a command line tool that could install Java JARs on Linux, MacOS, and Windows. These JARs could be commands on the command line and/or services. This code has been retained in the bndtools site as the jpmcli repository. However, this code was crippled since the JPM server, that was the back-end for its search capabilities, did no longer exist. It could still be used to install JARs via URLs and I actually still use it frequently.
In the intermediate years, on the
bnd side we added quite complete Maven repository support. It should therefore be quite easy to adapt the
jpm command to make it use Maven repositories instead of JPM? And then it would be easy to read snapshots!
I took the old code and added it to my primary open source workspace
biz.aQute.osgi.util since I wanted to throw away a lot of stuff in it and was not sure how many people used it. Ok, ok, I guess also did not like it had grown a
pom.xml file in my absence.
So I cleaned up the code and added Maven repository support. For kicks, I added the Maven Central search support so you can also search from the command line.
After making it all work and returning to the Github Action I realized that, again, I had just moved the goal post Since the new JPM was a snapshot, I did not have a constant URL for the
jpm JAR yet until I released. Ah well, then we use a JAR in the repo … That was only a one time situation until I had released this project.
hen I realized I could directly edit the action code on the Github side (just type
. to start a VS Code session in your browser), to be honest, I was actually warming up to VS Code a bit
So now the remaining part was to update the workflow files. I used the
biz.aQute.osgi.util project as guinea pig. With the local tests, I’d already removed the gradle files. So I just inserted the new
jobs: build: name: build on OpenJDK Linux runs-on: ubuntu-latest steps: - name: Git Checkout uses: firstname.lastname@example.org - name: Set up Java uses: actions/setup-java@v1 with: java-version: 1.8 - name: install gradle uses: email@example.com
- name: Build shell: bash run: | jpm install -f biz.aQute.bnd:biz.aQute.bnd:6.2.0-SNAPSHOT bnd buildtool -f ./gradlew --parallel build
It did work like a charm! However, it was much more work than I anticipated. And to be honest, I removed clutter from the root of my workspace, which is terrific, but the actions has gotten more complicated, which is a bummer.
So if I were a wise man I’d stop and take my loss. However, when writing this I realized that I could make a
bnd-gradle Github Action that would collapse all the setup to a single action? … Hmm, that should not be too much work to do?