Thanks to all for putting your thoughts together. We will start working on moving third party code out of the framework soon.
As suggested by Mridul, we will take one integration at a time and validate if it is working and up to date with current scenarios and migrate only those integrations which are valid implementations today. Kind Regards, -- Pritam Kute On Thu, Jul 30, 2020 at 10:23 PM Pawan Verma <pawan.ve...@hotwaxsystems.com> wrote: > Thanks Mridul and Jacques for the valuable feedback. > > I also agree with your proposition. My vote is also for approach #1. > > Best > Pawan > > On Thu, Jul 30, 2020, 9:32 PM Jacques Le Roux < > jacques.le.r...@les7arts.com> > wrote: > > > Hi, > > > > Like Mridul, I also suggested the 2nd approach. I eventually tend to > > agree with Mridul. Having clearly separated packages, even with a bit of > > redundancy, simplifies and consolidate things. > > > > Jacques > > > > Le 30/07/2020 à 17:37, Mridul Pathak a écrit : > > > Hi Pawan, > > > > > > Though few years ago I was advocate of the approach #2 that you have > > suggested here, now I think that #1 is the best approach. In real time > > implementations the idea of plugins is to be able to use only what you > > need. Like for payment integrations you selectively use the gateways, > > mostly one. So it should be as easy to drop the plugin for your preferred > > gateway and use it, you shouldn’t need to unnecessarily have to code of > all > > other payment integrations that you don’t need. Also, from maintenance > > perspective even though some of these third party integrations could be > > categorised but still each of them have their own API specification, > > configurations and they need to be maintained separately. So, my vote > would > > be to #1 that is to create separate plugins for each third party > > integration. > > > > > > Thanks. > > > -- > > > Mridul Pathak > > > > > > > > >> On 30-Jul-2020, at 8:34 PM, Pawan Verma < > pawan.ve...@hotwaxsystems.com> > > wrote: > > >> > > >> Hi Pritam, > > >> > > >> I am also more inclined to not create a different repository for > > >> third-party-plugins. As we can have any number of plugins in OFBiz and > > >> Users can set up required plugins as per their need. > > >> > > >> I would suggest creating separate plugins for each third-party > > integration > > >> like ups, firstdatapaymentgateway, etc that way if the user wants > only a > > >> specific gateway or plugins can have only that one. > > >> > > >> I suggest two approaches: > > >> #1: Create a separate plugin for each integration and put them into > the > > >> plugins directory. > > >> > > >> #2: Club all the related plugins into one directory and can add that > > parent > > >> directory in base/config/component-load.xml. The benefit of this > > approach > > >> is we can have all payment or other gateways in one place and also > don't > > >> need to create a separate repository for the third-party-plugins. > > >> Example for shipping gateways: > > >> > > >> 1. Club all shipping gateways into the plugins/shipping-gateway > > directory > > >> 2. Add this shipping-gateway into base/config/component-load.xml > > >> as <load-components parent-directory="plugins/shipping-gateway"/> > > >> > > >> If we follow the #2 approach we may need to improve our plugin setup > > Gradle > > >> target i.e. pullPluginSource. > > >> > > >> Please let me know your thoughts and I can provide more detail if > > needed. > > >> > > >> Best > > >> Pawan > > > > >
