creating dependency on fflib-apex-common about fflib-apex-common HOT 4 CLOSED

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.

from fflib-apex-common.

@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,

from fflib-apex-common.

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.

from fflib-apex-common.

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!

from fflib-apex-common.