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 <
[email protected]> 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 <[email protected]>
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 <
[email protected]
wrote:
+1 thank you for your dedication and thinking of this
On Jun 16, 2016 8:55 PM, "Mridul Pathak" <
[email protected]>
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 <
[email protected]>
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 <
[email protected]> wrote:
Hi Taher,
Payment integration files in accounting/thirdparty are not just
unused
files and all of it is not dead code. There is the whole
functionality
built around those files which is very crucial to production delivery
of
order management or ecommerce on top of OFBiz. There are many service
definition files whose implementation is written in these java files.
Some
examples are,
accounting/servicedef/services_authorizedotnet.xml
accounting/servicedef/services_clearcommerce.xml
accounting/servicedef/services_cybersource.xml
accounting/servicedef/services_orbital.xml
accounting/servicedef/services_paypal.xml
etc.
Along with that, many of the configurations needed to use these
payment
solutions are maintained in accounting/config/payment.properties
file. A
ProductStore in OFBiz as well can be configures to use on of these
payment
processors.
Also, these file are intentionally excluded from compile process, but
can
be included if you want to use/deliver one of these existing payment
solution in OFBiz in production. Following is the code snippet from
accounting/build.xml,
<target name="init">
<condition property="verisign-exclude"
value="org/ofbiz/accounting/thirdparty/verisign/**">
<not><available file="lib/payflow.jar"/></not>
</condition>
<patternset id="src.exc.set">
<!-- exclude the payment processor packages; comment this out
to
not exclude if you have libs -->
<exclude name="${verisign-exclude}"/>
<exclude
name="org/ofbiz/accounting/thirdparty/cybersource/**"/>
<exclude
name="org/ofbiz/accounting/thirdparty/paypal/PayPalServices.java"/>
<exclude name="org/ofbiz/accounting/thirdparty/orbital/**"/>
<exclude name="org/ofbiz/accounting/thirdparty/securepay/**"/>
<exclude name="org/ofbiz/accounting/thirdparty/ideal/**"/>
</patternset>
</target>
It clearly mentions that if you have required libraries for any of
the
third party payment solutions, you could comment out the exclusion.
Usually, when someone needs to use one of the available payment
processor,
they download the required jar and place it in accounting/lib folder,
make
the needed changes in build.xml and they are ready to use the
respective
payment solution.
We have used one or the other payment processors in OFBiz many a
times
to
deliver payment solutions as part of the software. I believe there
are
many
application users and service providers who might be using the
payment
processor functionality that comes with OFBiz OOTB.
So, it’s not just about moving some files from core applications to
some
other directory because they seems to be unused, the whole
functionality
needs to be moved so that current or future users of these
functionalities
can still use it. And that is the reason if we create a new special
purpose
component it will help us to keep the functionality intact and usable
at
the same time separate it from core applications. That would also
enable us
to keep such components out of component-load.xml and
specialpurpose/build.xml. A README file would help the user with
directions
to use it.
Additionally, I feel that most of these files may need to be upgraded
and
needs code refactoring probably because they might usually be left
out
as
they do not compile by default with OFBiz.
--
Thanks & Regards,
Mridul Pathak
HotWax Systems
http://www.hotwaxsystems.com
On Jun 16, 2016, at 6:44 PM, Taher Alkhateeb <
[email protected]>
wrote:
Hey Folks,
I would prefer to keep dead code away from the top level OFBiz
directory.
If you keep it there then you make it _closer_ to the framework!
Anyway, I don't see a problem with keeping it in specialpurpose! You
are
not creating a component, you are just creating a folder called
reference
and adding stuff to it, and you are not adding it to
component-load.xml?
Why is it that you cannot add it there?
Regards,
Taher Alkhateeb
On Thu, Jun 16, 2016 at 3:55 PM, Mridul Pathak <
[email protected]> wrote:
Introducing new directory “reference” seems reasonable approach to
me
as
it is a combined solution to everyone’s views.
--
Thanks & Regards,
Mridul Pathak
Senior Manager
HotWax Systems
http://www.hotwaxsystems.com
On Jun 16, 2016, at 5:56 PM, Jacques Le Roux <
[email protected]> wrote:
Hi Divesh,
Le 16/06/2016 à 13:38, Divesh Dutta a écrit :
3- In the case of non-compiling / broken / missing dependencies
code
highlight this issue somewhere visible to the programmer
(README,
whatever). Why is this important? Because we need to tell our
build
scripts
and our classpath settings to ignore these files.
The reason why I suggested to keep all of them in
/reference/each-component-name-here is to tell the build
system
to
ignore
all Java files found in /specialpurpose/reference. If you
instead
break it
up into multiple components, then I need to ignore the files
in
each
component by hand which makes the build script more complex
and
more prone
to human error and it would add to the confusion.
I agree and I think your initial proposition ("How about
reference/paymentext and reference/whatever-else-you-want?")
was
not
clearly understood by Pierre and maybe not Divesh. Pierre,
Divesh?
Actually Jacques, we cannot create component like
specialpurpose/reference/paymentext . Other way can be we
introduce
new
directory "reference" in parallel to specialpurpose, applications
,
framework . Do you mean to do that ?
You are right, and following Taher's idea I missed this point, it
seems
to me that your proposition of <<introducing a new directory
"reference" in
parallel to specialpurpose, applications ,framework>> is the best
one
so
far.
It could be also that Taher anticipated on the work (I know) he
will
do
on refactoring the build system and this possibility will be open
"soon",
Taher?
Also as Mridul put it, and you agreed, the "shipping
integration/s"
which
"doesn’t have the compilation or library reference issues"
would
be
in its
own independent component/s (ie not under /reference), same for
other
stuff
with the same status, if exist.
In this case, shipping integration can be under special purpose.
So
specialpurpose/shippingIntegratio.
Clearly, nobrainer :)
Jacques
Thanks
--
Divesh Dutta.
