NAME OPM::Maker::Command::sopm - Build .sopm file based on metadata VERSION version 1.1.1 DESCRIPTION SOPM files are used for ticket system addon creation (e.g. for Znuny, OTOBO, ((OTRS)) Community Edition). They define some metadata like the vendor, their URL, packages required or required Perl modules. It is an XML file and it's no fun to create it. It is not uncommon that the list of files included in the addon is not updated before the addon is built and released. That's why this package exists. You can define the metadata and stuff like database changes in a JSON file and the file list is created automatically. And you don't have to write the XML tags repeatedly. INSTALLATION PHASES When an addon is installed, it happens in several phases 1 CodeInstall - type "pre" 2 DatabaseInstall - type "pre" 3 Files are installed 4 Include SysConfig 5 DatabaseInstall - type "post" 6 CodeInstall - type "post" These types are important in some cases and you'll see them later. CONFIGURATION You can configure this command with a JSON file. A simple add on This configuration file defines only the metadata. { "name": "Test", "version": "0.0.3", "framework": [ "3.0.x" ], "vendor": { "name": "Perl-Services.de", "url": "http://www.perl-services.de" }, "license": "GNU AFFERO GENERAL PUBLIC LICENSE Version 3, November 2007", "description" : { "en": "Test sopm command" } } And this .sopm will be created (assuming the file exists) Test 0.0.3 3.0.x Perl-Services.de http://www.perl-services.de Test sopm command GNU AFFERO GENERAL PUBLIC LICENSE Version 3, November 2007 Support more than one framework version If the module runs on several framework version, you can define them in the list of frameworks "framework": [ "3.0.x", "3.1.x", "3.2.x", "3.2.x" ], And they will all be listed in the .sopm 3.0.x 3.1.x 3.2.x 3.3.x Required packages and modules Some addons depend on other addons and/or Perl modules. So it has to define those prerequesits. "requires": { "package" : { "TicketOverviewHooked" : "3.2.1" }, "module" : { "Digest::MD5" : "0.01" } }, Creates those tags TicketOverviewHooked Digest::MD5 Database changes Create new table Insert stuff Change Column Code execution You can execute code when an addon is installed. As you can see above, there are to phases when code can be executed. Run "post" code Sample config "code" : [ { "type" : "Install" }, { "type" : "Uninstall" } ] This creates Get('var::packagesetup::' . $Param{Structure}->{Name}->{Content} )->CodeInstall(); ]]> Get('var::packagesetup::' . $Param{Structure}->{Name}->{Content} )->CodeUninstall(); ]]> You need to provide the var::packagesetup::xxxxx package (where xxxxx is the name of the addon). There are four types: * Install * Upgrade * Reinstall * Uninstall The methods called are usually named CodeInstall, CodeUninstall, etc. If you need to run an other method, you can specify the method to be called: "code" : [ { "type" : "Install", "function": "OtherMethod" } ] And that would create Get('var::packagesetup::' . $Param{Structure}->{Name}->{Content} )->OtherMethod(); ]]> Usually you would run the code after the files are installed and database changes are done. But sometime you need to run code before this stuff is done. As the packagesetup file isn't available you, you would need to provide the Perl code in the JSON file. That's nasty. With inline you can tell this command to get the Perl code from a file. Options * type * version * phase * function * inline METHODS VERSION AUTHOR Renee Baecker COPYRIGHT AND LICENSE This software is Copyright (c) 2016 by Renee Baecker. This is free software, licensed under: The Artistic License 2.0 (GPL Compatible)