Description of problem: When roundtripping between Data Modeler and Eclipse, validation annotations added to fields in Eclipse are removed when updating the class in the Data Modeler. Version-Release number of selected component (if applicable): How reproducible: On Demand Steps to Reproduce: 1. In Data Modeler, create new type Test 2. Add a field test with type java.lang.String 3. Save the Data Model 4. In project imported into Eclipse, open Test class 5. Add @Size(max=10) javax.validation annotation 6. Commit and Push changes 7. In Data Modeler, add a new field (otherTest) to Test 8. Save the Data Model 9. Pull changes in Eclipse 10. Open Test class Actual results: Validation annotation is removed from test field Expected results: Validation annotations remain on test field Additional info:
Current data modeller do not support arbitrary annotations. (It's not java programming IDE). In my opinion enable support for arbitrary annotations is a feature request, not a bug. To support arbitrary annotations also carries the problem of dependencies, the same as happens in whatever other tool. If you use for example an annotation that belongs to a third party java libray, you should add the corresponding dependency to the project, etc. I added @etirelli and @pzapataf in the CC list so that they can evaluate this.
(In reply to Walter Medvedeo from comment #2) > Current data modeller do not support arbitrary annotations. (It's not java > programming IDE). > In my opinion enable support for arbitrary annotations is a feature request, > not a bug. > To support arbitrary annotations also carries the problem of dependencies, > the same as happens in whatever other tool. If you use for example an > annotation that belongs to a third party java libray, you should add the > corresponding dependency to the project, etc. > > I added @etirelli and @pzapataf in the CC list so that they can evaluate > this. The Data Modeler may not be an IDE, but Eclipse is. If I modify the classes generated by the Data Modeler, maybe the Data Modeler should no longer display the class. The bug is that there is loss of code without warning.
Walter, ideally we need the data modeller to preserve customer provided annotations, so it is something for the todo list. Having said that, I am nacking this for 6.0.0 and proposing it for 6.0.1. If it is not possible, lets discuss in engineering the alternatives.
The only and generic solution is to avoid consuming and introspecting compiled bytecode and start doing source code analysis. This change should be targeted for future versions, not for 6.0.1. This same problem occurs for any type of asset that has a UI. Data modeler is a tool aimed to non-developers and analyst capturing requirements. To increase robustness and reliability for 6.0.1 the following can be implemented: - Detect whether a change has been done to the POJO source code outside the data modeler editor (i.e with Eclipse). If so, then the data modeler UI will display the POJO in read-only mode, without the possibility of overwriting the changes made outside of data modeler. This option is safer and will avoid code loss scenarios.
According to the specification above, controls were added in order to detect if a file was created/modified by an external tool. To prevent loosing code pushed form external editors, if file was created/modified by an external editor the data modeller will show the file in read only mode. It means that It won't be possible to modify or delete the corresponding pojo from the datamodeller. When the model is opened, if there are readonly objects the user will receive an information dialog showing the list of readonly objects. After the information dialog is closed, readonly objects will show the sufix (read only) in the navigation breadcrumb. master URL: http://github.com/droolsjbpm/kie-wb-common/commit/83842a356 push 6.0.x URL: http://github.com/droolsjbpm/kie-wb-common/commit/24d2441b2
*** Bug 1063312 has been marked as a duplicate of this bug. ***
Verified in ER1. However the solution described in comment 6 is going to be obsoleted by bug 1066616.