Description of problem: If you make changes to your model through the default (text) editor and not through the "Data modeler", these changes are not picked up until server restart. These changes are not visible anywhere in the business-central, other than the file itself. E.g. a Guided Decision Table using a changed class will still use the previous version of that class. Version-Release number of selected component (if applicable): 6.0 ER1 Steps to Reproduce: 1. Create a data model in your project, through the "Data modeler" - class Person, with String attribute name. Save and close the "Data modeler". 2. Open the freshly created Person(.java) file in the text editor available in the business-central. 3. Rename the name attribute to surname. 4. Open the "Data modeler" again and look at the Person class. Actual results: Person class has name attribute still. Expected results: The attributed is surname instead.
With current definition (and implemented functionality) .java files should be generated and managed from the data modeler tool, and not individually. In order to let the user see the auto-generated java code for a given java pojo, a new specific java editor was provided. This editor works in read only mode. This editor was created for bug: https://bugzilla.redhat.com/show_bug.cgi?id=994559 and is applicable for this bug too.
Walter, how will this work when external files are being committed from the outside through Git? This is a supported use case and needs to work out of the box.
The change made through other means and pushed to git are still not picked up. This really needs to be fixed - as per comment 2.
Allowing to sync changes done on GIT and any of the editor sessions is currently a not supported use case. To be able to support it, GIT notifications must be captured and modifications events must be sent to all editors, including data modeler. After discussing this internally, a generic solution will be created for capturing and broadcasting all this GIT notifications to editors. Then every editor might have to adapt his behaviour. We'll try to address this before GA. This is definitely not a beta blocker, since it only affects a very specific use case and in some cases (only when the editors is already opened).
(In reply to Pedro Zapata from comment #5) > This is definitely not a beta blocker, since it only affects a very specific > use case and in some cases (only when the editors is already opened). This issue is currently classified as a beta blocker - if you disagree with that decision, please bring it up with Rajesh.
Several changes was done in order to keep the project and the data modeler synchronized with external changes (via push), and also to keep track of concurrent modifications of the model in another data modeler editor window. In general the same way as in the other editors, when external changes are detected the user is informed (using popup windows) an he can decide between "Ignoring" or "force writing" or "reloading the model" (loosing current changes) In general the data modeler window can have one of this two status: "Dirty": (the user that is editing the model has done some modification and not saved yet) "Clean": (the user opened the window but has not change anything). In the following lines I'll describe shortly what happens when "an external" change to the model is produced. (an external change the model can be produced because of the following scenarios: 1) a user modified/removed/added a pojo .java file and pushed it via git 2) another user working in another editor window saves the model. 3) another user working in the project editor saves the project. For the three scenarios, the data modeler editor will react in this way. "Dirty": If current window is dirty, and an external change is produced the user will immediately receive a popup window with the options "Reload" / "Ignore". "Clean": If current window is clean, and an external change is produced the data modeler will remember that an external change was produced, and as soon as the user tries to change something in current data model, It will receive a poup window the options "Reload" / "Ignore". The clean status case works in this way by definition in order to not disturb users that was only taking a look a the model. Then, as general rule for ALL cases: "if the user editing the model tries to save the model and an external change has bean produced the user will receive a popup window with the options "Force write" / "Reload". (the same as for the other editors.) The following commits has the modification. master: http://github.com/droolsjbpm/kie-wb-common/commit/469011052 6.0.x: http://github.com/droolsjbpm/kie-wb-common/commit/2ab5ba576
I forgot one last comment, at this moment we don't have yet a "BatchUpdateEvent" . So if user A is editing the model, and user B saves the same model in another window e.x. generating three new files A.java, B.java, C.java, user A will recieve three notifications. BatchUpdateEvent will be implemented and when we have them the user will receive only one notification in this case.
*** Bug 1028918 has been marked as a duplicate of this bug. ***
Git use-case is not fixed - user got no notification of anything. Data Modeler silently overwrites. Changes made through git are not picked up at all. Use-case of two users working with Data modeler at the same time was fixed.
Changing severity to high, as the interaction with Git is critical for Eclipse users.
Issue fixed on UF. The problem was related to normalization of git based URIs that from external changes (ssh) uses full tree reference instead of just branch name. https://github.com/droolsjbpm/uberfire/commit/31c9de05d https://github.com/droolsjbpm/uberfire/commit/c1e7a9b80
Improvement was added to the fix. guvnor: master: https://github.com/droolsjbpm/guvnor/commit/2bbdbd33a7e41720ffe4bd01dc69a12f7f7d0f15 6.0.x: https://github.com/droolsjbpm/guvnor/commit/da3864a48fc817138508c3b124eb70f02623f973 kie-wb-common: master: https://github.com/droolsjbpm/kie-wb-common/commit/0bf102440bff0b4db2e94894af70460c40669cb0 6.0.x: https://github.com/droolsjbpm/kie-wb-common/commit/ebf301c5a41b82e09499f2e337f22adc4a4d74c1 drools-wb: master: https://github.com/droolsjbpm/drools-wb/commit/f128abedac2823f4c2886eaa684e59692b7bd176 6.0.x: https://github.com/droolsjbpm/drools-wb/commit/9a8583e11432f9c3e81ed90287c5363eee85eccf
Still more issues with ER7. After starting the server with only the example repo, I created a pojo in 'org' package in the provided project. Then I switched packages in gui, this resulting in the pojo being visible in the Project Explorer. After that I opened the Data modeler for the first time. The pojo was NOT there. I had to create another pojo through the DM, save it and reopen the DM to see the first pojo as well. When I had the DM open and some changes made, so in the so-called dirty state, I pushed a change through git. After the change was visible in the Java editor, I still got no warning in the DM. I was allowed to save in the DM without any warning, the change I made previously through git was overwritten. As before, use-case of two users working with Data modeler at the same time seems to be ok.
One question, When you say: "After starting the server with only the example repo, I created a pojo in 'org' package in the provided project. Then I switched packages in gui, this resulting in the pojo being visible in the Project Explorer." ¿Do you mean that you created the pojo externally and then pushed it to the server? ¿If not, how did you create it without opening the DM? Thanks!
(In reply to Walter Medvedeo from comment #20) > One question, > > When you say: > > "After starting the server with only the example repo, I created a pojo in > 'org' package in the provided project. Then I switched packages in gui, this > resulting in the pojo being visible in the Project Explorer." > > ¿Do you mean that you created the pojo externally and then pushed it to the > server? Sorry for not mentioning this - yes, that pojo was created externally and pushed.
I've tried to reproduce the issue both in master, and 6.0.x branches and It wasn't possible to reproduce it. Here are the steps I'm doing. 1) started the server, etc. 2) for the test I'm using the mortgages project. 3) I cloned the repository with git clone ssh://admin@localhost:8001/uf-playground to my local filesystem. 4) I went to the cloned file structure .../mortages/src/main/org directory and added the City.java file in my local filesystem. (the City.java file is attached) 5) then I executed the git commands, "git add", "git commit -m "something", and finally "git push origin master" to send the new file to the server. 6) now if I go to the project browser I can see the file City.java. 7) now if I open the data modeler for the first time I can see the City pojo too. I'll appreciate strongly if you can check if you are doing the same steps, or maybe something different. ¿?
Created attachment 846699 [details] External push test file
I forgot a final request, ¿can you please point me to an URL that I can use for download and test exactly the same distribution you are using? Thanks!!!
Hello Zuzana, ¿Could you please describe the procedure you are using to clone the repository, including the command line options and protocol.? I need to be sure that we are reproducing the same steps you have done. Thanks again!
I reproduced the test case in: 1) master branch 2) 6.0.x branch 3) and business-central distribution downloaded from http://dev138.mw.lab.eng.bos.redhat.com/candidate/bpms-6.0.0-ER7. In all the three cases the system is working as expected. So I believe this BZ can be marked as MODIFIED. One important remark: When I tried to reproduce the test case in the "business-central" distribution I've found that in fact repositories can't be cloned in this distribution due to another small issue related to the product modularization. This new small issue was reported in the following BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1049530. So if you use current "business-central" ER7 distribution, I believe It's not possible to clone a repository in the correct way using "git clone ssh://XXXX" protocol." Given that, I will appreciate strongly if you can describe the procedure you are using to clone a repository in business-central, because likely an incorrect procedure is being used, or another error has been found. Finally in order to test the scenario in current business-central distribution, I had to apply a small fix in modules dependencies. (no java programming is needed) This small fix, enables the repository cloning, and will be pushed as the solution for the BZ https://bugzilla.redhat.com/show_bug.cgi?id=1049530
With BRMS ER7, no demo or example projects: A. Add the jar mentioned in bug 1049530 to modules, clone using 'git clone ssh://...' -- this works. B. Clone using 'git clone /<path to .niogit>/repo.git repo' -- project explorer sees the pojo and changes, DM does not. With BPMS ER7, if I apply the same 'fix' as in case A., business central won't deploy, so I was unable to test that yet. I don't see a reason for the DM to not 'work' when cloning from the local path, especially if the project explorer reflects the changes made. Nevertheless, cloning using ssh seems to make things work as expected and cloning using the local directory is not usable for the Eclipse use-case anyway. With that in mind, we can consider this fixed of course, though I'd like to wait for that bug 1049530 to retest with BPMS, just to be sure. I'm glad you pointed out the problem with different clone command and this turned out to be a false negative.
The reason why local clone doesn't work is that we can't listen to local changes, using ssh we can. Our docs makes a clear statement about direct use of .niogit folder: http://docs.jboss.org/drools/release/6.0.1.Final/drools-docs/html/wb.Workbench.html#wb.VFSRepository
Just to clarify why it won't work if the clone is done locally, DM is just a frontend UI to a backend types system. Broadly speaking, this subsystem holds some metadata information about the structure of classes, obtained via compilation and instrospection (and not directly from the source code). Therefore, the system must compile and instrospect all the resulting classes to get information about types If the repository is cloned via GIT/SSH, a server listener which is installed in the BPMS GIT 'daemon' is able to get the notification that the repository has been updated whenever you push some changes to it. The reason is the request will pass through the BPMS GIT server. So, it will trigger a rebuild -> validation -> class introspection cycle and everything will work. If the repository is cloned via file system, the GIT tooling will updated *directly* the content of the repository in the file system. The BPMS system won't be aware of these changes, and can't trigger the build -> instrospection process. Hope this provides some insight of how this is supposed to work.