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.
Related
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.
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.
I'm using Jenkins 1.646. I keep getting Unreadable Data entries in the Manage Old Data section.
These entries appear for pretty much every build that occurs on my Freestyle projects. The builds complete just fine. Does anyone have any idea what I need to do to correct this? I did install the Pipeline plugin recently, and it installed a dozen or so other plugins with it, so my guess is that something is incompatible with my version of jenkins and / or another plugin I have installed.
I think I figured it out. I found out that VariableInjectionAction is a domain specific class inner class we are using in one of our build steps. We are dynamically loading its parent class to the classpath using the GroovyClassLoader for each build. It would seem that jenkins is trying to keep track of all the classes that are used to run our groovy scripts for a particular build, and since this is a dynamically-loaded inner class, jenkins is unable to find the class for archived builds, thus giving the error above.
I assume the error would go away if we loaded our groovy scripts differently, e.g. pre-compiling them placing them on the root jenkins classpath. For now, since the builds are running fine, we'll probably just live with having to cleanup the unreadable data periodically.
Also, this obviously didn't have anything to do with conflicts with recently installed plugins as I first thought.
One of the tips Burt Beckwith provides when creating plugins is to delete files you don't use.
So if you don't use UrlMappings.groovy - delete it.
I was wondering about directories. If you have no controllers, should you delete the controller directory?
Thanks
The short answer is "Yes, you should." Looking at some of the other plugins you can see this is pretty standard practice. For example the Redis plugin on GitHub.
You can delete directories, but they'll get re-created after running various scripts, in particular package-plugin. I tend to remove them as source folders in GGTS so they're not distracting - I like to only see directories that are being used. I used to use an Ant script to do various build tasks for plugins, but at this point all I use them for is the post-package-cleanup task that deletes unused folders, e.g .https://github.com/grails-plugins/grails-spring-security-core/blob/master/build.xml.
It turns out that only three plugin files are required - all of the rest can be deleted if they're not used. These are the plugin descriptor, application.properties (although this is only used to specify the Grails version), and BuildConfig.groovy. BuildConfig.groovy might be optional too if you don't need to publish the plugin to a repo and have no dependencies. At a minimum it's needed to specify the release plugin, but if you don't need that they you can probably get by with just 2 files :)
I've had a lot of bizarre conflicts with my Grails (2.0.3) project using Intellij IDEA (11.1.3). My project is hooked up to our CVS repoitory. I finally traced my problems down to CVS creating a CVS\Base folder whenever I edit a file.
My problems arise because Grails finds conflicting copies of my .groovy files and chokes. For example, I edit MyDomain.groovy to add a new field and CVS creates a CVS\Base\MyDomain.class backup of the file. Grails tries to load both and throws various exceptions depending on the change.
I can't find any CVS settings in IDEA that control the creation of these backups. I don't want them and I just delete them manually. I also don't know how to get IDEA to add these to the exclude list. I've gone into Project Settings, but I can't find the folders to exclude them. I think because the .\CVS sub-folder is hidden from view by default, that the Base sub-folder is also inaccessible.
Ideally, I'd like to know how to...
...stop CVS from creating this Base folder
...get Grails to ignore the folder if it is there.
CrazyCoder has correctly pointed out that this is not an issue with IntelliJ IDEA specifically, but a known issue with Grails, but that still doesn't help me resolve my issue.
If you are having similar issues, please go to the Grails Jira page for this issue and add your comments and vote for this issue. If you have a workaround for this, then post the workaround as your answer.
IDEA is already ignoring CVS folders by default, the bug is in Grails.