Vendor libraries

Try a vendor today, swap them for a competitor tomorrow, or remove the feature entirely — at the same trivial cost. Pull ready-made capabilities (risk monitoring, metrics analysis, ML inference, sensor fusion, forecasting) into your application without writing any integration code.

Capabilities ship as ordinary Java. No middleware glue layer, no proprietary runtime to learn, no framework lock-in. The vendor wrote it once; your application uses it as if it had always been part of your own codebase.

The mechanism that makes this trivial is the cloud integration service: it wires the vendor's subgraph into your application at compile time, so dropping in a new capability costs no more than dropping in a JAR.

What this replaces

Adopting a third-party library normally means writing and maintaining a stack of integration code yourself. With Fluxtion that stack disappears:

When this pattern fits

If you ship a library

Every node class in your JAR ships two constructors:

public class MetricsAggregator {

    private final MetricsCollector collector;

    // 1. No-arg ctor — ease-of-use authoring.
    //    Spring XML / drag-and-drop / LLM-emitted topologies can
    //    reference this bean without wiring dependencies manually.
    //    Internally builds dependent nodes and delegates.
    public MetricsAggregator() {
        this(new MetricsCollector());
    }

    // 2. Field-matching ctor — Fluxtion source-gen picks this one
    //    when emitting reconstruction code. Parameters map onto
    //    the renderable fields one-for-one.
    public MetricsAggregator(MetricsCollector collector) {
        this.collector = collector;
    }

    @OnTrigger
    public boolean onCollectorUpdate() { ... }
}

That's the whole contract. Spring instantiates your bean via the no-arg ctor; the dependent node becomes a private field; Fluxtion source-gen walks that field at compile time and discovers MetricsCollector as a transitive node — without it ever appearing in the integrator's XML.

What to ship

• A normal maven JAR — Java 8 bytecode, no shading required.
• fluxtion-runtime as a provided dependency. Your consumer's runtime already has it.
• No Spring dependency. Integrators choose their own bean wiring framework; your library shouldn't dictate.
• A README that names your entry-point beans (the ones integrators reference in XML) vs. your internal nodes (the ones field-walking pulls in).

Your library inherits this

Every Fluxtion vendor library gets these substrate properties for free — your code only writes the domain logic, the rest is generated when the integrator compiles:

• Event coordination is generated across your nodes and the integrator's. You don't have to wire dispatch, callbacks, or fan-out.
• Lifecycle propagation — your nodes get init / start / stop / tearDown in dependency order automatically.
• Audit and replay compatibility — every event through your library passes through a deterministic, loggable path. Your customers' compliance team already has the workflow.
• Embed-ready everywhere — the resulting processor is a plain Java object. Drops into a service, an agent loop, a batch job, a web handler.
• Mongoose-ready — your library deploys into Fluxtion's production runtime container alongside any other vendor's library, without extra packaging work on your part.

Worked example

telaminai/acme_metrics — 3 event types + 8 nodes (3 collectors / aggregator / averager / alerter / 2 publishers). Includes a JUnit smoke test that compiles the subgraph in-process via FluxtionSpring and asserts state across every node. Use it as a template.

If you consume a library

Drop the JAR on your classpath. Reference the library's entry-point beans in your Spring XML — usually one or two — without mentioning the internal nodes.

<bean id="aggregator" class="com.acme.metrics.MetricsAggregator"/>

<bean id="publisher" class="com.acme.metrics.MetricsPublisher">
    <constructor-arg ref="aggregator"/>
</bean>

Two beans in XML. The generated processor contains eight nodes — the library's three collectors, three transformers (aggregator, averager, alerter), and two publishers. All wired by trigger edges Fluxtion inferred from constructor field types.

What you actually get

• A .java file showing every node the library contributed — same review workflow as your own code.
• A .graphml rendering of the full topology — your compliance team can read it.
• A compiled .class that only depends on fluxtion-runtime + the library JAR at deployment time.
• All event coordination automatically generated. No switch statements, no per-event dispatch glue — Fluxtion emits it from the topology you composed.
• Lifecycle coordination. init() / start() / stop() / tearDown() propagate through every node in dependency order. You call one method on the processor; the substrate fans out the rest.
• Event-sourcing, audit, and replay compatible out of the box. Every event is dispatched through a deterministic path that can be logged, captured, and re-driven through a fresh processor to reproduce state exactly.
• Ready to embed in your existing infrastructure — service, agent, batch job, web handler. The processor is a plain Java object: instantiate, call init(), feed events, read state.
• Ready for deployment into Mongoose — Fluxtion's runtime container for production (agent threading, lifecycle, ops endpoints). Same processor across simulation, soak-testing, and production; only the deployment plumbing changes.

Open the playground — pulls the library as a real maven artifact, runs the AOT build, prints the output. Generated source + graphml are both visible in the project tree.