Future of Camunda 7 Extensions

Camunda 7 Topics
,
1

Hi folks,

as you know we developed a bunch of Camunda 7 Extensions and I have several questions around them.

  1. Since the official Camunda 7 CE support will end on October 30th 2025 (with 7.24) I assume the repository will be archived and no CE artifacts will be produced anymore. In the same time, the Camunda Enterprise Edition will be supported for the next five years. We at Holisticon have a lot of customers using the C7 EE and our extensions and want to provide “support” for our extensions at least till the end of Camunda 7 EE support. Do you have any proposals how we can build our artefacts for the versions accessible in Camunda EE repository only?

  2. We have at least three extension we moved to Camunda Community Hub (but mainly developed and maintained by us): Mockito, Rest Client Spring Boot, Coverage. What will happen to those (since they are part of your GH org)?

  3. In case the three extensions are kept - how do you want us to handle dependencies to EE only?

P.S. We are consolidating all our extension (hosted in holunda.io GitHub Org) in a single mono-repo for reduction of release and update activities. One possible solution for the three extension on the hub is to relocate them back and integrate with other Holisticon extensions. So we would shift them to our mono repo, release from there with EE support and maintain there. I know we don’t need a legal approval for this, and this is one of our preferred solutions, but I just want to make sure we are doing this in a coordinated way.

Thanks,

Simon

5 Likes
2

Hi @zambrovski,

This is Tassilo – the Engineering Manager of the AP 7 team. Thank you for your patience!

I am happy to answer your questions and to find a way forward for your community extensions:

RE Question 1 + 3

Since the official Camunda 7 CE support will end on October 30th 2025 (with 7.24) I assume the repository will be archived and no CE artifacts will be produced anymore.

Your assumption is correct. The camunda/camunda-bpm-platform will be archived after October 2025, and we won’t release any CE artifacts anymore.

Do you have any proposals how we can build our artefacts for the versions accessible in Camunda EE repository only?

[…] how do you want us to handle dependencies to EE only?

From October 2025 on, we will stop publishing alpha and minor releases of the community edition. 7.24.0 will be the last publicly available community edition release users can pull from Maven Central.

What I’m wondering right now is whether the changes we introduce via patch releases after the 7.24.0 release have the potential to break your community extensions. :thinking: If not, maybe your community extensions can just continue to depend on 7.24.0 CE?

Can you please answer some questions so I can understand your requirements better?

  • Would integrating and testing your community extensions against 7.24.0 CE be sufficient to guarantee they continue to work with 7.24.X? If not, why?
  • Which concrete C7 artifacts do your community extensions depend on? Do they assume C7 uses specific third-party library versions?
  • Do your community extensions bundle C7 artifacts?

RE Question 2

We have at least three extension we moved to Camunda Community Hub […]. What will happen to those (since they are part of your GH org)?

These extensions can continue to reside in the Community Hub, with you as maintainers. We don’t plan to archive any C7 Community Extensions or Community Hub repositories.

Thanks in advance for answering my questions. :slightly_smiling_face:

Best,
Tassilo

3

Hi Tassilo,

thank you for your response.

  • Would integrating and testing your community extensions against 7.24.0 CE be sufficient to guarantee they continue to work with 7.24.X? If not, why?

Even if Camunda stops releasing new software, there might be changes in the ecosystem requiring changes in the engine code, which must be adopted in the extension. So the extensions are not solely depend on Camunda Java API, but use a lot of ecosystem code too (we usually use Spring Boot). In addition, our extensions are running a large amount of unit and integration tests. I’ll give you an example: at freeze time Camunda 7.24 will be based on SpringBoot 3.5.0 (released tomorrow), but in Nov 25 SpringBoot 3.6.0 will follow… Projecting further we will get every May/November a new minor event/odd release of SpringBoot. Don’t know when (and don’t know how many 3.x releases will follow), but a chance is quite large that stuff will break in the next five years, because of changes in the Spring Boot. The same applies to the entire stack of dependencies - Jackson, Jersey, JAX-B, Commons-io, MyBatis, Log4j, etc - if they introduce breaking changes, you will probably adopt them during the LTS of Camunda 7.
(I’m aware that most libs are there for quite long time, but you will probably provide support for the EE customers with updated versions in the engine and its ecosystem integration). Since most EE customers will go in-step with latest updates of the ecosystem, I need a best proof that the extensions work - and the best way to do so is to build it with latest EE version. In fact - we have a maven profile for doing that in most extension and test it locally (since we have a Camunda EE licence as a Camunda Partner).

  • Which concrete C7 artifacts do your community extensions depend on? Do they assume C7 uses specific third-party library versions?

We have several extensions (around a dozen) and they depend on different parts of Camunda artefacts. Let me group them together in a following way:

  • extensions for process applications and improved support: depend directly on camunda-engine, camunda-spring (mostly using camunda-spring-boot-starter-xxx), camunda-commons-typed-values and camunda-xxxx-model.
  • extensions for testing: camunda-engine, camunda-bpm-assert
  • for integration testing of remote C7 we are using docker images of camunda.
  • Do your community extensions bundle C7 artifacts?

No, we never bundle camunda artefacts. Even in Maven dependencies we try to use provided scope as much as possible.

We are aware of the fact, that in case of a incompatible change (introduced by EE or by the ecosystem) our examples inside of extension will loose their applicability for CE customers. This is fully accepted from our side - we want to provide support for our EE customers during the LTS support of Camunda 7 only. If something gets incompatible we will flag this fact in the extension by marking it “incompatible to 7.24”.

These extensions can continue to reside in the Community Hub, with you as maintainers. We don’t plan to archive any C7 Community Extensions or Community Hub repositories.

These are good news. I think we will still migrate them back to have a standard approach and reduce work on our side (Spring Boot upgrade once instead of currently about 12 times…). One of the extensions (camunda-test-coverage) will probably be split into two parts (c7 and c8), and c8 will remain on hub until CPT supports coverage measuring out of the box (and then will be archived).
Mockito is very close to Camunda 7 Engine, is heavily used in customer projects and would benefit from the common abstraction (sharing data objects with e.g. camunda-bpm-jgiven and some others) and the Camunda 7 REST Client Spring Boot and Custom Batch would be the last left on the hub then - so it is easier for us to bundle all together and consolidate in holunda-io.
There is another one (migration: fluent migration contributed by our guys which will be either archived or transferred to holunda-io too. I don’t think someone is using it at all…

We still have time to prepare all this and would slowly migrate the artefacts including relocation notices both in Maven Central and the release notes / repositories infos…

So still curious if we can arrange a read access for particular repository (GH org holunda-io managed and owned by Holisticon AG) to the EE JAR artefacts and EE docker images…

By the way - I checked for all C7 extension on Hub. Excluding the ones I would move there will remain the following:

  • keycloak (live)
  • mail (live)
  • micronaut (live)
  • camel (zombie)
  • grpc-external-task (PoC from Camunda team)
  • graphql (zombie)
  • osgi (zombie)

Hope my answers help you.

Cheers,

Simon

4

Hi Simon,

Thank you for your answer.

Just to double-check if I understood everything correctly:

  • Your primary concern was that Camunda would archive/remove access to your Camunda Hub repositories with C7 community extensions that you want to maintain after C7 enters maintenance mode.
    • A: On Community Hub, we don’t plan to archive any C7 repositories or remove access once C7 enters maintenance mode.
  • You want to gradually migrate/transfer the still actively developed extensions to your holunda-io GitHub organization.
  • You need access to EE artifacts to test the community extensions once moved to the holunda-io GitHub organization.
  • Your unmaintained C7 extensions will stay in the Community Hub.

Can you confirm I understood this correctly?

Best,
Tassilo

5

Hi,

In general, yes.

  1. We want to consolidate all our extensions on holunda-io (primarily to reduce maintenance overhead and profit from single repository approach) and deliver all of the from one multi-module repo with the same version (then date-based).
  2. We want to deliver the value by supporting those extensions until EOL of Camunda 7 EE
  3. We will discontinue all our C7 extensions on hub (those can be archived and will get relocation notices in the readmes)
  4. We will discontinue all holunda-io in separate repos but replace it by the one single repo…
  5. We need a solution for exactly one repository on holinda-io to be able to build with Camunda 7 EE artifacts.

Cheers,

Simon

6

Hi Simon,

Thanks for confirming this.

We need a solution for exactly one repository on holinda-io to be able to build with Camunda EE artifacts.

since we have a Camunda EE licence as a Camunda Partner

What prevents you from using your Camunda partner credentials to access the Maven enterprise artifacts after October 2025? :thinking:

Best,
Tassilo

7

Hi,

this is an option, we considered.

I would be happy if you confirm that this is ok from your side.

At the same time complete FOSS development in the past which converts into FOSS development for partly unavailable product is not a thing that must be bound to the partner status only (especially it is good to know what partner status allows this access - implementation? integration? sales? migration?). So even if we can fallback to it, I think there might be a better solution for example for the community members who still maintain extensions and are not partners.

This entire post is about synchronising ideas, approaches and moving forward together. Just want to make sure there are no surprises - neither for you nor for us.

P.S.

Maybe a question towards the opposite direction: would you by default provide access to EE repository to extension built by your CI/CD pipeline on HUB?

I’m just asking, because we might want to move the consolidated “holunda-extensions” repository entirely to HUB instead of holunda-io…

Nothing is decided yet, so I want to see what options do we have.

Cheers,

Simon

8

Hi Simon,

We are okay with you using your Camunda Partner Account credentials to continue testing your Community Extensions against enterprise artifacts.

So far, we haven’t received any other questions from Community Extension maintainers about obtaining access to enterprise artifacts when Camunda 7 enters maintenance mode (starting October this year).

Perhaps we could use this forum post to engage other Community Extension maintainers who don’t have access to enterprise artifacts because they are not Camunda Partners. Once we gauge the community’s interest, we can decide on the best course of action moving forward and think about solution ideas more concretely.

How does this sound to you?

Best,
Tassilo

1 Like
9

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.