CODEWITHSUNDEEP
grails
John Little
John Little

Reputation: 12449

grails 3 creating sub projects

It is common to have a web admin project which produces a war, and an API project which produces a different war. Each can run on different servers with different firewall rules (in production). The common part is the service and domain layer. Additionally, there may be other components which are optionional which also benefit from being exploded plugins. Exploded plugins allow separation but allow developers to see and modify all source together as if it was one giant project.

In grails 2.5 setting this up was trivial:

  1. create your web admin app in your project root
  2. create your core services app as a plugin in the project root
  3. Add one line in your web admin projects BuildConfig.groovy to use the services project as an exploded plugin, e.g. "grails.plugin.location.coreservices = "../coreservices""

To build the project, you just do grails war in the web admin app folder.

Brilliant. Effortless and effective. Developers just checkout both projects from git and off they go. Works seamlessly with intellij 14 also as a bonus (we dont have a license for 15+ unfortunately so no grails 3 support)

Before we can consider moving to grails 3, we need to be able to do the same thing.

We could only find one post on the subject.

This requires extensive "hacking" of gradle scripts and creation of scripts in the dir above the two projects, which is not ideal for use with git.

In the section "keeping things DRY", they move some stuff from the sub projects build.gradle file into a build.gradle file above the projects. Is this required?

  1. The new master gradle file has "repositories {mavenLocal().." twice. once at the top under buildscript, then again under "subprojects{ project->". Is this correct? Should it not either be only on the main project, or only on the two sub projects, not all 3?

  2. If we introduce optional exploded plugins (with different dependencies), the parent gradle will have to be edited by hand by each developer. This makes it hard to version and control.

  3. The article adds spring security core to the "plugin-domain", not the web app project. Surely the security is added to the web app, not the services/domain layer plugin? an API app project would have different security requirements.

Does anyone have a better way with grails 3, or shall we stick to grails 2.5? There are no features in grails 3 we need, but at some point 2.5 will become too old and migration looks to be infeasible for the most part. The fact there is no affordable IDE with integrated grails 3 support similar to intellij ultimate or GGTS is a big negative also.

Upvotes: 0

Views: 423

Answers (2)

John Little
John Little

Reputation: 12449

I found and followed this tutorial, which is different from most of the other tutorials as it uses create-plugin instead of create-app for the plugin part.

The project then works correctly with eclipse neon 2.

Upvotes: 0

Evgeny Smirnov
Evgeny Smirnov

Reputation: 3016

"hacking" is not necessary. Here is official multiproject tutorial: http://guides.grails.org/grails-quickcasts-multi-project-builds/guide/index.html

mavenLocal() - is a local folder that is used to store all your project’s dependencies. The "buildscript" block only controls dependencies for the buildscript process itself, not for the application code, which the top-level "dependencies" block controls. So you can have different repositories for "buildscript" and "dependencies".

Read the Gradle User Guide for more information. Gradle is harder then old grails build system, but more powerful.

I moved project from grails 2 to 3 and I was pleased with the result.

IntelliJ 2016 - 2017 work perfect with grails 3

Upvotes: 1

Related Questions