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 < [email protected]> 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 <[email protected]> > 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 < > > [email protected]> 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 < > >> [email protected]> 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. > >>>> > >>>> > >>>> > >>> > >> > >> > >
