How come it is good practice within Grails to place classes in packages (e.g. mycompany.Book)?
I know it is a prerequisite in order to deploy Grails solution to the Google App Engine (using the plugin), but other than that and a well structured code library for large projects, what other benefits are there in describing packages for classes within Grails?
Another good reason, as mentioned by Marcel Overdijk in this blog post, is if domain classes has the same name as classes within Groovy, it is not possible to distinguish the two.
Grails runs on Groovy, which has a strong heritage with Java. Java encourages packages for well-documented reasons and Groovy/Grails follows suit. I think the main benefit stems from your description: a well-structured code library for large projects.
The most valuable reason that I've seen, is that you cannot "import" classes without a package into a class that DOES have a package. that means that you can't access any domain/service/controller/etc classes that don't have packages from your utility code that you might put a package on.
Related
When modularizing a grails application, when does it make sense to add the module as a plugin vs gradle dependency?
For Example:
akaDomain contains all the domain objects.
akaWebsites contains all the presentation logic.
akaService1 contains some services.
akaService2 contains some other services.
All the websites and services share akaDomain.
Can the domain classes present in akaDomain be used for scaffolding controllers and views in another application like akaService and akaWebsite?
Can this be achieved using plugins or dependency or both.
Please explain what am I missing if I don't make a plugin of akaDomain.
This answer uses plugin to explain how to modularize grails app.
You can definitely use the domains defined in one plugin as the basis for scaffolding in another plugin or in a main application. There are several practical considerations when doing so however:
If you choose to implement UI in a plugin, then you are committing to a UI look and feel that is to be shared across multiple applications. This is often very difficult when doing custom / contract development where every customer wants their own personal look and feel. You will want to think about selecting a UI abstraction as well that allows flexibility on theme support at least. We use Twitter Bootstrap for this purpose but there are several others that fit the bill.
You must manage the dependencies between the "domain/service" and the "UI" plugins. This is true of any plugin ecosystem, but once you commit to abstraction, this discipline is very important or you end up with dependency dead ends or cycles. It is a lot of work, but the pay off for productivity is very high.
As for the question on Grails Plugins vs Gradle dependencies:
Plugins are in fact Gradle dependencies (in Grails 3.x at least). That is, plugin dependency management is implemented on top of Gradle. Plugins provide additional support for integrating into a Grails application that include things like:
Automated spring bean registration and initialization at startup.
Participation in application component reloading.
Artefact definitions and initialization at startup.
So, implement using plugins and you get the best of both worlds.
I have recently switched back from using a Spring MVC/Gradle/Groovy project back to a traditional Grails project. I have been noticing the file location conventions seem, intuitively, a little less organized. For example, having Groovy src files outside of src/main/groovy (exp. Controller filter), or having the src files themselves in src/java instead of src/main/java.
Now I know all of these things can be configured, but why don't they conform closer to the Maven3 structure?
Considering Maven 3 wasn't released until 2010 and Grails was around prior to that I don't see how they could have. The only "reason" Grails follows a different convention is because that's what the developers decided was the most logical structure for Grails. In a lot of cases it was to eliminate cruft (e.g. the /main/ in your example) or to place things more logically based on what they are.
I have a bunch of utility classes, that have nothing to do with web requests, database etc. Very similar to POJOS, except they are never persisted.
I want to make these classes available to a number of Grails applications and plugins.
At the moment, I putting these classes in their own plugin. It just seems like overkill. In the java world they would just be one package that was jar'ed.
I want to use some of the Groovy annotations such as #immutable etc so I want to stay in Groovy. But, I was wondering do I have any other options because a plugin, because that seems like overkill.
thanks
technically seen, this would be a bit of overkill indeed.
On the other hand, you just need a single repository and build process to deploy your app. I think, a single dependency resolution system which in integrated in Grails is better than 2 or more, unless you have them already.
You could make a plugin, or compile the Groovy into classes and make a jar that you share. Using annotations like #Immutable will work in classes from a jar or as source from a plugin.
We have many projects that need to use common version numbers.
What is best practice for doing this with Ant/Ivy? Do you just inherit a wad of properties from Ant that have the version numbers in them, or is there a more formal mechanism a la Maven?
As you've pointed out I think this is the problem which the new extends functionality has been designed to solve.
To be completely honest I'm not a fan of parent-child modules in Maven.... However, just like you sometimes I want to nail lots of my modules to a common version of Spring.
The solution I used was to have a set of properties defined in my shared ivysettings file. This keeps my ivy specific properties separate from my ANT build properties.
What is the best way to organize directories within a large grails application?
In a typical Spring application, we'd have myproject/domain/ and myproject/web/controllers and myproject/services
Since grails puts these artifacts in their own directories... and then just uses the same base project package for everything, what is the best practice? Use the same sub package name for domain objects, controllers, services too?
Ken
Use packages like any other app. Classes for com.mycompany should go in myproject/grails-app/domain/com/mycompany, myproject/grails-app/services/com/mycompany, myproject/grails-app/controllers/com/mycompany, etc.
Decide on your package structure as makes sense for you. Split on component type or on functionality type (but I recommend functionality type).
I don't see a difference here from the structure you mentioned.