Building 7.6.0-alpha3

I need to start build/testing extensions soon. Reason is to mix in additional features supported by the WildFly/JBoss Camel subsystem (and others). Additionally wanting to better take advantage of LDAP and WildFly’s new embedded ActiveMQ-Artemis (to name a few).

Also interested in the regression tests included with your build - maybe adding a few of my own.

So the question: looks like the 7.6.0-alpha3 build options/settings are a little out-of-date. I know they’re in there somewhere - but, need some help in pointing out their required values and application (where they’re used in the maven hierarchy).

Here’s my maven version:
Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T11:29:23-06:00)
Maven home: /opt/maven
Java version: 1.8.0_101, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el7_2.x86_64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: “linux”, version: “3.10.0-327.13.1.el7.x86_64”, arch: “amd64”, family: “unix”

This doesn’t build:
mvn clean install -Pengine-integration,wildfly,h2

Reasonable and very good error:
[ERROR] The project org.camunda.bpm.qa:camunda-qa-wildfly-runtime:7.6.0-alpha3 (/proj/camunda/camunda-bpm-platform-7.6.0-alpha3/qa/wildfly-runtime/pom
[ERROR] ‘dependencies.dependency.artifactId’ for org.camunda.bpm.wildfly:camunda-${server}-assembly:pom with value ‘camunda-${server}-assembly’ doespm.qa:camunda-qa-wildfly-runtime:[unknown-version], /proj/camunda/camunda-bpm-platform-7.6.0-alpha3/qa/wildfly-runtime/pom.xml, line 207, column 23

So, adjusted options:
mvn clean install -Pengine-integration,wildfly10,h2

And, (with “skiptests”) this starts the build. But, noticed a general download of all platforms… including Glassfish, etc… Realized something must be wrong with my options.

Getting back to tests… wasn’t able to get past this error:

First: your documents state a requirement for Java JDK 6 or 7. Shouldn’t we be using JDK 1.8? (assumed this is out-of-date). But, I get the following error with both JDK 7 and 8.

The test failure:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:testCompile (default-testCompile) on project camunda-qa-integration-tests-engine: Compilation failure: Compilation failure:
[ERROR] /proj/camunda/camunda-bpm-platform-7.6.0-alpha3/qa/integration-tests-engine/src/test/java/org/camunda/bpm/integrationtest/functional/ejb/request/JobExecutorRequestContextLocalInvocationTest.java:[14,44] cannot find symbol

Given that your build reports “passing” on github, I’m assuming either the error is mine and/or I’m missing a required artifact. For example, the new wildfly-camel build requires a WildFly platform be available and alongside the build’s directory… easily fixed (and also noticed a general migration towards wildfly-10.1.0.CR1.

So, either what am I missing or where is the best place to look for general build requirements and/or assumptions?

  • Thanks.

Hi @garysamuelson,

why do you have engine-integration profile activated? In order to get wildfly profiles activated properly I think you should use wildfly.widfly10 and not only wildfly10.

Could you give it a try?

Cheers,
Askar

Try mvn clean install -DskipTests -Pwildfly,wildfly10,h2,engine-integration

Thanks!
Kicking off a new build - appreciate the example.

When you want to execute the engine-integration tests, it is best to execute the build from the ‘qa’ folder, so only Wildfly-Runtime and Engine-Integration are build. This saves a lot of time.

And - to directly answer the “why”…
Two direct reasons:

  1. off-load Camunda’s transaction burden to JMS/Messaging technology for widely distributed interaction - better support for distributed transactions without accidentally extending Camunda’s DB context into integration components/adapters.

And -> Camunda offers the best implementation for transacted BPMN v2 sub-process.

  1. supporting a… better “seamless” (to fall back on jargon) approach with event management and routing technologies (CEP, ESB, or my favorite… Apache Camel). This includes streaming technologies such as Apache Flink and their underlying technologies (i.e. Kafka.

I don’t necessarily need to fork the build - Apache Camel just plugs into WildFly/JBoss. And, Camunda has no issue with this - it just works. But, now I want to create a few accelerators/examples. And, I need some assurance this’ll all work, hence the regression test.

Lastly… The 7.6 alpha release is looking very good. Want to remain current on feature/development.

Yes… just noticed this:

[INFO] camunda BPM - QA Integration Tests - Engine … FAILURE [05:02 min]
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.16:test (default-test) on project camunda-qa-integration-tests-engine: There are test failures.
[ERROR]
[ERROR] Please refer to /proj/camunda/camunda-bpm-platform-7.6.0-alpha3/qa/integration-tests-engine/target/surefire-reports for the individual test results.

I’ve worked around this before - noticed the same sort-of test dependency with the Wildfly-camel plugin builds (v4.2.1)

For anyone else test with 7.6.0-alpha3 I seeing a nasty dependency problem in the artefacts exported to Maven central.

The artifact ‘org.camunda.bpm.dmn:camunda-engine-dmn-root’ set the property
<version.commons>1.4.0-alpha1</version.commons>
This version of camunda-commons is not in Maven central! The simplest solution is to change the downloaded POM in you local maven repositiory to read:
<version.commons>1.4.0-alpha2</version.commons>

7.6.0-alpha3
camunda DMN - engine - root

org.camunda.bpm.dmn camunda-engine-dmn-bom 7.6.0-alpha3 bom

Hi @mstevens,

you are right. This is a known problem, see also

We are currently updating the camunda-commons version in the DMN engine see CAM-6752.

As an alternative solution you could add the Camunda nexus to your maven settings, see the linked post. Sorry for any inconvenience.

Cheers,
Sebastian

@menski -

thanks for the update.

Camunda v7.6+ is looking very good on WildFly v10 - this includes the Camel Add-on (plugin/patch). Very nice CDI access to Camel components/routes.

Next step is getting this all into WildFly Swarm. Hence the need for the regression tests available with the build.