First-Generation Managed Packaging Developer Guide

Clouds with binary code floating aboveCloud with binary code floating above

No Results

Search Tips:

  • Please consider misspellings
  • Try different search keywords
First-Generation Managed Packages
Why Switch to Second-Generation Managed Packaging?
Register a Namespace for a First-Generation Managed Package
Create a First-Generation Managed Package Using a UI
Create a First-Generation Managed Package using Salesforce DX
Enable Dev Hub and Second-Generation Managed Packaging
Limited Access License for Package Developers
Add a Limited Access User to Your Dev Hub Org
Link a Namespace to a Dev Hub Org
Scratch Orgs and Package Development
Build and Release Your App with Managed Packages
Packaging Checklist
Deploy the Package Metadata to the Packaging Org
Create a Beta Version of Your App
Install the Package in a Target Org
Create a Managed Package Version of Your App
View Information About a Package
Components Available in First-Generation Managed Packages
Behavior of Specific Metadata in First-Generation Managed Packages
Package and Test Your First-Generation Managed Package
Update Your First-Generation Managed Package
Publish Upgrades to First-Generation Managed Packages
Manage Licenses for Managed Packages
Manage Features in First-Generation Managed Packages
AppExchange App Analytics for First-Generation Managed Packages
Developing and Distributing Unmanaged Packages
PDF

Deploy the Package Metadata to the Packaging Org

Before you deploy the package metadata into your packaging org, you convert from source format to metadata format.
It’s likely that you have some files that you don’t want to convert to metadata format. Create a .forceignore file to indicate which files to ignore.
  1. Convert from source format to the metadata format.
    sf project convert source --output-dir mdapi_output_dir --package-name managed_pkg_name
    Create the output directory in the root of your project, not in the package directory. If the output directory doesn’t exist, it’s created. Be sure to include the --package-name so that the converted metadata is added to the managed package in your packaging org.
  2. Review the contents of the output directory.
    ls -lR mdapi_output_dir
  3. Authenticate the packaging org, if needed. This example specifies the org with an alias called MyPackagingOrgAlias, which helps you refer to the org more easily in subsequent commands.
    sf org login web --alias MyPackagingOrgAlias
    You can also authenticate with an OAuth client ID: sf org login web --client-id oauth_client_id
  4. Deploy the package metadata back to the packaging org.
    sf project deploy start --metadata-dir mdapi_output_dir --target-org me@example.com
    The --target-org is the username. Instead of the username, you can use -u MyPackagingOrgAlias to refer to your previously defined org alias. You can use other options, like --wait to specify the number of minutes to wait. Use the --metadata-dir parameter to provide the path to a zip file that contains your metadata. Don’t run tests at the same time as you deploy the metadata. You can run tests during the package upload process.
    A message displays the job ID for the deployment.
  5. Check the status of the deployment.
    When you run sf project deploy report, the job ID and target username are stored, so you don’t have to specify these required parameters to check the status. These stored values are overwritten when you run sf project deploy start again.
    If you want to check the status of a different deploy operation, specify the job ID on the command line, which overrides the stored job ID.