Plugging the users in - extend your application with pluggable Groovy DSL

t is often beneficial to allow users extend your software with their own logic. With the rise of dynamic languages on the JVM it is also much more easier to do than ever before. In this session we will share our experience in creating Groovy authored user plugins interface.

After a brief introduction to domain specific languages (DSLs), their relevance to user plugins and how they can be easily implemented in Groovy, we’ll look at more user-friendly, but developer-challenging type of DSLs, which support plugins written both in Groovy or Java.

Good public API design is another very important aspect - while the APIs have to be broad enough to allow interesting functionality, internals should stay close to allow changes and further development. Exposing APIs to the world come with great responsibility - once ublished they can’t be changed without a price, so it is important keep backwards compatibility in mind.

Another very important aspect is security - you let strangers into your chambers, and you better be ready. Leveraging security mechanisms is essential to establish proper sandboxing and protect your application from malicious or faulty plugins.

Finally, we will cover another very important and nontrivial aspect of user plugins exposure - the classpath isolation when your plugins require dependencies. We will compare different solutions like establishing classpath hierarchies, OSGi, JBoss modules and the long-awaited Project Jigsaw.

Transcript

1. © 2013 SpringOne 2GX. All rights reserved. Do not distribute without permission. Plugging the users in extend your application with pluggable Groovy DSL
15. – scheduled tasks
16. – scheduled tasks – Custom security realms
17. – scheduled tasks – Custom security realms – Change resolution rules
18. – scheduled tasks – Custom security realms – Change resolution rules – Manipulate downloaded content
19. – scheduled tasks – Custom security realms – Change resolution rules – Manipulate downloaded content – Listeners on storage events
20. – Custom security realms – Change resolution rules – Manipulate downloaded content – Listeners on storage events – searches
21. – Change resolution rules – Manipulate downloaded content – Listeners on storage events – searches – New rest commands
22. – Manipulate downloaded content – Listeners on storage events – searches – New rest commands – Custom promotions
23. – Listeners on storage events – searches – New rest commands – Custom promotions – Deploy and query artifacts and metadata
24. – Etc.
26. Requirements ___________
27. Requirements –Familiar to Java users ___________
28. Requirements –Familiar to Java users –Simple DSL ___________
29. Requirements –Familiar to Java users –Simple DSL –Simple deployment: ___________
30. Requirements –Familiar to Java users –Simple DSL –Simple deployment: –No packaging ___________
31. Requirements –Familiar to Java users –Simple DSL –Simple deployment: –No packaging –No restart ___________
34. Small helpers
35. Small helpers Totally new language
36. Small helpers Totally new language
39. Small helpers Totally new language
40. <3
41. Parse groovy scripts Create closure objects Cast to SAM Find SAMs in classpath SAMs map Cast to Closure Execute
42. Show me the code!
44. Public API Design _____________
45. Public API Design –Papi is contract _____________
46. Public API Design –Papi is contract –Maintain backwards compatibility at all costs _____________
47. Public API Design –Papi is contract –Maintain backwards compatibility at all costs – Breaking API might crash the server! _____________
48. Public API Design –Papi is contract –Maintain backwards compatibility at all costs – Breaking API might crash the server! – Start small _____________
49. Public API Design –Maintain backwards compatibility at all costs – Breaking API might crash the server! – Start small – Listen to users _____________
50. Public API Design compatibility at all costs – Breaking API might crash the server! – Start small – Listen to users – Fluent API is your friend _____________
51. Public API Design – Breaking API might crash the server! – Start small – Listen to users – Fluent API is your friend – Strong Java Types, compatibility _____________
52. Show me the code!
59. The conflict __________
60. The conflict – Need to access Artifactory jars (PAPI) __________
61. The conflict – Need to access Artifactory jars (PAPI) – Need to be isolated from Artifactory jars (3rd party) __________
66. We’ll do it ourselves! ________________
68. We’ll do it ourselves! 1. Pull up what’s common ________________
69. We’ll do it ourselves! 1. Pull up what’s common 2. isolate the rest ________________
70. We’ll do it ourselves! 1. Pull up what’s common 2. isolate the rest ________________