Modularizing your Grails Application with Private Plugins - SpringOne 2GX 2012

Modularizing Your
Grails Application
with Private Plugins
Ken Liu
IEEE
SpringOne 2GX 2012
17 Oct 2012

Wednesday, October 17, 12

About Me
• Web development with Java since
JDK 1.0.2 (applets, anyone?)

• Groovy/Grails since 2009
• Lead developer for IEEE Spectrum
• Always been a closet fan of dynamic
languages (starting with Perl)


About IEEE
• Institute of Electrical and Electronics
Engineers
• Widely known for standards - 802.11
• World’s largest technology
professional association - 400,000
engineers in 160 countries
• Publishes nearly a third of the world’s
technical literature in EE/CS


About IEEE Spectrum
• Flagship publication of IEEE
• General interest technology magazine
with focus on EE topics

• 2012 National Magazine Award winner


IEEE Spectrum website

• http://spectrum.ieee.org
• ~1.5M PV/mo
• Frequent referrals from HN, Reddit, /.
• 100% Groovy/Grails since 2009 -
both front-end and CMS
• Akamai/Weblogic/Oracle stack
• Award-winning coverage of ROBOTS!


Agenda

• Grails plugins overview
• Grails plugin development basics
• Application architecture with private
plugins
• Lessons learned


To fork or not to fork?

• “We need a new website...”
• “You must use the standard corporate
Enterprise CMS system.”

• “Can’t you guys just make a copy of
the existing code and tweak it?”

• DANGER!


From “big ball of mud” to
plugin architecture
Where do we go from here?

Front End Domain classes CMS
Controllers/Views/ (e.g Article, Controllers/
Services BlogPost) Views/Services
(e.g. article, blog pages)

Utility classes
UrlMappings Spectrum Taglib (src/**)

Quartz Jobs Front End & CMS
(e.g. sitemap Test classes
images, CSS, JS
generation)


Plugin systems and
component models
• Plugin systems are now commonplace
• Firefox, Eclipse, Jenkins, JEdit
• Package managers, OSGi, Ruby on
Rails Engines

• Component-oriented software?
• Coarse-grained high-level reuse,
separation of concerns


Grails plugins in a
nutshell
• Tightly integrated into Grails system
• Can implement common functionality
in plugins that is overridden by
application

• Can create new Artifact types
• Interact with Spring context
• Integrated with build system


Grails plugins in a
nutshell

• Central public plugin repository
• Version management
• Dependency management


Grails - plugins inside
• Many parts of Grails
itself are built as plugins
• Some default plugins can
even be swapped out
• Tomcat -> Jetty
• GORM/Hibernate ->
Redis GORM


Public Grails plugins
• 850 public plugins in the central
plugins repository

• Search on plugin portal
http://grails.org/plugins/

• Quickly bootstrap new applications
• Spend some time now
save some time later
• Follow @grailsplugins for updates


Selected Grails plugins
Spring Security - user authentication
Cache - caching using annotations
Quartz - job scheduling (like cron)
DB Migration - controlled schema changes
Mail - send email with JavaMail
Resources - web performance optimization
Console - in-app interactive console
CodeNarc - static code analysis
Spock - enable Spock unit testing framework


What can go into a
plugin?
• Really, anything
• Standard Grails artifacts: GSPs,
Controllers, Services, i18n, TagLibs -
just like in app

• Deﬁne custom Grails artifact types:
see Quartz plugin “Jobs”

• Plugins can depend on other plugins


Creating a new plugin

grails create-plugin myplugin


Creating a new plugin

Same structure
as a Grails
application, but
with an extra
plugin
descriptor ﬁle


Plugin Descriptor
class MypluginGrailsPlugin {
// the plugin version
def version = "0.1"

// the version or versions of Grails the plugin is designed for
def grailsVersion = "2.1 > *"

// the other plugins this plugin depends on
def dependsOn = [:]

def doWithDynamicMethods = { ctx ->
// TODO Implement registering dynamic methods to classes (optional)
}

def doWithApplicationContext = { applicationContext ->
// TODO Implement post initialization spring conﬁg (optional)
}


Excluded plugin files
/grails-app/conf/BootStrap.groovy
/grails-app/conf/BuildConfig.groovy
/grails-app/conf/Config.groovy
Grails excludes /grails-app/conf/DataSource.groovy
certain files (and any other *DataSource.groovy)
/grails-app/conf/UrlMappings.groovy
from packaging /grails-app/conf/spring/resources.groovy
/web-app/WEB-INF/**
/web-app/plugins/**
/test/**


Running a plugin
• A plugin is a Grails app!
• grails run-app from plugin dir
• excluded ﬁles loaded during run-app
• useful for testing
(test-app works too)


Packaging a plugin

• grails package-plugin
• creates a zip ﬁle that can be installed
& distributed


Installing a plugin

from local directory:
grails install-plugin /path/to/grails-example-0.1.zip

from URL:
grails install-plugin http://myserver.com/plugins/grails-
example-0.1.zip

in BuildConﬁg.groovy (“in-place” plugin):
// Uncomment this only for local development - do not check in!
grails.plugin.location.'spectrum-core' = '../spectrum-core'


Plugin Development

• Easy: create Controllers, Services,
Views, Taglibs, etc.

• Specify resource paths <g:resource>
• Can alter Spring context
• Hook into build system, reload events


Public vs. Private plugins
Public plugins
• Highly cohesive
• Maximize reuse
• Sometimes provide “horizontal slices” -
e.g. Spring security core
• Most don’t depend on other plugins


Public vs. Private plugins
Private Plugins
• Proprietary code
• Application or domain-speciﬁc
• Code reuse within an organization
• Can be coarse-grained, heavyweight
• Private forks of public plugins
• Enable interesting options for
application architecture


plugin architecture
• Grails applications tend to become
unmanageable over time
• Convention-based directory trees
(e.g. /grails-app/views )

• Rapid development/scaffolding
• Need “separation of concerns”


plugin architecture
Spectrum application before refactoring

Front End Domain classes CMS
Controllers/Views/ (e.g Article, Controllers/
Services BlogPost) Views/Services
(e.g. article, blog pages)

Utility classes
UrlMappings Spectrum Taglib (src/**)

Quartz Jobs Front End & CMS
(e.g. sitemap Test classes
images, CSS, JS
generation)


Reusable domain model
DB
• Reuse a set of
Domain classes
between applications
• Different applications,
same DB instance
Domain Model Domain Model

• Hibernate not
plugin plugin

included in plugins by API endpoint Primary web
application application
default
• Consider Hibernate Domain Model
plugin
caching issues
Reporting
application


Refactored with plugin
Spectrum Application Spectrum Core Plugin

Front End Core Domain Utility classes
Controllers/Views classes (src/**)

Front End CMS
Common Front
UrlMappings Controllers/
End Controllers
Views/Services

Front End Taglib
Core Services CMS test classes

Test classes CoreUrlMappings CMS Taglib

Front End CMS
Quartz Jobs
images, CSS, JS images, CSS, JS

Depends on other plugins: spring-security-core,
quartz, searchable, ckeditor, and others


Different web sites,
common backend code
spectrum-core
Plugin

Spectrum The Institute
website website
10.4+ 3.0


Same Controller,
different Views
FrontendArticleController#show()

Spectrum application The Institute application
show.gsp show.gsp


Same Controller,
different Views
• Define common Controller in plugin
• View resolution: application first, then
plugin
• Can specify plugin using
<g:render plugin=”myplugin”>

• The promise of MVC fulfilled!


Plugin UrlMappings
• UrlMappings.groovy excluded from plugin
build

• *UrlMappings.groovy merged into
application mappings

• Application can override plugin mappings
• Enables “mini application” in plugin
• Can’t remove unwanted mappings, only
override


Config.groovy
• Config.groovy is excluded from plugin
• Might want to fix certain config
properties - won’t need them in
application Config
• Manually merge config in
doWithSpring
• application.config.merge(new
ConfigSlurper().parse(application.classLoader.loadClass('MyPluginConfig
')))


Extending plugin
domain model
Content class
Domain model plugin Domain classes in
plugins can be
extended in
application
Webinar extends Content
Application


Publishing private plugins
• Publish to internal corporate Maven
repo - e.g. Artifactory or Nexus
• Release plugin - installed by default
• Old-style svn-based repos supported,
but not recommended for Grails 2
• Customize plugin metadata with
internal Maven groupId
• Publish from Jenkins


Declaring private plugin
dependencies
BuildConfig.groovy
(Maven/Ivy dependencies)
repositories {
grailsPlugins()
/* other default repos here */
/* point to internal corporate Maven repo */
mavenRepo 'http://mvn.ieee.org/nexus/content/repositories/spectrum/'
}
plugins {
/* other plugin dependencies here */
compile 'org.ieee.spectrum.plugins:spectrum-core:2.0-SNAPSHOT'
}


Day-to-day development
• Use “in-place” plugin (exploded plugin) in
your local dev workspace
(BuildConﬁg.groovy)

• Private plugins tend to be updated along
with application features

• Beware of potential breaking changes
(in other applications)

• Deﬁne deprecation strategy and use
@deprecated javadoc


Refactoring to plugin

• Determine candidates for refactoring
• Create new empty plugin & plugin descriptor
• Move Grails artifacts (e.g. Controllers,
Services, Views, etc.) into new plugin
• Move dependent ﬁles from /src
• Move related test ﬁles into new plugin
• Remove hard coded paths to resources
• Run your functional test suite


Refactoring to plugin

• Start small - don’t create a whole
bunch of plugins from the outset

• Consider migrating version history


Super-project with plugins
One application with several in-place plugins
/myapplication
/grails-app
...
/pluginA
/grails-app
/pluginB
/pluginC

In BuildConﬁg.groovy:
grails.plugin.location.pluginA = 'pluginA' // path to plugin
grails.plugin.location.pluginB = 'pluginB'
grails.plugin.location.pluginC = 'pluginC'


Public website,
private back end
Public Private
Internet intranet
Deploy public
Core
Core
application
application
plugin
and private
plugin
Business-
versions of
Public-facing
application facing application with
application
shared code

DB


Vertical slices / mini
Grails applications
• Plugins can be self contained
• UrlMappings + Controllers + Domains +
Views + Services = Grails application

• Remove views -> “white label” application
• Embed a small application within another
application

• Vertically slice your application into plugins


Plugins as a platform
Data Capture Data Cleaning Data Validation
plugin plugin plugin

Super-plugin to
combine plugin
Clinical Data Management dependencies into
Platform plugin a platform or
domain-speciﬁc
framework

Clinical data
Clinical data review
management server
application
application


Sensitive code protection
DB
Split application
into separate
Data Ingestion Data Analysis parts to isolate
plugin
plugin
“secret sauce” key algorithms
from external
vendor

Shell application Full application
(external team)


Domain/Schema
management
• Changes to domain model need to be
carefully managed
• Avoid dbCreate=update
• Adopt DDL ﬁle naming convention:
spectrum-core-2.1.sql
spectrum-core-2.2.sql

• Bootstrap-triggered migrations
• DB Migrations plugin (Liquibase)


Config.groovy changes
over time
• Easy to add a new entry to
Config.groovy and then forget about it

• Group together plugin config
properties into a closure

• Don’t forget about external config files
and differences in various
environments


Maven/Ivy/build issues

• Maven/Ivy hell > JAR hell
• SNAPSHOT resolution error-prone
• See JIRA for bugs related to plugins
• Avoid creating many small plugins
• Strange problems? Look at your build.


Plugin versioning and
branching

• Deﬁne version numbering strategy
• Be prepared to branch/merge
• Be sure to update plugin versions and
tag your code consistently
• Just use Git - merging & cherry-
picking are sweet


Code Rigidity

• Inﬂexibility to change/afferent
coupling
• Avoid breaking changes (duh)
• Solution: automate your tests, catch
breaking changes early


Continuous Integration

• Use Jenkins to trigger builds of
applications that depend on your
private plugin

• Run Plugin test suite with plugin build
• Publish snapshots to Maven repo from
Jenkins


Plugin namespace
conﬂicts

• Plugin artifacts all share same
namespace with each other
• Potential for class name collisions,
especially with “conventions”
• Planned enhancement for Grails 2.2


Plugin resources

• Plugin static resources (images, CSS, JS,
etc.) packaged in a path corresponding to
plugin name & version - /plugins/
myplugin-1.0/*
• path changes between dev mode and WAR -
<g:resource> handles correctly
• May need to redeploy with each plugin
version bump
• Don’t accidentally share sensitive ﬁles!


Component interfaces

• Grails plugins don’t have any kind of
external “interface” or contract
besides Plugin Metadata

• Up to you to make the rules
(not a bad thing)


Success!
Release strategy for 2013 website redesign

spectrum-core Plugin
2.0, 2.1, 2.2

The Institute
Spectrum Spectrum
website
website website
3.x
10.8, 10.9, 4.0 - 2013
10.10 release


Takeaway

• Plugins are easy to create and use
• Private plugins are a safe, robust way
to modularize Grails applications
• Private plugins enable coarse-grained
reuse of application components
• Conﬁguration management and OO
principles are important (as always)


Additional resources

• @grailsplugins - Grails plugin updates - https://twitter.com/
grailsplugins

• Grails reference docs chapter on plugins - http://grails.org/doc/
latest/guide/plugins.html

• Inside Grails: The Build System and Plugin Management - http://
www.slideshare.net/skillsmatter/grails-internals-ggug-dec-2009

• GGUG: Grails Plugins - Lessons to Learn http://skillsmatter.com/
podcast/java-jee/grails-plugins


Questions?


Thanks!

feedback is appreciated.
@kenliu
k.a.liu@ieee.org


Modularizing your Grails Application with Private Plugins - SpringOne 2GX 2012

More Related Content

What's hot

What's hot (20)

Similar to Modularizing your Grails Application with Private Plugins - SpringOne 2GX 2012

Similar to Modularizing your Grails Application with Private Plugins - SpringOne 2GX 2012 (20)

Recently uploaded

Recently uploaded (20)

Modularizing your Grails Application with Private Plugins - SpringOne 2GX 2012