Take the 2-minute tour ×
Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. It's 100% free, no registration required.

I'm working on a project that is extended by another package. The base package contains a global interface that will be implemented in the extension package. I'm having some problems with the development of the interface. My problem is that after I've uploaded a managed release of the base package the global interface can no longer be changed. It would be possible to upload a managed beta, but that I won't be able to update that in the extension environment without uninstalling it.

I need to able to upload a managed release of the base package and still be able to alter the global interface (because during the development of the extension class, the requirements for the interface change). Is that possible?

Suggested solution

What if I created 2 interfaces in the base class like this:

public virtual interface BaseInterface {
    //all the function definitions that need to be in the global interface
}

and

global interface GlobalBaseInterface extends BaseInterface {
    //no actual content
}

If I were to package these two interfaces and upload a managed release; would I still be able to alter the contents of the public virtual interface BaseInterface? And will the function definitions within that interface be visible in the extension package?

UPDATE

I actually tried the solution above and, as Stephen Willcock said, the functions are not visible. Although this works if you make sure you implement all the functions, the problem is that you will not get a compile time error if you don't implement one of the functions. If that function is used in the code you will get a run-time error. So it could be useful to do it like this; it could be very dangerous as well.

share|improve this question
    
Nice try :-) you will be able to change the public interface but you should not expect the methods to be accessible in the extension package –  Stephen Willcock Jan 11 '13 at 14:08
add comment

2 Answers

up vote 6 down vote accepted

As you have found, global interfaces in a released managed package cannot be changed. For versions of global interfaces across versions of your base managed package your only option is to add new versions as new (and distinct) interfaces. I would suggest adding a version number to the interface name - I am not suggesting using package version numbers, but a simple integer incremented each time a new version of the interface is required.

This could be useful in your development cycle before releasing your packages, but will quickly pollute your package with redundant interfaces. However, for a small project this may be sufficient.

For a larger project, I would suggest solving the problem by adapting your development process. I would develop your product unmanaged and unpackaged. Keep the code for your two packages quite separate in a source control system, and deploy both to the same developer org, base package code first and then extension package code. The interfaces will be global, but are malleable as they are unmanaged.

Having completed your development for a releasable version in an unmanaged environment, you can start your release cycle. In your release cycle you would build first the main package and then the extension package in a separate packaging exercise.

Once you have a stable base package, upload a release version and use this to start building the extension package.

share|improve this answer
    
Thanks for your answer. If I would install the unmanaged versions of the base package and extension package in new environment, what would be the easiest way to recapture the appropriate code to the development environment for the individual packages after I have developed a release candidate? And is there a way to do an unmanaged upload of a package that can also be uploaded managed? –  Lex Jan 11 '13 at 14:12
    
You won't be able to create separate unmanaged packages - I was suggesting unpackaged and unmanaged code, deployed via metadata API. –  Stephen Willcock Jan 11 '13 at 14:17
    
I haven't got any experience with the metadata API, I'll check that out. Thanks again. –  Lex Jan 11 '13 at 14:18
    
Re recapturing the source and separating into packages - if you are disciplined about using source control systems, you should be able to create separate Eclipse projects each based on a different source control folder, while both projects are bound to the same org. –  Stephen Willcock Jan 11 '13 at 14:21
    
Could you give me some pointer where to start using the metadata API? Maybe something like a tutorial? –  Lex Jan 13 '13 at 10:21
show 4 more comments

Lex, the Metadata API is what is used to deploy your code from your Force.com IDE (eg. Eclipse). http://wiki.developerforce.com/page/Force.com_IDE

You may also want to vote up this idea for change management of global interfaces, https://success.salesforce.com/ideaView?id=08730000000kmYbAAI

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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