Hi Rob, RE:
Some of the functionality we want would be best provided as modules: for example we intend to replace the current mail module with an implementation that can use Amazon's Simple Email Service instead. Sounds like the proper use for a module. IMHO, you may want to simply have your custom mail module declare a dependency on the magnolia mail module, then extend the magnolia classes with your own to add the functionality for Amazon Simple Email Service. My understanding of modules is that they are essentially the equivalent of .war or .ear archives. You create the desired functionality, bootstrap and so on, define the XML descriptor and then deploy your module into Magnolia. The module lifecycle is controlled by Magnolia and so on. Typically, a module is the equivalent of a .jar file. It can have it’s own development and release lifecycle, as well as the ability to declare its dependencies, both compile-time dependencies (can be specified in your modules pom.xml file if you’re using maven), and runtime via Magnolia’s Module Descriptor (XML file). Typically, if your using maven, you can simply add a dependency to your module in your custom webapp, and your module’s jar file will be included within your custom webapp’s .war file. The module lifecycle is controlled by what you specify in your module descriptor file, your Module Class, and your Module Version Handler when performing installs and updates. If you haven’t already read it, I’d suggest taking a look at the Technical Guide, lots of good stuff there. Of particular interest related to your question, check out the section on Modules here: http://documentation.magnolia-cms.com/technical-guide/modules.html My question relates to best practices for development and testing of modules. Those of you that have developed modules before, can you describe the process you take for development, test and deploy of modules? Other questions I have are: * What is the best way of testing Magnolia functionality in unit tests? I.e. lifecycle calls to modules? * What is the best way to tell Magnolia to "redeploy" a module? I use Maven for setting up my projects. Each of our custom modules contains it’s own unit tests (typically, the unit tests are written using JUnit 4 and EasyMock). In some cases we use Selenium for Functional Tests. The unit tests get run when ever we build locally, (i.e. mvn clean install from the command line, or Build and Run in an IDE). The unit tests also get run from Hudson CI when developers commit code to subversion. Regarding the best way to tell Magnolia to redeploy a module. We declare the dependencies to our custom modules in our custom webapp. The updated jars, each with an updated release version, get included in the generated war file for distribution. Each custom module contains any tasks that need to occur while upgrading in it’s Module Version Handler (this includes bootstrap xml files to import, freemarker scripts to import, resources like css, and theme images, etc.). When the war file gets deployed, you get the installer screen and click install module updates button to run through the various update tasks. In addition to the Technical Guide documentation mentioned above, have a look at the following for a little more detail: http://documentation.magnolia-cms.com/reference/module-mechanism.html http://documentation.magnolia-cms.com/reference/module-mechanism/version-handling.html http://wiki.magnolia-cms.com/display/DEV/Customer+Project+Setup HTH, Matt ________________________________ From: Rob Blake <[email protected]> Reply-To: Magnolia User-List <[email protected]> Date: Sun, 30 Jan 2011 13:15:13 +0000 To: Magnolia User-List <[email protected]> Subject: [magnolia-user] Best practices for module development, testing and deployment Hi all, We've just released the first version of our site running on Magnolia, and we've got a list of things we'd like to improve. Some of the functionality we want would be best provided as modules: for example we intend to replace the current mail module with an implementation that can use Amazon's Simple Email Service instead. My understanding of modules is that they are essentially the equivalent of .war or .ear archives. You create the desired functionality, bootstrap and so on, define the XML descriptor and then deploy your module into Magnolia. The module lifecycle is controlled by Magnolia and so on. My question relates to best practices for development and testing of modules. Those of you that have developed modules before, can you describe the process you take for development, test and deploy of modules? Other questions I have are: * What is the best way of testing Magnolia functionality in unit tests? I.e. lifecycle calls to modules? * What is the best way to tell Magnolia to "redeploy" a module? I look forward to hearing your experiences, cheers, Rob ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
