I am still somewhat green to Grails. Seems to me that there are multiple locations where you can put dependent JARs, among them are BuildConfig.groovy and then there is dependencies.txt in the grails folder and then there can also be n number of 'lib' folders.
What is the difference between these? When use one over the other? Why can't Grails have one central place where all dependencies are kept?
The preferred method to manage your dependancies is through BuildConfig.groovy since it's uses repositories (maven for example) for making those resources available.
The reason for grails-app/lib being available for use is because there are cases where resources aren't kept in a repository for one reason or another and you need a way to include the resource directly with the application itself.
When in doubt always use BuildConfig.groovy unless you have a use case where you can't.
Update
The dependencies.txt file is simply a listing of the dependencies used by Grails and is not used to resolve them. You can read more about it in the documentation.
You can find a list of dependencies required by Grails in the
"dependencies.txt" file in the root directory of the unpacked
distribution.
I was wondering if anyone could help.We have the following project structure in our company :
Code/Common
Code/Project1
Code/Project2
etc...
When the Common Project builds, it has a PostBuild Event that copies all the relevant files into the Code/Common/Binaries folder. Then all the other Projects reference the Common components in this folder.
However, what we are struggling with is that when TFS Online checks-out the solution it does so to c:\a\src and the Common binaries are placed in c:\a\src\Binaries. Now, when the other projects (Project1 etc) do their build it cannot find the Common Assemblies, as not only are they removed, but the paths are different from what it expects them to be in c:\a\src\Common\Binaries instead of c:\a\src\Binaries.
Is there anyway to tell the build server to not delete those files in the "Binaries" directory and to specify the folder location to checkout to? Or how one one go about solving such a problem?
Thanks very much
A build server is a transient thing, you cannot rely on files to be there.
You need to either Create Nuget Packages for you common output and then consume these in your other projects (the 'proper' way), or you will need to check your dependencies into source control after each build so you can then reference them in subsequent builds (the 'really frowned apon' way).
I have modified some grails plugins to customize them for my needs. I am deciding how to best manage these customizations. My thought was to put them in a separate project (which is version controlled) and upload them to my Nexus repository. It seems a little unclean to package the plugin source as part of the project (and check them into version control with the project).
I prefer to have my plugins installed to the .grails directory. Is this the preferred approach for dealing with grails pluging customizations?
The Nexus approach is a good one. It's best to rename the plugin, e.g. with a company-specific suffix, so there's no ambiguity which one you're using.
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.
For those of you that use Ant with multiple projects, where do you put the build.xml files? Do you put one in each project, or do you put them in a separate project that contains all your Ant-related files?
The usual recommendation is to put a build.xml in each project. But this has a few drawbacks:
It makes it hard to reuse common targets in multiple projects.
Sometimes you want to use Ant to export a project from source control and deploy it. Obviously you can't do this if the build file is in the project itself.
But if you put them all in a common location:
People need to be aware of their location to use them; they can't just use "ant -find" to find the current project's file.
You can't have different build instructions for different branches of the project.
What do you guys do?
EDIT: Thanks for the good suggestions so far. As far Maven, these aren't Java projects, and I get the impression that Maven is only meant for Java.
Place the Ant files with the project. That is the de facto standard and recommended by the creator of Ant. I will try to address some of the issues you have brought up:
Reuse of common targets should be done using techniques as described by Eric Hatcher in his book Java Development with Ant. Basically, you extract all commonality into a some top level files that all other Ant files "inherit" from.
Using Ant to export a project from source control seems odd to me, but if you want to do this, use a different Ant file :-) You can make a target like ant export -Dproject=foo/bar.
For Ant, I recommend you grab that book - it has a ton of helpful techniques.
The real recommendation I would make though is to drop Ant and convert over to Maven - like the Apache Software Foundation did (they maintain both Ant and Maven).
If you're working with independent projects, you can:
put your build.xml at the top level
place common Ant definitions (Antlib) into another project (e.g. config)
use svn:externals to import the common Antlib definition (from 'config') into your project
EDIT The trick with svn:externals is that if you link to the HEAD of some common files, it may happen that they will change after a couple of months/years. So each time you tag, you should change the svn:externals to point to a fix version of the included project. This may come handy when a project has to be rebuild years after it was last built.
My rule of thumb is to put the build.xml file in the directory under which all files are referenced. In other words, no relative paths should start with "../". Where I live, that usually means putting it in the "trunk" directory, which has src, lib, build, docs, etc underneath it.
Doing this makes the paths much cleaner in the file, and it makes it obvious how to build the project.
Where I have multiple projects that need to build, I will create a separate build.xml for each project, and a central build.xml in the directory all the project are in that calls those other build.xml files. That gives you a lot of flexibility with very little work.
I'd expect an Ant build file to be located at the top of a project (it's already a pain to have to look at a the build file to "discover" how to build the project, so if I have to locate it first, it'll drive me totally crazy). Now, regarding all the drawbacks you mentioned, I'm tempted to say: why don't you use Maven?
The way I have done this is in the past (Now I just use Maven):
Have a build.xml in the root of each project
Create an overarching build.xml
for all projects and place it in
the trunk of my repository
The overarching buid.xml has
checkout tasks for each project.
I am guessing when you mentioned
export from repository, you
actually meant import.
The overarching build file also
defines the dependencies, if any
You may update individual projects using each project's individual build file
If you do have common tasks defined, you may inherit from a common build file as well as someone else suggested.
Looks like your set of projects might be a good candidate for migration to Maven, I realize it is not always possible but if you have time, you might want to look into it.