hasPassed(activityId) throws java.lang.NoSuchMethodError

[Brutus5000]

Hi there,

I've tried using your module with camunda-bpm-spring-boot-starter. A shortened sample is available here: https://github.com/Brutus5000/demo-assert-issue

As soon as I use an assertThat(...).hasPassed(...) I run into this exception:
This happens on version 1.2 and 2.0-alpha1/2

java.lang.NoSuchMethodError: org.assertj.core.api.Assertions.assertThat(Ljava/util/List;)Lorg/assertj/core/api/AbstractListAssert;

	at org.camunda.bpm.engine.test.assertions.ProcessInstanceAssert.hasPassed(ProcessInstanceAssert.java:220)
	at org.camunda.bpm.engine.test.assertions.ProcessInstanceAssert.hasPassed(ProcessInstanceAssert.java:177)
	at net.brutus5000.bpmn.assertissue.SampleTest.success(SampleTest.java:45)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
	at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
	at org.camunda.bpm.engine.test.ProcessEngineRule$1.evaluate(ProcessEngineRule.java:165)
	at org.junit.rules.RunRules.evaluate(RunRules.java:20)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
	at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
	at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
	at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
	at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)

In your example everything is running fine, but it's based on a very old set of dependencies.
Do you have any idea what might cause this?

[jangalinski]

Check the "known issues" of 2.1.2: https://camunda.github.io/camunda-bpm-spring-boot-starter/docs/2.1.2/index.html

replace your dependencies to spring-boot-starter-test and camunda-bpm-assert with the dependency for camunda-bpm-spring-boot-starter-test.

Background: camunda-bpm-assert uses an outdated version of assertj and is not fully compatible with java8/spring boot 1.5.x. I had to include the sources in camunda-bpm-starter-test and recompile with java8. This might change in the future when we have a java8 compatible version of camunda.-bpm-assert.

[Brutus5000]

Many thanks! I completely missed that.
Now it's working.

[martinschimak]

Hi all. Many thx @jangalinski for clarifying the issue with @Brutus5000. I agree that we should change the situation - as always the limiting factor is time. I see several options to move forward. 1) Forget Java 6/7 and just support Java8. 2) Declare AssertJ to be a provided dependency 3) Cleanly support several JDKs, e.g. by making use of maven classifiers.

With Java 9 around the corner and 10 at the horizon, one can quite safely assume that 1) actually isn't a solution. 2) is actually a no brainer with the small drawback that the library isn't usable "out of the box". But I would need @jangalinski to comment whether this solves the whole issue? Or are there other aspects you ran into with spring boot? 3) is kind of "perfect", but then also time consuming and probably overkill for such a small project.