DEV Community: Bjarne Rentz

Configure DependencyTrack with Terraform

Bjarne Rentz — Sun, 15 Feb 2026 14:49:24 +0000

Dependency management and Software Bill of Materials (SBOMs) are more important than ever. With the upcoming EU Cyber Resilience Act, they are becoming a legal mandate for many organizations. Even beyond compliance, using SBOMs in combination with reproducible builds as your "source of truth" for dependencies is a good security practice.

DependencyTrack is a great tool from OWASP for managing SBOMs and auditing vulnerabilities of used dependencies. DependencyTrack is built around projects. While a project type (e.g., Application, Container Image) is technically just a label, how you structure them matters.

I recommend creating a standalone project for each component of your application (e.g., separate projects for your frontend and backend). This separation provides:

Contextual Auditing: Vulnerabilities are easier to triage when you know exactly which layer they affect.
Statistical Transparency: Clearer metrics on component counts per service.
Hierarchical Organization: Better integration with Collection Projects.

Collection Projects allow you to organize projects in a tree based structure. As an example, for an app My Calendar you can create a parent collection project that aggregates data from its child projects (Frontend and Backend). These collection project can't contain any direct components but rather aggregate them from their child projects dependent on the configuration.

As you probably already guessed, they are great to structure multiple apps, containing multiple components deployed across different environments such as dev or prod:

- My-Shop
  - Basket Service
    - Basket Service (Dev)
      - Basket Service Frontend (Dev)
      - Basket Service Backend (Prod)
    - Basket Service (Prod)
      - Baskend Service Frontend (Dev)
      - Basket Service Frontend (Prod)
  - Payment Service
    ...

The main hurdle to this granular approach is the manual effort required to set up dozens of nested projects. This is where the DependencyTrack Terraform Provider becomes essential.

The provider automates the creation of nested structures, teams, permissions, and LDAP mappings. If you want to dive straight into a "Product Group" approach - grouping services like Payment, Basket, and Inventory into a single functional unit - I’ve developed a Terraform Module to handle the heavy lifting for you.

Even if you don't use my module, you should treat your DependencyTrack configuration as code. Moving away from manual clicks ensures:

Auditability: Every change is tracked in version control.
Disaster Recovery: Easily restore your entire project structure if a database is lost.
Living Documentation: Your HCL files explain the setup better than a "lost" colleague ever could.

Journey Developing an Obsidian Plugin Part 2 - Improving the Architecture, Basic Error Handling and more!

Bjarne Rentz — Mon, 06 Jan 2025 18:44:49 +0000

Welcome back to the second part! In the first part, we explored the basics of creating an Obsidian plugin. If you missed it, I recommend reading it first. Now we'll improve the overall architecture and file layout of the plugin as well as adding basic error handling. Furthermore, I share my learnings from releasing the first patch versions, lets get started!

The Starting Point

Starting from the mentioned plugin-template, the overall structure of the plugin are a bunch of files all within the root folder of the repository:

main.ts
styles.css
manifest.json
versions.js

While not displaying technical configurations files such as package.json. The plugins's entire source code, including its settings, UI and logic is contained in a single file, main.ts. While serving the point of a starting point and template, this does not represent a good structure for further feature development.

The Desired State

Before describing the current layout and architecture, let's first recap some general guidelines used in this process:

Start simple and improve / reconcile as you grow: You don't win anything, if you start your simple project with the ultimate, scalable architecture. Start simple with your current requirements while being open for changes.
Separate different tasks into different files. We want to get rid of a single main.ts, that is responsible for all aspects of the plugin. With that done, I first started to separate all the classes within the main.ts into their own files and moved all of them into a src directory yielding:

src
|   commands.ts
|   gemini-client.ts
|   main.ts
|   settings-tab.ts
|   settings.ts
package.json
package-lock.jsoon
README.md

The main idea behind this structure is the separation of different tasks of the plugin into their own files: settings-tab.ts and settings.ts defines the UI and data structures for the required API-Key settings.
The single command of this plugin (with room to add more) is defined in commands.ts and gemini-client.ts abstracts the official Gemini library for the specific use case of this plugin and is used by the command. All parts are wired together in main.ts which bootstraps the plugin within the onload function:

export default class GeminiGenerator extends Plugin {
    settings: GeminiGeneratorSettings;

    // Loads the plugin.
    async onload() {
        await this.loadSettings();      

        this.addSettingTab(new GeminiGeneratorSettingTab(this.app, this));

        this.addEditorCommands();
    }

    private addEditorCommands() {
        for (const command of getEditorCommands(this)) {
            this.addCommand(command);
        }
    }

    ...
}

In contrast to the initial version, the main.ts got rid of all dependencies of the command. It only handles the settings and registers all EditorCommands (line 10). This registration is implemented with a combination of factory functions and dependency injection.

Quick recap, EditorCommands are registered in Obsidian though the call of addCommand, providing an object with the commands configuration and the callback, which represents the commands implementation:

this.addCommand(
    { id: 'print-greeting-to-console', 
      name: 'Print greeting to console', 
      callback: () => { console.log('Hey, you!'); 
    },
});

Hence, we are only able to register one command at a time. This is the reason, the private method addEditorCommands of main.ts iterates over a list of commands, returned by getEditorCommands and registers them one-by-one. As the commands implementation require a reference to the plugin respectively editor, this is passed as an argument.

The implementation is rather simple: The method simply returns a list of all (currently one) commands which are created through their corresponding factory function, which intern construct and return the mentioned command object required by the Obsidian API.

export const getEditorCommands = (plugin : GeminiGenerator) => 
    [
        buildGenerateNoteCommand(plugin)
    ];

With the addition of more commands, it could prove useful to create a new folder Commands, where each command is defined within its own file.

All in all, this structure offers several advantages:

Clearer separation of concerns
Improved scalability for future features
Easier maintenance # Basic Error Handling The current error handling is minimal at most, but this series is about sharing my leanings, so here we go! The main error handling can be described by four lines:

if(!result){
    notice.setMessage("❌ An error occured during the Google Gemini Request")
    return;
}

Basically, if any error occurs during the request to Google Gemini, a small error toast is shown. This served well for the beginning, yet this is not very precise for the user, as some prompts would benefit from a more differentiated error message.
Hence, I would suggest you to think about feasible error cases and messages. Do not overstrain your users with technical messages, while displaying enough information enabling to distinguish an input error from a server error for example.

Learnings from Releasing the first Versions

I use a small GitHub Action for bundling an creating a GitHub Release whenever I a git tag is pushed / created. The GitHub release is created as a draft, such that I'm able to adapt the release log or title. If you are using this setup as well, do not forget to publish this release, as otherwise no one will be able to update / download your plugin anymore. That's because in you repository, the versions.json already contains you new version but as the GitHub release is still a draft, no one is able to download it.

If you have the same setup as I do, I would recommend following this procedure:

Push a git tag for a new version
Wait for the Action to finish
Validate the created release draft
Publish the release

Again, thanks for reading and following this small series. As always, if you have suggestions or feedback, I'd love to hear from you in the comments! I'm looking forward to having more time for further development of the plugin. In the next part, we will add some more settings and another command, so stay tuned!

Further Resources and Tips

Take a look at other Obsidian plugins such as Obsidian Linter, they are all open source!
Start simple, be open to change and adapt as you go
Sourcecode of this plugin

Journey: Developing an Obsidian Plugin Part 1 - Getting Started

Bjarne Rentz — Tue, 06 Aug 2024 14:10:40 +0000

First of all, to set the right expectations, this is not a tutorial on how to develop Obsidian plugins. It's just a write-up of my journey developing and publishing an Obsidian plugin. I will write about my problems and my lessons learned, but not a step-by-step tutorial. The first part we will cover the idea, getting started with the development and submitting the MVP.

The Idea

As you may have probably noticed, everyone is talking about AI. So why not jump on the hype train as well? For university (and everything else) I use the fantastic note-taking tool Obsidian. Once in a lecture I asked myself, why don't use ChatGPT or Google Gemini for this? Sure, the details are probably pretty bad on some topics, but the overall structure is already there. So I started with Google Gemini and the simple prompt Generate me an Obsidian Markdown Note on: >>NoteTitel<< and copied the result into Obsidian.

Depending on the topic, the notes were acceptable and needed only minor changes. I asked myself:

Wouldn't it be easier to just create the note in Obsidian, set the title and with the help of a plugin and AI, use a command to generate the Note.

That's the simple, yet handy idea behind my plugin Gemini Generator. For a better understanding the GIF shows the workflow with Gemini Generator.

Starting the Project

At first I was a bit overwhelmed not knowing where to start. However, although it only shows the basics and not many examples of plugin functionality, the Obsidian tutorial and the sample plugin, which provides the basic structure of a plugin, are a good place to start. It's often easier to start with something simple and learn as you go, rather than planning and researching everything in advance. Sure, it's always important to plan a basic path for learning something new, but leave some room for learning along the way!

Starting with forking the sample project and renaming all relevant class names, the first goals were to find the appropriate command type and how to get the title of the currently open note. The first task was easily solved with the EditorCommand, as it provides an instance of the Editor for writing the response and is only available when an Editor-tab is open and active - exactly what we needed.

Getting the title of the currently active note was not so easy. My first guess was to use the mentioned instance of the Editor available through the EditorCommand. Unfortunately, I found no useful way to get the desired title. After searching the documentation (that has room to improve) and trying different things out, I ended up with plugin.app.workspace.getActiveFile()?.basename;. I'm not sure, weather its the best way or not. So please let me know if there is a better way!

Well, we have a command, the notes title, but the Gemini response is missing. Luckily, Google provides an easy to use NPM package and the first basic command implementation was done:

this.addCommand({
    id: "generate-note",
    name: "Generate Note with Gemini",
    editorCallback: async (editor: Editor) => {
        const title = this.app.workspace.getActiveFile()?.basename;
        if (!title) {
            new Notice("Could not get filename", 1500);
        }

        editor.setCursor(editor.lastLine());

        const prompt = `Write a me an Obsidian Markdown Note without the Title on:${title} `;
        const result = await model.generateContentStream(prompt);

        for await (const chunk of result.stream) {
            const chunkText = chunk.text();
            editor.replaceRange(chunkText, editor.getCursor());
            editor.setCursor(editor.lastLine());
        }
            new Notice("✅ Finished", 1500);
    },
});

As you can see, I wanted to use the stream-based response for a more responsive note generation. To do this, we need to append the current chunk to the end of the editor using replaceRangeand setCursor. Just using replaceRange did not work, because it keeps the cursor at the original position.

Alright, the editor command is up and running - only task left is to publish? It would be possible, but as I like to automate things, I wanted to add a CI pipeline before publishing the first version. The pipeline is triggered by a git tag and performs the two simple steps:

Build the plugin (npm ciand npm run build)
Create a draft release using the Github CLI.

Thus, for a new release, I can use the recommended command npm version (patch|minor|major), do a git push --tags, verify the release and publish it.

Submitting the Plugin

My original goal was to submit the plugin as soon as possible and provide new features as updates. However, during development I came up with new ideas: custom prompts, being able to change the default prompt, response processing, etc.
However, I decided to postpone them until after the initial release in order to gain experience in submitting and managing the first public release.

Hence, it was time to submit the first version of Gemini Generator. As mentioned above, a Github release is already created through the pipeline. However, in order for the plugin to be found by Obsidian, you need to submit the plugin for review and approval, as described in this guide. During this process, my pull request encountered a strange error where the pipeline performing some automated checks failed to checkout the pull request. I asked for help on the official Obsidian Discord server (which I can strongly recommend!), but the suggested fixes did not work. In the end, I had to close the PR and create a new one. After a few days, I got the approval and the first version of Gemini Generator was publicly available!

In part two we will improve the architecture of the plugin, add basic error handling and implement a first basic version of automatic response processing. So, if you're interested, don't forget to follow.

If you want to have a look at source code as well, you can find the Github Repo here.