Proposal to delete stale java files

[Mridul Pathak-4]

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

[taher]

+1 thank you for your dedication and thinking of this
On Jun 16, 2016 8:55 PM, "Mridul Pathak" <[hidden email]>
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 <[hidden email]>
> 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 <
> > [hidden email]> 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 <
> [hidden email]>
> >> 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 <
> >>> [hidden email]> 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 <
> >>>> [hidden email]> 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.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>
> >>
>
>

[Pierre Smits]

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 <[hidden email]
> wrote:

> +1 thank you for your dedication and thinking of this
> On Jun 16, 2016 8:55 PM, "Mridul Pathak" <[hidden email]>
> 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 <
> [hidden email]>
> > 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 <
> > > [hidden email]> 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 <
> > [hidden email]>
> > >> 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 <
> > >>> [hidden email]> 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 <
> > >>>> [hidden email]> 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.
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>>
> > >>
> > >>
> >
> >
>

[Mridul Pathak-4]

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 <[hidden email]> 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 <[hidden email]
>> wrote:
>
>> +1 thank you for your dedication and thinking of this
>> On Jun 16, 2016 8:55 PM, "Mridul Pathak" <[hidden email]>
>> 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 <
>> [hidden email]>
>>> 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 <
>>>> [hidden email]> 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 <
>>> [hidden email]>
>>>>> 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 <
>>>>>> [hidden email]> 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 <
>>>>>>> [hidden email]> 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.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>>

[Pierre Smits]

I agree that there are common patterns. And the common patterns should be
in the base component, to enable the payment and shipment solution
integrations. These integration solutions should be optional when
implementing an OFBiz setup.

An example please evaluate the MultiSafepay integration component I
created.
See for a high level description:
http://oem.ofbizci.net/oci-2/products/p_omultisafepay.
Visit for the code: https://github.com/ORRTIZ/omultisafepay
And for the implementation instruction:
https://github.com/ORRTIZ/omultisafepay/wiki/How-to-implement

This component applies the common patterns, without any new entities to be
created, and a minimal adjustment to the e-commerce and the product
component.

Best regards,

Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Sat, Jun 18, 2016 at 12:08 PM, Mridul Pathak <
[hidden email]> wrote:

> 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 <[hidden email]>
> 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 <
> [hidden email]
> >> wrote:
> >
> >> +1 thank you for your dedication and thinking of this
> >> On Jun 16, 2016 8:55 PM, "Mridul Pathak" <
> [hidden email]>
> >> 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 <
> >> [hidden email]>
> >>> 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 <
> >>>> [hidden email]> 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 <
> >>> [hidden email]>
> >>>>> 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 <
> >>>>>> [hidden email]> 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 <
> >>>>>>> [hidden email]> 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.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>
>
>

[Jacques Le Roux]

This needs to be carefully reviewed indeed (I did not yet)

Jacques

Le 18/06/2016 à 13:00, Pierre Smits a écrit :

> I agree that there are common patterns. And the common patterns should be
> in the base component, to enable the payment and shipment solution
> integrations. These integration solutions should be optional when
> implementing an OFBiz setup.
>
> An example please evaluate the MultiSafepay integration component I
> created.
> See for a high level description:
> http://oem.ofbizci.net/oci-2/products/p_omultisafepay.
> Visit for the code: https://github.com/ORRTIZ/omultisafepay
> And for the implementation instruction:
> https://github.com/ORRTIZ/omultisafepay/wiki/How-to-implement
>
> This component applies the common patterns, without any new entities to be
> created, and a minimal adjustment to the e-commerce and the product
> component.
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM <http://www.orrtiz.com>
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Sat, Jun 18, 2016 at 12:08 PM, Mridul Pathak <
> [hidden email]> wrote:
>
>> 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 <[hidden email]>
>> 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 <
>> [hidden email]
>>>> wrote:
>>>> +1 thank you for your dedication and thinking of this
>>>> On Jun 16, 2016 8:55 PM, "Mridul Pathak" <
>> [hidden email]>
>>>> 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 <
>>>> [hidden email]>
>>>>> 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 <
>>>>>> [hidden email]> 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 <
>>>>> [hidden email]>
>>>>>>> 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 <
>>>>>>>> [hidden email]> 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 <
>>>>>>>>> [hidden email]> 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.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>

[taher]

Hi Mridul, Everyone,

Now that we have a stable running build, perhaps it's time to move forward
with this discussion? All the excluded java files are listed in the master
build.gradle. If you move them to specialpurpose we can figure out a simple
solution to hide these exclusions away from the master build script and
declare them in the components build.gradle files away from the framework
and applications.

Do we have an available JIRA? Are you still interested in applying the work?

Taher Alkhateeb

On Sun, Jun 19, 2016 at 11:09 PM, Jacques Le Roux <
[hidden email]> wrote:

> This needs to be carefully reviewed indeed (I did not yet)
>
> Jacques
>
>
> Le 18/06/2016 à 13:00, Pierre Smits a écrit :
>
>> I agree that there are common patterns. And the common patterns should be
>> in the base component, to enable the payment and shipment solution
>> integrations. These integration solutions should be optional when
>> implementing an OFBiz setup.
>>
>> An example please evaluate the MultiSafepay integration component I
>> created.
>> See for a high level description:
>> http://oem.ofbizci.net/oci-2/products/p_omultisafepay.
>> Visit for the code: https://github.com/ORRTIZ/omultisafepay
>> And for the implementation instruction:
>> https://github.com/ORRTIZ/omultisafepay/wiki/How-to-implement
>>
>> This component applies the common patterns, without any new entities to be
>> created, and a minimal adjustment to the e-commerce and the product
>> component.
>>
>> Best regards,
>>
>> Pierre Smits
>>
>> ORRTIZ.COM <http://www.orrtiz.com>
>> OFBiz based solutions & services
>>
>> OFBiz Extensions Marketplace
>> http://oem.ofbizci.net/oci-2/
>>
>> On Sat, Jun 18, 2016 at 12:08 PM, Mridul Pathak <
>> [hidden email]> wrote:
>>
>> 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 <[hidden email]>
>>>>
>>> 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 <
>>>>
>>> [hidden email]
>>>
>>>> wrote:
>>>>> +1 thank you for your dedication and thinking of this
>>>>> On Jun 16, 2016 8:55 PM, "Mridul Pathak" <
>>>>>
>>>> [hidden email]>
>>>
>>>> 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 <
>>>>>>>
>>>>>> [hidden email]>
>>>>>
>>>>>> 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 <
>>>>>>> [hidden email]> 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 <
>>>>>>>>>
>>>>>>>> [hidden email]>
>>>>>>
>>>>>>> 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 <
>>>>>>>>> [hidden email]> 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 <
>>>>>>>>>>>
>>>>>>>>>> [hidden email]> 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.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>
>

[taher]

Actually, I think you can also enable these files and declare whatever
proprietary libraries you need since they will be pulled from an external
repository, please correct me if I'm wrong anyone I'm not the best guy to
speak legalese in here.

On Wed, Jul 27, 2016 at 3:07 PM, Taher Alkhateeb <[hidden email]
> wrote:

> Hi Mridul, Everyone,
>
> Now that we have a stable running build, perhaps it's time to move forward
> with this discussion? All the excluded java files are listed in the master
> build.gradle. If you move them to specialpurpose we can figure out a simple
> solution to hide these exclusions away from the master build script and
> declare them in the components build.gradle files away from the framework
> and applications.
>
> Do we have an available JIRA? Are you still interested in applying the
> work?
>
> Taher Alkhateeb
>
> On Sun, Jun 19, 2016 at 11:09 PM, Jacques Le Roux <
> [hidden email]> wrote:
>
>> This needs to be carefully reviewed indeed (I did not yet)
>>
>> Jacques
>>
>>
>> Le 18/06/2016 à 13:00, Pierre Smits a écrit :
>>
>>> I agree that there are common patterns. And the common patterns should be
>>> in the base component, to enable the payment and shipment solution
>>> integrations. These integration solutions should be optional when
>>> implementing an OFBiz setup.
>>>
>>> An example please evaluate the MultiSafepay integration component I
>>> created.
>>> See for a high level description:
>>> http://oem.ofbizci.net/oci-2/products/p_omultisafepay.
>>> Visit for the code: https://github.com/ORRTIZ/omultisafepay
>>> And for the implementation instruction:
>>> https://github.com/ORRTIZ/omultisafepay/wiki/How-to-implement
>>>
>>> This component applies the common patterns, without any new entities to
>>> be
>>> created, and a minimal adjustment to the e-commerce and the product
>>> component.
>>>
>>> Best regards,
>>>
>>> Pierre Smits
>>>
>>> ORRTIZ.COM <http://www.orrtiz.com>
>>> OFBiz based solutions & services
>>>
>>> OFBiz Extensions Marketplace
>>> http://oem.ofbizci.net/oci-2/
>>>
>>> On Sat, Jun 18, 2016 at 12:08 PM, Mridul Pathak <
>>> [hidden email]> wrote:
>>>
>>> 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 <[hidden email]>
>>>>>
>>>> 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 <
>>>>>
>>>> [hidden email]
>>>>
>>>>> wrote:
>>>>>> +1 thank you for your dedication and thinking of this
>>>>>> On Jun 16, 2016 8:55 PM, "Mridul Pathak" <
>>>>>>
>>>>> [hidden email]>
>>>>
>>>>> 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 <
>>>>>>>>
>>>>>>> [hidden email]>
>>>>>>
>>>>>>> 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 <
>>>>>>>> [hidden email]> 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 <
>>>>>>>>>>
>>>>>>>>> [hidden email]>
>>>>>>>
>>>>>>>> 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 <
>>>>>>>>>> [hidden email]> 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 <
>>>>>>>>>>>>
>>>>>>>>>>> [hidden email]> 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.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>
>>
>

[Jacopo Cappellato-5]

Hmmm... not sure about this because jars with incompatible licenses should
not be required to build a release.

Jacopo

On Wed, Jul 27, 2016 at 2:18 PM, Taher Alkhateeb <[hidden email]
> wrote:

> Actually, I think you can also enable these files and declare whatever
> proprietary libraries you need since they will be pulled from an external
> repository, please correct me if I'm wrong anyone I'm not the best guy to
> speak legalese in here.
>
> On Wed, Jul 27, 2016 at 3:07 PM, Taher Alkhateeb <
> [hidden email]
> > wrote:
>
> > Hi Mridul, Everyone,
> >
> > Now that we have a stable running build, perhaps it's time to move
> forward
> > with this discussion? All the excluded java files are listed in the
> master
> > build.gradle. If you move them to specialpurpose we can figure out a
> simple
> > solution to hide these exclusions away from the master build script and
> > declare them in the components build.gradle files away from the framework
> > and applications.
> >
> > Do we have an available JIRA? Are you still interested in applying the
> > work?
> >
> > Taher Alkhateeb
> >
> > On Sun, Jun 19, 2016 at 11:09 PM, Jacques Le Roux <
> > [hidden email]> wrote:
> >
> >> This needs to be carefully reviewed indeed (I did not yet)
> >>
> >> Jacques
> >>
> >>
> >> Le 18/06/2016 à 13:00, Pierre Smits a écrit :
> >>
> >>> I agree that there are common patterns. And the common patterns should
> be
> >>> in the base component, to enable the payment and shipment solution
> >>> integrations. These integration solutions should be optional when
> >>> implementing an OFBiz setup.
> >>>
> >>> An example please evaluate the MultiSafepay integration component I
> >>> created.
> >>> See for a high level description:
> >>> http://oem.ofbizci.net/oci-2/products/p_omultisafepay.
> >>> Visit for the code: https://github.com/ORRTIZ/omultisafepay
> >>> And for the implementation instruction:
> >>> https://github.com/ORRTIZ/omultisafepay/wiki/How-to-implement
> >>>
> >>> This component applies the common patterns, without any new entities to
> >>> be
> >>> created, and a minimal adjustment to the e-commerce and the product
> >>> component.
> >>>
> >>> Best regards,
> >>>
> >>> Pierre Smits
> >>>
> >>> ORRTIZ.COM <http://www.orrtiz.com>
> >>> OFBiz based solutions & services
> >>>
> >>> OFBiz Extensions Marketplace
> >>> http://oem.ofbizci.net/oci-2/
> >>>
> >>> On Sat, Jun 18, 2016 at 12:08 PM, Mridul Pathak <
> >>> [hidden email]> wrote:
> >>>
> >>> 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 <[hidden email]>
> >>>>>
> >>>> 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 <
> >>>>>
> >>>> [hidden email]
> >>>>
> >>>>> wrote:
> >>>>>> +1 thank you for your dedication and thinking of this
> >>>>>> On Jun 16, 2016 8:55 PM, "Mridul Pathak" <
> >>>>>>
> >>>>> [hidden email]>
> >>>>
> >>>>> 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 <
> >>>>>>>>
> >>>>>>> [hidden email]>
> >>>>>>
> >>>>>>> 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 <
> >>>>>>>> [hidden email]> 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 <
> >>>>>>>>>>
> >>>>>>>>> [hidden email]>
> >>>>>>>
> >>>>>>>> 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 <
> >>>>>>>>>> [hidden email]> 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 <
> >>>>>>>>>>>>
> >>>>>>>>>>> [hidden email]> 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.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>
> >>
> >
>

[taher]

I see, if that is the case then we should continue disabling them but do so
in the components' own build.gradle file to make the build cleaner.

On Wed, Jul 27, 2016 at 3:58 PM, Jacopo Cappellato <
[hidden email]> wrote:

> Hmmm... not sure about this because jars with incompatible licenses should
> not be required to build a release.
>
> Jacopo
>
> On Wed, Jul 27, 2016 at 2:18 PM, Taher Alkhateeb <
> [hidden email]
> > wrote:
>
> > Actually, I think you can also enable these files and declare whatever
> > proprietary libraries you need since they will be pulled from an external
> > repository, please correct me if I'm wrong anyone I'm not the best guy to
> > speak legalese in here.
> >
> > On Wed, Jul 27, 2016 at 3:07 PM, Taher Alkhateeb <
> > [hidden email]
> > > wrote:
> >
> > > Hi Mridul, Everyone,
> > >
> > > Now that we have a stable running build, perhaps it's time to move
> > forward
> > > with this discussion? All the excluded java files are listed in the
> > master
> > > build.gradle. If you move them to specialpurpose we can figure out a
> > simple
> > > solution to hide these exclusions away from the master build script and
> > > declare them in the components build.gradle files away from the
> framework
> > > and applications.
> > >
> > > Do we have an available JIRA? Are you still interested in applying the
> > > work?
> > >
> > > Taher Alkhateeb
> > >
> > > On Sun, Jun 19, 2016 at 11:09 PM, Jacques Le Roux <
> > > [hidden email]> wrote:
> > >
> > >> This needs to be carefully reviewed indeed (I did not yet)
> > >>
> > >> Jacques
> > >>
> > >>
> > >> Le 18/06/2016 à 13:00, Pierre Smits a écrit :
> > >>
> > >>> I agree that there are common patterns. And the common patterns
> should
> > be
> > >>> in the base component, to enable the payment and shipment solution
> > >>> integrations. These integration solutions should be optional when
> > >>> implementing an OFBiz setup.
> > >>>
> > >>> An example please evaluate the MultiSafepay integration component I
> > >>> created.
> > >>> See for a high level description:
> > >>> http://oem.ofbizci.net/oci-2/products/p_omultisafepay.
> > >>> Visit for the code: https://github.com/ORRTIZ/omultisafepay
> > >>> And for the implementation instruction:
> > >>> https://github.com/ORRTIZ/omultisafepay/wiki/How-to-implement
> > >>>
> > >>> This component applies the common patterns, without any new entities
> to
> > >>> be
> > >>> created, and a minimal adjustment to the e-commerce and the product
> > >>> component.
> > >>>
> > >>> Best regards,
> > >>>
> > >>> Pierre Smits
> > >>>
> > >>> ORRTIZ.COM <http://www.orrtiz.com>
> > >>> OFBiz based solutions & services
> > >>>
> > >>> OFBiz Extensions Marketplace
> > >>> http://oem.ofbizci.net/oci-2/
> > >>>
> > >>> On Sat, Jun 18, 2016 at 12:08 PM, Mridul Pathak <
> > >>> [hidden email]> wrote:
> > >>>
> > >>> 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 <[hidden email]>
> > >>>>>
> > >>>> 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 <
> > >>>>>
> > >>>> [hidden email]
> > >>>>
> > >>>>> wrote:
> > >>>>>> +1 thank you for your dedication and thinking of this
> > >>>>>> On Jun 16, 2016 8:55 PM, "Mridul Pathak" <
> > >>>>>>
> > >>>>> [hidden email]>
> > >>>>
> > >>>>> 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 <
> > >>>>>>>>
> > >>>>>>> [hidden email]>
> > >>>>>>
> > >>>>>>> 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 <
> > >>>>>>>> [hidden email]> 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 <
> > >>>>>>>>>>
> > >>>>>>>>> [hidden email]>
> > >>>>>>>
> > >>>>>>>> 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 <
> > >>>>>>>>>> [hidden email]> 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 <
> > >>>>>>>>>>>>
> > >>>>>>>>>>> [hidden email]> 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.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>
> > >>>>
> > >>
> > >
> >
>

[Mridul Pathak-4]

Hi Taher,

Yes, I think it’s the right time for the movement. Below are the JIRA ticket links for the overall work discussed in this thread.

Delete stale java files from applications and framework <https://issues.apache.org/jira/browse/OFBIZ-7529>
Move 3rd party payment integrations from accounting application to sepcialpurpose <https://issues.apache.org/jira/browse/OFBIZ-7415>
Move 3rd party shipping integrations from product application to sepcialpurpose <https://issues.apache.org/jira/browse/OFBIZ-7935>
Move 3rd party tax integrations from order application to sepcialpurpose <https://issues.apache.org/jira/browse/OFBIZ-7936>

--
Thanks & Regards,
Mridul Pathak
Senior Manager
HotWax Systems
http://www.hotwaxsystems.com

> On Jul 27, 2016, at 5:37 PM, Taher Alkhateeb <[hidden email]> wrote:
>
> Hi Mridul, Everyone,
>
> Now that we have a stable running build, perhaps it's time to move forward
> with this discussion? All the excluded java files are listed in the master
> build.gradle. If you move them to specialpurpose we can figure out a simple
> solution to hide these exclusions away from the master build script and
> declare them in the components build.gradle files away from the framework
> and applications.
>
> Do we have an available JIRA? Are you still interested in applying the work?
>
> Taher Alkhateeb
>
> On Sun, Jun 19, 2016 at 11:09 PM, Jacques Le Roux <
> [hidden email]> wrote:
>
>> This needs to be carefully reviewed indeed (I did not yet)
>>
>> Jacques
>>
>>
>> Le 18/06/2016 à 13:00, Pierre Smits a écrit :
>>
>>> I agree that there are common patterns. And the common patterns should be
>>> in the base component, to enable the payment and shipment solution
>>> integrations. These integration solutions should be optional when
>>> implementing an OFBiz setup.
>>>
>>> An example please evaluate the MultiSafepay integration component I
>>> created.
>>> See for a high level description:
>>> http://oem.ofbizci.net/oci-2/products/p_omultisafepay.
>>> Visit for the code: https://github.com/ORRTIZ/omultisafepay
>>> And for the implementation instruction:
>>> https://github.com/ORRTIZ/omultisafepay/wiki/How-to-implement
>>>
>>> This component applies the common patterns, without any new entities to be
>>> created, and a minimal adjustment to the e-commerce and the product
>>> component.
>>>
>>> Best regards,
>>>
>>> Pierre Smits
>>>
>>> ORRTIZ.COM <http://www.orrtiz.com>
>>> OFBiz based solutions & services
>>>
>>> OFBiz Extensions Marketplace
>>> http://oem.ofbizci.net/oci-2/
>>>
>>> On Sat, Jun 18, 2016 at 12:08 PM, Mridul Pathak <
>>> [hidden email]> wrote:
>>>
>>> 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 <[hidden email]>
>>>>>
>>>> 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 <
>>>>>
>>>> [hidden email]
>>>>
>>>>> wrote:
>>>>>> +1 thank you for your dedication and thinking of this
>>>>>> On Jun 16, 2016 8:55 PM, "Mridul Pathak" <
>>>>>>
>>>>> [hidden email]>
>>>>
>>>>> 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 <
>>>>>>>>
>>>>>>> [hidden email]>
>>>>>>
>>>>>>> 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 <
>>>>>>>> [hidden email]> 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 <
>>>>>>>>>>
>>>>>>>>> [hidden email]>
>>>>>>>
>>>>>>>> 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 <
>>>>>>>>>> [hidden email]> 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 <
>>>>>>>>>>>>
>>>>>>>>>>> [hidden email]> 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.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>
>>