COPPER Java workflow engine

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: ... [More] <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! [Less]

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 ... [More] 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 [Less]

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 ... [More] 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 [Less]

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: ... [More] org.copper-engine copper-coreengine 3.0 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: org.copper-engine copper-spring 3.0 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! [Less]

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 ... [More] 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 [Less]

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: ... [More] org.copper-engine copper-coreengine 3.0 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: org.copper-engine copper-spring 3.0 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! [Less]

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: ... [More] org.copper-engine copper-coreengine 3.0 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: org.copper-engine copper-spring 3.0 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! [Less]

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 ... [More] 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 [Less]

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 ... [More] 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 [Less]

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 ... [More] 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 [Less]