Hide Forgot
Modules of the same name but with different contents exist in the BRMS and BPMS layers distribution: kie-eap-integration-bpms-<version>-bpms-layer.zip kie-eap-integration-brms-<version>-brms-layer.zip The modules in question are: modules/system/layers/b*ms/com/opensymphony/quartz/main modules/system/layers/b*ms/org/apache/commons/lang3/main/ modules/system/layers/b*ms/org/apache/commons/logging/main/ modules/system/layers/b*ms/org/drools/main/ modules/system/layers/b*ms/org/jbpm/main/ modules/system/layers/b*ms/org/kie/lib/main/ modules/system/layers/b*ms/org/kie/main/ Having the same module, same name but with different contents has the potential to create confusion when layering because the BRMS versions on the modules could be added to the FSW platform (which contains the BPMS) modules. Modules in both products which have the same name should have the same contents.
See also: https://bugzilla.redhat.com/show_bug.cgi?id=993126 https://bugzilla.redhat.com/show_bug.cgi?id=1025416
Related to this, is the BRMS + FSW combination allowed? It doesn't make sense, since BRMS does not provide all the features required by FSW (at least in theory, the FSW should be layered on top of BPMS). The modules have different contents because the products use different subset of the platform and different dependencies. If they have to be the same, I see no reason to have a different module structure for bpms and brms, since bpms is a superset of brms. Both then should have the same layer (bpms). Can you please clarify this? It's unclear what needs to be done to solve this. .
As Pedro comments, BRMS is a subset of BPMS. So, If you want the FSW using BPMS there is no reason to deploy the BRMS layer too. And if you want to use only the BRMS with FSW there is no reason to deploy the BPMS layer. The idea is that BPMS/BRMS layers should never be both depoyed on same EAP instance. The only difference between two zip distributions is the layer name, then the user can know which one is deployed in the EAP. The names for the modules are the same due to the module vendor/product is the same, I mean, as example, the resource "junit.jar" must be always included in a descriptive module named "org.junit", no matter if bpms or brms. But in some cases, as BRMS is a subset of BPMS, not all resources used by BPMS are used by the BRMS, then the resource is not added into the module. The final conclusion is that BPMS/BRMS layers should never be both depoyed on same EAP instance. The same happens with the WAR files, you should never deploy both BPMS and BRMS WAR files into same EAP, as BPMS includes all BRMS functionality.
If the platforms use different subsets then this should be reflected through the use of additional modules, you should not be generating the same module with different content.
Agreed, it probably doesn't make sense to deploy BRMS modules with FSW, we should use the BPMS modules instead. However, the point here is that code written against a named module will only be guaranteed to work if all the modules with that name (in all the products) are the same. The current situation means that I can write code against the BPMS version of the module and my code will fail to run on BRMS. This can cause confusion and support headaches in future.
Hi, I'm agree that deploying different layers with modules that have the name,in same eap instance, should contain same resources. But the premise for BPMS/BRMS layers is that they never should be both deployed on same EAP instance. So you can have, for example: - <EAP_HOME>/modules/system/layers - FSW - all fsw modules - BPMS - all bpms modules So, adding missing resources to BRMS layer comparing from the BPMS layer, IDK if it has much sense, probably the comparison should only be between resources in modules that have the same name comparing FSW and BPMS layers. Anyway, using the mail of Julian Coleman on 29th, November, with subject "[ip-dev] EAP modules mismatch", we can perform this changes to avoid possible errors: Module com/opensymphony/quartz ============================== - Delete this module for BRMS layer, as it is empy. Module org/apache/commons/lang3 ============================== - Delete this module for BRMS layer, as it is empy. Module org/apache/commons/logging ============================== - Add the commons-logging-api-1.1.jar to BRMS layer, as the BPMS layer contains it. Module org/drools ============================== - Add the drools-persistence-jpa-6.1.0-SNAPSHOT.jar to BRMS layer, as the BPMS layer contains it. Module org/kie/lib ============================== - Add the seam-transaction-api-3.1.0-Final.jar to BRMS layer, as the BPMS layer contains it. Module org/kie ============================== - Add the kie-services-client-6.1.0-SNAPSHOT.jar to BRMS layer, as the BPMS layer contains it. Module org/jbpm ============================== - This module contains several differences between bpms/brms layers. - So we can split it into two modules with different names: - A minimal jbpm module with resources required for brms layer. This module can be called org.jbpm-minimal or similar. - A jbpm module form bpms layer with all required resources. This module will still be named org.jbpm. Thanks in advance.
Fixed. The changes commented above have been applied. About the "org.jbpm" module, the solution consists on split it into two different modules: - For BRMS a module named org.jbpm-minimal contains the minimal resources required by drools to work. - For BPMS, a module named org.jbpm contains all jbpm core resources required by BPMS to work. The rest of the commented modules above have now same content. Commit on master ================ https://github.com/droolsjbpm/kie-wb-distributions/commit/681638669a0b87328068525596f4aa3db364efec Commit on 6.0.x =============== https://github.com/droolsjbpm/kie-wb-distributions/commit/708a41c793534ed7d27e486f0cb16d2d93e6aeb4
This is rather internal issue how jboss eap modules are organized. Users could have been unnecessarily affected by this issue when for example developing on bpms modules and later migrating to brms ones, because org.jbpm module contained different set of artifacts in each case. This has been fixed in BRMS distribution by renaming module to org.jbpm-minimal. Verified in ER6.