creating dependency on fflib-apex-common
Closed this issue · 4 comments
A colleague pointed me to this github. My question may look silly.
I would like to use this library in my development of the code. However, I find that it is shared as source-library and not as 'binary' of salesforce. The deployment to SF org creates unmanaged classes.
Could I know what is the recommended way of using the fflib-apex-common and fflib-apex-mocks in our development? I would like to refrain from including it as source-code library as much as possible.
This is because we need to create various packages, which can have dependencies between them. if these packages are using fflib_*, we would have code-duplicates.
also qualifying our packages to specific version of fflib-* is not possible with source-library.
Do you think converting the fflib-* as package will work?
Regards,
Amit
Amit, I think you basically have two choices; put the fflib code into a library package that all of your other packages will depend on, or duplicate the fflib code in each of your managed packages.
The first approach would require you to fork the code-base for you needs. You'd have to convert the classes / methods to have global visibility, so they can be called from your other managed packages. There are some pros and some cons to this approach. Since you've forked the original code base, it would be more difficult to take advantage of improvements to the original code. Also, once you've declared a class or method signature as "global" it is locked into the package's interface, and cannot be removed or changed. However, having the code in a managed package would allow you to update it in one place and deploy updates with package upgrades.
The second approach would be to include the fflib classes in each of your managed packages that will use it. This will allow you to use the code pretty much as-is, without having to change the class / method visibility, since the code will live within your packages' namespace. You will not have to worry about class namespace collisions. fflib is NOT a package namespace. If your package name is "MyPackage" the fflib classes would be named MyPackage.fflib_SObjectUnitOfWork, etc. Obviously the disadvantage is that you have duplicate copies of the fflib classes within all of your packages. Hope this helps you to make your decision.
@tfuda ,
thanks for the quick response. I understand the risk of forking and maintaining separate repo to create an independent package. In second approach however, there will be a lot of duplicate classes on same SF org if my real business packages are many.
Que: is there a possibility of extending the current classes to define global classes. Then if the library is used as source-library, current usage remains. If I were to use packaged version, the global classes can be used.
Well, thanks anyway. I am first going to start using it, I may have some more time before take a decision of "how to bundle all together".
Regards,
If you're an ISV, keep in mind that a separate managed package will also incur an additional security review + fee and that people won't be able to 'one click install' from the AppExchange because of the dependency.
Great support @tfuda thanks.
I personally would go with embedding it in the package, duplicates in each org is not a huge problem the platform isolates them via the package namespace as @tfuda points out. I've not heard of anybody adding it in a shared base package, this would be a considerable disadvantage to evolving the code and immediately start to erode the benefit of using an open source package.
Hope this answers your questions @arangari, of course the decision is all yours. Either way glad you've chosen to utilise the libraries and have fun!