function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion

Application with several editions

Short introduction: we want to separate our application to 3 editions, and one of them will have triggers and some specific pages, and another editions - no, so with such structure we cannot use one common application with some flag, that would identify the desired edition and change functionality (we don't want to add needless elements to package at all).

a) is it necessary to have 3 managed packages in our case? Or there is a better way?


b) and can we use one core(several Apex-classes) for different installed applications? Let's say user already has installed App_1, is it possible to install App_2, that will use some part of App_1's classes? Without creating new classes - duplicates(that will only have another namespace prefix).


You can request a feature known as partial packages, which allows you to create a package that has a dependency on another package. This way, you can have a Core module that all other packages will build upon, and then have them install the Core package plus any additional packages as they "upgrade." You will need multiple developer organizations, as each managed package takes over an entire developer organization's namespace.


I have a very similar question.  We are going to be offering multiple applications through the AppExchange with a considerable set of shared assets (custom objects, Apex classes, VisualForce pages, etc.).  As I understand it, this should be modeled as one managed package that is the common "shared library" and then one managed package extension per product that is built upon this common set of assets.  Each of these managed packages would have its own namespace.  Since any given org can produce only one managed package, that means that we would need one dev org for the common managed package and one dev org for each of the product managed package extensions.


Generally this seems reasonable, but it does raise a few questions/concerns.  The prescribed best practices for team development in have each individual contributor with a dev org that's populated using the Migration Toolkit and/or the IDE.  This is the model we've been using so far, but now that we've discovered that we need to produce more than one managed package, I'm concerned that it won't work well.


Let me give an example to make this concrete.  Let's say that in the common managed package we're going to have a custom object called "SharedBusinessObject__c", and let's say that the common managed package is going to be published with the namespace "common" (I know it needs to be more specific than that, but let's keep it simple in this example).  Now let's say that one of our products will be published with the namespace "product1", and it contains an Apex class that needs to reference "SharedBusinessObject__c".  Its reference to that object would take the form "common.SharedBusinessObject__c", and this would generally be hard-coded in the Apex source, e.g.:


List<common.SharedBusinessObject__c> objs = [select Id, Name from common__SharedBusinessObject__c];


If each developer has his or her own dev org per product (including the "common" product), I'm confused as to how this would work.  Today our ant build deploys the metadata into the build's sandbox dev org using the FMT, esentially as an unmanaged package.  Because of the way that downstream dependencies are going to be namespaced, though, I'm assuming that when "product1" is built, it will require "common" to be deployed as a managed package or it won't be able to resolve symbols like "common.SharedBusinessObject__c".


So the first question is whether there's a way to programmatically create and install a managed package as part of our automated build process.  I'd expect things to look something like:


  1. Deploy the metadata for "common" to the dev org, run unit tests, and verify sufficient code coverage.
  2. Create a managed package for "common" in the dev org.
  3. Undeploy the metadata for "common" from the dev org and install the managed package for "common" into that org.
  4. Deploys the metadata for "product1" to the dev org, run unit tests, and verify sufficient code coverage.
  5. Create a managed package for "product1" in the dev org.
  6. Undeploy the metadata for "product1" from the dev org and install the managed package for "product1" into that org.
  7. Run integration tests via something like Selenium against the fully-deployed "product1" instance.

Is this possible?


The second question is how this will work with a dev org per developer per product/managed package.  My understanding is that once an org has claimed a namespace, it's no longer available for any other org.  As a result, I don't see how two developers with two different sets of sandbox dev orgs could follow the steps above even if they're possible.  If each sandbox used a unique namespace, perhaps a concatenation of the developer's unique ID and the desired namespace (e.g., "username1common" and "username1product1"), the static references in Apex, SOQL, VisualForce, etc., wouldn't be correct.  Does the sandboxed team development model not work if you're publishing more than one managed package, or perhaps you have to take a repository-like approach where you can't install the "common" managed package from a local build but instead have to install it from the org that is actually associated with the final namespace?


Are there other ISVs out there that are building multiple products with shared underpinnings who have already tackled these issues?  Any help is GREATLY appreciated!!!



Each developer org may only have one namespace for all time; it is immutable, and that namespace is owned by that developer org. The correct process isn't as you've described, but instead runs along as follows:


  1. Create a developer org with the 'common' namespace.
  2. Create all the components necessary for the 'common' namespace, create a managed package, and upload a version of this for installation.
  3. Create a developer org with the 'product1' namespace.
  4. Install the 'common'  package into this organization.
  5. Create all the components necessary for the 'product1' namespace, create a so-called 'partial' managed package, and upload a version of this package for installation.

At this this point, you'd repeat steps 3 through 5 for each additional namespace you're using.


There's really not a programmatic way to automate the entire process, because you have to install the managed package for each instance that's going to build off of it. Eventually, I think we're going to have 'push updates' for managed packages, where you'll simply click upload on a managed package and each organization using it will automatically get the latest version. This would eliminate even an Eclipse IDE-style update. At least, I hope that would go there eventually...


Thanks for the reply!  Okay, so that was one of my suspicions, basically that our dev sandboxes for "common" will work fine because there won't be any references to namespaced symbols, and our dev sandboxes for "product1" will need to have "common" installed as a managed package explicitly/manually.  This means that if someone is working on functionality that cross-cuts both, we'll need to have a fast and easy way to generate that managed package, I assume.  It also means that development becomes a little single-threaded around the dev org that creates the "common" managed package.  Hmmmm....this is going to be pretty cumbersome.


Anyway, thanks so much again for the reply.  I think this warrants some additional thought.  Hopefully there's some reasonable workaround for us to be a little more productive than this process would allow.