We are proud to announce COPPER 3.1.0

• New feature: PersistentLockManager - a service to obtain/manager persistent locks, e.g. to functionally synchronize workflow instances.
• New feature: PersistentProcessorPool.suspendDequeue/resumeDequeue Suspends/resumes dequeuing of workflow instances from the storage.
• New feature: New utility org.copperengine.core.util.Backchannel, that offers functionality to signal a response from within a persistent workflow to its originator
• New feature: support for the H2 database
• New feature: added SimpleJmxExporter in copper-coreengine to ease the registering of JMX beans when COPPER runs without Spring
• Maven: copper-coreengine: moved dependency on C3P0 to copper-regtest. Removed *ConnectionCustomizer classes, because they broke the JDBC spec regarding autoCommit; also removed OracleConnectionTester as it can be substituted by setting ‘preferredTestQuery=”SELECT 1 FROM DUAL”’ in C3P0 datasource.
• Maven: copper-coreengine: removed unnecessary dependencies on aopalliance, findbugs-annotations and commons-codec, so the only remaining dependencies are on ASM and slf4j-api

You can get it here: https://github.com/copper-engine/copper-engine/releases/tag/3.1.0

The COPPER project now has a mailing list, hosted by Google Groups:

https://groups.google.com/forum/#!forum/copper-engine

The mailing list is intended as a forum for both users and developers. All current COPPER developers are signed up.

The list members discuss general and technical issues around current and future COPPER releases. New users are always welcome! Don’t hesitate to ask the developers any questions!

You can subscribe to this list either by using the Google Groups website or, if you don’t want to create a Google account, by sending an e-mail to copper-engine+subscribe@googlegroups.com with topic “subscribe”. Or, if that doesn’t work, simply e-mail us at contact@copper-engine.org and we’ll sign you up.

Since release 3.0 COPPER is available on the Maven Central Repository.

This means that now you can pull in the COPPER core engine and all its assorted libraries as a Maven dependency. Simply add the following dependency to your project’s POM:

<dependency>
    <groupId>org.copper-engine</groupId>
    <artifactId>copper-coreengine</artifactId>
    <version>3.0</version>
 </dependency>

This automatically pulls in the dependent libraries copper-jmx-interface and the third-party libraries asm, slf4j-api, log4j, commons-codec, c3p0 and aopalliance. (Note: we are currently working on a refactoring to make the list of third-party dependencies even smaller – in the end only asm and slf4j-api will be needed!)

If you are using Gradle, then add the following line to your dependencies:

compile 'org.copper-engine:copper-coreengine:3.0'

If you’re using the Spring Framework then you will also need copper-spring, because since 3.0 the Spring support classes have been moved from the core to its own project:

<dependency>
    <groupId>org.copper-engine</groupId>
    <artifactId>copper-spring</artifactId>
    <version>3.0</version>
</dependency>

Likewise for Gradle:

compile 'org.copper-engine:copper-spring:3.0'

There are other COPPER artifacts on Maven Central, namely copper-monitoring.* which contains our upcoming monitoring server and UI and orch-engine/orch-interfaces/orch-simulators which contains an exhaustive real-world COPPER example application. Both will be explained in future posts, so stay tuned!

The top item of this 3.0 release is that we changed COPPER’s toplevel package from de.scoopgmbh.copper to org.copperengine.

Other than that the public API is unchanged (almost, see below). If you are using COPPER then you can easily migrate your project by changing all import statements from de.scoopgmbh.copper to either org.copperengine.core (if the class resides in copperengine-core.jar) or org.copperengine (otherwise).

If you have persistent workflows, don’t worry that the persisted stackframes might contain references to old classes in the de.scoopgmbh.* package: we got you covered. Whenever COPPER loads a persistent workflow instance (or response) it transforms the package name automatically during load time – no further intervention neccessary.

Other changes, compared to the last stable release 2.4.3

• Refactoring: Renamed COPPER major Throwable from “de.scoopgmbh.copper.InterruptException” to “org.copperengine.core.Interrupt”. Persistent workflow instances and responses in existing databases keep compatible due to a loadtime adaptation feature - see StandardJavaSerializer.classnameReplacement
• Refactoring: All Spring supporting classes have been moved to an own subproject: copper-spring. Attention! SpringTransactionController and SpringTxnAuditTrail have been moved to another package
• Refactoring: de.scoopgmbh.copper.audit.BatchingAuditTrail does no longer implement spring’s InitializingBean. This makes copper less dependent on spring stuff.
• Refactoring: de.scoopgmbh.copper.Response.internalProcessingTimeout changed from Integer to Long to enable really LONG timeouts
• Refactoring: Renamed table ADAPTERCALL to COP_ADAPTERCALL, renamed index IX_ADAPTERCALL to COP_IDX_ADAPTERCALL
• New feature: Added new wait methods, e.g. de.scoopgmbh.copper.Workflow.wait(WaitMode, long, TimeUnit, String…)
• New feature: COPPER now uses the Eclipse compiler ecj (or any other JSR-199 compatible java compiler) when found on the CLASSPATH and the default Java compiler is not available. Thus you can run COPPER on a normal JRE instead of a full JDK, ie. you no longer need to provide tools.jar as long as you add ecj.jar to your runtime dependencies.
• Bugfix: Issue #26: Removed commons-logging from dependencies
• Bugfix: Issue #25: Removed log4j dependency from copper-coreengine
• COPPER is now available as a Maven dependency on Maven Central

You can get it here: https://github.com/copper-engine/copper-engine/releases/tag/3.0

Besides some new functional features, one main issue of the 3.0 release is the renaming of COPPER’s toplevel package to org.copperengine.

To make migration of existing applications easy, persistent workflow instances and responses in existing databases keep compatible due to a loadtime adaptation feature - see StandardJavaSerializer.classnameReplacement

A complete overview of what’s new in release 3.0 is available in our git repo at WHATSNEW.txt