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

Java 8 is just around the corner and you might wonder if COPPER is ready for Java 8, especially the new language features.

Alas, no! The reason is that we are using the awesome ASM bytecode engineering library to load, modify and store workflow classes from and into the database. The current stable release is 4.2, which is not ready for Java 8 yet.

However, the ASM developers are already working on Java8 compatibility and promise that it’s ready with the next major release 5.0. A beta version is already available, which we are testing right now.

Thus, in short: you cannot use Java8 with COPPER right now. If you really want to use COPPER with Java 8, you can do so, but be very careful to compile all your persistent workflow classes with --source 1.7 --target 1.7. (All your other classes can be compiled without these options.) But that’s probably not what you want, because you cannot use the new language features in your workflows, especially closures.

We will release a new COPPER version with Java 8 support as soon as ASM 5.0-stable hits the scene, so stay tuned!