Thanks for the hint about the camel-jbang-core tests. They ran one JVM per
test class, one class at a time, because the tests shared a static home dir
and files in the module directory. There are now three PRs:

- https://github.com/apache/camel/pull/28004 runs the tests in 4 reused
forks, each with its own home. The 15 test classes that use the working
directory or a fixed port run afterwards, in a single fork.
- https://github.com/apache/camel/pull/28005 loads the kamelet catalog and
the Quarkus BOM versions once per JVM, which takes ExportTest from 95 s to
44 s.
- https://github.com/apache/camel/pull/28003 fixes a startup race in
camel-core that the reused forks exposed. Any camel run could rarely fail
with a ConcurrentModificationException in DefaultBeanIntrospection. It
needs to go in before #28004.

Locally the module's tests now take about 96 s instead of 399 s. The fork
count is a property (-Dcamel.surefire.forkCount, 4 by default), so it can
be tuned for Jenkins with -T1C. I'd be interested to see what it gives
there. Running the tests concurrently inside one JVM would need the static
state removed from the CLI, so that can come later with the CLI overhaul.

See Also CAMEL-25720 and CAMEL-25734.

Also added instructions for AI agents so they in the future is aware of
parallel tests to avoid tests end up taking long time again.




On Fri, Oct 16, 2026 at 9:41 AM Aurelien Pupier via dev <
[email protected]> wrote:

> Hello,
>
> I think there is some work to do to drop Java 17 in Camel Jbang part. In
> case, the risk of conflicts is high with planned changes on Camel Jbang
> cli, would it be possible to wait for Java 17 drop before starting on Camel
> Jbang CLI? I think Java 17 drop should be finished at worst mid of next
> week.
> (I feel not enough familiar with Camel Jbang internals and the planned
> overhaul to know if it will really bring a lot of conflicts so maybe that's
> not really a concern and both could go in parallel.)
>
> And just in case synergy is possible, I think it is interesting to keep in
> mind, if there is a big overhaul that currently the camel jbang core tests
> are not parallelized and are taken almost 20% of the time almost alone when
> using the -T1C option on Jenkins CI. In case, while doing the work, there
> are possibilities to make it possible to have it in parallel at the same
> time that would be nice. If too complicated to think of both at same time,
> not a problem we can still get back to it later on.
>
> regards,
> ________________________________
> From: Claus Ibsen <[email protected]>
> Sent: Thursday, October 15, 2026 5:41 PM
> To: dev <[email protected]>
> Subject: [EXTERNAL] Camel JBang CLI overhaul work for 4.24
>
> Hi
>
> Part of the work for Camel 4.24 is to overhaul our codebase for camel-jbang
> CLI commands.
>
> So we are doing this now, so expect a set of PRs coming up that help
> improve, harden and fix this codebase over the coming days/week.
>
>
>
> --
> Claus Ibsen
>
> Unless otherwise stated above:
>
> Compagnie IBM France
> Siège Social : 17, avenue de l'Europe, 92275 Bois-Colombes Cedex
> RCS Nanterre 552 118 465
> Forme Sociale : S.A.S.
> Capital Social : 664 614 175,50 €
> SIRET : 552 118 465 03644 - Code NAF 6203Z
>


-- 
Claus Ibsen

Reply via email to