I've got a list of grails plugings in my 1.3.7 app.
I'm converting it to 2.1.0 and doing a cleanup.
In my application.properties I have the following:
plugins.build-test-data=2.0.3
plugins.fixtures=1.1
plugins.hibernate=2.1.0
plugins.pretty-time=0.3
plugins.mail=1.0
plugins.quartz=0.4.2
plugins.spring-security-core=1.2.7.3
plugins.tomcat=2.1.0
I'm moving them all to my BuildConfig.groovy instead.
I'm curious as to what is the most appropriate scope for each plugin?
Thanks
My usual rule of thumb is
build scope for plugins that are part of the build process but shouldn't go into the WAR for production deployment
test scope for things that should be available to tests but not to application code
runtime scope for plugins (or JAR dependencies) that you need for the app to run but which you don't want to tightly couple your app to (you can't import a class from a runtime dependency into one of your app's own classes, for example)
compile scope for everything else
If in doubt, compile will definitely work, as plugins in application.properties are treated as if they were declared in compile scope.
So tomcat definitely wants build scope, spring-security-core definitely wants compile, I guess fixtures and build-test-data should be test, the others compile or runtime depending on whether you need to import any of their classes directly.
Related
Have a groovy controller leveraging Java SSH package (JSch) with NO ISSUES in IDE (jar was added to library, import works, all calls against class pass) however I get failure only on run-app:
unable to resolve class JSch # ... : JSch jsch = new JSch()
I use the same code in Java without any issues for an SFTP application and this won't even instantiate the initial object so less concerned about the rest of the code. I've tried mucking with dependency mgmt and refreshing with no success.
I guess the question at hand is why does any class fail to resolve only at run when there are no obvious issues with implementation?
Yeah... Grails doesn't give a damn about which jars you add with your IDE. Grails uses Maven to resolve dependencies.
Next steps
The first thing is to remove the JSch jar. Then, add the following Maven artifact to your project: com.jcraft:jsch:0.1.53
Of course, adjust the version number as needed. How this is added to Grails depends on the version of Grails you're using.
Grails 3
Add the following to the dependencies closure in build.gradle:
compile 'com.jcraft:jsch:0.1.53'
Grails 2.4
For Grails 2.4 (and maybe earlier versions, I simply don't know) add the following within the plugins closure in grails-app/config/BuildConfig.groovy
compile 'com.jcraft:jsch:0.1.53'
I've modified my app to be a grails plugin, which I'm going to include in client-specific applications and customize some bits and pieces.
To test the whole thing, I've included the plugin as inline in the BuildConfig of a test application [bare application created using grails commandline].
grails.plugin.location."engine-plugin"="../../engine-plugin"
I did not install the plugin itself, I did not add a thing into plugins part of the BuildConfig in my app.
Now, in the BuildConfig of the plugin, I've included all of the plugins I require in my engine:
compile (
":asynchronous-mail:0.6",
":famfamfam:1.0.1",
":google-visualization:0.5.3",
":gsp-arse:1.3",
":jquery:1.8.0",
":jquery-ui:1.8.15",
":mail:1.0",
":navigation:1.3.2",
":prototype:1.0",
":quartz2:0.2.3",
":rendering:0.4.3",
":spring-security-core:1.2.7.3",
":spring-security-ui:0.2"
)
Unfortunately, when I run grails run-app in my test app, it can't resolve some classes:
4: unable to resolve class grails.plugins.springsecurity.Secured
# line 4, column 1.
import grails.plugins.springsecurity.Secured
^
Obviously, that's because my app can't see the spring-security-core or it's dependencies.
I've tried changing the scope in my plugin's BuildConfig from compile to build, but that changes nothing. I've tried adding export=true to it - nothing.
Any tips on how to proceed with this?
Thanks
EDIT:
getting the same error when using the packaged plugin instead of inline :/
What's the difference between build, runtime, and compile, in BuildConfig.groovy (1.3.7)
grails.project.dependency.resolution = {
plugins {
build "acme:acme-cache:latest.integration"
}
dependencies {
build "com.foo.bar:foobar:1.0.5"
runtime "org.apache.httpcomponents:httpclient:4.0.3"
compile("com.thoughtworks.xstream:xstream:1.3.1")
}
}
build - dependency that is only needed by the build process
runtime - dependency that is needed to run the application, but not compile it e.g. JDBC implementation for specific database vendor. This would not typically be needed at compile-time because code depends only the JDBC API, rather than a specific implementation thereof
compile - dependency that is needed at both compile-time and runtime. This is the most common case
There are a couple of other dependency scopes:
test - dependency that is only needed by the tests, e.g. a mocking/testing library
provided - dependency that is needed at compile-time but should not be packaged with the app (usually because it is provided by the container). An example is the Servlet API
It seems the 2 previous answers conflict on the distinction between compile and build. I believe that build is the scope that includes grails compile and grails run-app, while compile is just the former.
Starting from Grails 3, dependencies are managed by Gradle. The grails-app/conf/BuildConfig.groovy file has been replaced by the build.gradle file in the project's root.
The Grails user guide explain how to set grails depencies with gradle. See also the related Gradle documentation for further details on managing dependencies using it.
A couple grails commands help illustrate the difference. Consider grails run-app and grails compile. grails compile is the compile step and will include compile-time dependencies. grails run-app is the run step and will include runtime dependencies. Build dependencies are anything that you might need to run any of these commands, for example, a custom script that hooks into some build events.
So you would pick the one that best fits when you need to be certain the dependency is included.
I'm a bit of a Grails newbie. I have an app which works fine in Eclipse but when I deploy in production falls over because of missing dependencies.
When I run the dependency report it shows all the dependencies are automatically present for 'build' but absent for 'runtime'.
What's the neatest way to migrate the dependencies from to runtime so (I hope) they get copied into my war file?
Also, I'm using the sanitizer plugin. This runs fine in development but has the dependencies missing from 'runtime' so falls over. If I manually add, for example, one of the dependencies into BuildConfig.groovy ("org.owasp.antisamy:antisamy:1.4.3") then grails falls over with this error:
loader constraint violation: loader (instance of ) previously initiated loading for a different type with name "org/xml/sax/SAXParseException"
I'm assuming that this is a classpath issue but I'm not sure why this only happens when I manually add the dependency - surely it's present all the time?
You're right, you have to add missing runtime dependencies to BuildConfig.groovy. The simplest thing would be to copy them from the plugin's BuildConfig.groovy to your app's one. You should also raise a JIRA for the respective grails plugin to get this fixed upstream.
Lots of jars out there in the Maven repositories have their dependencies not correctly defined in their pom file.
There is a way to fix that in BuildConfig.groovy, by switching off transitivity:
runtime('org.owasp.antisamy:antisamy:1.4.3') {
transitive = false
}
Instead of 'transitive=false' you might also experiment with excluding only specific dependencies using e.g.
excludes "xml-apis", "xerces"
inside the 'runtime' closure.
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)