When I move or rename a file on the file system or delete it, it stays in the model / class repository. I do not want this behavior, having to go and manually keep the model in synch with the code (isn’t that the purpose of round trip anyway?).
How is it “synced” if it allows phantoms ???
Anyway, I am trying to use Java Round Trip, but to make the code “king”. In other words, I want the option to do round trip, but if I move a file or rename it in the source code on the file system, I want the model / class repository to reflect that every time.
I’m sorry that what you looking for is out of our capabilities. The round-trip code engineering we support is allows you to patch the model/source code without re-created or re-generate it. If you have modified the implementation in your source file, you can than reverse it by patching the model. On the other hand if you have modified the model you can generate them by patching the source code, without re-create your source file or erase the implementation you done in there. We will not monitor the activities on your file system, so manually trigger the synchronization need to be done after you directly made modification on the source file. And if you have renamed or moved a file in source folder, in our point of view that will be equal to delete + create.
I would not expect the software to monitor the file system automatically, nor would I want that. But I would expect the software to pick up the changes to the file system on the next reverse engineering activity. That is the very definition of reverse engineering …
Is that what you mean by “manually trigger the synchronization need to be done after you directly made modification on the source file”?
That will be depends on the scope when you trigger the reverse engineering. If you have trigger the reverse engineering just on specific class, then only the related source file will be reversed. But if you perform reverse engineering on the entire source path than all the changes in your source will be updated to model.
That’s a great marketing description, and that’s exactly what I would expect. Unfortunately that’s not how it works. It appears to be updated in the model, but the Round trip node is not updated.
So I found your bug. What’s happening is that the “Java Round-trip” node is not accurate - it does not reflect what is on the file system, nor what is in the model. It retains “phantoms” that go away when you exit the application and return.
You can easily reproduce it - just create a class on the file system, reverse it into the model, then while outside the application, move it around, rename it, delete it. Now reverse again and the model and the class repository will reflect your changes, but the Java Round-trip node will not. The original file name and package location will still be there.
I suppose that’s not the end of the world, but it is terribly confusing and distracting. It’s also disappointing - not the kind of obvious bug I would expect from a professional tool and it makes me wonder what kind of other bugs are lurking around
