I'm creating a new Grails project. I decided to split it in one application and several plugins. Now, plugins and main application need to access each others classes.
In the main application I can access plugins classes thanks to this edit in my BuildConfig.groovy file:
grails.plugin.location.'plugin1' = "../Plugin1"
But, how can plugins access classes from the main application?
Plugins cannot access main application. Plugins are meant to be stand alone, having no dependencies to specific main application code, but can only have dependencies to other plugins.
You need to find a way you can split your application into parts, which are independent of each other.
Related
I am working on a POC where I had to containerize a part of application for eg - I need to containerize "add to cart" functionality in an e-commerce website, I see a various example https://dzone.com/articles/docker-for-devs-containerizing-your-application to containerize whole application,but how to do for a part of it where my functionalities has dependency on other code parts as well.
Any pointers will be very helpful as I am totally stuck and don't see similar query anywhere else.
Thanks
IMHO, the first thing you need to do is read more about the concept of microservices and how it works.
Basically, the idea is decouple your monolithic application into as many services as your want and deploy it separate of each other. Each of this parts will comminicate with other parts by API calls.
There are a lot of benefits of using microservices architecture, and there is no the "better way" to do this, it will depends of how your application works and how your team is engaged.
I can recommend you a couple of link about microservices:
https://medium.com/hashmapinc/the-what-why-and-how-of-a-microservices-architecture-4179579423a9
https://opensource.com/resources/what-are-microservices
https://en.wikipedia.org/wiki/Microservices
If the application is not build as microservices, it wont actually work. The POC you should be striving for is to decouple it in another seperate application.... Which I guess its much harder and larger scope of the original POC
This is how I'd do it:
create a new java/gradle module called "addToCart"
extract all functionality related to "add to cart" functionality to this single gradle, spring boot module (add relevant dependencies to build.gradle and update settings.gradle to include the new module. And use compile("module") to have dependencies on existing modules brought into your new spring-boot module (note: you can't depend on a module that is a spring boot application - this will fail because spring-boot modules are compiled differently to lib modules without the spring boot plugin).
extract any dependencies this new module has on existing code out to another new library module that can be pulled in using a gradle dependency (you're aiming to end up with a Gradle multiproject build). This is required so that existing projects/modules as well as the new one can maintain the same dependencies.
use a gradle docker plugin like https://github.com/palantir/gradle-docker OR https://github.com/bmuschko/gradle-docker-plugin to create a docker image/container for you (instructions on website). You can do this part manually also.
If you're feeling particularly adventurous you could look into building GraalVM "native images" that are container friendly. Native images start incredibly fast. Because they start so fast you don't actually need to have them running all the time, which can lower your costs. There are trade-offs though. There's a talk from Devoxx Belgium 2019 that goes into details about it here: https://youtu.be/3eoAxphAUIg?t=978
In grails 2 and earlier, plugins installed their source to .grails/<version>/projects/<projectName>/plugins/etc, this made it easy to debug plugins that were installed without having to check out and load the full source... find where problems were that could be hot-deployed. No need to install run the plugin locally.
In grails 3, this seems to be missing... or maybe I'm just missing something? Is there somewhere in my project I can directly modify the plugin source without checking out the plugin, compiling it and then installing it locally?
Yes, you're missing something rather important :)
Grails 2 plugins are distributed as ZIP files including source code, but Grails 3+ plugins are distributed as JAR files with the code compiled into classes. This has multiple benefits over the earlier approach, the biggest one being that you can no longer edit the source directly (which is the worst way to make changes to how a plugin works).
What you should do instead (in all versions of Grails) is to take advantage of the compilation/load/resolution order between the app and the installed plugins - plugins load first, then the app. This allows you to override nearly anything in a plugin just by creating a file (Groovy/Java/GSP/etc.) with the same name and same relative location in your app code, and it will automagically override the plugin's file or class. E.g. to override a plugin's com.foo.BarController controller, create grails-app/controllers/com/foo/BarController.groovy in your app (manually or by copying the original source and modifying it).
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.
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.
I'm considering developing aspects of a website as Rails plugins for reuse. My question is about the development process. Since each of these plugins will provide a "slice" of functionality, should I develop each "slice" as it's own application and then extract the code from each application into a plugin? Or, should I write them as plugins right in an application? Ultimately I will be linking to these plugins from each site to keep it DRY.
I guess the main question is what would be the development process for creating multiple "Engine" type plugins?
Thanks in advance for any help.
Either approach is valid.
When writing a basic plugin I usually find it easier to write it in tandem with the application that will use it. Because I find it easier to design/test around something that already exists.
However, when it comes to Engine plugins, I prefer to develop them as a separate application and then rip out all the unnecessary bits when I move it into a plugin. They are in essence mini applications, and they should be completely functional when installed on a freshly created rails project.
By designing them as their own application I'm ensuring proper compartmentalization. This ensures that I'm not accidentally referring to code models/controllers/views/helpers that are not a part of the engine I'm developing.
If you're developing multiple engine type plugins this way, you might want to condense a few of the steps with a utility script. Such as one that streamlines the process of turning an application into an Engine plugin.
It should restructure your app as necessary and populate the files that plugins should have, such as init.rb.
You might want to give a look to Desert framework as well .