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: 1. 2. 3. Actual results: Expected results: Additional info:
I suspect your NewProcessHandler (or whatever class it is you have) doens't use the the selected path/Workbench Context?
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.
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? Thx, Kris
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?
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).
Looks good.
Kris, please is it possible to rename the Package property of the process? Something like "Scope", "Scope Package", etc.
*** Bug 1002428 has been marked as a duplicate of this bug. ***
Closing, requires doc text.
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.
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.
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.
I belive it's not necessary to test that the package is always org.jbpm.