Camel JBang: Prototype, Debug, and Export Routes Without a Project

Most Camel questions are settled faster by running a route than by arguing about it. The obstacle used to be ceremony: generate a project, pick a runtime, wire a pom.xml, add the component dependency, write a test harness, then finally find out whether the FTP endpoint accepts that filename pattern. Camel JBang removes the ceremony. You write one .java or .yaml file with a route in it, type camel run, and it runs.

This is the part of the 4.x line that has changed our day-to-day work the most, and it is under-used by the integration teams we review. Below is what it is actually good for, and where we stop using it.

Getting a route running

Install JBang, then install the Camel app once:

jbang app install camel@apache/camel

Now a whole integration is one file. hello.camel.yaml:

- from:
    uri: "timer:tick?period=2000"
    steps:
      - setBody:
          simple: "tick ${exchangeId}"
      - log: "${body}"

And:

camel run hello.camel.yaml

No project, no dependency list. Camel resolves the components the route references and downloads them. Add --dev and edits to the file reload live, which makes endpoint-option guesswork a two-second loop instead of a rebuild.

The same works for Java route builders, XML routes, and .kamelet.yaml files, and you can pass several files at once — a route file plus an application.properties — which is how you keep credentials out of the route while spiking.

Where it earns its keep

Four uses account for nearly all of ours:

Answering endpoint questions. Does this SFTP server tolerate stepwise=false? What does the JDBC component put in the body for an empty result set? Does the partner's SOAP endpoint actually honour the WS-Security header we think it needs? These are empirical questions, and a five-line route answers them honestly in less time than reading three Stack Overflow posts of uncertain vintage.

Reproducing a bug outside the client's codebase. A production route misbehaving inside a 400-class Spring Boot application is hard to reason about. Lifting the suspect three steps into a standalone file — same component versions, same options — either reproduces the behaviour (now you have a minimal case, and possibly an upstream issue report) or fails to, which tells you the problem is in the surrounding application, not in Camel. That fork in the road is worth a lot during an incident.

Inspecting what a running route is doing. camel trace streams messages through the route steps; camel debug gives you breakpoints at the step level with the exchange body and headers; camel get route and camel top show route counts, inflight exchanges, and failures. These work against a JBang-run integration, and — the underrated part — they also attach to other local Camel processes, so you can point them at an application you started from your IDE.

Kamelet and connector evaluation. camel run a Kamelet with parameters and see what it emits, before you decide whether it belongs in your platform's catalogue.

Exporting the spike into a real project

The part that keeps JBang from being a toy:

camel export --runtime=spring-boot \
  --gav=com.example:order-feed:1.0.0 \
  --dir=../order-feed

That generates a normal Maven project — pom.xml with the dependencies your routes actually used, the route files in place, the runtime wired. --runtime=quarkus does the same for Quarkus, and there is a --runtime=camel-main for the plain case. So the throwaway file is not throwaway: a spike that answered the question becomes the skeleton of the deliverable, with the dependency set derived from the routes rather than guessed.

We treat the export as a starting point, not output. It has no tests, no configuration strategy, no error handler worth the name. You still own all of that.

Where we stop

Honesty about the boundary matters more than the enthusiasm:

• Not a production runtime. You can run a JBang integration as a long-lived process, and for a tiny internal utility that may be fine. For anything a business depends on, we want a built artifact, a locked dependency set, a reproducible image, and a CI pipeline that ran tests. On-the-fly dependency resolution is a wonderful development property and a poor production one.
• Not a substitute for tests. Live reload feels like verification. It is not. AdviceWith, mock endpoints, and Testcontainers still do the work of proving a route keeps behaving.
• Version drift is real. The JBang Camel version is whatever you installed; your production estate is on whatever it is on. When you are reproducing a bug, pin the version (camel run --camel-version=4.8.5 ...) or the reproduction is about a different Camel than the one that broke.
• Dependency resolution needs network and a repository. In locked-down enterprise environments, plan for the Maven repository access and the proxy settings, or the first camel run on a client laptop fails in a way that has nothing to do with Camel.

Why we raise it in reviews

In architecture reviews we often find teams whose feedback loop for an integration change is measured in tens of minutes: build, deploy to a shared dev environment, poke, read logs. That cost shapes behaviour — fewer experiments, bigger changes, more guessing about endpoint semantics. Camel JBang shortens the loop for the class of questions that make up most integration work, and camel export means the shortcut has a legitimate exit into the real project.

It does not replace your runtime, your tests, or your platform. It replaces the twenty minutes you were about to spend scaffolding a project to ask a one-line question.