Tech talk live alfresco add ons


Published on

Slide deck to accompany 1st Feb 2012 webinar on finding, distributing and packaging Alfresco add-ons. With Jeff Potts, Rich McKnight and Gab Columbro

1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Tech talk live alfresco add ons

  1. 1. Tech Talk Live: Packaging & DeployingExtensionsFebruary 2012Gabriele Columbro, Jared Ottley, Richard McKnight,Jeff Potts
  2. 2. Rough Agenda•  Alfresco Add-Ons•  Packaging•  Deployment•  Project Structure & Builds•  More on Maven
  3. 3. Introducing Alfresco Add-Ons••  Directory of Alfresco add-ons and extensions –  Not a code hosting site –  Replaces Alfresco Forge•  Eventually integrated into the platform –  Community, Enterprise, Cloud•  May feature monetization at some point
  4. 4. Add-ons Timeline•  Alfresco Forge is no longer accepting new projects•  Add-ons out of beta in February•  Register for an account, begin listing your add-ons today•  New releases to follow regularly•  Platform integration expected with Alfresco 5.x
  5. 5. Packaging
  6. 6. What is an AMP?•  Alfresco Module Package•  A zip with a defined structure•  Gets “installed” into an alfresco or share WAR using the Module Management Tool (MMT)•  The best practice for distributing add-ons•
  7. 7. Reasons to Dislike AMPs•  Requires a proprietary tool (MMT)•  Longer dev cycles (merge, deploy entire WAR) versus unzipping/copying•  Lacks value-add features such as merge•  Lacks an undeploy
  8. 8. Why You Should Use ThemAnyway•  Namespacing built in•  Can include bootstrapping logic•  Can be used for both repo and Share tiers•  Repeatable deployment process for Ops•  We (the Royal “We”) need one “module” approach for add-ons•  Expect AMP/MMT improvements in the coming year
  9. 9. Best Practices•  Package as an AMP•  Use reverse domain for module ID•  Consider using a straight copy for local Dev, then package as an AMP for Test/QA/ Prod
  10. 10. Deployment
  11. 11. Where Should I Stick This?•  If you’re using AMPs, this isn’t an issue•  Otherwise… –  Repo: WEB-INF/classes/alfresco/extension –  Share: WEB-INF/classes/alfresco/web- extension• Packaging_And_Deploying_Extensions
  12. 12. Best Practices•  Use AMPs so you don’t have to worry about it•  Separate your repo tier extensions from your Share tier extensions•  Deploy to the appropriate webapp, not to Tomcat shared
  13. 13. Project Structure & Builds
  14. 14. Best Practices•  “More projects” is usually better than “one project” –  One each for shared config, server settings –  For each module, one repo tier, one Share tier•  Have a repeatable build•  Incorporate minification into your build•  Ant versus Maven
  15. 15. MORE ON MAVEN
  16. 16. Alfresco field expertise tells methat…•  Community / Enterprise Networks1.  Develop their own build system2.  Generally leverage the Eclipse SDK but in many different flavors3.  Rarely do test driven development (difficult) or CI4.  Often use a poor / no packaging5.  Either manual (error prone) or over-complex .doc based deployment strategy6.  Often not contribute as it takes time to understand “How To”7.  Almost no reuse/sharing between projects•  Common pitfalls1.  Wrong environmental properties2.  AMP leftovers in the WAR from previous deployments3.  Single point of failure (“oh no, the build guy is on holiday”)4.  No reuse & difficult integration between different projects5.  No versioning!
  17. 17. Packaging & lifecycle matter It’s not *just* about the content, form counts!•  My quick tips:1.  Give time to define build /Application Lifecycle Mgmt strategy •  Modules Requirements & Tooling •  Deployment / environment promotion process •  Contracts with Operations / System Administrators2.  Use a standard tool OR document your procedure thoroughly3.  Leverage AMPs as distribution packaging atom •  Can also be used during day by day development4.  Automate (packaging), automate (release notes), automate (CI)!5.  Minimize MANUAL activity, during development and upon release6.  Version (code & binaries) !!!7.  If I was you, I’ll just use Maven J
  18. 18. Why not just use the SDK? IMHO Alfresco Development could be much quicker and automated ==> FUN!•  Community limitations of current SDK:1.  Non standard (not even de facto), requires too much RTM2.  200MB and growing? Not always need for EVERYTHING…3.  Alfresco not available in mainstream download channels•  Enterprise limitations of current SDK:1.  Eclipse bound, so not suitable for other IDEs or automation2.  No dependency management / control3.  Ant sample builds covers a small subset of the Alfresco landscape4.  Not Enterprise process ready
  19. 19. By the way… Building Alfresco applications with Maven ≠ Alfresco to build with Maven Currently there is no plan to build Alfresco with Maven
  20. 20. Maven Alfresco Lifecycle•  Vision“Provide a Community / Enterprise unified concise approach tosupport the full lifecycle of an Alfresco application, from projectcreation to release and integration in enterprise processes”•  State of the nation •  Mature project (since 2007) à Set of archetypes / plugins –  Used by Jive toolkit & Bulk Import tool •  Current version 3.9.1 in •  Testing against 4.x EE underway•  Stay tuned at•  Get it
  21. 21. Maven Alfresco Lifecycle features•  Current release (3.9.1, tested with 4.0 CE) –  Alfresco, Share, AMP archetypes –  Run Alfresco embedded in Jetty –  WAR can depend on AMP (no MMT required) –  Per environment separate configuration –  Mandatory integrated versioning! –  Release & distribution•  Roadmap (will be 4.0, to be tested with 4.0 EE) –  Multi module archetype •  Repo/Share/Solr/AMPs •  Super POM dependency management –  Integrated support for TDD –  Run embedded in favorite appserver –  General cleanup
  22. 22. Maven support from AlfrescoCommunity Support –  Maven Alfresco Lifecycle Available as of 2007 –  Artifacts on (Nexus) as of 2009 •  4.x Community artifacts already available •  Still manual deployment LEnterprise Support1.  Target: 4.x EE deployed on 1.  Only JARs / WARs 2.  NO POMs2.  New release of Maven Alfresco Lifecycle •  Working to get it to a full “alternative” to Eclipse SDKAlready/soon in HEAD1.  Automated artifacts deployment to maven.alfresco.com2.  More granular dependency definition in .classpath files