• sandyb
  • NEWBIE
  • 0 Points
  • Member since 2012

  • Chatter
    Feed
  • 0
    Best Answers
  • 0
    Likes Received
  • 0
    Likes Given
  • 2
    Questions
  • 1
    Replies

I am starting to learn more about managed packages, and if I'm understanding things correctly only one managed package is allowed per developer organization. Therefore if I had two applications that shared some common code and I wanted to be able to sell them separately, one way to set things up would be as follows:

 

Approach 1

-----------------

1) Create a dev org which contains a managed package containing common shared code and config -- namespace BASE.

2) Create a dev org which contains a managed package containing code and config specific to app1 -- namespace APP1. APP1 has classes that inherit from and use classes and config contained in BASE.

3) Create a dev org which contains a managed package containing code and config specific to app2 -- namespace APP2. APP2 has classes that inherit from and use classes and config contained in BASE.

 

Advantages: There is no dual maintenance of code since functionality is cleanly delineated into separate packages. APP1 and APP2 can be installed and sold independent of one another.

Disadvantages: During development, if changes occur in BASE those changes will need to be pushed into the APP1 and APP2 dev orgs. When installing from the app exchange, users will need to be sure to install BASE before installing APP1 or APP2. Developers may find that functionality originally developed in BASE really belongs in an APP (or vice versa), requiring refactoring.

 

Approach 2

-----------------

1) Create a dev org which contains managed package code and config for BASE, APP1 and APP2 combined.

 

Advantages: addresses all the disadvantages detailed in Approach 1. Also only one dev org needed.

Disadvantages: Package could grow extremely large as more apps are added. If user only purchases APP1, must find a way to disable their access to APP2 components (or vice versa).

 

Are there other approaches that I'm missing? Any thoughts on a 'best' design pattern to address this problem?

 

Thanks!

SandyB

  • November 28, 2012
  • Like
  • 0

I have recently started using the new Developer Console quite a bit. It's a great tool, but I am experiencing an error that I have never seen before when using it: 

 

Organization Administration Locked

The changes you requested require salesforce.com to temporarily lock your organization's administration setup. However, the administration setup has already been locked by another change. Please wait for the previous action to finish, then try again later. 

 

When this happens a lock is placed on an Apex class and I cannot edit it.  Any idea how to get out of this locked state? I have tried logging out of Salesforce and logging back in again multiple times.

  • October 31, 2012
  • Like
  • 0

I have recently started using the new Developer Console quite a bit. It's a great tool, but I am experiencing an error that I have never seen before when using it: 

 

Organization Administration Locked

The changes you requested require salesforce.com to temporarily lock your organization's administration setup. However, the administration setup has already been locked by another change. Please wait for the previous action to finish, then try again later. 

 

When this happens a lock is placed on an Apex class and I cannot edit it.  Any idea how to get out of this locked state? I have tried logging out of Salesforce and logging back in again multiple times.

  • October 31, 2012
  • Like
  • 0