Description of problem: Data modeler adds automatically kie annotations, but does not add kie-api dependency in pom.xml of the kjar project. This means that the kie project cannot be built outside business central. We found it here [1]. There are two annotations @org.kie.api.definition.type.Label(value = "Reward recipient") @org.kie.api.definition.type.Position(value = 0) added by business-central (the first one is definitely added by data modeler, the second one might be by form modeler). However there is no kie-api dependency added in kie project pom.xml file. So the kie project cannot be built outside business central. I had to fix that manually like this [2]. Version-Release number of selected component (if applicable): BPM Suite 6.1.0.CR1 Steps to Reproduce: 1. Create a project in business central. 2. Add a new data object. 3. Fill in id, name and label. Label is important! 4. Click on tab button 'Source'. 5. You can see similar annotation added to an attribute of the data object: @org.kie.api.definition.type.Label(value = "idcko") 6. Click on wheel and change 'Project View' to 'Repository View'. 7. Open pom.xml. There is no dependency to artifact kie-api defined. Project cannot be built outside business-central. Actual results: Business central adds automatically kie annotations, but does not add kie-api dependency in pom.xml of the kjar project. Such kie project cannot be built outside business central. Expected results: When business central adds a kie annotation to data model classes, they should also add necessary dependencies to project's pom.xml file, so the kie project can be built without modifications outside business central. [1] https://github.com/jsvitak/jbpm-6-examples-assets/commit/625dd865e9ff0c2678c04ef08679f5cb2b02c0da#diff-6db57578e3b4faa0d83daa221191f9a6R7 [2] https://github.com/jsvitak/jbpm-6-examples-assets/commit/3862a126872396383225c31399397b2d861bf6dc#diff-0e4ce80139ae74c93022962a42b05de6R20
This is a more generic issue, basically all the core jars are provided when building in the workbench, but they are not declared as such. It does however require a solution to include dependencies like this without losing the ability to migrate projects from one version to the other (without having to manually update all pom files).
A release needs to be 100% reproducible, up to the last bit. That's important when doing a hotfix release (from a release branch) on a mission-critical kjar that's running in production while you're changing it on the master branch. (This only applies when wb supports branching and hotfix releases of course). Therefore, I would recommend that when a kjar is being released (more specifically during the tagging of all the source code for that release), that a kie-api version is recorded in the wb repository, which is the same as the current workbench version. This way, the release (or a hotfix version of it) can be released again at a later change, even if the workbench version has upgraded, without affecting the kie-api version in the released kjar.