DEV Community: Luis Iñesta Gelabert

What I underestimated about open-source: getting users after the project already works

Luis Iñesta Gelabert — Wed, 03 Jun 2026 15:10:42 +0000

I’m currently building an open-source project, and I think I understand fairly well why getting users is hard — but I still don’t have a clear mental model for what actually moves the needle.
I already wrote about Azertio itself in a previous post, so I won’t go into what it is or how it works in detail.

This is more about something I’ve learned while building it: the gap between “a working open-source project” and “a project that actually gets users” is much larger than I expected.

I think I understand the reasons behind it fairly well at this point, but I still don’t have a clear model for what actually turns that understanding into traction.

A few observations from the experience so far:

“It works” is not a growth factor

Once a project reaches a usable baseline, functionality stops being the main constraint.

At that point, additional improvements tend to have diminishing returns in terms of adoption. The difference between “good enough” and “very good” is often not what determines whether people try it. Most potential users never reach that evaluation stage in the first place.

In practice, “it works” is necessary, but almost irrelevant for getting initial attention.

Discovery is the real bottleneck

The hardest problem is not convincing someone who has already seen the project — it’s getting them to see it at all.

There are a few concentrated channels where discovery happens (communities, feeds, word of mouth), and if you don’t get initial visibility in those places, the project tends to remain invisible regardless of quality.

This makes early distribution disproportionately important compared to everything else.

OSS removes friction of use, not friction of adoption

Open source is often associated with easier adoption, but that only applies after someone is already interested.

It reduces barriers like pricing, licensing, and sometimes trust. But it doesn’t meaningfully reduce the biggest barrier, which is awareness.

In other words, OSS helps once the decision to try it is already made — but does very little to influence whether that decision happens at all.

Early momentum dominates everything

There seems to be a strong feedback loop at the beginning of a project’s life.

If early exposure happens in the right places, momentum can build relatively quickly. If it doesn’t, the project tends to plateau, even if it is useful or well designed.Later improvements don’t seem to fully compensate for missing that initial wave of attention.

What I missing

What I understand reasonably well is why this happens. The part I don’t have is a clear sense of what actually works as a lever at that early stage. I can list the usual approaches — writing about it, posting in communities, word of mouth, waiting for timing, etc. — but I don’t yet have a strong mental model for what reliably creates that first meaningful set of users in practice.

I’d be interested in hearing from others. If you’ve worked on open-source projects, I’d really like to hear your experience:

What actually brought your first meaningful users to a project?
Was there a specific channel or action that made the difference, or was it mostly timing and persistence?
Looking back, what do you think you underestimated most at the beginning?

I’m less interested in generic advice and more in concrete experiences or patterns you’ve personally seen work (or fail). I’m trying to understand what the real “levers” are at this stage, if they exist at all.

When Cucumber Grows Too Big: Pain Points, Lessons Learned, and Alternatives

Luis Iñesta Gelabert — Wed, 27 May 2026 13:19:13 +0000

What Is Cucumber, and Why Do Teams Love It?

If you have spent any time in behavior-driven development (BDD), you have almost certainly encountered Cucumber. First released in 2008, it has become the de facto standard for writing executable specifications in plain language.

The core idea is elegant: tests are written in Gherkin, a structured natural language format built around three keywords — Given, When, and Then. A product owner, a tester, and a developer can all read the same file and agree on what the system is supposed to do.

Feature: User login

  Scenario: Successful login with valid credentials
    Given the user "alice" exists with password "secret"
    When she submits the login form
    Then she is redirected to the dashboard
    And a session cookie is set

Under the hood, each step is matched by a regular expression or a cucumber expression to a step definition — a method in Java, Ruby, JavaScript, or whatever language your project uses. Cucumber finds the right method, runs it, and aggregates the results into a report.

The promise is compelling: business-readable tests that are also executable. The gap between what stakeholders describe and what testers automate, closed forever. In small projects and well-contained modules, it genuinely works.

Where Things Start to Break Down

I spent several years working on large backend systems where Cucumber was adopted as the standard integration testing tool. Early on, things were manageable. Over time, a set of recurring problems emerged that no amount of team discipline could fully solve.

1. The Glue Code Explosion

Every Gherkin step needs a step definition. In a project with hundreds of scenarios covering REST APIs, databases, message queues, and background jobs, this means hundreds — sometimes thousands — of step definition methods spread across dozens of classes.

The immediate problem is discoverability. When a new developer writes a step, how do they know whether it already exists? The IDE can sometimes help, but step matching relies on regular expressions that are not always obvious to navigate. You end up with:

Duplicate step definitions that do subtly different things
Slightly different phrasing that bypasses an existing step and creates a new one
Inconsistent abstractions because different people solved the same problem independently

The deeper problem is coupling. Step definitions are not unit-tested; they are integration plumbing. When a REST client is refactored, you find that fifteen step definitions directly instantiate it. When a database fixture format changes, you discover that nobody documented which step methods touch which tables.

2. Shared State and Context Passing

Cucumber scenarios are supposed to be independent, but step definitions need to share state: the HTTP response from the When step needs to be inspectable in the Then step. The standard solution is a World object (or @ScenarioScoped beans in Java) — a bag of shared state injected into step definition classes.

This works until you have fifteen step definition classes all mutating the same World, nobody owns the contract for what each field means, and a flaky test appears because some scenario left dirty state that wasn't cleaned up. Debugging it means reading glue code, not feature files — which defeats half the purpose of BDD.

3. The Feature File Drift Problem

In a healthy BDD process, feature files are living documents co-authored by business and technical people. In practice, after the initial sprint, product owners stop reading them. They become developer-only artifacts, written with the same mindset as JUnit tests: exhaustive, technical, and opaque to anyone outside the team.

You end up with scenarios like:

Given the user entity with id 42 exists in schema "core" table "users" with status "ACTIVE"
When the endpoint POST /api/v2/auth/session is called with payload from fixture "auth_fixtures/alice_valid.json"
Then the response body path "$.data.token" matches regex "[A-Za-z0-9-_]{40}"

This is not BDD. It is JUnit with extra ceremony.

4. Step Definition Scope Creep

In Cucumber, step definitions are global. There is no namespacing, no module boundary, no way to say "these steps belong to the payments domain." As the test suite grows, you inherit every step ever written, and step expressions start colliding.

Teams work around this with naming conventions, careful phrasing, and tribal knowledge. That is technical debt in disguise.

5. Maintenance Cost Compounds Over Time

Every refactor of production code ripples through glue code. A renamed endpoint, a changed response schema, a migrated database table — each one can silently break dozens of step definitions, or worse, fail to break them because a step is now asserting against stale data that happens to still match.

The test suite that was supposed to give you confidence becomes a maintenance burden that slows releases down. At some point the question stops being "how do we fix the tests?" and becomes "is this the right tool for this job?"

The Specific Pain That Made Me Reconsider

The breaking point for me was the combination of two things happening simultaneously.

First, onboarding friction. A new team member joining the project needed days to understand the glue code before they could write a single new test. The feature files were not self-explanatory; they were a surface sitting on top of an iceberg of implementation. That is the opposite of what BDD promises.

Second, the semantic gap for API testing. Our integration tests were almost entirely black-box: send an HTTP request, assert on the response, check the database state. For this use case, Cucumber adds a translation layer — Gherkin step → step definition → HTTP client call — that provides no value. The "business readable" framing makes no sense for Then the response status is 200. Nobody is showing those files to a product owner.

We were paying the full cost of Cucumber's glue code model while getting almost none of its BDD benefits.

Alternatives Worth Considering

Depending on what is actually causing your pain, different tools address different problems.

Karate is the closest direct alternative for API testing. It uses a Gherkin-like syntax but eliminates step definitions entirely — steps are interpreted directly by the framework. You get zero glue code for REST and GraphQL testing, plus built-in mocking and performance testing. If your Cucumber usage is primarily API testing, Karate is worth a serious look.

REST-assured (with JUnit or TestNG) takes the opposite position: abandon the DSL entirely and write your tests as code. You lose the business-readable layer, but you gain the full power of a proper programming language — real abstractions, composable helpers, IDE support, type safety. For teams that have already given up on non-developer readers, this is often the pragmatic choice.

Playwright / Cypress are not Cucumber replacements, but if your integration tests are UI-heavy, their built-in test organization and recording capabilities may do more for you than Cucumber's BDD layer.

SpecFlow (for .NET) and Behave (for Python) are Cucumber-family tools that sometimes have better ecosystem integration for their respective stacks, though they share the same architectural tradeoffs.

The rule of thumb I arrived at: Cucumber earns its keep when the scenario files are genuinely read and validated by non-developers on a regular basis. If that is not happening — and it often is not — you are paying glue-code tax for a benefit you are not receiving.

A Tool Built From These Lessons

After working through these problems repeatedly, I designed Azertio as an attempt to take what Cucumber gets right (human-readable Gherkin, structured scenario files) and eliminate what causes the most pain in large projects.

The central bet: for black-box testing of REST APIs and databases, there should be no glue code at all. Steps are provided by plugins loaded at runtime — rest, db, and others — and every step in those plugins is immediately available in any feature file without any wiring. You declare which plugins you use in a YAML config file and write tests immediately.

Scenario: Creating an order reduces stock
  Given db table stock has:
    | sku   | units |
    | P-001 | 10    |
  When I make a POST request to "orders" with body:
    """json
    { "sku": "P-001", "quantity": 3 }
    """
  Then the HTTP status code is equal to 201
  And db table stock row where sku = "P-001" has units = 7

No step definitions. No World objects. No regex to maintain.

It also directly addresses the definition/implementation split that Cucumber struggles with: you can write a definition feature (business-readable, owned by the product team) and a separate implementation feature (technical, owned by testers), linked by a tag. The execution report shows the business structure; the implementation details stay out of the way.

The project is open source, still early, and genuinely shaped by the frustrations described in this article. If any of this resonates with your own Cucumber experience, I would be glad to hear your feedback at azertio.org.

Have you hit any of these Cucumber pain points in your own projects? Which solutions worked for you? Let me know in the comments.

Azertio: API and Database Testing Without the Glue Code

Luis Iñesta Gelabert — Sun, 17 May 2026 17:37:07 +0000

If you have ever maintained a Cucumber + RestAssured test suite, you know the feeling. The feature files look clean. But underneath there are dozens of step definition classes, ScenarioContext maps to pass state between steps, @Before hooks to wire up the HTTP client, and a pom.xml that has grown to include JDBC drivers, connection pools, and fixtures loaders just to back up a few database assertions.

The tests work. But they are a project in themselves.

Azertio is a new open-source testing tool that takes a different approach: instead of writing glue code, you declare plugins. Instead of managing a build file, you configure a YAML file. Instead of parsing JUnit XML reports, you browse a live execution history in your IDE.

Let me walk you through what it does and how it is designed.

The Problem: Tests That Require Too Much Code

BDD tools like Cucumber are built around a promise: business stakeholders write the test scenarios, developers implement the steps. In practice this rarely holds. Every new step a tester wants to use requires a developer to:

Write a Java method annotated with @Given, @When, or @Then
Wire it to a Gherkin expression via a regex
Manage shared state between steps
Register configuration in a Spring context or a custom hook

The result is that feature files — the part everyone can read — are tightly coupled to a growing body of Java infrastructure that almost nobody reads. And this infrastructure is per-project: if three teams test REST APIs, each team writes their own iMakeGetRequest and statusCodeIs methods.

Azertio's premise is simple: the most common test steps should already exist as reusable, versioned plugins, and you should not need to write any Java to use them.

How It Works

An Azertio project consists of two things: an azertio.yaml configuration file and your .feature files. That's it — no pom.xml, no step definition classes, no build tool.

# azertio.yaml
testProject:
  organization: Acme Corp
  name: Payment Service Tests
  test-suites:
    - name: smoke
      tag-expression: "smoke"
    - name: regression
      tag-expression: "regression or smoke"

plugins:
  - gherkin
  - rest
  - db with org.postgresql:postgresql-42.7.3

configuration:
  rest:
    baseURL: "{{base-url}}/api"
    timeout: 10000

profiles:
  dev:
    base-url: http://localhost:8080
  staging:
    base-url: https://staging.example.com

Then you install the plugins (downloaded from Maven Central and cached locally):

azertio install

And run your tests:

azertio run -s smoke -p staging

Your feature files can use REST and database steps immediately, with no backing code:

Scenario: Creating a payment persists it in the database
  When I make a POST request to "payments" with body:
    """json
    { "amount": 49.99, "currency": "EUR", "card": "4111111111111111" }
    """
  Then the HTTP status code is equal to 201
  And I store the value of field "id" from the response body into variable paymentId
  * use db "main"
  * db query:
    """sql
    SELECT status FROM payments WHERE id = '${paymentId}'
    """
  * db query count = 1

Variable interpolation (${paymentId}) is first-class. No custom parameter types, no manual string replacement.

Architecture: Plugins All the Way Down

Every capability in Azertio is a plugin — including the Gherkin parser, the REST steps, and the database steps. Plugins are standard Maven artifacts loaded at runtime via the Java Platform Module System (JPMS).

This has concrete consequences:

No classpath pollution. Each plugin runs in its own module layer. A plugin's dependencies cannot interfere with the core runtime or with other plugins. You can have two plugins that depend on different versions of the same library without conflict.

Runtime dependency declaration. Need to test a MySQL database? Add db with com.mysql:mysql-connector-j to azertio.yaml. The JDBC driver is downloaded from Maven Central and loaded into the plugin's module layer at runtime. No pom.xml edit required, because there is no pom.xml.

True extensibility. Writing a custom step plugin is straightforward: implement StepProvider, annotate methods with @StepExpression, and publish the artifact to any Maven repository. Teams that consume it just add one line to azertio.yaml.

@Extension(name = "My Protocol", scope = Scope.TRANSIENT)
public class MyStepProvider implements StepProvider {

    @StepExpression(value = "my.connect", args = {"host:text", "port:integer"})
    public void connect(String host, int port) {
        // your implementation
    }
}

The consuming project gets it automatically on the next azertio install — no code changes, no dependency management.

Benchmark Mode: Performance Testing Without a Separate Tool

One problem with specialized testing tools is proliferation. You have one tool for functional tests (Cucumber), one for performance (Gatling or k6), and you end up maintaining the same test logic in two places.

Azertio has a built-in benchmark mode that works on any compatible step in the same .feature file:

Scenario: Functional — retrieve payment
  When I make a GET request to "payments/1"
  Then the HTTP status code is equal to 200

Scenario: Performance — retrieve payment meets SLA
  Given benchmark mode is enabled with 500 executions and 16 threads
  When I make a GET request to "payments/1"
  Then the benchmark P95 response time (ms) is less than 150
  Then the benchmark error rate is equal to 0.0
  Then the benchmark throughput (req/s) is greater than 200.0

Benchmark runs use virtual threads for high concurrency with low resource overhead. Statistics (min, max, mean, P50, P95, P99, throughput, error rate) are stored with the execution and visible in the VS Code extension alongside functional results. If the P95 threshold is breached, the CI build fails — no Gatling server, no separate pipeline stage.

The Definition / Implementation Model

One of Azertio's most distinctive features is a two-level scenario model that has no direct equivalent in other tools.

In most BDD projects, feature files serve two masters at once: business stakeholders who need to validate that tests reflect real requirements, and engineers who need steps precise enough to execute. These two needs pull in opposite directions, and the result is usually a compromise that satisfies neither.

Azertio solves this with a formal separation. A definition feature (tagged @definition) contains the abstract, business-readable test intent:

@definition
Feature: User Registration

@ID-REG-01
Scenario: A new user can register with valid data
  Given a valid registration form
  When the form is submitted
  Then the account is created
  And a welcome email is sent

An implementation feature (tagged @implementation) contains the concrete, executable steps, matched to the definition by identifier:

@implementation
Feature: User Registration — REST

# gherkin.step-map: 1-1-1-1
@ID-REG-01
Scenario: A new user can register with valid data
  When I make a POST request to "users" with body:
    """json
    { "name": "Alice", "email": "alice@example.com" }
    """
  Then the HTTP status code is equal to 201
  And the response body contains:
    """json
    { "email": "alice@example.com" }
    """
  And the response body field "welcomeEmailSent" is equal to "true"

At plan-build time the two files are merged. The result tree shows the definition structure — business-readable, approvable in a pull request — while executing the implementation steps underneath each abstract step. Stakeholders see the definition; the framework runs the implementation.

The gherkin.step-map comment controls how many implementation steps correspond to each abstract definition step, including 0 for steps that should appear in the result tree but not execute.

This model is particularly useful for:

Regulatory traceability — the definition is the signed-off specification; the implementation is the audit trail.
Multilingual teams — definition in the business language, implementation in the team's preferred language.
Protocol evolution — one definition, multiple implementations (REST today, gRPC tomorrow).

Execution History and VS Code Integration

A persistent frustration with most testing tools is that execution history vanishes. JUnit XML reports go into target/, CI artifacts expire after 30 days, and there is no way to compare last Thursday's run with today's without a separate Allure or ReportPortal setup.

Azertio has a built-in persistence layer with three modes:

Mode	Backend	Use case
`transient`	Temp HSQLDB (deleted on exit)	CI pipelines that only need pass/fail
`file`	HSQLDB file in `.azertio/`	Developer workstation
`remote`	PostgreSQL + MinIO	Shared team history

In remote mode, every CI run writes the full execution tree — plan, suites, scenarios, steps, timings, and binary attachments — to a shared PostgreSQL database. Every developer's VS Code extension connects to the same backend and can browse, inspect, and re-run any past execution from any branch or CI run.

The VS Code extension connects to the CLI via a JSON-RPC server and provides:

Execution history with date, duration, and pass/fail status
Result tree navigation from suite down to individual steps with timings
Attachment inspection — response bodies, CSV query results, any data produced by steps
One-click re-run of any past execution against its original plan and profile
Inline benchmark statistics alongside functional results

No Allure server. No external dashboard. No configuration beyond the persistence block in azertio.yaml.

Comparison: How Azertio Fits Against Other Tools

vs. Cucumber + RestAssured

Cucumber requires glue code for every step — a Java method annotated with @Given/@When/@Then. RestAssured provides the HTTP layer, but state management between steps, configuration wiring, and especially database assertions are all your problem.

Azertio eliminates glue code entirely. The rest and db plugins cover the majority of API and database testing scenarios without writing any Java. When you do need custom steps, you write a plugin once and reuse it across all projects.

The tradeoff: if your tests are tightly coupled to a Spring Boot application context (accessing internal services, using transactional rollback between scenarios), Cucumber + RestAssured remains the right tool. Azertio is explicitly a black-box tool and does not access application internals.

vs. Karate

Karate embeds a JavaScript engine inside .feature files. You can call Java, write loops, and use conditional logic directly in feature files — which is powerful, but it means tests become mini-programs that non-technical stakeholders cannot read or validate.

Azertio enforces a clean boundary: feature files contain only declarative steps, all logic lives in typed Java step providers. The configuration model is also fundamentally different — Karate uses a karate-config.js JavaScript file for environments, while Azertio uses pure YAML profiles. Azertio also has first-class features that Karate lacks: the definition/implementation model, built-in persistence, and a dedicated VS Code extension.

The tradeoff: Karate has a larger ecosystem, more community resources, and built-in support for protocols (gRPC, WebSocket) not yet available as Azertio plugins.

vs. Postman / Newman

Postman is an excellent tool for interactive API exploration. Newman makes collections runnable in CI. The problems emerge when teams graduate to treating tests as code: Postman collections are proprietary JSON that produces noisy diffs, assertions are JavaScript scattered across collection items, and there is no database testing, no benchmark mode, and no persistent execution history.

Azertio's .feature files are plain text, fully diffable, reviewable in pull requests, and readable by business stakeholders. The two tools are not mutually exclusive — many teams use Postman for initial exploration and translate validated scenarios into Azertio for the automated regression suite.

Quick Start

# 1. Download the distribution from GitHub releases and add bin/ to PATH

# 2. Create azertio.yaml in your project
cat > azertio.yaml <<EOF
testProject:
  name: My Project
  test-suites:
    - name: smoke
      tag-expression: "smoke"
plugins:
  - gherkin
  - rest
configuration:
  rest:
    baseURL: "https://jsonplaceholder.typicode.com"
EOF

# 3. Write a feature file
mkdir -p features && cat > features/posts.feature <<EOF
@smoke
Feature: Posts API

  Scenario: Retrieve a post
    When I make a GET request to "posts/1"
    Then the HTTP status code is equal to 200
    And the response body contains:
      """json
      { "id": 1 }
      """
EOF

# 4. Install plugins
azertio install

# 5. Run
azertio run -s smoke

Where Things Stand

Azertio is in early alpha. The core runtime, the REST plugin, and the database plugin are functional; the VS Code extension is published. Protocol plugins for gRPC, GraphQL, and WebSocket are on the roadmap but not yet available.

If you are building a new test suite for API and database testing and want clean feature files, no glue code, and execution history out of the box — it is worth a look.

GitHub: github.com/org-azertio/azertio
Getting started: docs/getting-started.md

JExten: Building a Robust Plugin Architecture with Java Modules (JPMS)

Luis Iñesta Gelabert — Thu, 15 Jan 2026 16:45:48 +0000

1. Motivation: The Road to Modular Isolation

When building extensible applications in Java, developers often start with a simple question: "How can I let users add functionality without recompiling the core application?" The journey usually begins with the standard java.util.ServiceLoader, which provides a simple mechanism for discovering implementations of an interface.

However, as the application grows, a critical problem emerges: "Classpath Hell."

Imagine you have a host application that uses library-v1. You create a plugin system, and someone writes a "Twitter Plugin" that requires library-v2. If you run everything on the same flat classpath, you get a conflict. Either the host crashes because it gets the wrong version of the library, or the plugin fails. You cannot have two versions of the same library on the classpath without facing the risk of runtime exceptions such as ClassDefNotFoundError or NoSuchMethodError.

This was the driving motivation behind JExten. I needed a way to strictly encapsulate plugins so that each one could define its own dependencies without affecting the host or other plugins.

Enter JPMS (Java Platform Module System)

Java 9 introduced the Module System (JPMS), which provides strong encapsulation and explicit dependency graphs. It allows us to create isolated "layers" of modules.

Boot Layer: The JVM and platform modules.
Host Layer: The core application and its dependencies.
Plugin Layers: Dynamically created layers on top of the host layer.

By leveraging JPMS ModuleLayers, JExten allows Plugin A to rely on Jackson 2.14 while Plugin B relies on Jackson 2.10, and both can coexist peacefully within the same running application.

2. Architecture and Design

JExten is designed to be lightweight and annotation-driven, abstracting away the complexity of raw ModuleLayers while providing powerful features like Dependency Injection (DI) and lifecycle management.

The architecture consists of three main pillars:

The Extension Model

At the core, JExten uses a clean separation between the "contract" (API) and the "implementation".

Extension Point (@ExtensionPoint): An interface defined in the host application (or a shared API module) that defines what functionality can be extended.
```
@ExtensionPoint(version = "1.0")
public interface PaymentGateway {
    void process(double amount);
}
```

Extension (@Extension): The concrete implementation provided by a plugin.

@Extension(priority = Priority.HIGH)
public class StripeGateway implements PaymentGateway {
    // ...
}

Notice that you can make use of the ExtensionManager without the PluginManager. This is useful for testing or when you want to use JExten in a non-plugin environment and all the extensions are already available in the modulepath.

The Manager Split

To separate concerns, the library splits responsibilities into two distinct managers:

PluginManager ("The Physical Layer"):
- This component handles the raw artifacts (JARs/ZIPs).
- It verifies integrity using SHA-256 checksums ensuring that plugins haven't been tampered with.
- It builds the JPMS ModuleLayer graph. It reads the plugin.yaml manifest, resolves dependencies (from a local cache or Maven repo), and constructs the classloading environment.
ExtensionManager ("The Logical Layer"):
- Once layers are built, this component takes over.
- It scans the layers for classes annotated with @Extension.
- It manages the lifecycle of these extensions (Singleton, Session, or Prototype scopes).
- It handles Dependency Injection.

Dependency Injection (DI)

Since plugins run in isolated layers, standard DI frameworks (like Spring or Guice) can sometimes be "too heavy" or tricky to configure across dynamic module boundaries. JExten includes a built-in, lightweight DI system.

You can simply use @Inject to wire extensions together:

@Extension
public class MyPluginService {
    @Inject
    private PaymentGateway gateway; // Automatically injects the highest priority implementation
}

This works seamlessly across module boundaries. A plugin can inject a service provided by the host, or even a service provided by another plugin (if the module graph allows it).

3. Usage Example

Here is a quick look at how to define an extension point, implement it in a plugin, and use it in your application.

I. Define an Extension Point

Create an interface and annotate it with @ExtensionPoint. This is the contract that plugins will implement.

@ExtensionPoint(version = "1.0")
public interface Greeter {
    void greet(String name);
}

II. Implement an Extension

In your plugin module, implement the interface and annotate it with @Extension.

@Extension
public class FriendlyGreeter implements Greeter {
    @Override
    public void greet(String name) {
        System.out.println("Hello, " + name + "!");
    }
}

III. Discover and Use

In your host application, use the ExtensionManager to discover and invoke extensions.

public class Main {
    public static void main(String[] args) {
        // Initialize the manager
        ExtensionManager manager = ExtensionManager.create(pluginManager);

        // Get all extensions for the Greeter point
        manager.getExtensions(Greeter.class)
               .forEach(greeter -> greeter.greet("World"));
    }
}

IV. Package your Extension(s) as a Plugin

Finally, use the jexten-maven-plugin Maven plugin to check your module-info.java at compile time and package your extension into a ZIP bundle that includes all dependencies and the generated plugin.yaml manifest.

<plugin>
    <groupId>org.myjtools.jexten</groupId>
    <artifactId>jexten-maven-plugin</artifactId>
    <version>1.0.0</version>
    <executions>
        <execution>
            <goals>
                <goal>generate-manifest</goal>
                <goal>assemble-bundle</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <hostModule>com.example.app</hostModule>
    </configuration>
</plugin>

You can then install the generated ZIP bundle to your host application:

  public class Application {
    public static void main(String[] args) throws IOException {
        Path pluginDir = Path.of("plugins");

        // Create plugin manager
        PluginManager pluginManager = new PluginManager(
            "org.myjtools.jexten.example.app",  // Application ID
            Application.class.getClassLoader(),
            pluginDir
        );

        // Install plugin from bundle
        pluginManager.installPluginFromBundle(
            pluginDir.resolve("my-plugin-1.0.0.zip")
        );

        // Create extension manager with plugin support
        ExtensionManager extensionManager = ExtensionManager.create(pluginManager);

         // Get extensions from the plugin
        extensionManager.getExtensions(Greeter.class)
            .forEach(greeter -> greeter.greet("World"));
    }
}

4. Comparison with Other Solutions

Choosing the right plugin framework depends on your specific needs. Here is how JExten compares to established alternatives:

PF4J (Plugin Framework for Java)

PF4J is a mature, lightweight plugin framework that relies on ClassLoader isolation.

Isolation: PF4J uses custom ClassLoaders to isolate plugins. JExten uses JPMS ModuleLayers. The latter is the "native" Java way to handle isolation since Java 9, strictly enforcing encapsulation at the JVM level.
Modernity: While PF4J is excellent, JExten is designed specifically for the modern modular Java ecosystem (Java 21+), taking advantage of module descriptors (module-info.java) for defining dependencies rather than custom manifests.

OSGi

OSGi is the gold standard for modularity, powering IDEs like Eclipse.

Complexity: OSGi is powerful but comes with a steep learning curve and significant boilerplate (Manifest headers, Activators, complex service dynamics). JExten offers a fraction of the complexity ("OSGi Lite") by focusing on the 80% use case: strictly isolated extensions with simple dependency injection, without requiring a full OSGi container.
Runtime: OSGi brings a heavy runtime. JExten is a lightweight library that sits on top of the standard JVM features.

Layrry

Layrry is a launcher and API for executing modular Java applications.

Scope: Layrry focuses heavily on the configuration and assembly of module layers (often via YAML/TOML) and acts as a runner. JExten focuses on the programming model within those layers.
Features: Layrry is great for constructing the layers, but it doesn't provide an opinionated application framework. JExten provides the "glue" code—Extension Points, Dependency Injection, and Lifecycle Management—that you would otherwise have to write yourself when using raw Module Layers or Layrry.

Feature	JExten	PF4J	OSGi	Layrry
Isolation	JPMS ModuleLayers	File/ClassLoader	Bundle ClassLoaders	JPMS ModuleLayers
Configuration	Java Annotations	Properties/Manifest	Manifest Headers	YAML/TOML
Dependency Injection	Built-in (`@Inject`)	External (Spring/Guice)	Declarative Services	None (ServiceLoader)
Learning Curve	Low	Low	High	Medium

5. Conclusion

JExten is a lightweight, annotation-driven plugin framework that leverages JPMS ModuleLayers to provide isolation and dependency management. It is designed to be easy to use and understand, with a focus on simplicity and ease of use.

Finally, keep in mind that JExten is still in its early stages, and there is much room for improvement. Feel free to contribute to the project on GitHub and/or engage in a discussion in the issues section. Link to the repository is here .