Maybe it wouldn't be a problem. I assume the way to make the dependencies non-transitive would be to change the scope from compile to provided in the relevant pom.xml files. Then any application embedding the process engine could use whichever version of Spring it likes, as long as any Spring methods used by the process engine are compatible with the specified version. There are 95 org.springframework classes (71, excluding test-related classes) imported in camunda-bpm-platform 7.4.0. To safely state that Camunda works with Spring 3+, you'd have to ensure that any API changes since Spring 3.1.2 don't affect the usage of these classes (I suspect this may be the case, but I'm not sure).

In my opinion, a better option would be to migrate the process engine dependencies to an actively supported generation of Spring (3.2, 4.1 or, preferably 4.2) and state that Camunda works with that version. Then, if the dependencies are made non-transitive it may (might/should?) also work with previous, unsupported versions.

Hi Tom,

thanks a lot for this input.

Yes, the scope of the dependencies would be changed from compile to provided.
We would then need to decide on the baseline supported version of Spring. Will it be 3+ or will it be 4+?
If multiple major versions are supported at the same time (with potentially non-backwards compatible changes in Spring itself), then we need to create two maven profiles and run the testsuite against both versions. That should not be a problem, we do that in other places as well.

Based on the feedback I received so far, a good initial scope could be

• decide on supported versions for spring
• test against all supported major versions
• demote transitive spring dependencies to "provided" OR if we keep transitive dependencies use a more recent version
• update documentation (users now need to include spring themselves)
• update get-started guides
• add note to update guide

WDYT?

Daniel

Thanks Daniel, that looks perfect.

I will see whether we can schedule this for 7.5

https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/camunda-bpm-dev/X68A7s0XQcs/BEskfmULAQAJ

Any hope for inclusion in 7.5?

The problem is resolved:

https://groups.google.com/forum/#!topic/camunda-bpm-users/qjpdUCTBMDk

add this part in your pom.xml file:

<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.camunda.bpm</groupId>
<artifactId>camunda-bom</artifactId>
<version>7.3.0</version>
<scope>import</scope>
<type>pom</type>

</dependency>
<dependency>
<groupId>org.springframework</groupId>

<artifactId>spring-framework-bom</artifactId>
<version>4.2.3.RELEASE</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>

Hi everyone,

We are finally going to do this with Camunda 7.11
I have updated the description with what we specifically intend to do. Thanks for all your input, that is greatly appreciated.

Cheers,
Thorben

Changes and findings:

• We now run the unit tests of engine-spring (as compiled with Spring 3) with Spring 4 and 5
• We continue supporting Spring 3 for now but will look into dropping that in the next release(s)
• Spring 5 requires Java 8, so the compatibility test module is excluded for Java 7
• Spring 4 and 5 require JPA 2+; to make our JPA integration tests run, the matching Hibernate versions are used (before, we used OpenJPA; I replaced this, because OpenJPA is not actively developed anymore and Spring 5 does not integrate with OpenJPA out of the box anymore)
• sets the engine-spring dependency in both camunda-engine and camunda-engine-spring to scope `provided`; this reflects the fact that users can bring their own Spring version => applications must now always declare explicit Spring dependencies
• rewrites some methods in SpringAutoDeployTest that were rewriting classpath resources during the test; this did not work when the resources are served from a JAR file
• moves SpringProcessEngineTestCase to the test package due to its Spring-version-specific code; simplifies the logic that ensures that the application context is removed from the context cache
• bumps JUnit from 4.11 to 4.12, which is required by Spring 5
• Autodeployment of BPMN ByteArrayResources does not work with Spring 5 => CAM-10177
• Getting started guide should be adapted => CAM-10178
• Examples should be adapted => CAM-10179

We decided to keep the dependency from camunda-engine to spring-beans in compile scope. If it was provided, all applications using camunda.cfg.xml for testing would break without declaring an explicit spring-beans dependency, even if they are otherwise non-Spring applications.

In a Spring project that uses camunda-engine-spring with a higher Spring version, this should not matter because the dependency version would get overridden anyway.