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.
>>>>
>>>>
>>>>
>>>
>>
>>
