Apex Code Development You need to sign in to do that
Don't have an account?
dfc Shared Code Across Packages
If I understand the other postings correctly, if we are an ISV building 5 related but stand-alone applications we need 5 separate DE orgs, one for each application/managed package.
Here's the problem: What if there are shared custom objects and Apex classes that all 5 applications use? A given customer may have 1, 2, 3, 4, or 5 of the applications installed. Does not the prepending of each DE namespace result in redundant code for the shared objects and Apex classes? Also, how would you prevent the creation of up to 5 tables for an effectively identical custom object when you really want all five applications reading and writing to the same single table via the same page, controllers, object, etc?
Said another way, how do you separate and reuse cross-application architectural code and the applications that use it in a multi-application, managed-package environment?
Thanks!
Dave
Hi Dave,
If you plan to release multiple apps as managed packages that shared common architecture, then the recommendation is to use extension managed packages. The idea here is that you have 1 base Managed Package that houses the objects/apex that you know is shared across all of your apps. You then install this core Managed Package into other DE orgs and build Manged Package Extensions. This way you can reuse functionality, rather than recreating it.
Hope that helps,
Sati
All Answers
Hi Dave,
If you plan to release multiple apps as managed packages that shared common architecture, then the recommendation is to use extension managed packages. The idea here is that you have 1 base Managed Package that houses the objects/apex that you know is shared across all of your apps. You then install this core Managed Package into other DE orgs and build Manged Package Extensions. This way you can reuse functionality, rather than recreating it.
Hope that helps,
Sati
I haven't done this for real myself, but this is how I understand that it would be done. To write 5 managed-released apps that share common code, you need (at least) 6 DE orgs. The first org should contain the common code that you need to share between all the 5 apps. Release the first org's code as a managed-released package, with its own prefix (for example prefix0__). This package can be a private listing if you wish.
Now install that package into each of the other 5 DE orgs. Write one app in each of the 5 orgs. Each of the 5 apps will be an extension of the 'prefix0__' package. When you publish the apps from each of the 5 orgs, the SFDC packager will automatically package the 'prefix__0' package along with the 5 app packages. Thus all 5 will share the same common code with the same common prefix. At the same time the code specific to each of the 5 apps will have it's own prefix ('prefix1'-'prefix5').
Because each of the 5 apps uses the same namespace prefix for the common code, you will not have up to 5 of the same tables created. They will share the same table.
There is one 'challenge' in this approach that I have seen mentioned on the forums, which I am not sure is fixed, so you might want to check this. Basically there used to be a problem that if you have a custom field/object installed from one package, then you install another package that contains the same object/field, the installation can fail because the object/field already exists. Can someone from SFDC comment on whether this is still an issue please?
Extensions are by reference not by value. Or put another way, the extension just contains a reference saying it requires the base package to be installed. The extension does not contain all of the base package's components.