Hi, the purpose of this BZ is to discuss the possibility of packaging BRMS web artifacts targeted for EAP 6 / AS 7 such that they leverage the JBoss modules architecture. leveraging the JBoss modules architecture would be a departure from the existing approach where each BRMS web artifact for AS7 is self-contained with all jbpm5/drools/mvel libraries that the web artifact needs the reason for this request is primarily to prevent potential Drools class inconsistency problems that still exist even in an EAP6/AS7 environment. for example, in assisting Jeff Delong support one of our partners .... we came across the following exception : java.io.InvalidClassException: org.drools.rule.constraint.MvelConstraint; local class incompatible: stream classdesc serialVersionUID = 2788259769774369539, local class serialVersionUID = -5171063419941396016 this problem was caused in a Switchyard environment (which integrates jbpm5/drools) when the knowledge agent in our switchyard service attempted to query guvnor and build a KnowledgeBase from those results. this problem was resolved by upgrading the drools libraries found in Switchyard's $EAP6_HOME/modules/org/drools directory such that those libraries are consistent with the drools libraries embedded in the WEB-INF/lib directory of the guvnor web archive in use. (background: Switchyard packages drools/jbpm5 dependencies as JBoss modules ) however, it would be really nice if instead of trying to coordinate drools libraries that switchyard deploys as modules with libraries buried in guvnor's web archive ...... BRMS itself included a script that configures JBoss modules. Projects building upon BRMS in EAP 6, along with BRMS's own web artifacts, could all then leverage the exact drools/jbpm5 module dependencies. thoughts ? thank you, jeff
one more additional comment : seems that it would be important to keep in mind a customer's EAP6.* environment built using BRMS-Deployable, in particular. so in addition to a WEB-INF/jboss-deployment-structure.xml added to each BRMS web archive .... maybe an extension to jbpm-installer/build.xml such that it provisions the target ${jboss.home}/modules directory with the appropriate drools/jbpm5/mvel modules ?
looks like we have several parallel efforts (from various projects all downstream to brms deployable) accomplishing pretty much the same thing (provisioning an AS7/EAP6 runtime with jbpm5/drools modules): Maciej's ant-based approach : https://github.com/mswiderski/jbpm-enterprise/blob/master/jbpm-enterprise-appservers/jbpm-enterprise-jbossas7/src/main/resources/build.xml PFP's ant-based approach : https://github.com/jboss-sso/processFlowProvision/blob/master/config-build.xml (in particular the "configure.jboss.modules" target ) switchyard's maven-based approach: https://github.com/jboss-switchyard/release/tree/master/jboss-as7/modules/src/main/resources/external/jbpm
Starting with 5.3.1, we'll be producing EAP6/AS7 compatible wars (that use JPA2 and do NOT package Hibernate 3 in the wars). Given that we have that as a starting point, this should be a lot easier, right? The approach used for the EAP6 war creationg currently produced is maven/assembly based. @jbride: thanks for the link to the switchyard configuration, it looks like we can use that.
as an example, the switchyard project provides the following distribution of JBoss modules specific to their project : https://hudson.jboss.org/hudson/job/SwitchYard-Release/791/artifact/jboss-as7/modules/target/switchyard.deployer.zip providing a similar distribution of jbpm6 modules would be perfect.
This is exactly what we need to do for BRMS/BPMS 6. Could we move the "product" field to "BRMS Platform 6" and BPMS Platform 6" instead of "BRMS 5"?
${summary} says BRMS -> moving to product BRMS
ER5 includes the modularization work. The fallout (if any) will be filed as separate regression bugs.