Internally when we want to share code between multiple managed packages we do it in an unstructured way. Having used Nods.js's NPM recently, it seems that in comparison we in the Salesforce community are a long way behind on good ways to re-use Apex code (and other components) and I wonder why.

Do you already have good ways to do this internally or have you come across any good public mechanisms that are already available? More detail here Salesforce Packaged Modules – what do you think? as this question is likely to get closed for being broad/opinion based.

  • Fwiw, I started a GitHub where I'll be posting code publicly. Also, there are many others out there that have also done this.
    – sfdcfox
    May 24 '14 at 19:19
  • @sfdcfox Just wondering about a way to make such contributions more visible and avoid name collisions and allow one to layer upon another etc.
    – Keith C
    May 24 '14 at 22:01
  • Good question, though this type of question might be a better fit for chat, since I agree it's a bit broad, likely to result in opinions, and clearly not a meta question either. Posted link to this question on Salesforce.SE's chat.
    – blunders
    May 24 '14 at 23:32
  • This could definitely benefit from discussion and I'd love to know the results of that, but a discussion doesn't really fit here. Maybe move it to Meta, though not strictly for 'real' questions I don't want to lose this content. That said, I'm leaving this open because there is a definite answer to the actual question.
    – Matt Lacey
    May 25 '14 at 23:37

I've been building an installer for the Salesforce.com Foundation's upcoming release of NPSP 3.0 which can effectively handle installation/upgrade of dependent managed packages as well as bundles of metadata in a zip file (via a url). This definitely has made it a lot easier to deploy dependent managed packages along with unpackaged code which doesn't play nicely in a managed package. For example, NPSP 3.0 consists of 6 managed packages and 2 unpackaged bundles of metadata.

You can configure the dependencies for each individual version. We have versions setup automatically via a python script run by Jenkins after a new beta package or production package has passed testing.

The application uses oauth to the target org to do the deployments and will determine if it needs to install, upgrade, or uninstall/install (downgrade or beta "upgrade"). You can also set conditions based on metadata in the target org such as "deploy this package if there are no record types on opportunity".

However, it's definitely not without limits:

  1. It's not a mechanism for copying code between multiple packages, though I'm not sure that's the right approach for code re-use anyhow.

  2. It doesn't handle push upgrades of the unpackaged metadata bundles though you could send users to the installer app again to get the updated bundles installed in their orgs.

The whole project is up on Github at https://github.com/SalesforceFoundation/mrbelvedere and the installer related code is in the mpinstaller subdirectory. I'll be doing more work soon to make it more generic (i.e. strip out the Foundation branded theme) and document the setup process. The running instance of the installer is at https://mrbelvedere.salesforcefoundation.org/mpinstaller/npsp/beta if you want to try it against a fresh DE org.

Another option is to use ant to control the dependencies. I've built ant targets that handle the install/upgrade/uninstall logic for specific versions of a managed package. We use a version.properties file in the root of the repo to specify the package requirements: https://github.com/SalesforceFoundation/Cumulus/blob/dev/build.xml https://github.com/SalesforceFoundation/Cumulus/blob/dev/version.properties

For the unbundled metadata, the build.xml has targets to deploy each subfolder of unpackaged/pre and unpackaged/post as individual metadata bundles before and after the deployment of the main package (see the deployCI target for the sequence).

I really like the idea of using a config file in the repo to specify the dependencies as that allows for dependency changes to track with a feature branch. I've been doing some thinking about a format for that file but haven't really settled on anything yet.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.