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. Tech Talk Live: Packaging & Deploying
Extensions
February 2012
Gabriele Columbro, Jared Ottley, Richard McKnight,
Jeff Potts

2. Rough Agenda
• Alfresco Add-Ons
• Packaging
• Deployment
• Project Structure & Builds
• More on Maven

3. Introducing Alfresco Add-Ons
• http://addons.alfresco.com
• 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

5. 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

6. Packaging

7. 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
• http://wiki.alfresco.com/wiki/AMP_Files

8. 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

9. Why You Should Use Them
Anyway
• 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

10. 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

11. Deployment

12. 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
• http://wiki.alfresco.com/wiki/
Packaging_And_Deploying_Extensions

13. 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

14. Project Structure & Builds

15. 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

16. MORE ON MAVEN

17. Alfresco field expertise tells me
that…
• Community / Enterprise Networks
1. Develop their own build system
2. Generally leverage the Eclipse SDK but in many different flavors
3. Rarely do test driven development (difficult) or CI
4. Often use a poor / no packaging
5. Either manual (error prone) or over-complex .doc based deployment strategy
6. Often not contribute as it takes time to understand “How To”
7. Almost no reuse/sharing between projects
• Common pitfalls
1. Wrong environmental properties
2. AMP leftovers in the WAR from previous deployments
3. Single point of failure (“oh no, the build guy is on holiday”)
4. No reuse & difficult integration between different projects
5. No versioning!

18. 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 Administrators
2. Use a standard tool OR document your procedure thoroughly
3. Leverage AMPs as distribution packaging atom
• Can also be used during day by day development
4. Automate (packaging), automate (release notes), automate (CI)!
5. Minimize MANUAL activity, during development and upon release
6. Version (code & binaries) !!!
7. If I was you, I’ll just use Maven J

19. 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 RTM
2. 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 automation
2. No dependency management / control
3. Ant sample builds covers a small subset of the Alfresco landscape
4. Not Enterprise process ready

20. By the way…
Building Alfresco applications with Maven
≠
Alfresco to build with Maven
Currently there is no plan to build
Alfresco with Maven

21. Maven Alfresco Lifecycle
• Vision
“Provide a Community / Enterprise unified concise approach to
support the full lifecycle of an Alfresco application, from project
creation 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 http://maven.alfresco.com
• Testing against 4.x EE underway
• Stay tuned at maven-alfresco@googlegroups.com
• Get ithttp://wiki.alfresco.com/wiki/Managing_Alfresco_Lifecyle_with_Maven

22. 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

23. Maven support from Alfresco
Community Support
– Maven Alfresco Lifecycle Available as of 2007
– Artifacts on http://maven.alfresco.com (Nexus) as of 2009
• 4.x Community artifacts already available
• Still manual deployment L
Enterprise Support
1. Target: 4.x EE deployed on http://maven.alfresco.com
1. Only JARs / WARs
2. NO POMs
2. New release of Maven Alfresco Lifecycle
• Working to get it to a full “alternative” to Eclipse SDK
Already/soon in HEAD
1. Automated artifacts deployment to maven.alfresco.com
2. More granular dependency definition in .classpath files