Bug 973193 - Build & deploy does not create package directory structure in .jar deployments and does not include process definitions
Build & deploy does not create package directory structure in .jar deployment...
Product: JBoss BRMS Platform 6
Classification: JBoss
Component: Business Central (Show other bugs)
Unspecified Unspecified
unspecified Severity high
: DR6
: 6.0.0
Assigned To: manstis
Marek Baluch
Depends On:
  Show dependency treegraph
Reported: 2013-06-11 08:53 EDT by Jiri Svitak
Modified: 2014-08-06 16:17 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-08-06 16:17:45 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jiri Svitak 2013-06-11 08:53:16 EDT
Build & deploy does not create package directory structure in .jar deployments. I wanted to create a project with groupId com.bpms.flood. I was able to find the deployment both in GUI and REST API, but no process definitions inside. I found out that the .jar file contained just folder with name "com.bpms.flood", which contained only default WorkDefinitions.wid instead of expected directory structure com/bpms/flood.

I guess that this is the reason why also the process definition was not included in the deployment .jar.

To reproduce:
1. Login to business-central.
2. Create new git repo. Create new project and package named "com.bpms.flood".
3. Inside the package create a simple process and save it.
4. Open project and add a session ksession1 to kmodule.xml. (I think this could be fixed as well - that the project should forbid here the name "default" as it later complains when deploying. Also the name of the session is later usually invisible. I'll file a new bugzilla for this.)
5. Try to Build & Deploy and try to run the process instance either in gui or rest api. Investigate the local maven repo and content of the .jar file.

My environment:
business-central.war - BPMS 6 DR5
Comment 1 Mauricio Salatino 2013-06-13 07:52:31 EDT
Hi, this is the Project Editor responsibility, and it's not related with the jbpm side. This issues should be assigned to Michael Anstis or Toni Rikkola, or at least ask them who is responsible for the Project Editor screen and how the assets and projects are generated.
Comment 2 Edson Tirelli 2013-06-19 10:10:27 EDT
Just to make sure I understand the problem: is the problem that the process definition is not included in the generated kjar?
Comment 3 Edson Tirelli 2013-06-19 10:17:01 EDT
As explained during the call, it happens only when a custom package name is used. In that case, the process definition is not added to the kjar.
Comment 4 Marek Baluch 2013-06-19 16:06:27 EDT

I just tried out the following:

1) create a new project in any predefined repository (I used jbpm-playground.git)

I tried four possibilities I think can happen in a project in the resources directory:

1) don't create a package but you create a process definition
2) create the defaultPackage and a process definition in it
3) create a com/jboss/flood package and a process definition in it
4) create a com.jboss.flood package and a process definition in it

Every time I hit build & deploy then the following happens for the cases above

1) WorkDefinitions.wid is included without the process definition
2)3)4) directory structure is included with the WorkDefinitions.wid in the directories but no process definition.
Comment 6 Kris Verlaenen 2013-06-19 21:52:43 EDT

I believe this might also be caused by the "default" kbase that is automatically added (in Beta3 at least) to a new project.  Could you try the following, immediately after create a new project:

 - open the project editor
 - open the kmodule.xml tab
 - remove the "default" kbase
 - save the file

Now try adding a new process and doing Build & Deploy on that, the process should show up in the jar after a successful build.

This means a user would have to manually remove the "default" kbase every time he creates a new project.  I've asked Maciej to identify the commit that fixes this in master, so we can consider if we want to cherry-pick this on top of Beta3 as a possible solution.

Comment 7 Marek Baluch 2013-06-20 04:38:50 EDT

removing the default kbase as described above works. Processes are included on each level.

This solution has one problem. It generates the following segment in kmodule.xml

<kbase name="defaultKieBase" default="true" ...>
    <ksession name="..." default="true" .../>

When such a project is deployed the the server restart will fail. Which is this bug:


Comment 8 Marek Baluch 2013-06-20 10:17:29 EDT
It may not be the same issue after all.

The NPE is thrown on a different line.

Comment 9 Marek Baluch 2013-06-20 10:19:21 EDT
... meaning the server may fail to start not because of BZ-975820.
Comment 10 Kris Verlaenen 2013-06-20 13:49:48 EDT

Are you using an in memory database?  If so, the session that is was using before for execution will no longer be there (as the database is empty), and that's why it's probably complaining (the link between the deployment and the session is stored in a .ser file inside the server data dir).

Could you try either:
 - removing the .ser file(s) inside 
 - configuring a datasource that would survive a restart, like file-based h2

Note that we have fixed this to not fail on this any more (simply create a new ksession in that case) for Beta4).

Comment 11 Marek Baluch 2013-06-21 10:38:05 EDT
To summarize all the findings to get this working:

On the new project after it was created:
 - open the project editor
 - open the kmodule.xml tab
 - remove the "default" kbase
 - save the file

Then when you made changes (either to kmodule.xml or you just added a new process or an existing process  definition has been updated)

 - open the project editor
 - open the pom.xml tab
 - change (e.g. increase) the version
 - save the file

You're ready to "build and deploy".
Comment 12 Kris Verlaenen 2013-06-26 20:16:47 EDT
Fixed in Beta4
Comment 13 Marek Baluch 2013-07-11 06:46:46 EDT
Verified on DR6.

Note You need to log in before you can comment on or make changes to this bug.