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.
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?
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 have a bunch of utility classes, that have nothing to do with web requests, database etc. Very similar to POJOS, except they are never persisted.
I want to make these classes available to a number of Grails applications and plugins.
At the moment, I putting these classes in their own plugin. It just seems like overkill. In the java world they would just be one package that was jar'ed.
I want to use some of the Groovy annotations such as #immutable etc so I want to stay in Groovy. But, I was wondering do I have any other options because a plugin, because that seems like overkill.
thanks
technically seen, this would be a bit of overkill indeed.
On the other hand, you just need a single repository and build process to deploy your app. I think, a single dependency resolution system which in integrated in Grails is better than 2 or more, unless you have them already.
You could make a plugin, or compile the Groovy into classes and make a jar that you share. Using annotations like #Immutable will work in classes from a jar or as source from a plugin.
I have a project with a RESTful Rails back-end and a Flex front-end, first time for me with this combo and I debating whether to put the flex source somewhere inside the Rails folder hierarchy or making it a separate project. If I do so which folder would be most suitable /lib?
Also be doing one click deployment with Vlad which can also compile the flex app and dump it in the public folder.
Or does anyone have any good reasons why the flex project shouldn't reside within the Rails folder hierarchy?
Cheers
From personal experience, it's fine in the Rails folder structure. We have a "/flexsrc" folder a the rails project level in git, and when we build, the swf and related files are dumped to the /public area. It's been this way for a while, and there's no apparent drawback.
I think it would be more of a hassle to have two source depots.
(disclaimer, I've only used Flex with PHP and Java, I'm not terribly familiar with Rails so I can only really address the last part of the question).
My general experience is that it is best to keep both Flex and its hosting server components in the same source tree and svn project. Unless you have reason to believe that you are going to need a different server at some point, I can't really imagine any reason why you wouldn't want to:
Keeping them in the same project makes it easier to automate builds (in Java definitely, and it sounds the same in Rails).
If they are in the same tree, then it is easier for other developers to work on the same code without using SVN externals.
Placing them as separate projects can complicate compiler arguments for RemoteObjects and the like
This is the way I do it:
AppRepo
FlexAppFolder/
RailsAppFolder/
I like the Glenn's approach, but as ChrisInCambo said he's using a RESTful Rails back-end, which means that Rails has a bunch of services to expose and which means that the services could be consumed from different clients (front-ends), maybe not now, but in a future.
Another approach could be
RailsAppRepo
FlexAppRepo
and if you're using git you can do:
git submodule add backend git://your_backend_repo
or an svn external
Any ideas?
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 .