Bug 991013 - A new BPMN2 process doesn't have package from its location in resources
A new BPMN2 process doesn't have package from its location in resources
Product: JBoss BPMS Platform 6
Classification: JBoss
Component: jBPM Designer (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ER4
: 6.0.0
Assigned To: Tihomir Surdilovic
Ivo Bek
: 1002428 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2013-08-01 08:01 EDT by Ivo Bek
Modified: 2014-08-06 16:10 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-08-06 16:10:53 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 Ivo Bek 2013-08-01 08:01:05 EDT
Description of problem:

When I create a new BPMN2 process in src/main/resources/com/xyz, the package contains org.jbpm instead of com.xyz. It happens even if I create a process in src/main/resources.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:

Actual results:

Expected results:

Additional info:
Comment 1 manstis 2013-08-01 08:26:12 EDT
I suspect your NewProcessHandler (or whatever class it is you have) doens't use the the selected path/Workbench Context?
Comment 2 Ivo Bek 2013-08-01 09:05:56 EDT
I don't know what exactly you mean by that but the new process definition has been created in the com/xyz directory and the process package isn't the same as the selected path.
Comment 3 Kris Verlaenen 2013-08-01 09:42:27 EDT
Correct, the package that is shown there is just the default for new processes.  A restriction in BRMS 5.3.x was that the package of a process needed to be the same as the package the process file was located in in Guvnor (which caused various issues).  This restriction is no longer there in BPMS6.  As a result, the package of a process is currently (I believe) only used for import scoping.

We believed it to be easier to just default it to a fixed value (org.jbpm) rather than to try and derive the actual path it is located in in guvnor (which wouldn't be updated when the file is moved anyway).

So the observed behaviour is as expected, could you clarity why you believe this might be an issue?

Comment 4 Marek Baluch 2013-08-01 09:49:29 EDT
It is confusing at best. I remember that previous versions did not use the package string as it is now (org.jbpm). They used part of the package name plus folders like resources, src, etc.

I believe that this should be documented. Do you have a different opinion?
Comment 5 Kris Verlaenen 2013-08-01 10:15:58 EDT
Sure, wdyt about adding something like this to the release notes:

The restriction that the package attribute of a process should be the same as the package it is located in is no longer applicable.  The package attribute for newly created processes now defaults to "org.jbpm".  The user can update this property at will, this will then be used as the default package of the process regarding imports (a process has by default access to classes that are defined in the same package as itself).
Comment 6 Marek Baluch 2013-08-02 02:57:40 EDT
Looks good.
Comment 7 Sona Mala 2013-08-30 04:27:43 EDT
please is it possible to rename the Package property of the process? Something like "Scope", "Scope Package", etc.
Comment 8 Kris Verlaenen 2013-09-03 10:45:23 EDT
*** Bug 1002428 has been marked as a duplicate of this bug. ***
Comment 10 Kris Verlaenen 2013-09-24 11:33:02 EDT
Closing, requires doc text.
Comment 11 Ivo Bek 2013-10-15 12:21:58 EDT
Returning due to the unresolved Sona's request https://bugzilla.redhat.com/show_bug.cgi?id=991013#c7 to rename the package property in BPMN Designer. The reason has been to make the package "types" clearer for users when there are some differences. Also it will help to write the documentation about this special package because it's easy to get lost with all the different package types.
Comment 12 Kris Verlaenen 2013-10-15 14:43:40 EDT
I'm sorry, but I really don't think "scope" is any less overloaded than package (we for example already have variable scope, exception scope, etc.).  The reason why we use package is that this attribute is used whenever compiling (generated) rules or scripts from the process, these are generated in the given package.  So there's a direct match from process package to the package keyword in drl.  It also behaves similar to a Java package when it comes to imports.

So I would like to keep the name for now, at least until we find a better overall name across rules and processes.
Comment 13 Ivo Bek 2013-10-16 04:22:55 EDT
Ok, I see. We wanted to change the package property in the BPMN Designer to be clear that this package affects which classes are imported in default. The change wouldn't be anywhere else (maybe except the BPMN Designer in JBDS). It was only about one label we discussed.

Probably I'll propose a request to add tooltips (or some information icon), containing the description of every property which is a better option, I believe.
Comment 14 Ivo Bek 2014-03-18 06:06:20 EDT
I belive it's not necessary to test that the package is always org.jbpm.

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