I'm not seeing anything resembling an answer to this on the googlytubes so here goes...
We make use of several local plugins in our grails project. One of our plugins recently has a dependency on SLF4J. Our main webapp (that uses the plugin) also has a dependency on SLF4J. This results in the entirely harmless but nevertheless irritating warning at runtime:
Error SLF4J: Class path contains multiple SLF4J bindings.
Typically I'd just define an "excludes" on the plugins SLF4J dependency, but since this is a local plugin I don't see any way to do so. I tried...
grails.plugin.location.'localpluginname' = '../localplugindir'
grails.project.dependency.resolution = {
plugins {
runtime("com.ourcompany:localpluginname:1.0") {
excludes('slf4j-api')
}
}
}
...but then it tries to actually resolve said plugin on the remote repositories, and fails. We also don't want to exclude the dependency directly in the plugin because the plugin may be used in other projects which do not provide the dependency already.
Before anyone suggests we deploy our local plugin to a local maven repo in order to do this, let me get it out of the way that we don't want to do that. We have them local for a reason...so we can rapidly make changes and see said changes. We'd rather live with the annoying warning messages than add in the increased pain of deploying on every change.
The warning you are getting is not related to having multiple versions of the slf4j-api present in the classpath. SLF4J API is designed to bind with one and only one underlying logging framework at a time. If more than one binding is present on the class path, SLF4J will emit a warning, listing the location of those bindings. You can read more about it in the SLF4J warning or error messages and their meanings document.
The solution proposed by Slf4J is: When multiple bindings are available on the class path, select one and only one binding you wish to use, and remove the other bindings.
In your case the best way would be to exclude the Slf4J binding directly from the plugin. The plugin should not rely on having its own binding but rather assume that the Grails application will provide the binding (which is what it will do)
Related
I have a grails application with multiple internally developed plugins. Since upgrading from 4.x to 5.2.3, codecs are not found in one plugin, but are found in others. Specifically, I can place the same file (UsernameListCodec.groovy, package name changed from one plugin to the next but otherwise no changes) in grails-app/utils in one plugin and it works; when placed in grails-app/utils in another plugin it fails with MissingMethodException.
What could cause this? The plugins are fairly different in terms of what they provide, but very similar in terms of how they're built, published, etc. Clearly this is something I'm doing wrong (since the codec works in another plugin) but I don't even know where to begin looking. Does a plugin need to do something in particular to be able to provide custom codecs as of grails 5?
Errors range from 404s, IOExceptions, or encoding exceptions. They can be buried in the error stack, and occasionally suggest a versioning problem.
How can I prevent or address this class of errors?
The Dataflow service's SDKs and worker take dependencies on common third-party components, which themselves import various dependencies. Version collisions can result in unexpected behavior in the service. If you are using any of these packages in your code, be aware that some libraries are not forward-compatible and you may need to pin to the listed versions that will be in scope during execution. In order to determine whether your JAR has a conflicting version in use, consider inspecting the dependency tree of your project. Consult the list of specifically pinned versions if you suspect a problem here, and also avoid using "latest" for any of these libraries.
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`m using Apache Tika 1.4 to extract content from my documents. But it also comes with org.bouncycastle.* classes, and I use another version of bouncycastle which is conflicting with the Tika packages.
If the Tika was using the bouncycastle (bcprov) jar, I could exclude that using exclusion tag from Maven, but the TikaApp has copied the org.bouncycastle classes into it, so, I cannot exclude them.
There`s some way to remove this package without recompiling or branching Apache Tika and set to use another JAR to this specified package or something like that?
Thanks
Your problem is that you're using completely the wrong packaging of Tika!
The tika-app jar is a standalone, runnable jar, containing all of the Tika code + all dependencies required to let it run. It's intended to be used from the command line, standalone, to allow non-Java users to call Tika, and to allow for easy testing.
If you're writing your own Java application, which it sounds like you are, you will want to depend on the tika-core artifact as a minimum. That contains all the interfaces, the mime detection, service loaders etc. You'll then almost certainly also want to depend on tika-parsers , which provides all the code to do the actual parsing of the file formats, along with pulling in their required dependencies. This gives you the full control you seem to want.
Finally, there's also an OSGi bundle available, for those who prefer the control and classloading that OSGi offers, that's in the tika-bundle artifact. There's also a CXF powered JAX-RS version, which offers Tika's services over a RESTful interface, that comes in the tika-server artifact.
Is there a way to check which Grails plugins are active and used durring application runtime?
I want to remove a plugin but I want to be absolutely sure that it is not used anymore...
Well, a brute force way would be to copy your Grails project (preferably using a source control tool like git's branching feature), remove the plugin, and make sure that:
No exceptions on a grails clean, grails compile, and grails refresh-dependencies.
All unit and integration tests pass (your team is writing those, right? ;) )
You can run the application and use it fairly normally; warning, this is the worst test, and by itself isn't sufficient, as you could end up with a BOMM.
If you're familiar with the classes in the plugin, but there are way too many Grails files to look through manually, you could use code search tools like those found in GGTS whatever IDE/text editor you're using. Even grep could be handy for finding references to those classes or some distinctly named methods.
Conversely, if the plugin is basically a black box, and your Grails app is small enough to get around, check the import statements at the top of your Controllers, Domains, and Services. If the plugin provides more client-side technology (like the jQuery plugin) check your GSPs and various items in the web-app directory (like Javascript files) for references to it.