Oaebanner

Packaging your Product for Adobe Exchange

Avatar

Adobe Solutions Enablement Team

Package/Sign ZXP, EULA, Troubleshoot

Mar 05, 2015 11:23 PST

How to Package your Product as a ZXP



Overview


The first step in successfully using Adobe Exchange is making sure Adobe Extension Manager can properly install your product. You must upload your product as a single file in order to take advantage of Adobe Exchange to market, distribute or sell your product. As part of defining your product in the Adobe Exchange Producer Portal, you must include the file or file package in order to submit it for approval. You can always package your product in the Adobe ZXP format that Adobe Extension Manager expects.

  • If your product is meant to be compatible with Creative Suite 6 applications, you MUST package it as an Adobe ZXP file.
  • If you do NOT need your product to be backward compatible, you have additional packaging options:
    • A simple product such as brush or image can be submitted as a single file, or you can submit an executable (EXE or APP).
    • You can create a simple ZIP archive for a set of files and submit the ZIP file.

Adobe Extension Manager requires the ZXP format in order to install an extension into an Adobe desktop application; for simpler submissions, the files you submit are automatically converted to this format before being deployed.

About the ZXP Packaging Format

For CS6 hosts, and for more complex products on CC hosts, you must create an Adobe ZXP package that conforms to the Adobe Exchange requirements. This article explains the terminology and requirements for ZXP packaging.

In order to package your product in the ZXP format, you must provide a manifest and a signing certificate:

  • Configuration Manifest: The ZXP format requires a manifest, which is an XML file that specifies all of the configuration details for the product, such as where to install files, which applications are supported, and so on. Depending on how you created your product, the manifest can be an XML file named manifest.xml, or an MXI file.
  • Signing your Package: Adobe Exchange requires that the ZXP be signed and time stamped. This provides consumers a level of assurance; they can trust that the producer and product have been verified by a trusted authority and that the product has not been tampered with.
    • If your product will be distributed free of charge, the ZXP can use a self-signed certificate.
    • If your product will be sold through Adobe Exchange, then we recommend that the ZXP be signed with a code-signing certificate from a trusted authority to increase the level of assurance for your consumers. See the section Obtaining a code-signing certificate

Packaging Tools

There are a various tools available that you can use to package your product as a ZXP, depending on how you have created the product and the complexity of your product.

  • Packager Utility: You can use the Adobe Exchange Packager utility if your product consists of any of the supported types of files that extend Adobe desktop applications. There are two packaging tools available:
  • Export Wizards: If you have created a panel using Configurator 4, or an Adobe Extension using Extension Builder 2, you can use the Export Wizards that are built into those tools to create ZXP packages that you can submit to Adobe Exchange. These tools build a manifest for you. See the sections Using Configurator and Using Extension Builder
  • Packaging and Signing Toolkit: If you have created your product using earlier versions of these tools, or the free Adobe Extension SDK, or if it is a script or C++ plug-in, or some combination of these things, you can manually create a manifest MXI file and package your delivery files into a ZXP, using the command-line utility in the Packaging and Signing Toolkit. See the section Packaging Manually

This figure provides an overview of the tools and procedures you can use to create a ZXP package that you can submit to Adobe Exchange, depending on how you have created your product and what kinds of files it contains.



Specific ZXP requirements for Adobe Exchange products


Adobe Exchange has a number of specific requirements for ZXP packages. If the package you produce does not meet these requirements, the Producer Portal does not accept the upload.

  • The ZXP must be signed with either a self-signed or commercial certificate. A commercial certificate is recommended for paid products.
  • The bundle ID of your product must be unique across all the products on Adobe Exchange. In order to ensure uniqueness we recommend that you use the convention “com.mycompany.myproduct” for your bundle ID.
    • The bundle ID value must be alphanumeric, and can contain dot “.” and dash “-”, but no spaces or other special characters.
    • The bundle ID for the trial and paid versions of your product should match.
    • For an Extension Builder product, the bundle ID is specified by the ExtensionBundleId attribute of the ExtensionManifest tag.
    • For an MXI manifest, the bundle ID is specified by the id attribute of the macromedia-extension tag.
    • If you use an MXI manifest, the name of the MXI file must match the bundle ID; that is, “com.mycompany.myproduct.mxi”
  • The product version value must follow the convention of three dot-separated integers, “major.minor.patch”; for example, “1.0.0”.
    • For a trial version of your product, the version value must be of the form “major.minor.patch.trial”; for example, “1.0.0.trial”.
    • If you do not specify a patch number in the first upload, the .0 patch number is appended automatically. Subsequent patches to this product must follow the correct structure.
    • Subsequent patch uploads must have a higher patch number than the latest patch in the system, and currently cannot exceed 99.
  • The product must support CS6 or CC versions of Creative Suite applications. Products that support earlier versions are not accepted.
  • If you choose to include an End-User License Agreement (EULA) in your product, it must be formatted as HTML in order to display properly in Adobe Exchange and Extension Manager. You can preview how this will appear once it is uploaded in the in-app panel in the Producer Portal’s preview mode. See Default template EULA



Obtaining a code-signing certificate


There are two types of code-signing certificate: commercial certificates provided by a trusted certificate authority, and self-signed certificates. Commercial certificates must be purchased from a trusted certificate authority. Self-signed certificates can be created free of charge using Configurator 4 or Extension Builder 2, as described above. Both types of certificate can be used to sign ZXP files that will be distributed as free products on Adobe Exchange. It is recommended that paid products be signed with a commercial certificate.

The p12 certificate file that you provide with your ZXP package must contain all of the certificates in the certification chain; that is, certificates for the developer, issuer, and root certificate authority.

The following vendors can provide a commercial code-signing certificate that is suitable for signing ZXPs to be distributed as Adobe Exchange paid products. Contact one of these vendors directly to purchase a code-signing certificate. Submissions signed with other types of certificate may not be accepted by Adobe Exchange.

Comodo certificate troubleshooting

If you encounter problems using a Comodo-created certificate in Extension Manager, re-export the certificate as a PFX in Internet Expolorer, then rename it to .p12.

Here’s how to do that:

1. In the Internet Explorer tools menu, choose Internet options.
2. In the Internet Options dialog, select the Content tab and click Certificates.
3. In the Certificates dialog, locate the signing certificate (probably listed under Personal), select it and click Export.
4. In the wizard, select Yes, export the private key, and when asked to select a format, choose PKCS #12 (.PFX).
5. Check the box “Include all certificates in the certification path if possible”, and then choose a password.
6. Rename the exported PFX file to “p12” in order to use it with the ZXPSignCmd tool (along with your new chosen password).



The Adobe Exchange Packager Utility


This standalone tool is intended to provide an easy and intuitive way to collect all of the information needed to package a product to be installed by Adobe Extension Manager. You can download the Packager Utility from the Adobe Exchange resources page

System requirements

  • 512MB of RAM (1GB recommended)
  • JRE 1.6 or higher
  • Mac OS X v10.6 or v10.7 with Intel Core Duo or faster processor
    - or -
  • Windows Vista® Home Premium, Business, Ultimate, or Enterprise (including 64-bit editions) with Service Pack 2; or Windows 7, with 2.33GHz or faster x86-compatible processor or Intel® Atom® 1.6GHz or faster processor for netbooks

Supported file types

You can use Packager if your product includes the following types of files that can extend CS6 applications:

  • Illustrator
    • Actions (AIA)
    • Brushes, Graphic Styles, Symbols (AI)
    • Scripts (JSX)
    • Swatches (AI, ASE)
    • Templates (AIT)
  • Dreamweaver
    • Behaviors, Commands, Server Behaviors (folder of HTM and JS)
    • Snippits (CSN)
  • Flash
    • Behaviors, Data types, Encoders,Formatters, Kinds, Motion Presets, Publish Profiles (XML)
    • Libraries (SWC)
    • Scripts (JSX)
    • Templates (FLA)
  • Fireworks
    • Color books (ACB)
    • Libraries, Patterns, Templates (PNG)
    • Textures (PNG, JPG)
  • InDesign
    • Buttons (INDL)
    • Motion Presets (XML)
    • Scripts (JSX, JSXBIN)
    • Swatch Libraries (ACB, ASE)
    • Templates (INDT)
  • Photoshop
    • Actions (ATN)
    • Brushes (ABR)
    • Gradients (GRD)
    • Patterns (PAT)
    • Scripts (JSX)
    • Swatches (ACO, ASE)

Using Adobe Exchange Packager

  • Click Create New Package on the welcome screen to get started.

  • On the next screen, enter your basic package information.

The Name, BundleID, Version, and Author are required. You can also add a Description, and an End-User License Agreement (EULA). A EULA template is included below for your convenience. If you chooseto make use of the template, replace the placeholder text in square brackets with appropriate text for your organization.

  • Click Next to add the files that make up your product.

You can use the Add files and Add a directory buttons, or drag and drop files or folders from the file system.

  • Click Certificate and Settings to specify Certificate information.

If it is installed in the default location, the Java installation location is filled in automatically. If not, browse to the installation location or type in the path. In Mac OS, Java is installed in a hidden folder, typically /usr/bin/java.
On this screen, you can uncheck the Remember checkbox if you don’t want Packager to remember your settings by default.

You can browse to an existing certificate, or create a new one. Any product that you intend to offer for sale through Adobe Exchange be signed, using a code-signing certificate from a trusted authority. See Obtaining a code-signing certificate. For free products or for testing, you can click Create to create a self-signed certificate.

  • When you have created or specified a certificate, and specified all of the files to be included, click Package. Browse to or enter the path where you want the ZXP file to be saved. The location must be outside the folder that contains your product resources.

PackageSuccess

Test the resulting ZXP file by installing it in the host application using Adobe Extension Manager. If it is all correct, you can use this file as part of your product submission to Adobe Exchange.



Using the Online Packager


An online packaging utility is available as part of the product-creation process. After you have supplied the Product Details for your new product, the Upload Product section of the New Product page allows you to either upload an existing package or file, or create a new package:

When you choose “Create a new package (ZXP)”, use the Add files and Add a directory buttons, or drag and drop files or folders from the file system. The acceptable file types and procedure are exactly the same as when you use the standalone tool.

To add a Lightroom Plugin package using the Online Packager, you must first zip the package, keeping your package’s internal folder structure intact. For example, “myplugin.lrplugin” becomes “myplugin.lrplugin.zip”. The Online Packager automatically unzips “.lrplugin.zip” files before adding them to the ZXP, providing a seamless installation experience for your users.


Troubleshooting for Adobe Exchange Packager

If Packager fails to package your files:

  • Check that your certificate password is correct in the settings. Reset your password and try packaging again.
  • Make sure that the geotrust website is not down. You can do this by pinging timestamp.geotrust.com. If the site does not respond, wait until you get a response and try packaging again
  • Check that Adobe Packager can recognize the Java path, especially in Mac OS. It is usually /user/bin/java



Using Configurator 4 to create products for Adobe Exchange


Configurator 4 includes a tool for exporting the panels you build as ZXP packages that you can submit to Adobe Exchange. If you have a paid subscription for Adobe Exchange, you can download Configurator 4 from the resources page.

  1. When you have designed a panel, choose File > Export Panel as CS Extension.
  2. You must have a Java Runtime Engine (JRE) installed in order to create the package. If it is installed in the default location, the Java installation location is filled in automatically. If not, browse to the installation location or type in the path. In Mac OS, Java is installed in a hidden folder, typically /usr/bin/java.
  3. Choose a location to write the ZXP package file. The location must be outside the folder that contains your product resources.
  4. A CS Extension requires a signed certificate; if you plan to submit it to Adobe Exchange, it must also be time-stamped. If you already have one, you can browse to it and provide the password (less than 32 characters). Otherwise, click Create to a create a new certificate.
  5. When you complete all fields and click Export, Configurator creates the package and writes the package file, panel_name.zxp, to your chosen export folder.
  6. You can test the package by opening the target application and installing the panel with Extension Manager.



Using Extension Builder 2 to create products for Adobe Exchange


Extensions that you create using Extension Builder are based on the CEP infrastructure, and are intended for deployment with the Adobe Extension Manager. Extension Builder 2 includes an Export wizard that makes it easy to build ZXP packages that are compliant with Adobe Exchange.

If you have a paid subscription for Adobe Exchange, you can download Extension Builder from the Adobe Exchange resources page. The tool includes extensive documentation and instructions for exporting projects to the ZXP format.

Creating a ZXP for your Adobe Extension

When you export your extension with the Export Wizard, it creates a manifest file for you (the file manifest.xml in your project) and creates the ZXP package.
You can edit the manifest file directly, if necessary, or you can use the Extension Builder’s Bundle Editor. You must make sure that the manifest values conform to all Adobe Exchange specific requirements

  • The extension must support a valid CS6 or CC host application. If your product supports a range of versions, make sure that the version for the corresponding CS6 or CC application is included. The version tag for supported host applications should match one of the following:
   <HostList>
      <Host Name="FWKS" Version="12.0" />   (CS6 only)
      <Host Name="ILST" Version="16.0|17.0" />
      <Host Name="PHXS" Version="13.0|14.0" />
      <Host Name="FLPR" Version="12.0|13.0" />
      <Host Name="PHSP" Version="13.0|14.0" />
      <Host Name="DRWV" Version="12.0|13.0" />
      <Host Name="IDSN" Version="8.0|9.0" />
      <Host Name="AICY" Version="8.0|9.0" />
      <Host Name="PPRO" Version="6.0|7.0" />
      <Host Name="PRLD" Version="1.0|2.0" />
   </HostList> 
  • If your product supports a range of versions, make sure that the version for the corresponding CS6 or CC product is included.

Example of a well-formed manifest file

<?xml version="1.0" encoding="UTF-8"?>
<ExtensionManifest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Version="2.0" 
       ExtensionBundleId="com.example.productX" ExtensionBundleVersion="1.0.0">
   <ExtensionList>
      <Extension Id="com.example.productX.ProductX" Version="1.0.0"/>
   </ExtensionList>
   <ExecutionEnvironment>
      <HostList>
            <Host Name="ILST" Version="16.0"/>
      </HostList>
      <LocaleList>
         <Locale Code="All"/>
      </LocaleList>
      <RequiredRuntimeList>
         <RequiredRuntime Name="CSXS" Version="2.0"/>
      </RequiredRuntimeList>
   </ExecutionEnvironment>
   <DispatchInfoList>
      <Extension Id="com.example.productX.ProductX">
         <DispatchInfo>
            <Resources>
               <SwfPath>./tester.swf</SwfPath>
            </Resources>
            <Lifecycle>
               <AutoVisible>true</AutoVisible>
            </Lifecycle>
            <UI>
               <Type>Panel</Type>
               <Menu>ProductX</Menu>
               <Geometry>
                  <Size>
                     <Height>200</Height>
                     <Width>200</Width>
                  </Size>
               </Geometry>
            </UI>
         </DispatchInfo>
      </Extension>
  </DispatchInfoList>
</ExtensionManifest>



Using the Packaging and Signing Toolkit


You can use the Packaging and Signing Toolkit to package and sign content manually. The tools and documentation you need can be downloaded here:
http://www.adobe.com/devnet/creativesuite/sdk/eula_cs6-signing-toolkit.html.

To package content as an extension, you must create the MXI manifest file, save it next to a folder that contains the extension resources, and run the UCF command-line utility. You can package any kind of content, such as new brushes or fonts that you have created or C++ plug-ins that use an application SDK, by creating a manifest (an MXI file) and building the ZXP package with the command-line tool.

Creating an MXI manifest

You must create an MXI manifest file that specifies the contents of your package. MXI is an XML schema; complete schema details of the MXI format are part of the Toolkit documentation, in the MXI Technical Note. You must make sure that your manifest values conform to all Adobe Exchange specific requirements

  • Adobe Exchange requires that the name of the MXI manifest file match the bundle name for the extension. For example, if your bundle name is com.mycompany.myproduct, the name of the MXI file must be com.mycompany.myproduct.mxi. This match is not case-sensitive. If you try to upload a ZXP package that does not satisfy this constraint, Adobe Exchange reports an error.
  • The extension must support a valid CS6 or CC host application. If your product supports a range of versions, make sure that the version for the corresponding CS6 or CC application is included. The version tag for supported host applications should match one of the following:
   <HostList>
      <Host Name="FWKS" Version="12.0" />   (CS6 only)
      <Host Name="ILST" Version="16.0|17.0" />
      <Host Name="PHXS" Version="13.0|14.0" />
      <Host Name="FLPR" Version="12.0|13.0" />
      <Host Name="PHSP" Version="13.0|14.0" />
      <Host Name="DRWV" Version="12.0|13.0" />
      <Host Name="IDSN" Version="8.0|9.0" />
      <Host Name="AICY" Version="8.0|9.0" />
      <Host Name="PPRO" Version="6.0|7.0" />
      <Host Name="PRLD" Version="1.0|2.0" />
   </HostList> 
  • For a product that supports Illustrator, the MXI must include a Product tag with no name attribute, and with the attribute familyname set to “Illustrator”.
  • For a product that supports Photoshop/Photoshop Extended, the MXI must include a Product tag with no name attribute, and with the attribute familyname set to “Photoshop”.

Example of a simple valid MXI file

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<macromedia-extension name="com.example.ProductX" id="com.example.ProductX" requires-restart="true" version="1.0.0">
   <author name=""/>
   <description/>
   <license-agreement/>
   <products>
      <product maxversion="8" name="InDesign" primary="true" version="8.0"/> 
      <product familyname="Illustrator" maxversion="16.1" primary="true" version="16.0"/>
      <product familyname="Photoshop" maxversion="13.1" primary="true" version="13.0"/>    
   </products>
   <files>
      <file destination="" file-type="CSXS" products="" source="SomeProduct.zxp"/>
   </files>
</macromedia-extension>

Using the UCF command

A typical command to package an extension might look like this:

cd /User/me/myPanelStaging 
java -jar ucf.jar -package -storetype PKCS12 -keystore myCert.p12 -storepass mypasswd -tsa https://timestamp.geotrust.com/tsa myExtension.zxp -C ./myExtension .

where:

  • ucf.jar is the version contained within the Packaging and Signing Toolkit
  • myCert.p12 is your P12 certificate
  • mypasswd is the password for your certificate
  • https://timestamp.geotrust.com/tsa is the time stamping server you are using. To be accepted by Adobe Exchange, your product’s signature must be time stamped; that is, you must supply the “-tsa” parameter with a valid time-stamp authority.
  • myExtension.zxp is the name of the ZXP file you want to create. You can specify the destination path here; the destination must NOT be in the folder that contains your assets.
  • ./myExtension is the relative path to the folder containing your assets
  • The dot “.” at the end of the command is required. It enables recursive processing of the folder contents.


Example: Packaging a Mac OS APP file

  • Create a stage folder. For example, /Users/me/PackageAppDemo
  • Create a sub folder and place the .app file in it. For example, /Users/me/PackageAppDemo/content/HelloAgora.app
  • Create an MXI file that lists the .app file. For example:
    <files>
        <file source="content/HelloAgora.app" file-type="ordinary" products="" 
                      platform="mac" destination="$indesign/Plug-Ins/Agora"/>
    </files>
  • Save the MXI file into the stage folder, next to the content folder. The MXI file name must match the id tag value in the file.
  • Run the UCF command-line tool from the stage folder:
cd  /Users/me/PackageAppDemo

java -Djsse.enableSNIExtension=false  -jar /path/to/ucf.jar  -package -storetype pkcs12 
     -keystore /path/to/certificate/myCert.p12 -storepass myPass 
     -tsa https://timestamp.geotrust.com/tsa /Path/to/outputfolder/HelloAgora.zxp 
     -C /Users/me/PackageAppDemo/ .


Example: Adding a file to a ZXP created by Configurator

Suppose you want to add a file, such as a readme, to a package that you created using Configurator.

  1. Place the signed ZXP created by Configuator and the readme file in a folder together.
  2. Create an MXI manifest file that references to both the ZXP and the readme file, and specifies the location where you want them installed.
  3. Run the UCF command-line utility to repackage the panel together with the readme file and a code-signing certificate.


Example: Signing or converting an existing package

Suppose you have an existing ZXP file that does not have a time-stamped signature, or an existing MXP package that you want to convert to ZXP.

  1. If you have an MXP package, use Extension Manager to convert it to an unsigned ZXP.
  2. To sign the unsigned ZXP package, convert the ZXP to a ZIP file by changing the extension.
  3. Open the ZIP archive and remove the files “meta-inf” and “mimetype”, if they exist.
  4. Create an MXI manifest file that references the ZIP file (or the folder to which you have extracted it) as the package contents.
  5. Run the UCF command-line utility to repackage the contents together with a code-signing certificate.


Creating a non-product-specific package

It is possible to package up files to be installed by Extension Manager in non-product-specific locations. You might do this, for instance, in order to package profiles or resources to be used by multiple extensions.
You can create a package to be installed in any location that you can specify in the MXI manifest using system locations for which there are global tokens. For example:

$system
$fonts
$userhomefolder
$userdatafolder
$shareddatafolder

For the latest complete list of these tokens and their values in Mac OS and Windows, see Path tokens.

Extension Manager requires, however, that any package it manages must install at least one file in a product-specific destination. To satisfy this constraint, you can include in your assets a dummy file (that is, an empty file) to be installed in a product-specific location such as $indesign/Scripts.



Troubleshooting packaging errors


These are some error messages you might encounter when submitting a ZXP file to Adobe Exchange, with suggestions about how to remedy the problems they indicate. When you encounter one of these errors, the file is not uploaded or processed. You must correct the error and submit a new ZXP

Illegal element in signature

There is something unexpected in the ZXP signature file. Submit a new ZXP with a properly formed signature.

Root element isn’t “signatures”

The signature section of the ZXP does not have “signatures” as a root element. Submit a new ZXP with a properly formed signature section in the manifest.

No Manifest section found in signature file

The signature file of the ZXP does not have a recognizable manifest section. Submit a new ZXP with a properly formed manifest section in the signature file.

Invalid zxp file

The submitted ZXP file does not meet the required format. Submit a new ZXP that conforms to the format.

No reference for file

The ZXP contains a file in the package that is not referenced in the manifest. Submit a new ZXP that properly references the file.

Couldn’t find file in zxp

The ZXP references a resource file that cannot be found in the package. Submit a new ZXP that contains the missing resource.

Missing or unsupported digest method for xx

There is no digest method for a resource file referenced in the ZXP. Submit a new ZXP that contains a digest method for the file type.

Missing digest value for xx

There is no digest file for a resourse file referenced in the ZXP. Submit a new ZXP that contains a digest file for the resource.

Digest mismatch. Expected xx

The decoding of a resource file in the ZXP did not match the expected decoding. Submit a new ZXP with a resource that can be decoded properly.



Frequently asked questions


Here are some answers to the frequently asked questions on packaging your product as ZXP for submission to Adobe Exchange:


I have a ZXP already, how do I get it signed with a timestamped signature?

Convert the ZXP to a ZIP file by changing the extension.
Open the ZIP archive and remove the files “meta-inf” and “mimetype” if they exist.
Use the UCF command-line tool to repackage the ZIP archive (or the folder to which it is extracted) with a code-signing certificate.


I have an MXP file, How do I convert it to ZXP?

Extension Manager lets you convert a MXP file to a ZXP file.
The resulting ZXP is not signed, so to submit it to Adobe Exchange, you must sign the ZXP manually, using the Packaging and Signing Toolkit.


I created a ZXP through Extension Manager, but Adobe Exchange complains that it is not signed.

Extension Manager does not create a signed ZXP. You must sign the ZXP manually, using the Packaging and Signing Toolkit.


How do I create a self-signed certificate?

You can use Packager or Configurator to easily create a self-signed certificate. See those sections:


Can I add a readme file to my Configurator panel ZXP?

Unfortunately, Configurator does not let you add additional files to the panel you create.
If you have create a fully signed ZXP from Configurator, you can manually unpack it, add the additional file to the MXI manifest file, and rebuild the ZXP.


How do I package a .app (Mac OS application) into a ZXP?

You can use the Packaging and Signing Toolkit to do this; the .app file is the file to be packaged.
Create an MXI manifest and specify the .app file as a resource in a file element:

    <files>
        <file source="content/HelloAgora.app" file-type="ordinary" products="" 
        	      platform="mac" destination="$indesign/Plug-Ins/Agora"/>
    </files>


How do I package my existing C++ plug-in into a ZXP?

Create an MXI manifest for the plug-in and use the UCF command-line tool to package and sign it.


How can I find out what path tokens are available?

For the latest complete list of path tokens and their values in Mac OS and Windows, see Path tokens.


How can I install files into a directory without a path token?

If there is no path token for the directory you want to install files into, you can define a custom token in your MXI file. For example, there is no path token for the Mac OS “/Applications” directory. Too add a custom token for that directory, add this XML to the MXI file:

<file-tokens>
   <token name="macAppFolder" definition="/Applications" />
</file-tokens>

<files>
   <file source="myFile" destination="$macAppFolder" platform="mac" />
</files>


How can I use Packager to package up stuff that is not product-specific?

Extension Manager requires that any package it manages must install at least one file in a product-specific destination.
If your content is all installed elsewhere, you can still satisfy this constraint by including in your assets a dummy file (that is, an empty file) to be installed in a product-specific location such as $indesign/Scripts.


My commercial certificate is not being accepted, what could the issue be?

Adobe Exchange only signs an extension if the p12 file contains all of the certificates in the certification path; that is, developer, issuer, and root certificate authority. When you export a certificate, you must be sure to export the entire certificate chain.


Can I use an Apple certificate to sign my extension?

Unfortunately not. The p12 file must contain all of the certificates in the certification path. Although you can convert an Apple certificate to a p12 file, it contains only one certificate (because it is marked as “not exportable”).


Is there a way to automate the creation and signing of a ZXP?

It is possible to automate the creation of your ZXP for upload to Exchange. There are many possible ways to do this; there is no single correct way. As a producer, you must evaluate your situation and use the tools that that work best for you. In general, you would use the Packaging and Signing Toolkit, and some mechanism to run the UCF command from the command line.

If you use a centralized repository for your source code, a continuous integration tool like Jenkins might be a good option to run the packaging command. You might also use an Ant script to package the ZXP. Alternatively, you could use Ant to gather your source files to a staging directory, and then run a target script such as the following to package the ZXP.

Here is a sample of an Ant build file that does the final packaging and code signing using the UCF command-line tool. This sample expects these folders under the one containing the build file:

  • The temp/ folder is a temporary build location
  • The lib/ folder contains the tools
  • The src/ folder contains the project assets
  • The bin/ is where output is written
<target name="sign">
<!--
first copy the files to a temp folder
-->
<copy overwrite="true" file="./MYMXI.mxi" todir="temp"/>
<copy overwrite="true" file="./src/MY-OTHER-FILE" todir="temp"/>
<!--
run ucf
-->
<java fork="true" jar="lib/signingtoolkit/ucf.jar" dir=".">
  <arg value="-package" />
  <arg value="-storetype" />
  <arg value="PKCS12" />
  <arg value="-keystore" />
  <arg value="src/YOUR-CERT.p12" />
  <arg value="-storepass" />
  <arg value="YOUR-PASS" />
  <arg value="-tsa" />
  <arg value="https://timestamp.geotrust.com/tsa" />
  <arg value="./bin/com.YOUR-EXTENSION.zxp"/>
  <arg value="-C" />
  <arg value="./temp/" />
  <arg value="." />
</java>
<!--
clear the temp folder
-->
<delete dir="temp"/>
</target> 


Using the command-line tool (UCF.jar) creates a temp file in my resulting ZXP.

When using the command-line tool, you must make sure the destination location for the created ZXP file is separate from the actual contents you want to package.


How do I package a Flash-based extension if I didn’t use Extension Builder to create it?

Create an MXI manifest for it and use the Packaging and Signing Toolkit to package it manually.



Consumer License Agreement Template


This is a template for an End-User License Agreement (EULA), that you can use to create a EULA for your product. When you associate a EULA with your product, users must agree to the terms before they can purchase or download the product.


1. Your Agreement With Developer.

1.1 This agreement is with [Developer Name] (“Developer”), and you agree, that your relationship with Developer will be governed by the laws of the state of [state where Developer is located], United States, as set forth in section 10.

1.2 By downloading a Product (defined below), you agree to the terms and conditions contained herein and You state that You have all legal rights and powers needed to give the statements, assurances and commitments in this document and to agree to it as a validly executed, legal instrument. It shall be binding on you and on Your heirs, executors and assigns.

1.3 Developer and its respective suppliers and licensors shall retain all right, title and interest in and to the Product and all portions thereof, including, without limitation, all Intellectual Property Rights thereto. Developer is solely responsible for performing, all installation, training, support, and other services requested or required for those Products you acquire through the Marketplace. By utilizing the Marketplace, you agree and acknowledge that Developer and Adobe are not liable for any Products which do not perform as advertised or stated, including but not limited to any liability related to compatibility with hardware or software.

1.4 Developer reserves the right to modify the Agreement accompanying the Product from time to time at its sole discretion.

2. Definitions. Unless otherwise defined, capitalized terms used throughout these General Terms have the meanings stated below:

2.1 “Product” means Developer extensions, application software, code, material, text, data and other works of authorship offered through the Marketplace (“Products”).?

2.2 “Payments” mean that any Product shall be handled in accordance with the applicable third party’s policies. By engaging in a transaction which utilizes a third party payment mechanism, You agree and acknowledge that Developer and Adobe shall not be liable for any damages or claims which are incurred as result of such transaction.?

2.3 “Marketplace” means those methods of distribution available via the Service.

3. Privacy Policy.
Please refer to Developer’s privacy policy as relates to the Product at: [Please provide URL of Developer Privacy Policy]

4. Warranties And Disclaimers.
Developer provides the Product “AS IS.” DEVELOPER, ADOBE, AND ITS SUPPLIERS MAKE NO EXPRESS, IMPLIED, OR STATUTORY WARRANTY OF ANY KIND WITH RESPECT TO THE PRODUCT, YOUR TRANSACTIONS, OR THOSE PRODUCTS OBTAINED THROUGH THE MARKETPLACE INCLUDING, BUT NOT LIMITED TO, ANY WARRANTY OF PERFORMANCE, MERCHANTABILITY, SATISFACTORY QUALITY, NONINFRINGEMENT, OR FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT WILL DEVELOPER, ADOBE, OR ITS SUPPLIERS BE LIABLE TO YOU OR ANY OTHER PARTY FOR ANY DAMAGES, EVEN IF DEVELOPER OR ANY COMPANY REPRESENTATIVE HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. YOU BEAR THE ENTIRE RISK AS TO THE USE OF THE PRODUCT, YOUR TRANSACTIONS ON THE MARKETPLACE, THE PRODUCTS AND ANY USE OF A THIRD PARTY PAYMENT MECHANISM. TO THE EXTENT AN IMPLIED WARRANTY CANNOT BE EXCLUDED, SUCH WARRANTY IS LIMITED IN DURATION TO THE EXPRESS WARRANTY PERIOD. BECAUSE SOME STATES OR JURISDICTIONS DO NOT ALLOW LIMITATIONS ON THE DURATION OF IMPLIED WARRANTIES, THE ABOVE LIMITATION MAY NOT APPLY.?THE USE OF THE MARKETPLACE, INCLUDING BUT NOT LIMITED TO YOUR TRANSACTIONS, AND THE DOWNLOADING AND/OR USE OF ALL PRODUCTS IS DONE AT YOUR OWN DISCRETION AND RISK AND WITH YOUR AGREEMENT THAT YOU WILL BE SOLELY RESPONSIBLE FOR ANY DAMAGE TO YOUR COMPUTER SYSTEM, LOSS OF DATA, OR OTHER HARM THAT RESULTS FROM SUCH ACTIVITIES. DEVELOPER ASSUMES NO LIABILITY FOR ANY COMPUTER VIRUS OR OTHER SIMILAR SOFTWARE CODE THAT IS DOWNLOADED TO YOUR COMPUTER OR DEVICE IN CONNECTION WITH YOUR USE OF THE MARKETPLACE, THE PRODUCTS OR YOUR TRANSACTIONS. NO ADVICE OR INFORMATION, WHETHER ORAL OR WRITTEN, OBTAINED BY YOU FROM DEVELOPER OR THROUGH OR FROM THE MARKETPLACE, THE PRODUCTS OR A THIRD PARTY PAYMENT MECHANISM SHALL CREATE ANY WARRANTY NOT EXPRESSLY STATED IN THE AGREEMENT. ANY AGREEMENTS ENTERED INTO WITH THIRD PARTIES ARE AT YOUR OWN RISK.?THE MARKETPLACE MAY INCLUDE TECHNICAL OR OTHER MISTAKES, INACCURACIES OR TYPOGRAPHICAL ERRORS. DEVELOPER MAY MAKE CHANGES TO THE PRODUCT AT ANY TIME WITHOUT NOTICE.

5. Limitation of Liability.
You shall, at your own expense, indemnify, defend and hold Developer harmless from and against any and all claims, costs, fees (including reasonable attorneys’ fees), damages, liabilities and expenses to the extent such claim arises out of: (a) any breach of this Agreement, (b) any claims or allegations made in connection with your use of a third party payment mechanism, © any breach or alleged breach of any representations and warranties made by a third party concerning any aspect of a Product, including but not limited to compatibility, (d) any claims made by or on behalf of any third party pertaining directly or indirectly to Your use of a Product, (e) any alleged or actual violation of your privacy or other rights by a third party, and (f) any allegations based on a product liability claim.

6. Indemnity.
TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, (A) IN NO EVENT WILL DEVELOPER BE LIABLE FOR ANY CONSEQUENTIAL, INDIRECT, EXEMPLARY, SPECIAL OR INCIDENTAL DAMAGES, INCLUDING WITHOUT LIMITATION ANY LOST DATA, LOST PROFITS AND COSTS OF PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES, ARISING FROM OR RELATING TO THIS AGREEMENT HOWEVER CAUSED AND UNDER ANY THEORY OF LIABILITY (INCLUDING NEGLIGENCE), EVEN IF DEVELOPER HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES; AND (B) DEVELOPER’S TOTAL CUMULATIVE LIABILITY ARISING FROM OR RELATED TO THIS AGREEMENT, WHETHER IN CONTRACT OR TORT OR OTHERWISE, WILL NOT EXCEED THE LESSER OF US$50 OR THE AMOUNTS RECEIVED BY DEVELOPER IN CONNECTION WITH THIS AGREEMENT DURING THE TWELVE (12) MONTH PERIOD PRECEDING THE EVENT GIVING RISE TO THE LIABILITY. You acknowledge that the fees and amounts payable set forth in this Agreement reflect the allocation of risk set forth in this Agreement and that the other party would not enter into this Agreement without these limitations on its liability. Each party agrees that these limitations shall apply notwithstanding any failure of essential purpose of any limited remedy. The foregoing limitations of liability are independent of any exclusive remedies for breach of warranty set forth in this Agreement. Some jurisdictions do not allow the exclusion or limitation of liability, so the above limitation or exclusion may not apply.

7. Export.
You acknowledge that the Products are subject to the U.S. export control and sanctions laws (including the Export Administration Regulations) (“Export Controls”) and that You will comply with the Export Controls. You will not export or re-export the Products, directly or indirectly, to, or use or provide (or enable any third party to use) the Products in connection with: (a) any countries that are subject to U.S. export restrictions (including, but not limited to, Cuba, Iran, North Korea, Sudan, and Syria), (b) any third party whom You know or have reason to know will utilize them in the design, development or production of nuclear, chemical or biological weapons, or rocket systems, space launch vehicles, and sounding rockets, or unmanned air vehicle systems, or © any third party who has been prohibited from participating in the U.S. export transactions by any federal agency of the U.S. government.

8. Release.
You will not hold Developer responsible for any damages, costs or liabilities of any kind arising out of or in connection with use of any Product, use of any third party payment mechanism, and You hereby release Developer, jointly and separately, from any and all such claims. If you are a California resident, you waive California Civil Code § 1542, which says: “A general release does not extend to claims which the creditor does not know or suspect to exist in his favor at the time of executing the release, which if known by him must have materially affected his settlement with the debtor.”

9. Counterparts; Entire Agreement.
This Agreement may be executed in counterparts, each of which will be considered an original, but all of which together will constitute the same instrument. This Agreement, together with any Exhibits hereto, constitutes the entire agreement between the parties regarding the subject hereof and supersedes all prior or contemporaneous agreements, understandings, and communication, whether written or oral.

10. Governing Law; Venue.
This Agreement shall be governed by the laws of the State of [Developer’s State], and the parties hereby irrevocably consent to jurisdiction and venue in the state and federal courts located in [Developer’s State] without regard to any conflicts of laws principles that would require the application of the laws of another jurisdiction. In any action or suit to enforce any right or remedy under this Agreement or to interpret any provision of this Agreement, the prevailing party shall be entitled to recover its costs, including, without limitation, reasonable attorneys’ fees. The United Nations Convention on Contracts for the International Sale of Goods does not apply to this Agreement.