Is there any advantages or any available pattern where in we create just the Domain classes and jar it, to be used in different grails applications applicable.
The standard approach for reusing Grails artifacts (domain classes, controllers, etc.) is to create a plugin, not a jar file. See http://grails.org/doc/latest/guide/12.%20Plug-ins.html
Related
I'm working on a multi-module project right now, where most of the modules are designed to have their own Web interface (REST API, Web pages, etc.) done using Grails. There are a few classes that I want to be utilized by different (all) modules. If this were a straightforward Java project, I would just create a new Maven project (using archetype:generate), deploy/install, and just import it on the modules accordingly. How do I do this with Grails? Is this one of the things Grails plugins are meant to address?
Since you are talking about a jar/lib artifact it would be best to use a local Maven repository where you build your maven project to then resolve it as a dependency for your modules within your BuildConfig.groovy.
Nothing is stopping you from using a Grails plugin to provide this resource, but that seems a bit overkill since Grails plugins are intended to do so much more.
It looks to me that you want to have a multi-project build or a Mavenized Grails project or separate plugins.
Use a Grails multi-project-build
Guide: http://grails.org/doc/2.1.0/ref/Command%20Line/create-multi-project-build.html
Straight Maven integration
Guide : http://grails.org/doc/latest/guide/commandLine.html#antAndMaven
I have a basic introduction video here: https://www.youtube.com/watch?v=tqGN61hiciE
Separate Grails plugins
You could still use separate Grails plugins and reference them in your main application.
Is it possible to use a grails plugin outside a grails application?
I would like to use the functionality of grails-mail-plugin in a simple groovy/gradle app.
I found some information about binary plugins but I'm not sure how to define the dependency to an official grails plugin.
Thanks!
I don't think you could use any Grails plugin itself outside the Grails environment, usually there is a ton of Grails-specific assumptions built into the plugins' code.
If your Groovy application uses Spring, you could migrate the most important functionality out of it.
For this, you will have to get into the innards of the source code of the plugin (e.g. how it uses the Spring Mail package for example) which not may be very quick or easy work.
If your requirements are simple, you may be better of with building a standalone solution, possibly, directly on top of JavaMail.
If you already have a heterogeneous architecture, you may build a separate Grails application/module which only does mailing functionality (possibly through the Async Mail plugins database tables) in integration with the module you build in pure Groovy.
I am converting a .NET 2.0 Winforms applications to ASP.NET MVC3. The Winforms solution uses several projects for business logic, and the MVC application includes these projects. The projects are also used by a variety of Windows console applications.
The problem is that these projects use System.Windows.Forms.Application.StartupPath to find files they use, whereas for web development System.Web.HttpRunTime.AppDomainAppPath is used.
I would prefer that both solutions use the same projects and that these projects are modified as little as possible as they are large, old, and relatively undocumented. What is the correct way to address this issue?
Right now I am thinking that I would create a new configuration with each project that would define WEB, and then use #if/#else statements to include the correct depedency and to define the return of the getPath() method.
Before you start plaguing your code with preprocessors, you should consider creating an interface IApplicationConfigurator or IApplicationStarter
public interface IApplicationStarter
{
string GetPath();
}
And inject it with a MvcApplicationStarter or a WinformsApplicationStarter depending on your application. You can then have your project libraries have a dependency on the IApplicationStarter interface. It should require minimal implementation on the projects, and you can reuse the pattern for other common dependencies. Look into dependency injection frameworks as it takes this approach into the next level.
This is what class libraries are for. Create a class library project, move all the common bits there, and then have a separate WinForms and MVC project that both reference your class library.
I have installed grails support in STS. and I have a grails application inside that I got package com.mycompany.myapp in domain, controllers and tests. I want to rename them to mycompany.myapp, So that It should affect the functionality of application. Is there any way to do it in Grails.
You can use the normal Eclipse refactoring tooling ie ALT+SHIFT+V to move package.
If you're using any inheritance in your domain classes you'll need to upgrade the class name in the class column for these tables.
Is it possible to compile and sign grails plug-in? I am thinking about distributing my application logic using grails plug-in architecture and I do not want my client to be able to read that easily .groovy or to modify it. Is it possible to package it somehow or at least distribute only compiled .class?
Yes. you need to think more traditional Java.
Create a JAR with your logic in it and sign the jar. Put the minimum Groovy code in the plugin. You have not stated where the logic is if it's a controller or GORM object so I am not sure what you looking for 100%.
Hope this helps.
It is possible to compile and package groovy/java code into a jar and then use it in a grails app. (as Scott suggests) but these classes can not directly benefit from grails ie. no way to declare grails service, domain class or controller in a separate jar.
There is an issue in grails jira describing the same problem:
http://jira.codehaus.org/browse/GRAILS-4956
Since Grails 1.4 M1 there are binary plugins, I assume this is exactly what you need. I'm not sure if signing is supported in any way, but it's at least possible to distribute the plugin without its sources.