Description of problem: This can lead to a troublesome situation when an object that is used in rules is renamed. After renaming the object and saving the Data Modeler, the project will have build errors (unresolvable object type), and if you closed the Data Modeler after saving the change, it will be quite difficult to fix the errors because the renamed object will not be loaded. The only way to fix it in the UI is to re-create the renamed object with its original name, including all its used fields and reloading the Data Modeler. Surprising, hard to fix. Steps to Reproduce: 1. Open Data Modeler in mortgages sample project. 2. Rename LoanApplication to LoanApp, save changes, close Data Modeler. 3. Reopen Data Modeler. 4. [optional] Create some new objects, save changes, close, reopen. Actual results: LoanApp is not there, so it cannot be renamed back to LoanApplication to resolve project build errors. Any new objects created when project has build errors are not loaded into Data Modeler. Expected results: Data Modeler should always display up-to-date objects. If this is "won't fix", then at least display a warning: "Project has errors, cannot load data model completetly". Also it should be possible to easily revert the object rename, that broke the project build. Additional info:
With reference to the reported problem a fix has been added and if you reproduce the use case the renamed data object LoanApp will be loaded into the model, even if the project has compiling errors in some other assets. The following steps will enable you to recover the project compilation state. 1) open the datamodeller. (the LoanApp will be loaded) 2) rename the dataobject to the original nane LoanApplication 3) save the model. 4) when the model is saved, the dataobject will be renamed and the project will be automatically rebuilt. You will see the compiling errors disappear from the problems window.
The following commit solves adds the fix in 6.0.x branch: http://github.com/droolsjbpm/kie-wb-common/commit/350d1fa6d It's not possible to establish the corresponding commit in master branch because the internal programming of the model loading was changed in master branch, and will be released in 6.1 community version, and in future 6.1 GA releases. But it was verified in master branch that the new programming works in the same way.
*** Bug 1115371 has been marked as a duplicate of this bug. ***