Creating payment/shipping/tax solution specific components would introduce 17 new components to specialpurpose and that doesn’t seems like a favorable approach.
These integrations usually share a common code pattern and in longer vision we could possibly implement payment/shipping integration frameworks with a lot lesser and cleaner code that makes introducing new payment processor or shipping solution a lot easier with the help of configurations and little code. Most of us seems to be fine with three new components for payment processor, tax integration and shipping integration and that would leave us room for further refactoring. I think many on this thread has already given approval for three new components so that’s the way we should go. -- Thanks & Regards, Mridul Pathak HotWax Systems http://www.hotwaxsystems.com > On Jun 17, 2016, at 12:37 PM, Pierre Smits <pierre.sm...@gmail.com> wrote: > > Hi all, > > Moving all 3rd party related integrations solutions from accounting, > product and order into 1 special purpose component makes is worse to > maintain. Moving those from accounting into one in special purpose, those > from product into one and those from order into another just shifts the > problem from the base applications stack to a another stack, which is the > complexity that results from the total being being bigger than the sum of > its parts. > > I understand and accept that there might be adopters of old release out > there that are still on those old releases and use some (or all) of the 3rd > party integrations. But I believe that breaking these sets up in to the > smaller components not only makes maintenance less complex but also > increases the appeal of OFBiz (visavis completeness and flexibility). Given > that this is in the 'improvement' section of what we do, I understand that, > it won't be back ported to running release branches. So, there is a means > to communicate up front and prepare the adopters who want to migrate. > > Therefore I suggest we split the 3rd party payment solutions integrations > up into: > /specialpurpose/paypay > /specialpurpose/orbital > etc > > and the 3rd party shipment solutions integrations up into: > /specialpurpose/dhl > /specialpurpose/fedex > /specialpurpose/ups > etc > > and the same for the other 3rd party solutions integrations. > > After all, these functionalities should be optionals, not mandatories from > an integration perspective. Splitting them up will also bring the benefit > of easier maintenance, bringing in contributors who are experienced with > that piece of software and if adoption/use is 0, an easier path to the > attic (in stead of waiting and waiting untill all goes to being unused. > > Bringing this to separate components in special purpose doesn't mean we > need to bring those into the build process (as long as they are not fixed). > Leaving them out of the component-load.xml file (or commented out) will > avoid that, and give adopters an opt-in choice. > > So to recap: > +1 on the move out of the base applications stack > -1 on the move in catch-all components in another stack. > > Best regards, > > Pierre Smits > > ORRTIZ.COM <http://www.orrtiz.com> > OFBiz based solutions & services > > OFBiz Extensions Marketplace > http://oem.ofbizci.net/oci-2/ > > On Thu, Jun 16, 2016 at 7:57 PM, Taher Alkhateeb <slidingfilame...@gmail.com >> wrote: > >> +1 thank you for your dedication and thinking of this >> On Jun 16, 2016 8:55 PM, "Mridul Pathak" <mridul.pat...@hotwaxsystems.com> >> wrote: >> >>> Hi Taher, >>> >>> I was just trying to suggest that we will have to create two components >> in >>> specialpurpose, one for payment processor related functionality and one >> for >>> tax related functionality and the reason behind it. Which means we should >>> probably drop the idea of introducing a directory named “reference” and >>> instead create two separate components. >>> >>> Our main goal here is to move these files out of core applications and >>> most of us are fine with moving it to specialpurpose. I think we can >>> conclude our approach as most of us seems fine with having two separate >>> components in specialpurpose which was the original suggestion as well. >>> >>> -- >>> Thanks & Regards, >>> Mridul Pathak >>> HotWax Systems >>> http://www.hotwaxsystems.com >>> >>>> On Jun 16, 2016, at 8:23 PM, Taher Alkhateeb < >> slidingfilame...@gmail.com> >>> wrote: >>>> >>>> Hi Mridul, >>>> >>>> Thank you for the detailed and well thought out feedback. >>>> >>>> I am a little confused however, what is the point you are trying to >>> state? >>>> The only point from my previous email was to suggest avoiding creating >> a >>>> directory called reference in the top level ofbiz directory and instead >>>> keep it in /specialpurpose. If you want to keep it in >>>> specialpurpose/reference, fine, if you want to keep it in >>>> specialpurpose/your-component-here fine, if you want to do anything in >>>> specialpurpose then also fine My point was simply to suggest steering >>> away >>>> from ofbiz top level directory. >>>> >>>> Regards, >>>> >>>> Taher Alkhateeb >>>> >>>> On Thu, Jun 16, 2016 at 5:34 PM, Mridul Pathak < >>>> mridul.pat...@hotwaxsystems.com> wrote: >>>> >>>>> Hi Taher, >>>>> >>>>> Payment integration files in accounting/thirdparty are not just unused >>>>> files and all of it is not dead code. There is the whole functionality >>>>> built around those files which is very crucial to production delivery >> of >>>>> order management or ecommerce on top of OFBiz. There are many service >>>>> definition files whose implementation is written in these java files. >>> Some >>>>> examples are, >>>>> >>>>> accounting/servicedef/services_authorizedotnet.xml >>>>> accounting/servicedef/services_clearcommerce.xml >>>>> accounting/servicedef/services_cybersource.xml >>>>> accounting/servicedef/services_orbital.xml >>>>> accounting/servicedef/services_paypal.xml >>>>> etc. >>>>> >>>>> Along with that, many of the configurations needed to use these >> payment >>>>> solutions are maintained in accounting/config/payment.properties >> file. A >>>>> ProductStore in OFBiz as well can be configures to use on of these >>> payment >>>>> processors. >>>>> >>>>> Also, these file are intentionally excluded from compile process, but >>> can >>>>> be included if you want to use/deliver one of these existing payment >>>>> solution in OFBiz in production. Following is the code snippet from >>>>> accounting/build.xml, >>>>> >>>>> <target name="init"> >>>>> <condition property="verisign-exclude" >>>>> value="org/ofbiz/accounting/thirdparty/verisign/**"> >>>>> <not><available file="lib/payflow.jar"/></not> >>>>> </condition> >>>>> <patternset id="src.exc.set"> >>>>> <!-- exclude the payment processor packages; comment this out >> to >>>>> not exclude if you have libs --> >>>>> <exclude name="${verisign-exclude}"/> >>>>> <exclude >> name="org/ofbiz/accounting/thirdparty/cybersource/**"/> >>>>> <exclude >>>>> name="org/ofbiz/accounting/thirdparty/paypal/PayPalServices.java"/> >>>>> <exclude name="org/ofbiz/accounting/thirdparty/orbital/**"/> >>>>> <exclude name="org/ofbiz/accounting/thirdparty/securepay/**"/> >>>>> <exclude name="org/ofbiz/accounting/thirdparty/ideal/**"/> >>>>> </patternset> >>>>> </target> >>>>> >>>>> It clearly mentions that if you have required libraries for any of the >>>>> third party payment solutions, you could comment out the exclusion. >>>>> Usually, when someone needs to use one of the available payment >>> processor, >>>>> they download the required jar and place it in accounting/lib folder, >>> make >>>>> the needed changes in build.xml and they are ready to use the >> respective >>>>> payment solution. >>>>> >>>>> We have used one or the other payment processors in OFBiz many a times >>> to >>>>> deliver payment solutions as part of the software. I believe there are >>> many >>>>> application users and service providers who might be using the payment >>>>> processor functionality that comes with OFBiz OOTB. >>>>> >>>>> So, it’s not just about moving some files from core applications to >> some >>>>> other directory because they seems to be unused, the whole >> functionality >>>>> needs to be moved so that current or future users of these >>> functionalities >>>>> can still use it. And that is the reason if we create a new special >>> purpose >>>>> component it will help us to keep the functionality intact and usable >> at >>>>> the same time separate it from core applications. That would also >>> enable us >>>>> to keep such components out of component-load.xml and >>>>> specialpurpose/build.xml. A README file would help the user with >>> directions >>>>> to use it. >>>>> >>>>> Additionally, I feel that most of these files may need to be upgraded >>> and >>>>> needs code refactoring probably because they might usually be left out >>> as >>>>> they do not compile by default with OFBiz. >>>>> >>>>> -- >>>>> Thanks & Regards, >>>>> Mridul Pathak >>>>> HotWax Systems >>>>> http://www.hotwaxsystems.com >>>>> >>>>>> On Jun 16, 2016, at 6:44 PM, Taher Alkhateeb < >>> slidingfilame...@gmail.com> >>>>> wrote: >>>>>> >>>>>> Hey Folks, >>>>>> >>>>>> I would prefer to keep dead code away from the top level OFBiz >>> directory. >>>>>> If you keep it there then you make it _closer_ to the framework! >>>>>> >>>>>> Anyway, I don't see a problem with keeping it in specialpurpose! You >>> are >>>>>> not creating a component, you are just creating a folder called >>> reference >>>>>> and adding stuff to it, and you are not adding it to >>> component-load.xml? >>>>>> Why is it that you cannot add it there? >>>>>> >>>>>> Regards, >>>>>> >>>>>> Taher Alkhateeb >>>>>> >>>>>> On Thu, Jun 16, 2016 at 3:55 PM, Mridul Pathak < >>>>>> mridul.pat...@hotwaxsystems.com> wrote: >>>>>> >>>>>>> Introducing new directory “reference” seems reasonable approach to >> me >>> as >>>>>>> it is a combined solution to everyone’s views. >>>>>>> >>>>>>> -- >>>>>>> Thanks & Regards, >>>>>>> Mridul Pathak >>>>>>> Senior Manager >>>>>>> HotWax Systems >>>>>>> http://www.hotwaxsystems.com >>>>>>> >>>>>>>> On Jun 16, 2016, at 5:56 PM, Jacques Le Roux < >>>>>>> jacques.le.r...@les7arts.com> wrote: >>>>>>>> >>>>>>>> Hi Divesh, >>>>>>>> >>>>>>>> Le 16/06/2016 à 13:38, Divesh Dutta a écrit : >>>>>>>>>> 3- In the case of non-compiling / broken / missing dependencies >>> code >>>>>>>>>>>>> highlight this issue somewhere visible to the programmer >>> (README, >>>>>>>>>>>>> whatever). Why is this important? Because we need to tell our >>>>> build >>>>>>>>>>>>> scripts >>>>>>>>>>>>> and our classpath settings to ignore these files. >>>>>>>>>>>>> >>>>>>>>>>>>> The reason why I suggested to keep all of them in >>>>>>>>>>>>> /reference/each-component-name-here is to tell the build >> system >>> to >>>>>>> ignore >>>>>>>>>>>>> all Java files found in /specialpurpose/reference. If you >>> instead >>>>>>> break it >>>>>>>>>>>>> up into multiple components, then I need to ignore the files >> in >>>>> each >>>>>>>>>>>>> component by hand which makes the build script more complex >> and >>>>>>> more prone >>>>>>>>>>>>> to human error and it would add to the confusion. >>>>>>>>>>>>> >>>>>>>>>>> I agree and I think your initial proposition ("How about >>>>>>>>>>> reference/paymentext and reference/whatever-else-you-want?") was >>> not >>>>>>>>>>> clearly understood by Pierre and maybe not Divesh. Pierre, >> Divesh? >>>>>>>>>>> >>>>>>>>> Actually Jacques, we cannot create component like >>>>>>>>> specialpurpose/reference/paymentext . Other way can be we >> introduce >>>>> new >>>>>>>>> directory "reference" in parallel to specialpurpose, applications >> , >>>>>>>>> framework . Do you mean to do that ? >>>>>>>> >>>>>>>> You are right, and following Taher's idea I missed this point, it >>> seems >>>>>>> to me that your proposition of <<introducing a new directory >>>>> "reference" in >>>>>>> parallel to specialpurpose, applications ,framework>> is the best >> one >>> so >>>>>>> far. >>>>>>>> It could be also that Taher anticipated on the work (I know) he >> will >>> do >>>>>>> on refactoring the build system and this possibility will be open >>>>> "soon", >>>>>>> Taher? >>>>>>>> >>>>>>>>> >>>>>>>>> Also as Mridul put it, and you agreed, the "shipping >> integration/s" >>>>>>> which >>>>>>>>>>> "doesn’t have the compilation or library reference issues" would >>> be >>>>>>> in its >>>>>>>>>>> own independent component/s (ie not under /reference), same for >>>>> other >>>>>>> stuff >>>>>>>>>>> with the same status, if exist. >>>>>>>>> In this case, shipping integration can be under special purpose. >> So >>>>>>>>> specialpurpose/shippingIntegratio. >>>>>>>> >>>>>>>> Clearly, nobrainer :) >>>>>>>> >>>>>>>> Jacques >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> -- >>>>>>>>> Divesh Dutta. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> >>
