deleting entity

[rbellia]

Hi !

When I manually delete an entity Roo doesn't take care of test classes / web layer.
Therefore in the next build the controller fails and related data on demand tests fail.
After removing tests and controller, the menu stills showing operations for the deleted entity.

Indeed Roo shell detects the controller removal, but doesn't touch jspx files.
It ends up that I have to manually delete all these generated artifacts.

Is there a way via Roo shell to delete an entity and cascade it to tests and web layer ?

By the way, I'm having fun with Roo Congratulations to the developer team !

[Ben Alex]

This is by design.

Roo has some key usability conventions that are detailed in the reference guide, particularly the http://static.springsource.org/sprin...sage-usability section. As quoted in that section:

Let's start by looking at file conventions. Roo will never change a .java file in your project unless you explicitly ask it to via a shell command. In particular, Roo will not modify a .java file just because you apply an annotation. Roo also handles .xml and .properties files in the same manner. There are only two file types that may be created, updated or deleted by Roo in an automatic manner, those being .jspx files and also AspectJ files which match the *_Roo_*.aj wildcard.

We believe there are good reasons for having the .java "file touching" convention. We don't want people to be afraid of Roo tampering with people's projects, even though sometimes (like in your example) it would be helpful. It's also relatively difficult to do it consistently, as Roo would need to know entities which used to exist but no longer exist. It wouldn't be enough to simply delete a controller if a dependent entity type didn't exist, as what if someone just accidentally popped an extra letter into the @RooWebScaffold annotation and then Roo suddenly deleted the whole .java controller in response? Of course that would be a disproportionate reaction to a key slipping onto the wrong key. :-)

Hope this explains the rationale for why you need to delete the .java files. At least deleting the .java files will cause the .aj files to automatically be removed by Roo. We do try to keep things easy as much as we can, within the constraints of predictable, conservative usability conventions.

[rbellia]

Ben,

Usage and Conventions section states that .jspx files can be automatically deleted, as you have quoted.
How can we trigger such Roo behaviour ?

Tks,
Renato

[Ben Alex]

Stefan might be able to offer some thoughts on this. One challenge is Roo would need to know it can delete the .jspx even though the controller that permitted its creation may no longer exist. From a lifecycle point of view I can't see how this would be easy. Stefan might be addressing this as part of ROO-8, though that key issue would likely still remain.

[Stefan Schmidt]

Hi guys,

As Ben mentioned on of our conventions used in Roo is not to delete project artifacts which the user can see and manage. This is a conscious decision to avoid confusion by the user. So if a user adds custom code to a java file he will never be surprised by Roo altering or deleting it.

Since ITDs are always managed by Roo and it is explicitly stated that manual changes to these artifacts will be replaced by Roo we are save to delete these files (remember, you have the option to 'push-in' your code so it lives outside an ITD).

The only other artifacts where our convention (not to delete user-visible code) is currently not in use are certain jspx files in the scaffolded views. If you change a source under /WEB-INF/views/mydomainobject Roo will currently delete that file and replace it with its own version. This is not ideal and has already caused some confusion among users. It can, however, be disabled with automaticallyMaintainView=false. In any case Roo will replace the jspx artifacts by default but not delete them if your controller is deleted.

Currently I am working on a change on this (as part of ROO-8) which will allow Roo to round-trip your jspx files rather than replacing them if a change in the domain model is detected. This will allow you to change code in your jspx files as needed while Roo can still help you manage them. It also means that our convention then fully applies: all user-visible artifacts will never be deleted by Roo.

If you wish to delete certain functionality from your project, you can do so by deleting the relevant annotation or source file manually and roo will not regenerate it if no trigger for it exists (ie @Roo annotation).

I hope this makes sense to you and explains the conventions used in Roo.

Cheers,
Stefan