Jul 16th, 2010, 02:58 PM
Improving the Roo experience for existing projects
A while back, I posted some vague thoughts about getting Roo to work in an existing project. Now that I've had some time to dig into it deeper and come up with some more concrete ideas of what needs to be done, I want to share what I think can be done and get some feedback on it.
I understand that support for existing (and to some extent, multi-module) projects is not currently high on the Roo team's priority list, but it is crucial to us if we want to use Roo (and we do!) and we are willing to put forth effort to help make it happen.
Here is our scenario: We have existing multi-module projects that we'd like to use with Roo. In our case, we don't necessarily need Roo to know or care about any code in other projects, but we do need it to be aware of the parent POM when taking into account Maven dependencies at least.
There are a few immediate problems in getting this working:
1) The current Roo maven addon is pretty simplistic in its approach to getting Maven metadata. It only looks at the current POM for dependencies and other data, it fails immediately if you don't explicitly have a groupId in the project (ie, you are extending another project), it can't deal with properties in dependencies, and a few other things.
The current addon can be made marginally smarter to get around most of these issues, and I've already made most of the fixes to my local branch. I'm happy to supply a patch if anyone cares about these issues.
However, it still can't deal with dependencies defined in the parent, doesn't know about transitive dependencies, and can't look in the parent for version information defined by dependencyManagements. To support any of this, we'd really need something like Maven embedder.
Our idea is to create a new Roo addon for Maven that uses Maven Embedder to deal with these issues. Of course, we don't need any official support or endorsement from the Roo team to do this, but we will make it public and available under an open-source license and hope that it would be folded into Roo if the quality and usefulness of it were sufficient.
2) Several other addons read and manipulate the POM without going through the Maven addon and they are really brittle because they depend on the POM having certain elements in it.
For example, the GWT addon will fail if you don't have a <build /> element already in your POM. I see two issues here:
a) Shouldn't all operations like this go through the Maven addon?
b) Can we make it so that there is a bit less of a dependency on a specific POM structure?
For example, there are a lot of calls to XmlUtil.findRequiredElement that will fail if an element doesn't already exist. One change I'm working on is to add XmlUtil.findOrCreateElement that will find and return an element if it exists or create a new one and return it if one can't be found. Then many uses of findRequiredElement could be replaced with this and there would be less dependency on the POM having specific elements.
What is the likelihood of changes like these being accepted?
If anyone has any other thoughts as to how important these things are, the likelihood of efforts in this area being able to get into Roo, or ideas about how to achieve these goals, please let me know.
For reference, here are a few existing issues that are related to these ideas:
Jul 20th, 2010, 07:50 PM
I like the sound of the proposed enhancements, although I am not keen on embedding Maven Embedder (one of Roo's requirements is to minimize dependencies). I'd prefer we parse the XML files to build a POM containing the subset of data we need (ie we shouldn't need full transitive dependency information, just the dependencies declared in the parents etc).
I'd recommend you start by making the existing Maven addon more robust, and ensuring all existing Roo add-ons use the provided APIs. Please feel free to log patches in our Jira instance and I'll take a look. Please note we have a ICLA process for accepting patches, but I can send you that off-list after you've had a chance to log a patch.
Thanks for your help.