I am currently defining the project structure for a project that I am working on. The project is a simple SOA implementation and as such has a grails app and a number of different services.
I wanted to package these services into separate modules (jars) so that they can easily be deployed separately and there is no risk of cost-contamination of classes.
The project structure and dependancies could be visualised as:
Grails App (war)
|__ Service Gateway (jar)
|__Service A (jar)
|__Service B (jar)
Whilst these services will eventually be deployed seperately, for ease of local development I want to package them into a single grails app until such time as it is necessary to break them apart.
My ultimate goal was to be able to develop these services in the same way I would a simple grails app in that I would be able to change any class (within any of the modules) on the fly and have it picked up.
I am struggling though to see the best way in IntelliJ to represent this structure.
I had created seperate modules for each of the above and added the dependancies between them, but obviously grails has no idea of this at runtime.
I have read about and found the following possible solutions, all of which currently feel a bit unsatisfactory as would require a jar to be built meaning that classes cannot be reloaded on the fly.
Install the modules into the local maven repository and reference this in the grails build dependancies.
Drop the built jars into the lib directory.
Add them as grails plugins (seems a little heavy handed as they won't require grails functionality).
Find some other way of including the output directories for these modules on the grails classpath (not sure of the cleanest way to do this).
Thanks!
In the end, I went with a multi module Maven build. The key to the on the fly code deployment is using JRebel to monitor the output directories and reload the classes when they change.
Related
Bazel is a multi-language build tool from Google that acts as a replacement for things like Maven, Gradle, Make, etc. There are articles written on how to migrate from Gradle to Bazel, for instance. But I wonder if this tool works with Grails.
Grails is a web app framework that uses Gradle, but from what I've seen it's a bit more than that. For lack of a better term, Grails itself acts as a "wrapper" for common tasks such as building an app as a WAR or JAR file, running the app locally with different profiles, or scaffolding new files and features. Popular IDEs such as IntelliJ have Grails plugins available to run these Grails commands. So it seems to me like it's perhaps tightly coupled to the Gradle build script that backs it.
It also seems to me that just because Bazel says it supports Gradle projects doesn't necessarily imply that it supports Grails projects, because of all these reasons regarding Grails being more than just Gradle. But I wanted to ask the community if my assumptions are true, or if, in fact, people are already using Bazel as a substitute for Gradle inside Grails projects. Can it be done?
Bazel could in theory be used to build grails projects as it is fundamentally agnostic to the type of thing being built. That said, grails probably works well with gradle out of the box and you'd have to re-implement a number of things yourself again and probably is not worth the effort. If you are a large shop and have multiple other languages that you need to support however, it may be worth investing in the effort.
https://github.com/pubref/rules_maven supports using a gradle file to determine transitive maven dependencies if you want to investigate further.
I'm developing a Grails 2.0.x application that of course has several external dependencies. Since I'm sitting behind a corporate firewall I've configurerd my ProxySettings.groovy to allow access to internet, which works as it should.
Now we also need to include dependencies to some local artifacts (from other projects), which can be found in our local Maven repository. Our corporate network setup is to use the proxy only for external sites, not internal ones. So when Grails resolve my dependencies at startup it downloads all the external artifacts fine, but fails when trying to fetch our local dependencies. If I completely remove the content of my ProxySettings.groovy-file, then the opposite is true, Grails can't resolve the external dependencies, but does manage to download the JARs from our local Maven repository.
I've tried to find documentation on how to exclude internal sites from using the proxy-settings in Grails, but failed miserably so far.
One other alternative could perhaps be to remove (or change) the proxy settings programmtically in BuildConfig.groovy before the call to mavenRepo?
Currently we are not using Maven to build our Grails projects (since we previously have had some issues with creating release builds on the build server).
Any help would be much appreciated!
Right now I do not thing there is an easy way to get around this.
There is currently an open bug for being able to switch the Proxy-Setting programmtically
http://jira.grails.org/browse/GRAILS-7658
Another option would be to move the internal dependencies inside your grails project.
or you could just dump everything in BuildConfig.groovy
System.properties.putAll([
"http.proxyHost": "myproxy.hostname.com",
"http.proxyPort": "8080",
"http.proxyUserName": "myUser",
"http.proxyPassword": "myPass"
])
clear it out for the internal dependencies and then you might be good.
I have two grails projects (on different versions of grails), but they work together to provide a seemless user experience. Can IntelliJ have a single project which has both grails projects?
Some terminology clarifications:
What you're calling a project, IntelliJ calls a module. An IntelliJ module typically generates a single artifact (.war, .jar, etc). The Eclipse equivalent of an IntelliJ module is a project.
An IntelliJ project is a grouping of related modules. The Eclipse equivalent of an IntelliJ project is a workspace
So what you probably want to do is create a IntelliJ project, which contains two modules (one for each Grails app). IntelliJ will allow you to add two Grails modules that use different versions of Grails to the same project. Each IntelliJ module has its classpath.
Yes, sure. You can add it as a new module to current project/workspace: File -> New Module
This has been very upsetting for me up till now. Here is what I am trying to do:
IDE I'm using is Intellij IDEA.
Building a grails application.
Grails application specifies two dependencies on in house grails plugins also being developed in IntelliJ as separate grails plugin projects.
Now to make any changes to plugins, I update the source code in plugin projects and use mavan-install (Maven Publisher plugin) to deploy to local Maven repository.
I have to uninstall the plugin in core grails project. Delete the plugin cache from ivy and then run the core grails project which gets the latest copy of plugin from local maven repository.
What's the effective and ideal way to achieve this? A single change makes me do some 5 minutes of labour work to even test and run core application.
Any recommendations/ best practices?
Use inline plugins for this - see section "Specifying Plugin Locations" in http://grails.org/doc/latest/guide/12.%20Plug-ins.html#12.1%20Creating%20and%20Installing%20Plug-ins
By specifying the plugin project directory with grails.plugin.location.<plugin-name> as the location of the installed plugin, you can edit the real files and the changes will affect the test application, and there's no need to sync anything up.
At my new gig, they use Ant and cannot be persuaded to move to Maven.
I've looked everywhere for a decent example of how a multi-project ant build system should be assembled. The apache site falls short. I'm looking specifically for best practices to:
Automatically build local projects that are dependencies of a project
Share artifacts from project to their dependents
Export a project's dependencies and generated artifacts (jars) to be inherited by dependent projects
Share third-party dependencies between projects
I'm sure I can do all this without using Ivy - what did people do before Ivy? I really don't want to have to set up a corporate repository or rely on external repositories - the engineers here are really against that and have all their third-party jars checked into src control.
Can anyone point me at a good open source example of a multi-project ant build?
I don't have too much hands on experience with building large numbers of dependent projects with Ant, but this tutorial looks like it will do what you need without any additional tools.