> Hello,
>
> We have a Roo web project and we want to add some
> Entites from an external JAR as maven dependencies.
> We built this Entities using Roo as well.

I probably have no answers, just reacting and giving my
thoughts.

A quick disqualifying question - what is your top level package
name? Both artifacts should use this value. Otherwise
Hibernate won't see the other entities, even if they exist
on the classpath.

Maybe as a test you could rename the applicationContext.xml file
for the external JAR artifact so that it doesn't potentially
conflict with the one in META-INF/spring in your primary
web application.

This is something I think they have to address infrastructurally,
and since Roo doesn't run in OSGi (only the Shell does)
complex classloading isn't possible, as you're essentially
in a single classpath in a given WAR.

We have Spring web applications at Chariot where we
load a number of jar files as dependencies to our final
war, and we name each application context with a -warname.xml
extension, so applicationContext-reports.xml, for example.
Then, we do a load of the app contexts either path-based
or in older apps we just listed them.

So I know it is possible as just a WAR with dependencies
in Spring itself, and a standard practice. But I am pretty
sure the two issues you're facing in Roo are
a) the name collision for applicationContext.xml, and perhaps
b) AspectJ compilation -vs- source code across two
Maven projects.

You could, perhaps, use Shade or the Assembly add-on
to assemble everything at runtime, and you'd have to
get the IDEs to look at the packaged (compiled) dependency as
opposed to the source code.

>
> However, it doesn't work. This is the error message:
> @OneToOne or @ManyToOne on
> ourPackage.OurClass.currency references an unknown
> entity: ourExternalPackage.Currency.
>
> I've created a POST in the Roo forum with more
> detail:
> http://forum.springsource.org/showthread.php?114144-JP > A-Entities-from-an-external-JAR-quot-references-an-unk
> nown-entity-quot-error.
>
> Appart from any help, I'd like some suggestions for
> managing multi module projects, because my approach
> (importing other projects as maven JAR dependencies)
> doesn't seem to work.
>
> I know it's an open issue, according the POST of this
> forum:
> http://www.manning-sandbox.com/thread.jspa?threadID=46 > 083&tstart=0 and the most popular Roo JIRA Ticket:
> https://jira.springsource.org/browse/ROO-120 >
> Thank you very much in advance.

At the end it worked without any extra configuration from my part. Maybe it was some issue from part of the STS.

In order to use another JAR with JPA entities, appart from including the JARs as MAVEN dependencies, the only configuration I need is to add manually the classes that are no in the top level package in the persistence.xml:

As you suggested, I removed all the configuration files from the JARs in order to avoid conflicts.

In fact, the configuration of the application should be done in the application itself. You can't suppose anything for the main application when you're creating a module. And you can't expose the API in a single not modular (OSGI, for instance) JAR.

However, the debate about this approach remains.

We're doing that because there is no support for multi modules in Roo.

But now we have to create the views for the helper classes within the application:
- Should we copy and paste the Controllers and views from the Roo projects used to create the modules? It depends on the names, for instance, the embedded annotations are not
- Should we create Spring MVC objects from scratch? It's possible, but it's a cumbersome work, since everything was done previously.

1) you can maybe use the Hibernate packageToScan parameter to specify your packages. This would be on your main applicationContext.xml file as a property of LocalContainerEntityManagerFactoryBean. It takes wildcards:
[pre]
<property name="packagesToScan">
<list>
<value>com.a.b.c.d</value>
<value>com.e.f.g.h</value>
</list>
</property>
[/pre]

I am unsure if once you go out of the JAR you'd have problems... I am thinking you might, but my first gut instinct is that you don't have to. There was something about <jar>jarfilename.jar</jar> in persistence.xml that would add that jar's classes to the scanning path, but I think that has to do with EARs, which have multiple deployed units. I never asked you whether you are deploying WARs or the JARs and WARS wrapped in an ear.

2) I would approach it slightly differently. Suppose you have a customer service app that has two domains - order_tracking and problem_resolution. Suppose further you have set up each of those Jar files this way:

(Bonus, that's what it is set to now). So, as long as they all start with applicationContext and end in .xml, they will be loaded.

Then, your web context inherits the configuration from the jar files, which are assembled at runtime to live in WEB-INF/lib.

2) Your Spring MVC application context - in WEB-INF/spring/webmvc-config.xml - automatically inherits from the business context, and so can see all beans in the jar files you've added, plus, since you added those jar files as Maven dependencies (and the common one), you can code your controllers against the beans in the other jars, which will be automatically mounted and used.

3) So, in answer to what I think you are asking - you don't copy anything, you just define the value objects in a common JAR file that the service/repositories and the web tier both see.

I think you are planning on true component programming, and that's more of a deployment thing than anything else - if you program your application to access exposed services, it doesn't matter whether they come from the local WAR or from another JAR in an EAR - they get injected by Spring and that's it. I think of the separation of the WAR and JAR as a physical implementation detail, and try to go as simple as possible.

If you really want to go down the OSGi route, I can get you in touch with some of our developers who work on those projects - they have been using what used to be called Spring dm Server (now an Eclipse project named Virgo) and they deploy modularly. OSGi lets you expose packages, so that you only show what you want to, and is very complex. However, since Roo doesn't really support it out of the box, I think the WAR + JARs approach is the simplest deployment model. At least for this year.

Thanks for the suggestion of allowing Hibernate to scan packages using Spring configuration. Since there're a lot of Entities in the Helper modules (external JAR), the persistence.xml should be very verbosed.

I think I can't use the <jar> tag in the persistence.xml, because it accepts local paths, so it's not intended for Java EE applications.

By the way, the application will be an EAR with a WAR file and one or more JAR files for this helper entities and maybe another custom classes. We don't use EJBs, but the production server is an IBM WebSphere 6.1 (yes, there's room for more problems at deploy time)

Regarding your suggested approach, it's the one I've been followed.

The copy-paste option was only considered for the desperate time when the time is close to the end of the project.

We're building each module as a complete web Roo application in order to have the views and the Controller created. The latter can be used directly because they're POJOs in the JAR modules.

Renaming the application context is a good approach, but I need to remove the persistence.xml and I'd like to provide a "clean" module for future projects. However, I will reconsider it because I need a "short" package to scan (com.company)

Regarding OSGI, I apreciate a lot your offer, you're very kind. But for the time being nobody in the company is using it. And we should learn how to configure OSGI applications in WebSphere with the collaboration of the Production department. Maybe one day.

Tomorrow I'll continue with the development. I can share in this forum the progress, in order to see the benefits (and issues) of using Roo in a real project.