Tech Talk Live: Packaging & DeployingExtensionsFebruary 2012Gabriele 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
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 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
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
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
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
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!
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
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
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 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 http://maven.alfresco.com • Testing against 4.x EE underway• Stay tuned at firstname.lastname@example.org• 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 AlfrescoCommunity 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 LEnterprise Support1. Target: 4.x EE deployed on http://maven.alfresco.com 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
A particular slide catching your eye?
Clipping is a handy way to collect important slides you want to go back to later.