It also seems that roo gets dependency version numbers straight from the pom's XML, rather than using maven version resolution mechanism. Moving the <version> to a parent pom leads to exceptions like:

Exception in thread "main" java.lang.NullPointerException
at org.springframework.roo.project.Dependency.<init>(Dependency.java:97)
at org.springframework.roo.addon.maven.MavenProjectMetadataProvider.get(MavenProjectMetadataProvider.java:108)
at org.springframework.roo.metadata.internal.DefaultMetadataService.get(DefaultMetadataService.java:106)
at org.springframework.roo.metadata.internal.DefaultMetadataService.get(DefaultMetadataService.java:124)
at org.springframework.roo.classpath.converters.JavaTypeConverter.completeProjectSpecificPaths(JavaTypeConverter.java:189)
at org.springframework.roo.classpath.converters.JavaTypeConverter.getAllPossibleValues(JavaTypeConverter.java:114)
at org.springframework.roo.shell.SimpleParser.complete(SimpleParser.java:553)
at org.springframework.roo.shell.jline.JLineCompletorAdapter.complete(JLineCompletorAdapter.java:27)
at jline.ConsoleReader.complete(ConsoleReader.java:832)
at jline.ConsoleReader.readLine(ConsoleReader.java:518)
at jline.ConsoleReader.readLine(ConsoleReader.java:448)
at jline.ConsoleReader.readLine(ConsoleReader.java:300)
at org.springframework.roo.shell.jline.JLineShell.promptLoop(JLineShell.java:73)
at org.springframework.roo.bootstrap.Bootstrap.run(Bootstrap.java:109)
at org.springframework.roo.bootstrap.Bootstrap.main(Bootstrap.java:49)

Multi-project-related support is not a priority for Roo at this time, as our focus is on single project productivity. If we support multi-project semantics a number of improvements would be necessary to related infrastructure (particularly classpath metadata abstractions, as we'd need to access the source code or bytecode for related projects) and therefore this request is not as simple as it initially appears.

If many people would like to see this issue resolved, would they please vote on this issue so we can gauge community demand.

I don't see this request as being about multi-project support as much as it being about letting a single project use a parent pom.

Even to support single project productivity there are many compelling reasons to use a multi-module maven project even if the artifacts are only used by one web application.

It's widely considered a maven best practice to use <dependencyManagement> and <pluginManagement> sections in a parent pom and to have multiple modules to split the project out into smaller chunks.

Roo seems to have a good handle on best practices and has some interesting and the use of aspectJ to enhance the domain objects is one example of this - but the at the same time Roo also forces you to use a single-module maven build which is pretty bad.

Until this issue gets addressed, the only way I could see Roo being useful for anything beyond a throwaway one-off project (i.e. something that works as a quick demo) is as an initial jumpstart for a project - you use Roo to build up some domain stuff, then you remove Roo and move your files around into proper maven modules and maintain the stuff by hand moving forward.

See also ROO-644

If the Roo maintainers don't want to add Maven and its long list of dependencies to Roo, it's still possible to support such a feature with the help of a simple parser for Maven POM files. I have written one for the Debian project, and it should be easy to integrate it in Roo. It supports merging <dependencyManagement> and <pluginManagement> versions from the parent POM.
Checkout the code at svn://svn.debian.org/svn/pkg-java/trunk/maven-repo-helper

80 votes and counting!

I'm with a client who can see the value of Roo, and our simple requirement is to use Roo for a rich domain and persistence, and to have other modules in the same project which aren't using Roo.

We want to manage dependencies, exclusions etc in one place.

I'd argue that Roo not supporting a parent POM goes against the simplicity of keeping unnecessary stuff out of the way.

Roo should behave in the same way for dependencies in a parent pom, as it behaves when deciding whether or not to generate ITDs for, e.g. toString().

i.e.

• If there is a parent POM, and the dependency is already provided, don't add it to the Roo project's POM.
• If it isn't provided, add it.
• On each edit of the parent POM, update Roo's managed dependencies.

This may sound like Roo 2.x or even 3.x stuff, but it is stuff like this that makes the difference between a nice tool to use for prototyping, and a serious tool we can use for enterprise functionality.

To expand on my suggestion above, I think the approach might require a 3rd POM to allow there to be a Roo-managed POM that developers don't touch.

This would result in the following heirarchy:

• parent POM (managed by user)
• Roo managed POM (managed by Roo), and referencing the parent POM (where one has been specified by user)
• Project POM referencing Roo managed POM as it's parent.

Roo's workflow would be to manage dependencies only when that requirement is not provided by the parent or project POM.

The other alternative is to create a parallel to ITDs for XML files

'A rose by any other name is still a rose'. Mulitple levels of object classes, multiple levels of configuration files, each hierarchial chain having:

1/ Global
2/ AutoGeneratedGlobal
3/ Local
4/ AutoGeneratedLocal

is pretty standard in MVC Frameworks these days. The authors of all of these should get together and write a white paper that guides each of these projects. The major players I know of are:

Ruby on Rails (Ruby)
Doctrine in Symfony(PHP)
Spring Roo w/ JPA.(Java)

There's NOT much difference in what they are trying to achieve. Java has the benefit of better development ecosystem and standards based community, and enterprise grade libraries and functionalities. But I think other frameworks are slightly more transparent and agile in design usage than Spring Roo. Spring Roo is probably between Symfony 1 & 2. (Symfony 2 is a definite work in progress, but has good goals - albeit just as documentless as other frameworks)

Git commit 7701ceeff7d7e2bad5c44cc0884f78685e469bf8 adds a new, optional "parent" parameter to the existing "project" command, taking a value like "parentGroupId:parentArtifactId:parentVersion" as suggested above. The new parameter works as follows:

• if blank, the created POM will contain no "/project/parent" element (as before)
• otherwise, the created POM will contain that element with the given coordinates, in which case the project's own groupId will be:
  • omitted if the same as the parent's, otherwise
  • populated as usual

To specify the parent POM for an already generated Roo project, simply update the child POM manually (noting that since ROO-1193, Roo no longer requires an explicit groupId if a parent POM is specified). Roo will not touch this part of the POM in any case.

The project's version will still default to 0.1.0.BUILD-SNAPSHOT, as there is no way for Roo to know whether the project should inherit the parent POM's version. If the version should be inherited from the parent, simply delete the /project/version element from the POM manually.