Support of extension packages development

Issue #1718 resolved
Констатин Афанасьев created an issue

In our project, we develop an extension to a Managed Package.
This extension is a regular and separate Managed Package that can be installed after the main Managed Package.
The main and extension have different namespaces.The main Managed Package official namespace is REVVY. The extension official namespace is REVVYLS.
The main and the extension are in different repositories.
This extension can refer to code from the main Managed Package (call his methods, use his Objects, extend his classes, etc…).

On our staging development ‘orgs' we deploy the main and the extension as Unmanaged Packages for development purpose.And our development ‘orgs' have different namespaces from the ‘org’ which is used to assemble packages for customers (different from official namespace). When I write code of the extension in the IDE → I need to see metadata (Objects, Classes, VF pages, etc…) from the main package by typing its namespace and ‘dot’. But Illuminated Cloud allows this only by referring to my personal dev ‘org’ namespace, no to official namespace.

I tried to create a workaround inside open project with extension by selecting official namespace from the main package. But in this case I see only metadata which belongs to extension only.

We have mature project with official namespace usage in many places and I can’t use autocomplete and code inspection at all.

Official response

  • Scott Wells repo owner

    Okay, great. This is one of those semi-undocumented things, but I've used it extensively on two major projects alongside numerous team members (as many of 30-40 in one case), and I've helped another half dozen or so folks set it up. Here are some instructions I provided a few times (not for scratch org dev unfortunately):

    As far as setting up IC for multi-package development, here are a few additional tips (assuming two packages in a base/extension relationship)

    1. Create two development packages in your dev org, one for the base package content and one for the extension package content. Make the base package a managed package (you're not really ever going to upload it, though).
    2. Get a namespace for your org that's a variant of the official namespace for your base package. Our convention is <dev-initials><official-namespace>, e.g., "scwfoo" for my dev org where the official base package namespace is "foo".
    3. In Illuminated Cloud, set up one module for your base package source and another for your extension package source. Both will use the same connection to the org configured in the steps above. Configure the extension package module as a dependency of the base package module (this is standard IntelliJ module dependency config).
    4. Retrieve the organization namespace in the connection configuration screen using the Test button, or if you're in a source format module, make sure it's set in your sfdx-project.json file.
    5. Use Illuminated Cloud>Configure Project to open the project configuration dialog. Associate your base package source module with the base development package and your extension package source module with the extension development package.
    6. Enter the official namespaces for the base and extension packages in the respective rows of that table. This will allow the automatic translation on deployment and retrieval to work properly. It should look something like:

      Issue_1718.png

    7. Click OK to save those changes.

    8. Generate the OST for the connection.

    Once that's done (hoping/assuming I haven't left out any major steps), your local source should always use the official namespaces when qualifying Apex classes, SObjects/fields, custom VF components, etc., in the extension package source files. IC will automatically translate those to the organization namespace on deployment and back on retrieval before showing the comparison window. IC will also automatically add namespace prefixes for completions when referencing base package Apex classes and SObjects/fields from extension package source.

    Important: Salesforce will sometimes strip out what it perceives to be unnecessary namespace qualifications when retrieving metadata. I REALLY wish they wouldn't modify the source code that I send up, but they do. As a result, sometimes the retrieved source may not be 100% correct for the real-world packaging orgs. In the past I've augmented our build scripts to fix this, but I haven't put that logic into Illuminated Cloud since very few customers are currently using this development model. I still think the efficiency gains of this model FAR outweigh the diligence when retrieving and merging changes, but I want to warn you about this current omission.

    Let me know how far you get based on this description and I'll be happy to help with anything that's not clear or working as expected/described.

Comments (8)

  1. Scott Wells repo owner

    Assuming these are first-generation managed packages, I can probably provide a nice solution for you. Also, are you using Illuminated Cloud with IntelliJ IDEA or one of the other JetBrains IDEs? That makes a difference because the solution I can provide is based on modules which are only supported in IntelliJ IDEA.

  2. Констатин Афанасьев reporter

    Hello @Scott Wells !
    Yes, we have first-generation managed packages.
    I’m using Intellij IDEA Ultimate.

  3. Scott Wells repo owner

    Okay, great. This is one of those semi-undocumented things, but I've used it extensively on two major projects alongside numerous team members (as many of 30-40 in one case), and I've helped another half dozen or so folks set it up. Here are some instructions I provided a few times (not for scratch org dev unfortunately):

    As far as setting up IC for multi-package development, here are a few additional tips (assuming two packages in a base/extension relationship)

    1. Create two development packages in your dev org, one for the base package content and one for the extension package content. Make the base package a managed package (you're not really ever going to upload it, though).
    2. Get a namespace for your org that's a variant of the official namespace for your base package. Our convention is <dev-initials><official-namespace>, e.g., "scwfoo" for my dev org where the official base package namespace is "foo".
    3. In Illuminated Cloud, set up one module for your base package source and another for your extension package source. Both will use the same connection to the org configured in the steps above. Configure the extension package module as a dependency of the base package module (this is standard IntelliJ module dependency config).
    4. Retrieve the organization namespace in the connection configuration screen using the Test button, or if you're in a source format module, make sure it's set in your sfdx-project.json file.
    5. Use Illuminated Cloud>Configure Project to open the project configuration dialog. Associate your base package source module with the base development package and your extension package source module with the extension development package.
    6. Enter the official namespaces for the base and extension packages in the respective rows of that table. This will allow the automatic translation on deployment and retrieval to work properly. It should look something like:

      Issue_1718.png

    7. Click OK to save those changes.

    8. Generate the OST for the connection.

    Once that's done (hoping/assuming I haven't left out any major steps), your local source should always use the official namespaces when qualifying Apex classes, SObjects/fields, custom VF components, etc., in the extension package source files. IC will automatically translate those to the organization namespace on deployment and back on retrieval before showing the comparison window. IC will also automatically add namespace prefixes for completions when referencing base package Apex classes and SObjects/fields from extension package source.

    Important: Salesforce will sometimes strip out what it perceives to be unnecessary namespace qualifications when retrieving metadata. I REALLY wish they wouldn't modify the source code that I send up, but they do. As a result, sometimes the retrieved source may not be 100% correct for the real-world packaging orgs. In the past I've augmented our build scripts to fix this, but I haven't put that logic into Illuminated Cloud since very few customers are currently using this development model. I still think the efficiency gains of this model FAR outweigh the diligence when retrieving and merging changes, but I want to warn you about this current omission.

    Let me know how far you get based on this description and I'll be happy to help with anything that's not clear or working as expected/described.

  4. Scott Wells repo owner

    Hi. It looks like you posted and then perhaps deleted a comment on how to add modules. I assume you found out how to do so?

  5. Log in to comment