Question

I have a Grail application that references a Java library (as an IntelliJ Module dependency). This works, but as soon as I add hibernate as a dependency of the Java library the Grails will no longer run.

Loading Grails 2.0.1
Error Error executing script RunApp: Provider for javax.xml.parsers.SAXParserFactory cannot be found (Use --stacktrace to see the full trace)

In my Java module, I am adding hibernate with the following:

<dependency>
  <groupId>org.hibernate</groupId>
  <artifactId>hibernate-entitymanager</artifactId>
  <version>4.0.0.Final</version>
</dependency>

I can’t see any good way around this. The Grails dependency-report does not show any libraries in conflict. The error occurs if the hibernate plugin is installed in the Grails application or not.

Bear in mind that (in this case) the Java library is not being incorporated via the BuildConfig.groovy. It is being incorporated as an IntelliJ Module dependency. If I incorporate the module as a jar via BuildConfig.groovy, everything works, but I lose the ability to step into the Java code.

Clarifying:

Per the JetBrains folks, the Java library is incorporated both as an IntelliJ Module dependency and in the BuildConfig.groovy. When executed from the command line, the project works, this is only an issue when starting from the IDE.

Suggestions?

Answer 1

After experimentation, I stumbled upon the following which seems to be working very well (at least in IDEA 11.1):

• Your Java library JAR should be referenced from the
  BuildConfig.groovy (we use Maven, so we had to add the local Maven
  repo as well)
• Also reference your modules as module dependencies of the Grails module
• (this is critical) in the run config for your grails project, uncheck the “add –classpath …” option

The module dependency gives you:

• Immediate awareness of the Java classes and their methods from the Grails project
• Support for stepping into the Java code from your Grails project.

The BuildConfig reference gives you:

• support for the grails commands, including run-app (which is how IntelliJ kicks things off when running/debugging a project)

If you leave the –classpath option checked, then you foul up the way that grails resolves its dependencies. There may be a better way to do this, but I haven’t found it.

Additional Note

There’s a bug in the interaction of grails and maven which causes grails to not pull in dependencies from local Maven 3 repositories if the pom.xml wasn’t changed.

Therefore, our complete dependency refresh cycle looks like:

• goto top
• mvn clean install
• find the relevant POM files in the repo and touch them
• back to grails app directory and grails refresh-dependencies
• run the app

You only need to do this when there are updates to the upstream Java libraries.

Hat tip to Sergey from Jet Brains for tracking that one down.