It would also be necessary to add the Spring Aspects JAR, so that @Transactional, @Configurable etc works. If people just want to @RooToString etc, this isn't needed, but they'll be surprised when they use @RooEntity.
I agree with Christian that Roo should understand what it needs to do to a Maven POM to make it into a Roo project and cause the required adjustments to take place. It would be a source of incompatibilities, support incidents and maintenance cost for STS to be continuously updated to reflect the latest Roo POM configuration policies.
In any event there have been requests from the Roo community to be able to use their own POMs - not the Roo template POM. Accordingly having some sort of "setup my existing POM" command in Roo would make it possible to implement that new feature.
On the downside the present project metadata and services abstractions were intentionally designed to generalise the dependency management features of Maven and Ant+Ivy. If we start to add more Maven-related commands, it gets harder and harder to support Ant+Ivy. The relevant ticket is https://jira.springsource.org/browse/ROO-91 and presently has some 26 votes. I am reluctant to go down a path that would make Ant+Ivy even harder to achieve. Having said that, we already have the "perform" commands and these are not going to be supported by Ant+Ivy either, so maybe it will just be a case that you get a better experience with Maven and Ant/Ivy support is more primitive. As an aside, can Christian comment on the state of Ant/Ivy container classpaths in Eclipse/STS at this time? Last time I discussed it with Ben Hale he said it was not quite ready for prime time, but that was some time ago.
Keith, I would not recommend the svn:ignore portion of the commands. We generally recommend the checkin of ITDs, so your project will always be compilable without running Roo again and you know the exact ITDs you had when you did a CI/release build. In any event I'm not sure we'd want to favour SVN, as I think it's fair to say SVN has a lot more feasible OSS competition these days.
Christian, I would also like to see the AJDT weaving message be eliminated if any project in the workspace has the AspectJ nature. An informational message might be of the style, "One or more of your projects is currently using AspectJ [name of projects]. JDT weaving has therefore been enabled to ensure you have a better development experience. You can switch this off if required by using Preferences > etc after the restart (although this is not recommended)". We know they need this feature, so switching it on and informing them delivers better usability. I'd also like to see fewer messages to do with AJDT weaving. I'd like AJDT to simply tell them what has happened and click the "Restart Now" button or "Restart Later" in the same dialogue. Then when the IDE restarts it can do the reindex automatically. Right now there are three prompts (enable weaving, restart workbench, should I reindex) and each require a decision from the user. We could have an "automatically handle AJDT weaving decisions" tick box under the AJDT settings (which would default to true) if we wanted to ensure expert users could still have the present three messages displayed.