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.
-
gradle.properties, -
settings.gradle, -
gradlew, -
gradlew.bat, -
.gradle.
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.
Design
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
For example:
$ ls
<no gradle files>
$ bnd buildtool
$ ./gradlew --parallel build
Execution
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!
Well locally.
Github Action
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?
JPM
Almost a decade ago I left the OSGi and worked on my own for a year on JPM. Not directly to get rich (financially it was definitely not a good idea) but because I felt I was out of touch with newer technologies like Javascript, the web, etc. It was a wonderful year where I developed a (still missed!) world wide index of Java repositories with dependency analysis and nice graphics. Several of the technologies I developed still live on in OSGi specs.
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!
Fantastic idea!
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.
Github Action Again
I’d never made a Github Action so there was some reading to do. I am in awe over what Github is doing, and their documentation is truly extensive, but it did take me some time before I got something working. I had to brush up on my Javascript and overcome my resistance to VS Code. However, I got an action going, called setup-jpm. Now I know how to do it, it is not that hard.
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 
Workflow files
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 setup-jpm action:
jobs:
build:
name: build on OpenJDK Linux
runs-on: ubuntu-latest
steps:
- name: Git Checkout
uses: actions/checkout@v2.4.0
- name: Set up Java
uses: actions/setup-java@v1
with:
java-version: 1.8
- name: install gradle
uses: pkriens/setup-jpm@v1.0.0
And then
- name: Build
shell: bash
run: |
jpm install -f biz.aQute.bnd:biz.aQute.bnd:6.2.0-SNAPSHOT
bnd buildtool -f
./gradlew --parallel build
Conclusion
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?