Advice with Roo and multiple front-ends

[matan_am]

Hi Guys,

Just started playing around with Roo and it is pretty nice. Sure saves a lot of headache! Especially can't wait for Solr support.

I need some advice on how to organize a product that will use Roo. Basically the domain model and service layer will be shared between two different web applications (a "customer" app and a "backoffice admin" app - which can be installed on different machines) as i'd like to avoid duplicating most of the shared functionality / persistence layer.

Any hints on how to best do this with Roo? (I'll also be using STS as well for the first time as i usually use IDEA). It might be super simple, but i want some advice for the experts.

Cheers and thanks!

[hatim]

Well, you could make one application with Restful interfaces and call it from your other application.

It also depends how you create/read/update/delete. If you are only reading from one application then you can safely share the logic of your application in the second application.

I think a proper way to reuse would be to make a bundle (OSGI or maven) and then share it amongst two packages , but I suggest that you go with Restful interfaces first.

[matan_am]

Thanks hatim,

Thanks for the advice, but i'm not sure i'd want to implement a remoting solution to share the services/persistence layer.

Normally I would just create three different "projects" - one for the service and persistence layer (core project), and one for each web application which would use the core as a dependency.

Is this feasible with Roo or will there be some pitfalls?

Thanks,
Matan

[hatim]

ROO will help you generate the projects but then you will have to do all the plumbing your self. So in that sense ROO will not hinder in any way when it comes to hand crafted code (but your particualr scenarios is not dealt with code generation at this point AFAIK)

[whyBish]

There are various flavours of this request floating around
https://jira.springsource.org/browse/ROO-120
I might be wrong but I think the spring team said something about they'd expect that someone could/would deliver this as a plugin but it wouldn't be core. I can't find any such statements in my quick search though.

[Ben Alex]

We don't presently support multi-projects, as mentioned above. My advice would be to use a single project for now, and refactor into separate projects only if you need to. Even if Roo never supports the feature, you can always push-in refactor and remove Roo, so you're never going to be stuck waiting for the feature. But in my experience many efforts to have different projects stem from over-complicating the problem. There's certainly cases you need different projects, but it's less common than you'd think.

[whyBish]

In my context (development for banks / govt departments large corporates etc.), 'multimodule' is the only allowable pattern. Defense in depth requires separation between the web / business / and database tiers. (i.e. completely separate servers often in physically different locations.

[Ben Alex]

It's not that hard to make multi-project work if you have the source code. It gets more tricky if you only have .jar / .class files available, as we'd have to write a parser for them (and the source-level @Roo annotations won't be in there etc). So can we make an assumption when you say multi-project you mean a typical Maven-style project where there's a root pom.xml with a packaging of "pom", then subdirectories for each module? If so we can probably do that in a 1.x.0 release. If we need .jar / .class support, it's a x.0.0 release instead.

[whyBish]

What I'd expect would be some deployment split so that the result is something like:

common to business logic deployment and web tier deployment:
domain.jar
service.jar

business logic deployment only:
dao/daoimpl/serviceimpl (whether separate or the same jar)

web deployment only:
jspx/controllers

Not sure:
validators

[Ben Alex]

One of the issues with making multi-project work without relying on the availability of .java source code is the @Roo* annotations are source retention only so there is no way to discover them from the .class files. Sure there are ways to resolve this but it's an example of why multi-project is non-trivial.