Tech Talk Live: Packaging & Deploying Extensions February 2012 Gabriele Columbro, Jared Ottley, Richard McKnight, Jeff Potts

Rough Agenda

•  Alfresco Add-Ons •  Packaging •  Deployment •  Project Structure & Builds •  More on Maven

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

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

Packaging

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

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

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

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

Deployment

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

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

Project Structure & Builds

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

MORE ON MAVEN

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!

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

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

By the way…

Building Alfresco applications with Maven

≠ Alfresco to build with Maven

Currently there is no plan to build

Alfresco with Maven

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

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

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