6

As a Salesforce ISV, we are currently facing the following situation:

We have one managed package available as an application on AppExchange and we would like to propose a 'premium' version of our application providing additional features.

For that matter, we started to develop another managed package. This new package would partly rely on the same APEX code as our initial package.

We tried the Extension to managed package proposed by Salesforce, which makes the first package required to install the 'extension' package. This later would then be able to use the APEX code of the main package. But still, it is necessary to install both packages, even if you only need the features of the second one, which is not appropriate for some of our AppExchange customers. An idea has already been posted to simplify the installation process.

Do you see any other solution to use the same APEX code within two packages, apart from code duplication ? Any idea would be greatly appreciated.

| improve this question | | | | |
  • We have the same problem (also ISV). It would be nice to have at least an automated installation for all necessary base packages... Thanks for posting the IDEA link! – Nisse Knudsen Nov 27 '12 at 9:53
  • I reckon Base + Extension is the only way to do it today. – techtrekker Nov 27 '12 at 10:02
  • @Nisse, yes totally agree, when you truly want to support Checkout and/or ultra smooth subscriber driven install, extension packages do make this more difficult. The bindings between them also get quite hard to manage. – Andrew Fawcett Nov 27 '12 at 10:05
4

The straight answer is no, there is no package / jar / library concept in Apex like Java for example. All code must be in your package or accessible from other packages via the 'global' access modifier. Which as you points out creates a dependency users need to install.

That said if you are using source control management and Ant scripts, you can implement reuse between your packages upstream from them. Accepting that the code will eventually be duplicated in the packages, but ensuring you have only one place to maintain and manage them. Which is generally the main goal, even though the end result does not reflect that.

A couple of options exist between SVN (for example) and Ant.

  • SVN route, you could create a 'shared code' repo and utilise Externals, check out this link.
  • Ant route, you can build an Ant script that explicitly pulls in (via the SVN tasks for example) source from different locations prior to deploying to your development and/or packaging orgs.

Hope this helps!

P.S. Have you considered using Permission Sets (which in the future we hope will be licensable) to control your features for both types of users, standard and premimum, and thus having one package? Or if your worried about misuse, by standard users, implement some kind of Protected Customer setting to enable/disable those features? I say this as P.S. as of course your question does not relate to designing packaging strategies, but thought I would mention it, in case you are interested.

| improve this answer | | | | |
  • You're totally right we can use our SCM system (we use git) to avoid divergence of the code. However, it will not avoid heterogeneity in the installed packages: a user can have an old version of the first package and a recent version of the second one. The use of permission set is a brilliant idea, however it doesn't seem usable until LMA can manage how many users a given permission set is assigned to. Ideally, we want an organization to have (for instance) 10 licenses for the first package and 5 licenses for the second one. We didn't see another option that having two packages. But thank you! – Eric L. Nov 27 '12 at 13:21

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.