Grails 2.x Multiple Projects in one Site - grails

There are multiple Grails 2.3.11 projects I have that I would like to integrate. Is it possible to have a "multi-project" setup in Grails 2? For development I would think there could be a root project that (on the UI side) you could click a link to enter into another project. As far as production would go, when the war file gets deployed, all the projects under the root could get included somehow.
If this doesn't exist I could just copy all project files into one project and edit accordingly but the former idea seems more streamlined.

Related

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:
create your web admin app in your project root
create your core services app as a plugin in the project root
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?
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?
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.
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.
"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
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.

Should umbraco & umbraco_client be checked in to source control?

Just installed the latest Umbraco (7.2.1) package via NuGet. My development environment is as follows:
Umbraco is installed installed on IIS8 as shown below and is all up and running.
My Visual studio project is set up as shown below (For the sake of clarity, any folder/file excluded from project is not in included in my source control.
The content folder houses all scripts, images & css
On build - bin, config, content, masterpages, usercontrols, Views, xslt, default.aspx, Global.asax & the transformed Web.config are copied to the IIS instance (I don't like running Umbraco in the same place as my project, it just seems messy.)
Is this an appropriate way of developing for Umbraco? Am I missing anything, my biggest concern is whether or not I should include the umbraco & umbraco_client folders in version control and in the post build action. Any suggestions would be great.
There is some debate over what should and shouldn't be in your repository and ultimately it comes down to personal preference. I used to only add custom files and files that I changed from the Umbraco install such as the config files however since the introduction of the Nuget package I do put all but the binaries into source control because when I upgrade via Nuget later on I can easily see changes and merge customisations back in.
It saves a lot of hassle running Umbraco directly (IMO) especially if you make any changes via the UI and if you're not running it directly then there is little point really in using the Nuget package because you will end up with a bunch of unused files in your project. In your situation you might as well keep your project clean and do a manual install into the location IIS is using for the site and only keep files in your project that you have created.
This is only my opinion so take from it what you wish but hopefully it is of some help.
Simon

Multiple Grails projects named the same Build problems

I currently have one workspace for our 'Mainline' code, and 1 workspace for each branch that we create at the end of each iteration. I am using STS and grails 1.3.6, with no added plugins and a couple of java jar files. It seems like whenever I create a new workspace for a new branch, the branch workspace ends up getting corrupted. I start getting build errors locally revolving around missing hibernate classes such as AbstractEntityPersister. I am working in a Windows 7 environment.
My question is two-fold.
One-Is this problem likely related to a caching issue? Theoretically the build grails dependency jars should be the same between the workspaces, so I don't know why one workspace would have problems and one wouldn't
Two-What is the best way to debug said problem? Currently the only thing I'm going on is the Problems view and then comparing the two workspaces as best I can.
By default, grails uses "$USER_HOME/.grails/grailsVersion/projectName" as a working directory, so having two projects with the same name and same grails version will cause you several headaches.
Take a look at the docs below, you'll want to set 'projectWorkDir' in each project BuildConfig to prevent interferences.
http://grails.org/doc/latest/guide/commandLine.html#buildCustomising
Do your project working directories have the exact same name?
Grails creates a project cache folder in $USER_HOME/.grails/<grailsVersion>/projects/<basedirname> which contains compiled plugins and scripts. Even running grails clean does not wipe out these directories.
It's likely that the two projects that have the same name are updating files in this folder simultaneously. In theory this shouldn't mess anything up because you're probably not working on the two projects simultaneously, but if you have both open in STS it might be auto building and messing with the automatic reloading mechanism that Grails uses.
I would try to set the working directory in BuildConfig.groovy or override the folder using grails -Dgrails.project.work.dir=work as documented.
Failing this, I would suggest disabling any auto build in STS as Grails itself will compile/reload classes when run-app is running. Also I would try editing your application using a text editor (Sublime Text 2 is fantastic) instead of STS to see if you have the same problems.

How to add plugin project as a dependency to my main projects

My requirement is as below:
I will be having three projects.
Main project (Grails project)
Main project adaptor (Grails project)
Domains plugin project (Grails project)
Domains plugin project will be having all of the domain classes and its test cases in it. So, I want to use those domain classes in other two projects. Here, I want to build Domains plugin project first, and the output of this build project should be the dependency of other two projects. I should be able configure this in BuildConfig.groovy.
Presently, I have done in the following way:
Created a plugin project using create-plugin and followed by package plugin command. Now, I kept that ZIP file in my lib folder and configured in Build-config.groovy. This works as expected. But, when ever I change domain classes, I need to do lot stuff. Like coping it to lib.
Is there any possibility to do in the first way I explained..!! Please help me out in this..!!
Thanks in advance
You can use inline plugins - put all of your three projects at the same level (in the same directory) and then configure adaptor and domain plugin as inline plugins in Main project.
That way you dont have to build each project separately, you can do changes in your domain plugin or adapter and they will get picked in main project automatically.
Inside your main project's BuildConfig.groovy
grails.plugin.location.'adapter' = "../path-to-adapter-plugin"
grails.plugin.location.'domain' = "../path-to-domain-plugin"
Note - putting all three projects at same level isn't required, but doing that will let you use relative paths - but if you want you can use absolute paths as well

Why does my Web Deployment Project remove .ascx files from my MVC2 project?

I am currently working on a project that consists of an ASP.NET MVC 2.0 front end and has been developed in VS 2008. I have been messing around with the Web Deployment Project to deploy the application so we can also change various Web.config settings based on the build configuration.
However, when the deployment project publishes the output files to its target (currently a location on my local machine), all the .ascx partial views are not included and so everything stops working. I can do a standard Publish via VS and all works as expected.
It seems that the deployment project embeds the .ascx files when it compiles everything. So, how do I get it to include the .ascx files as they are (i.e. not embeded)? Am I missing something?
Thanks in advance.
Nick.
There are a few things you might want to consider:
Make sure the .ascx are included as part of your project. They probably are, but I had to throw it out there.
On the WDP property page, check the box for "Allow this precompiled site to be updatable.
On the WDP property page, select "Merge all outputs to a single assembly" and provide a assembly name.
Make sure you don't have any pre/post build steps which are removing those files intentionally.
Here's a walk through of Web Deployment Projects for ASP.NET MVC

Resources