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.
Related
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 added an svn:externals to my project, and it works great locally via TortoiseSVN. When I use Jenkins to pull from the same repository, it's not showing anything about the externals in the console output.
I read some other questions on here and I made sure my SVN version number in Jenkins was set to (1.6 externals to file) and restarted Jenkins. The problem is still occurring. Any ideas of something else I could set, or something I could use for troubleshooting? Thanks.
Oh, and the external directory is in the same repository, so I don't think it's an authentication issue as it builds fine without a reference to the external files.
I fixed this issue by selecting higher SVN Version Number on Jenkins 2.222.1.
Here is the procedure:
Manage Jenkins -> Configure System -> Subversion Workspace Version
Select at least v1.6. (The default one was 1.4 for me)
I may have had a very uncommon structure, but here's what worked for me...
First of all, here's the directory structure:
--Parent
----folder1
------subfolder1
------svnexternalfolder
----svnexternalfolder
As you can see, I had my svn external folder in two different levels of the project structure, but the Jenkins project was pointing directly at "folder1".
When first configured, it would never pull the files for my svn external folder (whether it was a full checkout, or svn update). This was configured with the svnexternals at the parent level.
My next try was to remove the svn externals at the parent, then specify just the higher location on the parent, then the lower location on folder1. This gave an error since the child svn directory had the same name as the other one.
So I flip-flopped the order of creating the svn external locations and did the child first (on "folder1"), then did the higher one on parent. Once I did that, everything started working.
Hope this helps someone else.
If you're curious about why I configured the directory structure this way, this was a PhoneGap project. apparently cordova/phonegap projects create their directory structures like this, the common folder beneath the parent is the "www" which houses all html, javascript, etc files, then those are also used under the platforms/ios, or platforms/android folders (in my example, I just called it folder1).
I have a solution with a few SSIS projects, which is in TFS. I was helping a guy fix some project names to be consistent with the other projects in the solution. After updating the names, we checked in the project and the solution files. When I got latest (I tried both GetLatest and GetSpecific), TFS kept asking me to checkout those project files and it got pretty annoying and I ended up checking them out and then undid my changes on the project files.
Does anyone know why it keeps doing that?
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.
We have multiple projects in a given ClearCase view. Somehow, we now have a handful of files that are pointing to the same resource in two different projects.
We had a JavaTestProject that was put in ClearCase as a sample project.
The code was used as a model to create a new project: JavaLiveProject.
For a few pieces of code with the same name, ClearCase has pointed the JavaTestProject to the JavaLiveProject file with the same name.
Using ClearCase Explorer, the View Path for JavaTestProject/MyJavaProgram.java looks like it belongs to JavaTestProject.
However, if you use the Properties of Element option, the full path is pointing to JavaLiveProject/MyJavaProgram.java.
If you check out and edit the file in either project, you are really editing JavaLiveProject/myJavaProgram.java.
We are not certain how this happened (we do not see any symlinks in ClearCase Explorer).
However, we would like to make it so that JavaTestProject/myJavaProgram.java does not affect JavaLiveProject/MyJavaProgram.java.
There are other instances where the code has the same name (MySampleProgram.java for instance) where this did not happen.
Any ideas?
The easiest way to troubleshoot that kind of situation is to leave the GUI aside for a moment, and see what the command-line interface returns:
In a DOS session, go to your (snapshot I presume) view and type:
cleartool ls
If there is a symlink (it shouldn't be since you didn't see it through the GUI, but I am just checking there), it would be displayed as:
JavaTestProject/MyJavaProgram.java --> C:\path\to\JavaLiveProject/MyJavaProgram.java
If not, check if there is some kind of OS-based symlink (like a Junction)
A cleartool descr -l of both "JavaTestProject/MyJavaProgram.java" and "JavaLiveProject/MyJavaProgram.java" can help troubleshoot the issue too.
After working with ClearCase support (internal, not official), the reason that the files were pointing to the same resource could not be determined. However, removing the files from the JavaTestProject seems to have cleared up the issue (it did not delete the files in JavaLiveProject).
I did make backup copies before deleting files from ClearClase, just in case.