I have a Grails application and a custom plugin with separate code included in the main application in BuildConfig.groovy using grails.plugin.location.'my-plugin' = '../my-plugin'. Now I'm looking for a way to customize what artefact directories will be exported in the plugin. I want to place a custom resource file (e.g. SQL script) into src/resources directory of the plugin and I need to see the file on classpath of the main application. I know files in grails-app/conf and other directories get included along with the plugin source, but can the convention of resource directories be altered?
Related
Just like to define custom Bootstrap.groovy or UrlMappings.groovy in a Grails plugin, we can define FooBootstrap.groovy or FooUrlMappings.groovy so that those can be bundled in the plugin because the earlier are excluded by default. http://docs.grails.org/latest/guide/plugins.html#_excluded_artefacts
How can we do the same for logback.groovy? I have a multi-project build where a single Grails plugin is used by 3 different Grails application.
My research & trials:
I tried creating a foo-logback.groovy but that is not loading.
Grails 3: External Logback.groovy file
Another resource: https://logback.qos.ch/manual/configuration.html
Basically, there can only be one logback.groovy or logback.xml in the classpath. In order to achieve what you are asking you could use your root project's logback.groovy and load a foo-logback.groovy using a GroovyShell instance (see https://stackoverflow.com/a/9006034/260487).
Alternatively you can have the plugin resources defined in its own package and include that package in your root logback.groovy file. For example, instead of com.example.FooService you would define it as com.example.plugin.foo.FooService, and you'd define a log rule for the com.example.plugin.foo package.
Grails 3.2.5. Build.gradle has mail plugin:
compile "org.grails.plugins:mail:2.0.0.RC6"
In deploying a war to production I need to remove javax.mail-1.5.6.jar from WEB-INF/lib since that jar must be in the Tomcat lib when using a JNDI mail resource. So how do I keep the mail plugin but remove the offending jar file from the war? I knew how to do this in Grails 2.x. Via the gradle war task in build.gradle I have tried to exclude the file (doesn't work - the jar drifts in from a plugin somehow), and have tried to filter the file out. When I build the war I get two files - "app-0.1.war" and "app-0.1.war.original". The "original" file has the WEB-INF/lib/javax.mail jar filtered out, but the real, complete war still has it.
So how do I prevent that plugin jar from getting into the war file? Thanks.
One way to do it is with something like this:
war {
rootSpec.exclude '**/javax.mail*.jar'
}
(you may need to adjust depending on whether or not you want to also exclude the javax.mail-api jar file along with the javax.mail jar)
See https://github.com/jeffbrown/excludejar/blob/67734ac0c65cdbead468f1e65bcfc29041cd2279/build.gradle#L70-L72
I'm trying to find documentation and code samples on how to add a local / non-maven jar file to my Grails 3.x project?
I found the separate thread How to add a non-maven jar to grails - but that's only to grails 2.3, and the file structure and configuration has undergone a big overhaul in 3.x.
Any help and (especially) code samples would be wonderful! The .jar is in the local project directory, and I intend to package with the .war for deployment.
Additionally, once i add the dependency, should i just be able to call it's methods from the controller & service files? or do i need to include them in those as well?
thx!
Grails 3 uses Gradle, so there's nothing Grails specific about including a local jar. It's as easy as adding a file dependency to the dependencies block of your build.gradle file.
Per the Gradle documentation on File Dependencies:
To add some files as a dependency for a configuration, you simply pass a file collection as a dependency:
dependencies {
...
compile files('libs/a.jar', 'libs/b.jar')
// or
compile fileTree(dir: 'libs', include: '*.jar')
}
The above example shows two ways to include jars that exist in a local libs/ directory; you can do either/or. The jar(s) can be anywhere on the filesystem, just make sure you point to the correct path.
To use the classes from the dependency in your application, you'll include them in your services, controllers and all other classes like you normally would. Say libs/a.jar has a class org.example.Something, you'd add an import to the top of your Grails class like so:
import org.example.Something
I have a plugin that loads a custom Ivy resolver. It uses ${basedir}
to locate the jar file containing the resolver so I can load it inside
BuildConfig (see the answer for context). That compiles the plugin, but unfortunately, when the plugin is installed in a project,basedir becomes the project directory so it can't find the jar. pluginBasedir doesn't seem to point to anything, even inside the plugin's BuildConfig.groovy.
Is there any way to figure out the plugin base directory from within a
plugin's BuildConfig.groovy?
Ultimately I just want my custom resolver (in an external jar) to work when compiling the plugin and when compiling any project the plugin is a part of. Any solution is welcome.
The best answer I could come up with was to get my jar into a public Maven repo and use #Grab. e.g.,
#Grab(group='com.noahsloan.atg',module="atg-resolver",version="1.0")
import com.noahsloan.atg.ivy.AtgModuleRepository
grails.project.dependency.resolution = {
resolver AtgModuleRepository.newResolver
From my plugin. I'd still like to know if there is a way to reference pluginBasedir from BuildConfig.
I started a grails application by grails create-app. For modularity, I feel like it would be better that component be a plugin. Can I convert this application into a grails plugin?
thanks,
Babu.
I never created a plugin based on an application written before but looking at the documentation for grails plugins you can read the following statement:
The structure of a Grails plugin is exactly the same as a regular Grails project's directory structure, except that in the root of the plugin directory you will find a plugin Groovy file called the "plugin descriptor".
So I would suggest to create a new plugin with grails create-plugin *your-plugin-name* and copy all files from your application into the plugin.
In case anyone else is looking, this should be exactly what you need: http://burtbeckwith.com/blog/?p=1973
Excerpt:
So to convert an application to a plugin, the general workflow would
be something like
Create the plugin descriptor, FooGrailsPlugin.groovy. The easiest way to do this is to rungrails create-plugin pluginname and copy the
generated file from there
delete everything from application.properties except the app.grails.version property
if you have jars in the lib directory that are available in a Maven repo, delete them and replace with BuildConfig.groovy dependencies
change any plugin and jar dependencies that are needed for development and testing but not when the plugin is installed to not be
exported, by adding export = false
If you need the _Install.groovy, _Uninstall.groovy, or _Upgrade.groovy scripts (you probably don’t) grab those from the dummy plugin from step 1 (but delete any you don’t need, they’re all
optional)
delete ApplicationResources.groovy if you aren’t using it and don’t depend on resources plugin
move code from BootStrap.groovy init() toFooGrailsPlugin.doWithApplicationContext
and/orFooGrailsPlugin.doWithDynamicMethods and destroy() to
FooGrailsPlugin.onShutdown, and delete BootStrap.groovy
add a dependency for the release plugin in BuildConfig.groovy
delete everything but the log4j configuration from Config.groovy
delete UrlMappings.groovy unless you have exported mappings; only keep the added ones
move bean definitions from resources.groovy to FooGrailsPlugin.doWithSpring and delete resources.groovy
delete grails-app/i18n message bundle files unless you added messages; only keep the added ones
delete everything from grails-app/views that you don’t use (in particular error.gsp,index.gsp, and layouts/main.gsp)
delete everything from web-app that you don’t use (including WEB-INF xml and tld files)
now would be a great time to write those tests you’ve been meaning to get to
create one or more test applications to install the plugin into to ensure that it works as a plugin; consider scripting this
write documentation for how to use the plugin; at a minimum a README file, but Grails gdoc files would be much better (run grails doc
--init to get started)