Grails 3.3. I render gson views in a plugin. During plugin stand-alone run-app the views render fine as expected. After including the plugin in a main app the views cannot be resolved. I notice that the published plugin jar has no compiled gson class files in it, only the source gson files. Shouldn't there be gson class files in the jar? There is no gradle "compileGsonViews" task in the plugin app. Also, in Intellij the "build Artifacts" action is disabled. Shouldn't there also be a jar file artifact? Am I missing something in my build dependencies? The only "views" line in build.gradle is
compile "org.grails.plugins:views-json:1.2.6"
Indeed I was missing some things in build.gradle. I was missing:
buildscript {
dependencies {
classpath "org.grails.plugins:views-gradle:1.2.6"
}
}
apply plugin: "org.grails.plugins.views-json"
I should add that this does cause the gson class files to be included in the jar file. However, it has no effect on the larger issue of the inability to resolve the plugin view classes when running the main application.
Related
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
Grails is able to configure dependencies when you specify them in the BuildConfig.groovy file. Usually when you add it there and call grails compile --refresh-dependencies it will resolve the dependency, and download to .grails/ivy-cache/..... (in my case). However, one time, after downloading the jar files, it failed to automatically add the jar to the classpath. Does anybody have any idea on how this will happen? It has worked for me before on many other Maven repository dependencies. The specific dependency I failed to add to my Grails project classpath is http://mvnrepository.com/artifact/javax.mail/mail/1.4.7
I can just manually add the lib to the classpath, but I'd rather have dependencies resolved automatically with the BuildConfig.groovy file. I also can't manually add jars into the "Grails Dependencies" library in the classpath; they can only be outside that library.
How do I reference a dependency by convention within my project build path? Allow me to elaborate...
I'm using the Groovy/Grails Tool Suite (GGTS 3.0). I'm referencing the dependency as such in my BuildConfig.groovy:
dependencies {
compile 'tgt:jaxb-utils:1.0'
}
The referenced jar file is successfully pulled down from the Artifactory repo - I can find the jar file on my local file system in the Ivy cache. When I run any grails targets (grails compile, grails run-app, grails run-tests), it works fine - meaning my code that imports the classes from the jar has no problems. When I run grails war, the referenced jar file is packed into the constructed war.
However, and here is the crux of this post - the project build path does not reference this jar file by default or convention, so my java or groovy code that imports the classes from the jar file reports a unable to resolve class ... error.
One solution is to simply add the jar file to the lib folder and update the build path accordingly, or modify the build path to reference the jar file in the Ivy cache folder. However, I'd have to do this for any/all dependencies pulled down in this way. Any jars in the lib folder will get saved to the team source code repository, and that seems like wasted space since the grails commands work fine with just the dependency reference in BuildConfig.groovy.
Am I just being too idealistic (ie - difficult) here, or is there a better way to clean up the unable to resolve class ... errors in my IDE without having to manually add the dependent jar files to my lib folder and update my build path? Ideas?
Eclipse / STS / GGTS : If you have Grails plugin installed, you can do the following :
Right click on your project -> Grails Tools -> Refresh dependencies (or shortcut "Alt+G, R")
Complete gradle nooby here.
I want to be able to execute grails build commands like "grails compile", "grails test-app" and so forth from gradle.
I found the grails-gradle-plugin from Peter Ledbrook at: https://github.com/grails/grails-gradle-plugin.
Cloning the repository I get some files and folders. In the readme file it says " include the required JARs via buildscript {} and 'apply' the plugin". The apply part sure I get but how do I add the JAR? And which jar? Do I need to use gradle on the build file in the folder of the downloaded plug-in and compile a jar? And ones I get the jar where do I place it and how do I include it in my projects build.gradle file?
I have a feeling this is going to be ridiculously easy but I just can't get it to work.
In Gradle, the jars are added to build script or to your application class path through dependencies closure e.g.
dependencies {
compile "org.grails:grails-crud:1.3.4"
compile "org.grails:grails-gorm:1.3.4"
compile "ch.qos.logback:logback-core:1.0.7"
compile "org.slf4j:slf4j-api:1.7.2"
}
compile is a name of one of the many configurations (there are also test, runtime etc.) and e.g. "org.grails:grails-crud:1.3.4" is a reference to a jar in one of the public repositories, which are also specified in your scripts in repositories closure.
You can read more about Gradle dependency management in http://gradle.org/docs/current/userguide/dependency_management.html.
For your Grails project you need to define a build.gradle file which looks similar to what is described in the README.
Though I tried today to just create a simple Grails project using that plugin and gradle init command and it didn't work. I have created an issue for that: https://github.com/grails/grails-gradle-plugin/issues/16.
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.