You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Taher Alkhateeb <sl...@gmail.com> on 2016/06/14 14:10:40 UTC
Proposal to delete stale java files
Hi Everyone,
I cannot actually believe it but while I was working on a project (I will
announce later) I discovered in the process that the below files cannot
compile!!! They existed for years in the code base without even being able
to compile. They reference non existent libraries or they have faulty code
(e.g. not importing used code)
I propose to delete them immediately from trunk
applications/accounting/src/org/ofbiz/accounting/thirdparty/cybersource/IcsPaymentServices.java
applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealEvents.java
applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealPaymentServiceTest.java
applications/accounting/src/org/ofbiz/accounting/thirdparty/orbital/OrbitalPaymentServices.java
applications/accounting/src/org/ofbiz/accounting/thirdparty/paypal/PayPalServices.java
applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayPaymentServices.java
applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayServiceTest.java
applications/accounting/src/org/ofbiz/accounting/thirdparty/verisign/PayflowPro.java
applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayInputStream.java
applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayOutputStream.java
applications/content/src/org/ofbiz/content/openoffice/OpenOfficeServices.java
applications/content/src/org/ofbiz/content/openoffice/OpenOfficeWorker.java
applications/content/src/org/ofbiz/content/report
applications/content/src/org/ofbiz/content/report/JREntityListIteratorDataSource.java
applications/content/src/org/ofbiz/content/report/JRMapCollectionDataSource.java
applications/order/src/org/ofbiz/order/thirdparty/taxware
applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareException.java
applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareServices.java
applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareUTL.java
applications/product/src/ShipmentScaleApplet.java
applications/securityext/src/org/ofbiz/securityext/thirdparty/truition/TruitionCoReg.java
framework/webapp/src/org/ofbiz/webapp/view/JasperReportsJXlsViewHandler.java
framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPdfViewHandler.java
framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPoiXlsViewHandler.java
framework/webapp/src/org/ofbiz/webapp/view/JasperReportsXmlViewHandler.java
Regards,
Taher Alkhateeb
Re: Proposal to delete stale java files
Posted by Divesh Dutta <di...@hotwaxsystems.com>.
Hi Taher,
I am not sure about other Java files if they are heavily used or not,
but PayPalServices.java
and PayflowPro.java are the two files which I think lots of people use. So,
I will recommend keeping them. If needed we can talk on problems in this
file, and fix them.
Thanks
--
Divesh Dutta.
On Tue, Jun 14, 2016 at 7:40 PM, Taher Alkhateeb <slidingfilaments@gmail.com
> wrote:
> Hi Everyone,
>
> I cannot actually believe it but while I was working on a project (I will
> announce later) I discovered in the process that the below files cannot
> compile!!! They existed for years in the code base without even being able
> to compile. They reference non existent libraries or they have faulty code
> (e.g. not importing used code)
>
> I propose to delete them immediately from trunk
>
>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/cybersource/IcsPaymentServices.java
>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealEvents.java
>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealPaymentServiceTest.java
>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/orbital/OrbitalPaymentServices.java
>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/paypal/PayPalServices.java
>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayPaymentServices.java
>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayServiceTest.java
>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/verisign/PayflowPro.java
>
> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayInputStream.java
>
> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayOutputStream.java
>
> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeServices.java
> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeWorker.java
> applications/content/src/org/ofbiz/content/report
>
> applications/content/src/org/ofbiz/content/report/JREntityListIteratorDataSource.java
>
> applications/content/src/org/ofbiz/content/report/JRMapCollectionDataSource.java
> applications/order/src/org/ofbiz/order/thirdparty/taxware
>
> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareException.java
>
> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareServices.java
> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareUTL.java
> applications/product/src/ShipmentScaleApplet.java
>
> applications/securityext/src/org/ofbiz/securityext/thirdparty/truition/TruitionCoReg.java
>
> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsJXlsViewHandler.java
> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPdfViewHandler.java
>
> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPoiXlsViewHandler.java
> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsXmlViewHandler.java
>
> Regards,
>
> Taher Alkhateeb
>
Re: Proposal to delete stale java files
Posted by Ron Wheeler <rw...@artifact-software.com>.
+1
Exactly what the project needs.
Code hoarding is a big issue whenever "old programmers" get together (me
included).
We know that it is actually saved in the SCM but we remember the old
days before SCM when hoarding made sense.
Clear out anything that does not compile or does not get used.
If someone needs it, they will resurrect it, redesign it to make it fit
where it belongs and fix it so it works.
Ron
On 14/06/2016 1:19 PM, Taher Alkhateeb wrote:
> Hi Jacques Pierre and everyone,
>
> OFBiz suffers from code hoarding. A LOT of that code is badly written, non
> functional, or just a bare minimum POC.
>
> Thinking of OFBiz as full of features that would shrink is not very
> realistic, here is why:
>
> - If it was broken for years, then nobody is using it and nobody cares
> - Deleting things always keeps them in source control for review later
> - The whole purpose of refactoring OFBiz is to remove such dead code and
> improve the design.
> - One of the objectives (at least for me) in refactoring OFBiz is to
> redesign OFBiz to be modular with loose coupling between the parts. This
> loose coupling allows us to add TONS OF FEATURES that do not obstruct the
> functionality of the framework or touch core components.
>
> Look at the files I'm mentioning ... Where do they live? They live in the
> heart of the framework and the core applications. This is flat out wrong!
> We should never keep code for "reference on how to use" or "it might come
> in handy". Even if we do, it should never be in the core framework or core
> applications but instead in peripheral modules.
>
> Also keeping non compiling code means confusion for developers. Why is this
> file here? Why does it exist? Why is it not compiling? This just puts drag
> on the thinking velocity of developers and adds more weight to this already
> fat code base.
>
> I know it sucks, but the code base has many parts that suck! We have to
> strip down before we build again, it's just a price that we must pay to
> keep the project running. You just cannot think in a mess. It's a human
> thing!
>
> My 2 cents,
>
> Taher Alkhateeb
>
> On Tue, Jun 14, 2016 at 8:01 PM, Pierre Smits <pi...@gmail.com>
> wrote:
>
>> As the majority of the referenced java files are related to 3rd party
>> solutions integrations, we should have done the smart thing and that is
>> provide them as optional Proof of Concept components. In stead we had/have
>> them as almost hard coded functionalities. Removing these from the code
>> base in trunk involves more. It means also removing the elements that
>> access these (directly and indirectly), including screen and form widgets,
>> templates, services and request and view map uris.
>>
>> But if we remove them from the code base (to the attic), before long the
>> knowledge will be lost and the feature set of OFBiz will shrink. Some may
>> not care about that, but it will - again - make the uphill adoption battle
>> more difficult.
>>
>> Best regards,
>>
>> Pierre Smits
>>
>> ORRTIZ.COM <http://www.orrtiz.com>
>> OFBiz based solutions & services
>>
>> OFBiz Extensions Marketplace
>> http://oem.ofbizci.net/oci-2/
>>
>> On Tue, Jun 14, 2016 at 4:10 PM, Taher Alkhateeb <
>> slidingfilaments@gmail.com
>>> wrote:
>>> Hi Everyone,
>>>
>>> I cannot actually believe it but while I was working on a project (I will
>>> announce later) I discovered in the process that the below files cannot
>>> compile!!! They existed for years in the code base without even being
>> able
>>> to compile. They reference non existent libraries or they have faulty
>> code
>>> (e.g. not importing used code)
>>>
>>> I propose to delete them immediately from trunk
>>>
>>>
>>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/cybersource/IcsPaymentServices.java
>>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealEvents.java
>>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealPaymentServiceTest.java
>>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/orbital/OrbitalPaymentServices.java
>>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/paypal/PayPalServices.java
>>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayPaymentServices.java
>>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayServiceTest.java
>>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/verisign/PayflowPro.java
>>>
>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayInputStream.java
>>>
>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayOutputStream.java
>>>
>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeServices.java
>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeWorker.java
>>> applications/content/src/org/ofbiz/content/report
>>>
>>>
>> applications/content/src/org/ofbiz/content/report/JREntityListIteratorDataSource.java
>>>
>> applications/content/src/org/ofbiz/content/report/JRMapCollectionDataSource.java
>>> applications/order/src/org/ofbiz/order/thirdparty/taxware
>>>
>>>
>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareException.java
>>>
>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareServices.java
>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareUTL.java
>>> applications/product/src/ShipmentScaleApplet.java
>>>
>>>
>> applications/securityext/src/org/ofbiz/securityext/thirdparty/truition/TruitionCoReg.java
>>>
>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsJXlsViewHandler.java
>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPdfViewHandler.java
>>>
>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPoiXlsViewHandler.java
>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsXmlViewHandler.java
>>> Regards,
>>>
>>> Taher Alkhateeb
>>>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: Proposal to delete stale java files
Posted by Jacques Le Roux <ja...@les7arts.com>.
The point is the Attic is only documenting things which are removed but still in the repo (in the past)
https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Attic
Jacques
Le 14/06/2016 � 19:19, Taher Alkhateeb a �crit :
> Hi Jacques Pierre and everyone,
>
> OFBiz suffers from code hoarding. A LOT of that code is badly written, non
> functional, or just a bare minimum POC.
>
> Thinking of OFBiz as full of features that would shrink is not very
> realistic, here is why:
>
> - If it was broken for years, then nobody is using it and nobody cares
> - Deleting things always keeps them in source control for review later
> - The whole purpose of refactoring OFBiz is to remove such dead code and
> improve the design.
> - One of the objectives (at least for me) in refactoring OFBiz is to
> redesign OFBiz to be modular with loose coupling between the parts. This
> loose coupling allows us to add TONS OF FEATURES that do not obstruct the
> functionality of the framework or touch core components.
>
> Look at the files I'm mentioning ... Where do they live? They live in the
> heart of the framework and the core applications. This is flat out wrong!
> We should never keep code for "reference on how to use" or "it might come
> in handy". Even if we do, it should never be in the core framework or core
> applications but instead in peripheral modules.
>
> Also keeping non compiling code means confusion for developers. Why is this
> file here? Why does it exist? Why is it not compiling? This just puts drag
> on the thinking velocity of developers and adds more weight to this already
> fat code base.
>
> I know it sucks, but the code base has many parts that suck! We have to
> strip down before we build again, it's just a price that we must pay to
> keep the project running. You just cannot think in a mess. It's a human
> thing!
>
> My 2 cents,
>
> Taher Alkhateeb
>
> On Tue, Jun 14, 2016 at 8:01 PM, Pierre Smits <pi...@gmail.com>
> wrote:
>
>> As the majority of the referenced java files are related to 3rd party
>> solutions integrations, we should have done the smart thing and that is
>> provide them as optional Proof of Concept components. In stead we had/have
>> them as almost hard coded functionalities. Removing these from the code
>> base in trunk involves more. It means also removing the elements that
>> access these (directly and indirectly), including screen and form widgets,
>> templates, services and request and view map uris.
>>
>> But if we remove them from the code base (to the attic), before long the
>> knowledge will be lost and the feature set of OFBiz will shrink. Some may
>> not care about that, but it will - again - make the uphill adoption battle
>> more difficult.
>>
>> Best regards,
>>
>> Pierre Smits
>>
>> ORRTIZ.COM <http://www.orrtiz.com>
>> OFBiz based solutions & services
>>
>> OFBiz Extensions Marketplace
>> http://oem.ofbizci.net/oci-2/
>>
>> On Tue, Jun 14, 2016 at 4:10 PM, Taher Alkhateeb <
>> slidingfilaments@gmail.com
>>> wrote:
>>> Hi Everyone,
>>>
>>> I cannot actually believe it but while I was working on a project (I will
>>> announce later) I discovered in the process that the below files cannot
>>> compile!!! They existed for years in the code base without even being
>> able
>>> to compile. They reference non existent libraries or they have faulty
>> code
>>> (e.g. not importing used code)
>>>
>>> I propose to delete them immediately from trunk
>>>
>>>
>>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/cybersource/IcsPaymentServices.java
>>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealEvents.java
>>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealPaymentServiceTest.java
>>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/orbital/OrbitalPaymentServices.java
>>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/paypal/PayPalServices.java
>>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayPaymentServices.java
>>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayServiceTest.java
>>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/verisign/PayflowPro.java
>>>
>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayInputStream.java
>>>
>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayOutputStream.java
>>>
>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeServices.java
>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeWorker.java
>>> applications/content/src/org/ofbiz/content/report
>>>
>>>
>> applications/content/src/org/ofbiz/content/report/JREntityListIteratorDataSource.java
>>>
>> applications/content/src/org/ofbiz/content/report/JRMapCollectionDataSource.java
>>> applications/order/src/org/ofbiz/order/thirdparty/taxware
>>>
>>>
>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareException.java
>>>
>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareServices.java
>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareUTL.java
>>> applications/product/src/ShipmentScaleApplet.java
>>>
>>>
>> applications/securityext/src/org/ofbiz/securityext/thirdparty/truition/TruitionCoReg.java
>>>
>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsJXlsViewHandler.java
>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPdfViewHandler.java
>>>
>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPoiXlsViewHandler.java
>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsXmlViewHandler.java
>>> Regards,
>>>
>>> Taher Alkhateeb
>>>
Re: Proposal to delete stale java files
Posted by Taher Alkhateeb <sl...@gmail.com>.
Hi Jacques Pierre and everyone,
OFBiz suffers from code hoarding. A LOT of that code is badly written, non
functional, or just a bare minimum POC.
Thinking of OFBiz as full of features that would shrink is not very
realistic, here is why:
- If it was broken for years, then nobody is using it and nobody cares
- Deleting things always keeps them in source control for review later
- The whole purpose of refactoring OFBiz is to remove such dead code and
improve the design.
- One of the objectives (at least for me) in refactoring OFBiz is to
redesign OFBiz to be modular with loose coupling between the parts. This
loose coupling allows us to add TONS OF FEATURES that do not obstruct the
functionality of the framework or touch core components.
Look at the files I'm mentioning ... Where do they live? They live in the
heart of the framework and the core applications. This is flat out wrong!
We should never keep code for "reference on how to use" or "it might come
in handy". Even if we do, it should never be in the core framework or core
applications but instead in peripheral modules.
Also keeping non compiling code means confusion for developers. Why is this
file here? Why does it exist? Why is it not compiling? This just puts drag
on the thinking velocity of developers and adds more weight to this already
fat code base.
I know it sucks, but the code base has many parts that suck! We have to
strip down before we build again, it's just a price that we must pay to
keep the project running. You just cannot think in a mess. It's a human
thing!
My 2 cents,
Taher Alkhateeb
On Tue, Jun 14, 2016 at 8:01 PM, Pierre Smits <pi...@gmail.com>
wrote:
> As the majority of the referenced java files are related to 3rd party
> solutions integrations, we should have done the smart thing and that is
> provide them as optional Proof of Concept components. In stead we had/have
> them as almost hard coded functionalities. Removing these from the code
> base in trunk involves more. It means also removing the elements that
> access these (directly and indirectly), including screen and form widgets,
> templates, services and request and view map uris.
>
> But if we remove them from the code base (to the attic), before long the
> knowledge will be lost and the feature set of OFBiz will shrink. Some may
> not care about that, but it will - again - make the uphill adoption battle
> more difficult.
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM <http://www.orrtiz.com>
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Tue, Jun 14, 2016 at 4:10 PM, Taher Alkhateeb <
> slidingfilaments@gmail.com
> > wrote:
>
> > Hi Everyone,
> >
> > I cannot actually believe it but while I was working on a project (I will
> > announce later) I discovered in the process that the below files cannot
> > compile!!! They existed for years in the code base without even being
> able
> > to compile. They reference non existent libraries or they have faulty
> code
> > (e.g. not importing used code)
> >
> > I propose to delete them immediately from trunk
> >
> >
> >
> applications/accounting/src/org/ofbiz/accounting/thirdparty/cybersource/IcsPaymentServices.java
> >
> >
> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealEvents.java
> >
> >
> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealPaymentServiceTest.java
> >
> >
> applications/accounting/src/org/ofbiz/accounting/thirdparty/orbital/OrbitalPaymentServices.java
> >
> >
> applications/accounting/src/org/ofbiz/accounting/thirdparty/paypal/PayPalServices.java
> >
> >
> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayPaymentServices.java
> >
> >
> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayServiceTest.java
> >
> >
> applications/accounting/src/org/ofbiz/accounting/thirdparty/verisign/PayflowPro.java
> >
> >
> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayInputStream.java
> >
> >
> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayOutputStream.java
> >
> >
> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeServices.java
> >
> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeWorker.java
> > applications/content/src/org/ofbiz/content/report
> >
> >
> applications/content/src/org/ofbiz/content/report/JREntityListIteratorDataSource.java
> >
> >
> applications/content/src/org/ofbiz/content/report/JRMapCollectionDataSource.java
> > applications/order/src/org/ofbiz/order/thirdparty/taxware
> >
> >
> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareException.java
> >
> >
> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareServices.java
> > applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareUTL.java
> > applications/product/src/ShipmentScaleApplet.java
> >
> >
> applications/securityext/src/org/ofbiz/securityext/thirdparty/truition/TruitionCoReg.java
> >
> >
> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsJXlsViewHandler.java
> >
> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPdfViewHandler.java
> >
> >
> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPoiXlsViewHandler.java
> >
> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsXmlViewHandler.java
> >
> > Regards,
> >
> > Taher Alkhateeb
> >
>
Re: Proposal to delete stale java files
Posted by Jacques Le Roux <ja...@les7arts.com>.
Yes indeed, IIRW we crossed that with Ideal to Attic action and that's why it's still waiting, not as simple as it looks
Jacques
Le 14/06/2016 � 19:01, Pierre Smits a �crit :
> As the majority of the referenced java files are related to 3rd party
> solutions integrations, we should have done the smart thing and that is
> provide them as optional Proof of Concept components. In stead we had/have
> them as almost hard coded functionalities. Removing these from the code
> base in trunk involves more. It means also removing the elements that
> access these (directly and indirectly), including screen and form widgets,
> templates, services and request and view map uris.
>
> But if we remove them from the code base (to the attic), before long the
> knowledge will be lost and the feature set of OFBiz will shrink. Some may
> not care about that, but it will - again - make the uphill adoption battle
> more difficult.
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM <http://www.orrtiz.com>
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Tue, Jun 14, 2016 at 4:10 PM, Taher Alkhateeb <slidingfilaments@gmail.com
>> wrote:
>> Hi Everyone,
>>
>> I cannot actually believe it but while I was working on a project (I will
>> announce later) I discovered in the process that the below files cannot
>> compile!!! They existed for years in the code base without even being able
>> to compile. They reference non existent libraries or they have faulty code
>> (e.g. not importing used code)
>>
>> I propose to delete them immediately from trunk
>>
>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/cybersource/IcsPaymentServices.java
>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealEvents.java
>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealPaymentServiceTest.java
>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/orbital/OrbitalPaymentServices.java
>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/paypal/PayPalServices.java
>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayPaymentServices.java
>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayServiceTest.java
>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/verisign/PayflowPro.java
>>
>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayInputStream.java
>>
>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayOutputStream.java
>>
>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeServices.java
>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeWorker.java
>> applications/content/src/org/ofbiz/content/report
>>
>> applications/content/src/org/ofbiz/content/report/JREntityListIteratorDataSource.java
>>
>> applications/content/src/org/ofbiz/content/report/JRMapCollectionDataSource.java
>> applications/order/src/org/ofbiz/order/thirdparty/taxware
>>
>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareException.java
>>
>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareServices.java
>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareUTL.java
>> applications/product/src/ShipmentScaleApplet.java
>>
>> applications/securityext/src/org/ofbiz/securityext/thirdparty/truition/TruitionCoReg.java
>>
>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsJXlsViewHandler.java
>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPdfViewHandler.java
>>
>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPoiXlsViewHandler.java
>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsXmlViewHandler.java
>>
>> Regards,
>>
>> Taher Alkhateeb
>>
Re: Proposal to delete stale java files
Posted by Jacopo Cappellato <ja...@hotwaxsystems.com>.
This is an interesting conversation; removing the classes (and the
artifacts that use them) and documenting the removal in our Attic page for
history and future reference seems to me a good compromise for the various
point of views.
Jacopo
On Tue, Jun 14, 2016 at 11:34 PM, Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:
> Le 14/06/2016 à 19:56, Ron Wheeler a écrit :
>
>> Poorly documented, non-functioning code is not an attractive feature that
>> will draw new users.
>>
>> If there are pieces that are being removed that you think are worth
>> remembering, write a wiki note (it can be searched by Google) documenting
>> these partially implemented features that can be recovered from the SCM if
>> anyone cares in the future.
>>
>> The attic is a compromise to make hoarders feel comfortable but putting
>> junk in the attic with no documentation about why things were written, why
>> they are not finished or currently not used, is of questionable value.
>> Non-functioning code that may be written to older standards or, worse yet,
>> bad programming practices is just dangerous.
>>
>
> Better than throwing the baby with the bathwater, as we say in French (in
> other words remove without any mentions but in the commit log, good luck to
> find anything there). You never know and would be surprised by what can
> happen sometimes...
>
>
>> Is anyone willing to QC the code placed in the attic?
>>
>
> This could happen, again who knows and who can say better? We all know we
> have limited capable resources.
>
> Jacques
>
>
>> Ron
>>
>>
>> On 14/06/2016 1:01 PM, Pierre Smits wrote:
>>
>>> As the majority of the referenced java files are related to 3rd party
>>> solutions integrations, we should have done the smart thing and that is
>>> provide them as optional Proof of Concept components. In stead we
>>> had/have
>>> them as almost hard coded functionalities. Removing these from the code
>>> base in trunk involves more. It means also removing the elements that
>>> access these (directly and indirectly), including screen and form
>>> widgets,
>>> templates, services and request and view map uris.
>>>
>>> But if we remove them from the code base (to the attic), before long the
>>> knowledge will be lost and the feature set of OFBiz will shrink. Some may
>>> not care about that, but it will - again - make the uphill adoption
>>> battle
>>> more difficult.
>>>
>>> Best regards,
>>>
>>> Pierre Smits
>>>
>>> ORRTIZ.COM <http://www.orrtiz.com>
>>> OFBiz based solutions & services
>>>
>>> OFBiz Extensions Marketplace
>>> http://oem.ofbizci.net/oci-2/
>>>
>>> On Tue, Jun 14, 2016 at 4:10 PM, Taher Alkhateeb <
>>> slidingfilaments@gmail.com
>>>
>>>> wrote:
>>>> Hi Everyone,
>>>>
>>>> I cannot actually believe it but while I was working on a project (I
>>>> will
>>>> announce later) I discovered in the process that the below files cannot
>>>> compile!!! They existed for years in the code base without even being
>>>> able
>>>> to compile. They reference non existent libraries or they have faulty
>>>> code
>>>> (e.g. not importing used code)
>>>>
>>>> I propose to delete them immediately from trunk
>>>>
>>>>
>>>>
>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/cybersource/IcsPaymentServices.java
>>>>
>>>>
>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealEvents.java
>>>>
>>>>
>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealPaymentServiceTest.java
>>>>
>>>>
>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/orbital/OrbitalPaymentServices.java
>>>>
>>>>
>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/paypal/PayPalServices.java
>>>>
>>>>
>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayPaymentServices.java
>>>>
>>>>
>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayServiceTest.java
>>>>
>>>>
>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/verisign/PayflowPro.java
>>>>
>>>>
>>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayInputStream.java
>>>>
>>>>
>>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayOutputStream.java
>>>>
>>>>
>>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeServices.java
>>>>
>>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeWorker.java
>>>> applications/content/src/org/ofbiz/content/report
>>>>
>>>>
>>>> applications/content/src/org/ofbiz/content/report/JREntityListIteratorDataSource.java
>>>>
>>>>
>>>> applications/content/src/org/ofbiz/content/report/JRMapCollectionDataSource.java
>>>> applications/order/src/org/ofbiz/order/thirdparty/taxware
>>>>
>>>>
>>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareException.java
>>>>
>>>>
>>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareServices.java
>>>>
>>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareUTL.java
>>>> applications/product/src/ShipmentScaleApplet.java
>>>>
>>>>
>>>> applications/securityext/src/org/ofbiz/securityext/thirdparty/truition/TruitionCoReg.java
>>>>
>>>>
>>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsJXlsViewHandler.java
>>>>
>>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPdfViewHandler.java
>>>>
>>>>
>>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPoiXlsViewHandler.java
>>>>
>>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsXmlViewHandler.java
>>>>
>>>> Regards,
>>>>
>>>> Taher Alkhateeb
>>>>
>>>>
>>
>>
>
Re: Proposal to delete stale java files
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 14/06/2016 � 19:56, Ron Wheeler a �crit :
> Poorly documented, non-functioning code is not an attractive feature that will draw new users.
>
> If there are pieces that are being removed that you think are worth remembering, write a wiki note (it can be searched by Google) documenting these
> partially implemented features that can be recovered from the SCM if anyone cares in the future.
>
> The attic is a compromise to make hoarders feel comfortable but putting junk in the attic with no documentation about why things were written, why
> they are not finished or currently not used, is of questionable value. Non-functioning code that may be written to older standards or, worse yet,
> bad programming practices is just dangerous.
Better than throwing the baby with the bathwater, as we say in French (in other words remove without any mentions but in the commit log, good luck to
find anything there). You never know and would be surprised by what can happen sometimes...
>
> Is anyone willing to QC the code placed in the attic?
This could happen, again who knows and who can say better? We all know we have limited capable resources.
Jacques
>
> Ron
>
> On 14/06/2016 1:01 PM, Pierre Smits wrote:
>> As the majority of the referenced java files are related to 3rd party
>> solutions integrations, we should have done the smart thing and that is
>> provide them as optional Proof of Concept components. In stead we had/have
>> them as almost hard coded functionalities. Removing these from the code
>> base in trunk involves more. It means also removing the elements that
>> access these (directly and indirectly), including screen and form widgets,
>> templates, services and request and view map uris.
>>
>> But if we remove them from the code base (to the attic), before long the
>> knowledge will be lost and the feature set of OFBiz will shrink. Some may
>> not care about that, but it will - again - make the uphill adoption battle
>> more difficult.
>>
>> Best regards,
>>
>> Pierre Smits
>>
>> ORRTIZ.COM <http://www.orrtiz.com>
>> OFBiz based solutions & services
>>
>> OFBiz Extensions Marketplace
>> http://oem.ofbizci.net/oci-2/
>>
>> On Tue, Jun 14, 2016 at 4:10 PM, Taher Alkhateeb <slidingfilaments@gmail.com
>>> wrote:
>>> Hi Everyone,
>>>
>>> I cannot actually believe it but while I was working on a project (I will
>>> announce later) I discovered in the process that the below files cannot
>>> compile!!! They existed for years in the code base without even being able
>>> to compile. They reference non existent libraries or they have faulty code
>>> (e.g. not importing used code)
>>>
>>> I propose to delete them immediately from trunk
>>>
>>>
>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/cybersource/IcsPaymentServices.java
>>>
>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealEvents.java
>>>
>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealPaymentServiceTest.java
>>>
>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/orbital/OrbitalPaymentServices.java
>>>
>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/paypal/PayPalServices.java
>>>
>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayPaymentServices.java
>>>
>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayServiceTest.java
>>>
>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/verisign/PayflowPro.java
>>>
>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayInputStream.java
>>>
>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayOutputStream.java
>>>
>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeServices.java
>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeWorker.java
>>> applications/content/src/org/ofbiz/content/report
>>>
>>> applications/content/src/org/ofbiz/content/report/JREntityListIteratorDataSource.java
>>>
>>> applications/content/src/org/ofbiz/content/report/JRMapCollectionDataSource.java
>>> applications/order/src/org/ofbiz/order/thirdparty/taxware
>>>
>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareException.java
>>>
>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareServices.java
>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareUTL.java
>>> applications/product/src/ShipmentScaleApplet.java
>>>
>>> applications/securityext/src/org/ofbiz/securityext/thirdparty/truition/TruitionCoReg.java
>>>
>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsJXlsViewHandler.java
>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPdfViewHandler.java
>>>
>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPoiXlsViewHandler.java
>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsXmlViewHandler.java
>>>
>>> Regards,
>>>
>>> Taher Alkhateeb
>>>
>
>
Re: Proposal to delete stale java files
Posted by Ron Wheeler <rw...@artifact-software.com>.
Poorly documented, non-functioning code is not an attractive feature
that will draw new users.
If there are pieces that are being removed that you think are worth
remembering, write a wiki note (it can be searched by Google)
documenting these partially implemented features that can be recovered
from the SCM if anyone cares in the future.
The attic is a compromise to make hoarders feel comfortable but putting
junk in the attic with no documentation about why things were written,
why they are not finished or currently not used, is of questionable
value. Non-functioning code that may be written to older standards or,
worse yet, bad programming practices is just dangerous.
Is anyone willing to QC the code placed in the attic?
Ron
On 14/06/2016 1:01 PM, Pierre Smits wrote:
> As the majority of the referenced java files are related to 3rd party
> solutions integrations, we should have done the smart thing and that is
> provide them as optional Proof of Concept components. In stead we had/have
> them as almost hard coded functionalities. Removing these from the code
> base in trunk involves more. It means also removing the elements that
> access these (directly and indirectly), including screen and form widgets,
> templates, services and request and view map uris.
>
> But if we remove them from the code base (to the attic), before long the
> knowledge will be lost and the feature set of OFBiz will shrink. Some may
> not care about that, but it will - again - make the uphill adoption battle
> more difficult.
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM <http://www.orrtiz.com>
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Tue, Jun 14, 2016 at 4:10 PM, Taher Alkhateeb <slidingfilaments@gmail.com
>> wrote:
>> Hi Everyone,
>>
>> I cannot actually believe it but while I was working on a project (I will
>> announce later) I discovered in the process that the below files cannot
>> compile!!! They existed for years in the code base without even being able
>> to compile. They reference non existent libraries or they have faulty code
>> (e.g. not importing used code)
>>
>> I propose to delete them immediately from trunk
>>
>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/cybersource/IcsPaymentServices.java
>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealEvents.java
>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealPaymentServiceTest.java
>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/orbital/OrbitalPaymentServices.java
>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/paypal/PayPalServices.java
>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayPaymentServices.java
>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayServiceTest.java
>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/verisign/PayflowPro.java
>>
>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayInputStream.java
>>
>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayOutputStream.java
>>
>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeServices.java
>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeWorker.java
>> applications/content/src/org/ofbiz/content/report
>>
>> applications/content/src/org/ofbiz/content/report/JREntityListIteratorDataSource.java
>>
>> applications/content/src/org/ofbiz/content/report/JRMapCollectionDataSource.java
>> applications/order/src/org/ofbiz/order/thirdparty/taxware
>>
>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareException.java
>>
>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareServices.java
>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareUTL.java
>> applications/product/src/ShipmentScaleApplet.java
>>
>> applications/securityext/src/org/ofbiz/securityext/thirdparty/truition/TruitionCoReg.java
>>
>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsJXlsViewHandler.java
>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPdfViewHandler.java
>>
>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPoiXlsViewHandler.java
>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsXmlViewHandler.java
>>
>> Regards,
>>
>> Taher Alkhateeb
>>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: Proposal to delete stale java files
Posted by Pierre Smits <pi...@gmail.com>.
As the majority of the referenced java files are related to 3rd party
solutions integrations, we should have done the smart thing and that is
provide them as optional Proof of Concept components. In stead we had/have
them as almost hard coded functionalities. Removing these from the code
base in trunk involves more. It means also removing the elements that
access these (directly and indirectly), including screen and form widgets,
templates, services and request and view map uris.
But if we remove them from the code base (to the attic), before long the
knowledge will be lost and the feature set of OFBiz will shrink. Some may
not care about that, but it will - again - make the uphill adoption battle
more difficult.
Best regards,
Pierre Smits
ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services
OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/
On Tue, Jun 14, 2016 at 4:10 PM, Taher Alkhateeb <slidingfilaments@gmail.com
> wrote:
> Hi Everyone,
>
> I cannot actually believe it but while I was working on a project (I will
> announce later) I discovered in the process that the below files cannot
> compile!!! They existed for years in the code base without even being able
> to compile. They reference non existent libraries or they have faulty code
> (e.g. not importing used code)
>
> I propose to delete them immediately from trunk
>
>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/cybersource/IcsPaymentServices.java
>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealEvents.java
>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealPaymentServiceTest.java
>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/orbital/OrbitalPaymentServices.java
>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/paypal/PayPalServices.java
>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayPaymentServices.java
>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayServiceTest.java
>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/verisign/PayflowPro.java
>
> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayInputStream.java
>
> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayOutputStream.java
>
> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeServices.java
> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeWorker.java
> applications/content/src/org/ofbiz/content/report
>
> applications/content/src/org/ofbiz/content/report/JREntityListIteratorDataSource.java
>
> applications/content/src/org/ofbiz/content/report/JRMapCollectionDataSource.java
> applications/order/src/org/ofbiz/order/thirdparty/taxware
>
> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareException.java
>
> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareServices.java
> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareUTL.java
> applications/product/src/ShipmentScaleApplet.java
>
> applications/securityext/src/org/ofbiz/securityext/thirdparty/truition/TruitionCoReg.java
>
> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsJXlsViewHandler.java
> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPdfViewHandler.java
>
> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPoiXlsViewHandler.java
> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsXmlViewHandler.java
>
> Regards,
>
> Taher Alkhateeb
>
Re: Proposal to delete stale java files
Posted by Pierre Smits <pi...@gmail.com>.
Taher, all,
With respect to the /thirdparty/ideal functionality there already JIRA
issues registered (https://issues.apache.org/jira/browse/OFBIZ-5303, etc).
Best regards,
Pierre Smits
ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services
OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/
On Tue, Jun 14, 2016 at 4:22 PM, Taher Alkhateeb <slidingfilaments@gmail.com
> wrote:
> Hi Jacopo,
>
> Does that mean we should keep them? Mind you some of them have incorrect
> code (not importing EntityQuery for example). I'm not sure we want to keep
> dead code in trunk, unless people are using it?
>
> Regards,
>
> Taher Alkhateeb
>
> On Tue, Jun 14, 2016 at 5:18 PM, Jacopo Cappellato <
> jacopo.cappellato@hotwaxsystems.com> wrote:
>
> > Hi Taher,
> >
> > some background: these classes depends on jar files that have an
> > incompatible license that cannot be distributed with OFBiz; that is why
> > they are there but they are not built.
> >
> > Jacopo
> >
> > On Tue, Jun 14, 2016 at 4:10 PM, Taher Alkhateeb <
> > slidingfilaments@gmail.com
> > > wrote:
> >
> > > Hi Everyone,
> > >
> > > I cannot actually believe it but while I was working on a project (I
> will
> > > announce later) I discovered in the process that the below files cannot
> > > compile!!! They existed for years in the code base without even being
> > able
> > > to compile. They reference non existent libraries or they have faulty
> > code
> > > (e.g. not importing used code)
> > >
> > > I propose to delete them immediately from trunk
> > >
> > >
> > >
> >
> applications/accounting/src/org/ofbiz/accounting/thirdparty/cybersource/IcsPaymentServices.java
> > >
> > >
> >
> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealEvents.java
> > >
> > >
> >
> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealPaymentServiceTest.java
> > >
> > >
> >
> applications/accounting/src/org/ofbiz/accounting/thirdparty/orbital/OrbitalPaymentServices.java
> > >
> > >
> >
> applications/accounting/src/org/ofbiz/accounting/thirdparty/paypal/PayPalServices.java
> > >
> > >
> >
> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayPaymentServices.java
> > >
> > >
> >
> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayServiceTest.java
> > >
> > >
> >
> applications/accounting/src/org/ofbiz/accounting/thirdparty/verisign/PayflowPro.java
> > >
> > >
> >
> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayInputStream.java
> > >
> > >
> >
> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayOutputStream.java
> > >
> > >
> >
> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeServices.java
> > >
> >
> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeWorker.java
> > > applications/content/src/org/ofbiz/content/report
> > >
> > >
> >
> applications/content/src/org/ofbiz/content/report/JREntityListIteratorDataSource.java
> > >
> > >
> >
> applications/content/src/org/ofbiz/content/report/JRMapCollectionDataSource.java
> > > applications/order/src/org/ofbiz/order/thirdparty/taxware
> > >
> > >
> >
> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareException.java
> > >
> > >
> >
> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareServices.java
> > >
> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareUTL.java
> > > applications/product/src/ShipmentScaleApplet.java
> > >
> > >
> >
> applications/securityext/src/org/ofbiz/securityext/thirdparty/truition/TruitionCoReg.java
> > >
> > >
> >
> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsJXlsViewHandler.java
> > >
> >
> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPdfViewHandler.java
> > >
> > >
> >
> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPoiXlsViewHandler.java
> > >
> >
> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsXmlViewHandler.java
> > >
> > > Regards,
> > >
> > > Taher Alkhateeb
> > >
> >
>
Re: Proposal to delete stale java files
Posted by Jacques Le Roux <ja...@les7arts.com>.
This is now mostly history and I agree we should get rid of them if nobody complains. The best place for them would be Attic as we use to do and
mentioned by Pierre for Ideal.
I'd though like to keep the ShipmentScaleApplet.java file (blocked by NPL licence). Because, though I never used it myself, it's an example of how to
handle a Scale with Java.
Jacques
Le 14/06/2016 � 16:42, Jacopo Cappellato a �crit :
> I don't know if we should keep them, I don't have a strong opinion but if
> we decide to keep them they should be maintained and updated (otherwise
> they should go): my comment was simply to add some background.
>
> Jacopo
>
> On Tue, Jun 14, 2016 at 4:22 PM, Taher Alkhateeb <slidingfilaments@gmail.com
>> wrote:
>> Hi Jacopo,
>>
>> Does that mean we should keep them? Mind you some of them have incorrect
>> code (not importing EntityQuery for example). I'm not sure we want to keep
>> dead code in trunk, unless people are using it?
>>
>> Regards,
>>
>> Taher Alkhateeb
>>
>> On Tue, Jun 14, 2016 at 5:18 PM, Jacopo Cappellato <
>> jacopo.cappellato@hotwaxsystems.com> wrote:
>>
>>> Hi Taher,
>>>
>>> some background: these classes depends on jar files that have an
>>> incompatible license that cannot be distributed with OFBiz; that is why
>>> they are there but they are not built.
>>>
>>> Jacopo
>>>
>>> On Tue, Jun 14, 2016 at 4:10 PM, Taher Alkhateeb <
>>> slidingfilaments@gmail.com
>>>> wrote:
>>>> Hi Everyone,
>>>>
>>>> I cannot actually believe it but while I was working on a project (I
>> will
>>>> announce later) I discovered in the process that the below files cannot
>>>> compile!!! They existed for years in the code base without even being
>>> able
>>>> to compile. They reference non existent libraries or they have faulty
>>> code
>>>> (e.g. not importing used code)
>>>>
>>>> I propose to delete them immediately from trunk
>>>>
>>>>
>>>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/cybersource/IcsPaymentServices.java
>>>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealEvents.java
>>>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealPaymentServiceTest.java
>>>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/orbital/OrbitalPaymentServices.java
>>>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/paypal/PayPalServices.java
>>>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayPaymentServices.java
>>>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayServiceTest.java
>>>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/verisign/PayflowPro.java
>>>>
>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayInputStream.java
>>>>
>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayOutputStream.java
>>>>
>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeServices.java
>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeWorker.java
>>>> applications/content/src/org/ofbiz/content/report
>>>>
>>>>
>> applications/content/src/org/ofbiz/content/report/JREntityListIteratorDataSource.java
>>>>
>> applications/content/src/org/ofbiz/content/report/JRMapCollectionDataSource.java
>>>> applications/order/src/org/ofbiz/order/thirdparty/taxware
>>>>
>>>>
>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareException.java
>>>>
>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareServices.java
>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareUTL.java
>>>> applications/product/src/ShipmentScaleApplet.java
>>>>
>>>>
>> applications/securityext/src/org/ofbiz/securityext/thirdparty/truition/TruitionCoReg.java
>>>>
>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsJXlsViewHandler.java
>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPdfViewHandler.java
>>>>
>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPoiXlsViewHandler.java
>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsXmlViewHandler.java
>>>> Regards,
>>>>
>>>> Taher Alkhateeb
>>>>
Re: Proposal to delete stale java files
Posted by Jacopo Cappellato <ja...@hotwaxsystems.com>.
I don't know if we should keep them, I don't have a strong opinion but if
we decide to keep them they should be maintained and updated (otherwise
they should go): my comment was simply to add some background.
Jacopo
On Tue, Jun 14, 2016 at 4:22 PM, Taher Alkhateeb <slidingfilaments@gmail.com
> wrote:
> Hi Jacopo,
>
> Does that mean we should keep them? Mind you some of them have incorrect
> code (not importing EntityQuery for example). I'm not sure we want to keep
> dead code in trunk, unless people are using it?
>
> Regards,
>
> Taher Alkhateeb
>
> On Tue, Jun 14, 2016 at 5:18 PM, Jacopo Cappellato <
> jacopo.cappellato@hotwaxsystems.com> wrote:
>
> > Hi Taher,
> >
> > some background: these classes depends on jar files that have an
> > incompatible license that cannot be distributed with OFBiz; that is why
> > they are there but they are not built.
> >
> > Jacopo
> >
> > On Tue, Jun 14, 2016 at 4:10 PM, Taher Alkhateeb <
> > slidingfilaments@gmail.com
> > > wrote:
> >
> > > Hi Everyone,
> > >
> > > I cannot actually believe it but while I was working on a project (I
> will
> > > announce later) I discovered in the process that the below files cannot
> > > compile!!! They existed for years in the code base without even being
> > able
> > > to compile. They reference non existent libraries or they have faulty
> > code
> > > (e.g. not importing used code)
> > >
> > > I propose to delete them immediately from trunk
> > >
> > >
> > >
> >
> applications/accounting/src/org/ofbiz/accounting/thirdparty/cybersource/IcsPaymentServices.java
> > >
> > >
> >
> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealEvents.java
> > >
> > >
> >
> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealPaymentServiceTest.java
> > >
> > >
> >
> applications/accounting/src/org/ofbiz/accounting/thirdparty/orbital/OrbitalPaymentServices.java
> > >
> > >
> >
> applications/accounting/src/org/ofbiz/accounting/thirdparty/paypal/PayPalServices.java
> > >
> > >
> >
> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayPaymentServices.java
> > >
> > >
> >
> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayServiceTest.java
> > >
> > >
> >
> applications/accounting/src/org/ofbiz/accounting/thirdparty/verisign/PayflowPro.java
> > >
> > >
> >
> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayInputStream.java
> > >
> > >
> >
> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayOutputStream.java
> > >
> > >
> >
> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeServices.java
> > >
> >
> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeWorker.java
> > > applications/content/src/org/ofbiz/content/report
> > >
> > >
> >
> applications/content/src/org/ofbiz/content/report/JREntityListIteratorDataSource.java
> > >
> > >
> >
> applications/content/src/org/ofbiz/content/report/JRMapCollectionDataSource.java
> > > applications/order/src/org/ofbiz/order/thirdparty/taxware
> > >
> > >
> >
> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareException.java
> > >
> > >
> >
> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareServices.java
> > >
> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareUTL.java
> > > applications/product/src/ShipmentScaleApplet.java
> > >
> > >
> >
> applications/securityext/src/org/ofbiz/securityext/thirdparty/truition/TruitionCoReg.java
> > >
> > >
> >
> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsJXlsViewHandler.java
> > >
> >
> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPdfViewHandler.java
> > >
> > >
> >
> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPoiXlsViewHandler.java
> > >
> >
> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsXmlViewHandler.java
> > >
> > > Regards,
> > >
> > > Taher Alkhateeb
> > >
> >
>
Re: Proposal to delete stale java files
Posted by Taher Alkhateeb <sl...@gmail.com>.
Hi Jacopo,
Does that mean we should keep them? Mind you some of them have incorrect
code (not importing EntityQuery for example). I'm not sure we want to keep
dead code in trunk, unless people are using it?
Regards,
Taher Alkhateeb
On Tue, Jun 14, 2016 at 5:18 PM, Jacopo Cappellato <
jacopo.cappellato@hotwaxsystems.com> wrote:
> Hi Taher,
>
> some background: these classes depends on jar files that have an
> incompatible license that cannot be distributed with OFBiz; that is why
> they are there but they are not built.
>
> Jacopo
>
> On Tue, Jun 14, 2016 at 4:10 PM, Taher Alkhateeb <
> slidingfilaments@gmail.com
> > wrote:
>
> > Hi Everyone,
> >
> > I cannot actually believe it but while I was working on a project (I will
> > announce later) I discovered in the process that the below files cannot
> > compile!!! They existed for years in the code base without even being
> able
> > to compile. They reference non existent libraries or they have faulty
> code
> > (e.g. not importing used code)
> >
> > I propose to delete them immediately from trunk
> >
> >
> >
> applications/accounting/src/org/ofbiz/accounting/thirdparty/cybersource/IcsPaymentServices.java
> >
> >
> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealEvents.java
> >
> >
> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealPaymentServiceTest.java
> >
> >
> applications/accounting/src/org/ofbiz/accounting/thirdparty/orbital/OrbitalPaymentServices.java
> >
> >
> applications/accounting/src/org/ofbiz/accounting/thirdparty/paypal/PayPalServices.java
> >
> >
> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayPaymentServices.java
> >
> >
> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayServiceTest.java
> >
> >
> applications/accounting/src/org/ofbiz/accounting/thirdparty/verisign/PayflowPro.java
> >
> >
> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayInputStream.java
> >
> >
> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayOutputStream.java
> >
> >
> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeServices.java
> >
> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeWorker.java
> > applications/content/src/org/ofbiz/content/report
> >
> >
> applications/content/src/org/ofbiz/content/report/JREntityListIteratorDataSource.java
> >
> >
> applications/content/src/org/ofbiz/content/report/JRMapCollectionDataSource.java
> > applications/order/src/org/ofbiz/order/thirdparty/taxware
> >
> >
> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareException.java
> >
> >
> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareServices.java
> > applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareUTL.java
> > applications/product/src/ShipmentScaleApplet.java
> >
> >
> applications/securityext/src/org/ofbiz/securityext/thirdparty/truition/TruitionCoReg.java
> >
> >
> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsJXlsViewHandler.java
> >
> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPdfViewHandler.java
> >
> >
> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPoiXlsViewHandler.java
> >
> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsXmlViewHandler.java
> >
> > Regards,
> >
> > Taher Alkhateeb
> >
>
Re: Proposal to delete stale java files
Posted by Jacopo Cappellato <ja...@hotwaxsystems.com>.
Hi Taher,
some background: these classes depends on jar files that have an
incompatible license that cannot be distributed with OFBiz; that is why
they are there but they are not built.
Jacopo
On Tue, Jun 14, 2016 at 4:10 PM, Taher Alkhateeb <slidingfilaments@gmail.com
> wrote:
> Hi Everyone,
>
> I cannot actually believe it but while I was working on a project (I will
> announce later) I discovered in the process that the below files cannot
> compile!!! They existed for years in the code base without even being able
> to compile. They reference non existent libraries or they have faulty code
> (e.g. not importing used code)
>
> I propose to delete them immediately from trunk
>
>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/cybersource/IcsPaymentServices.java
>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealEvents.java
>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealPaymentServiceTest.java
>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/orbital/OrbitalPaymentServices.java
>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/paypal/PayPalServices.java
>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayPaymentServices.java
>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayServiceTest.java
>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/verisign/PayflowPro.java
>
> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayInputStream.java
>
> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayOutputStream.java
>
> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeServices.java
> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeWorker.java
> applications/content/src/org/ofbiz/content/report
>
> applications/content/src/org/ofbiz/content/report/JREntityListIteratorDataSource.java
>
> applications/content/src/org/ofbiz/content/report/JRMapCollectionDataSource.java
> applications/order/src/org/ofbiz/order/thirdparty/taxware
>
> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareException.java
>
> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareServices.java
> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareUTL.java
> applications/product/src/ShipmentScaleApplet.java
>
> applications/securityext/src/org/ofbiz/securityext/thirdparty/truition/TruitionCoReg.java
>
> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsJXlsViewHandler.java
> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPdfViewHandler.java
>
> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPoiXlsViewHandler.java
> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsXmlViewHandler.java
>
> Regards,
>
> Taher Alkhateeb
>
Re: Proposal to delete stale java files
Posted by Jacques Le Roux <ja...@les7arts.com>.
That's indeed the way it should be done, waiting for a way to have real addons support in OFBiz. Then OFBiz will be able to compete with its open
source concurrents, notably and mostly Oddo when we speak about addons.
Jacques
Le 15/06/2016 09:01, Mridul Pathak a crit :
> Yes, accounting/thirdparty has all the third party payment integrations supported by OFBiz. And, order/thridparty seems to have third party tax integration. We should not be deleting these files. I think we should refactor these third party integration files, and move these integrations to specialpurpose rather than keeping them with main applications. A bit off topic but shipping integrations reside with main application code as well, so that again is a candidate to be moved to specialpurpose. Any of such third party application integrations should be maintained separately.
>
> --
> Thanks & Regards,
> Mridul Pathak
> Senior Manager
> HotWax Systems
> http://www.hotwaxsystems.com
>
>> On Jun 15, 2016, at 12:00 PM, Ashish Vijaywargiya <as...@hotwaxsystems.com> wrote:
>>
>> I would prefer to keep Tax and Third Party Payment gateway files(The files
>> that does exists inside cybersource, ideal, orbital, paypal, securepay,
>> verisign etc). If you see some problems in those code base, like code base
>> is not updated based on latest changes then we can update those files.
>> Those files might have been used by so many users that we can't know
>> because we are doing this conversation on Dev mailing list. We should not
>> remove those files.
>>
>> --
>> Kind Regards
>> Ashish Vijaywargiya
>> HotWax Systems - est. 1997
>>
>> On Tue, Jun 14, 2016 at 7:40 PM, Taher Alkhateeb <slidingfilaments@gmail.com
>>> wrote:
>>> Hi Everyone,
>>>
>>> I cannot actually believe it but while I was working on a project (I will
>>> announce later) I discovered in the process that the below files cannot
>>> compile!!! They existed for years in the code base without even being able
>>> to compile. They reference non existent libraries or they have faulty code
>>> (e.g. not importing used code)
>>>
>>> I propose to delete them immediately from trunk
>>>
>>>
>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/cybersource/IcsPaymentServices.java
>>>
>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealEvents.java
>>>
>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealPaymentServiceTest.java
>>>
>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/orbital/OrbitalPaymentServices.java
>>>
>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/paypal/PayPalServices.java
>>>
>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayPaymentServices.java
>>>
>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayServiceTest.java
>>>
>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/verisign/PayflowPro.java
>>>
>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayInputStream.java
>>>
>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayOutputStream.java
>>>
>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeServices.java
>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeWorker.java
>>> applications/content/src/org/ofbiz/content/report
>>>
>>> applications/content/src/org/ofbiz/content/report/JREntityListIteratorDataSource.java
>>>
>>> applications/content/src/org/ofbiz/content/report/JRMapCollectionDataSource.java
>>> applications/order/src/org/ofbiz/order/thirdparty/taxware
>>>
>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareException.java
>>>
>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareServices.java
>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareUTL.java
>>> applications/product/src/ShipmentScaleApplet.java
>>>
>>> applications/securityext/src/org/ofbiz/securityext/thirdparty/truition/TruitionCoReg.java
>>>
>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsJXlsViewHandler.java
>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPdfViewHandler.java
>>>
>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPoiXlsViewHandler.java
>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsXmlViewHandler.java
>>>
>>> Regards,
>>>
>>> Taher Alkhateeb
>>>
>
>
Re: Proposal to delete stale java files
Posted by Jacques Le Roux <ja...@les7arts.com>.
Nicely said, thanks Sharan :)
Jacques
Le 15/06/2016 09:14, Sharan Foga a crit :
> Hi Everyone
>
> If we don't compromise on this then we are going to make the re-factoring effort that Taher is driving even harder. If we want to clean the code
> base (and I really think we do) then we need to take the some hard decisions. I'm sure that this won't be the last discussion over code removal so
> let's start getting used to it.
>
> The framework*must *have none of these dependencies (reverse or otherwise) so if we want to improve the quality of our code then the truth is - it
> really needs to go. In fact, for me these type of integrations fall into the addons category so that is what I think we should be looking at. If we
> need it then someone please re-write it as an OFBiz addon.
>
> We are going to totally transform our current trunk and when we are finished it will be totally different to what it is today. In the meantime
> please remember that we currently have 2 un-released OFBiz versions 14.12 and 15.12 where the code we are talking about will remain as it is. This
> will give us time to complete our transformation work and also time for our user base time to adjust to what will come.
>
> Thanks
> Sharan
>
> On 15/06/16 09:01, Mridul Pathak wrote:
>> Yes, accounting/thirdparty has all the third party payment integrations supported by OFBiz. And, order/thridparty seems to have third party tax
>> integration. We should not be deleting these files. I think we should refactor these third party integration files, and move these integrations to
>> specialpurpose rather than keeping them with main applications. A bit off topic but shipping integrations reside with main application code as
>> well, so that again is a candidate to be moved to specialpurpose. Any of such third party application integrations should be maintained separately.
>>
>> --
>> Thanks & Regards,
>> Mridul Pathak
>> Senior Manager
>> HotWax Systems
>> http://www.hotwaxsystems.com
>>
>>> On Jun 15, 2016, at 12:00 PM, Ashish Vijaywargiya <as...@hotwaxsystems.com> wrote:
>>>
>>> I would prefer to keep Tax and Third Party Payment gateway files(The files
>>> that does exists inside cybersource, ideal, orbital, paypal, securepay,
>>> verisign etc). If you see some problems in those code base, like code base
>>> is not updated based on latest changes then we can update those files.
>>> Those files might have been used by so many users that we can't know
>>> because we are doing this conversation on Dev mailing list. We should not
>>> remove those files.
>>>
>>> --
>>> Kind Regards
>>> Ashish Vijaywargiya
>>> HotWax Systems - est. 1997
>>>
>>> On Tue, Jun 14, 2016 at 7:40 PM, Taher Alkhateeb <slidingfilaments@gmail.com
>>>> wrote:
>>>> Hi Everyone,
>>>>
>>>> I cannot actually believe it but while I was working on a project (I will
>>>> announce later) I discovered in the process that the below files cannot
>>>> compile!!! They existed for years in the code base without even being able
>>>> to compile. They reference non existent libraries or they have faulty code
>>>> (e.g. not importing used code)
>>>>
>>>> I propose to delete them immediately from trunk
>>>>
>>>>
>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/cybersource/IcsPaymentServices.java
>>>>
>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealEvents.java
>>>>
>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealPaymentServiceTest.java
>>>>
>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/orbital/OrbitalPaymentServices.java
>>>>
>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/paypal/PayPalServices.java
>>>>
>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayPaymentServices.java
>>>>
>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayServiceTest.java
>>>>
>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/verisign/PayflowPro.java
>>>>
>>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayInputStream.java
>>>>
>>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayOutputStream.java
>>>>
>>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeServices.java
>>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeWorker.java
>>>> applications/content/src/org/ofbiz/content/report
>>>>
>>>> applications/content/src/org/ofbiz/content/report/JREntityListIteratorDataSource.java
>>>>
>>>> applications/content/src/org/ofbiz/content/report/JRMapCollectionDataSource.java
>>>> applications/order/src/org/ofbiz/order/thirdparty/taxware
>>>>
>>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareException.java
>>>>
>>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareServices.java
>>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareUTL.java
>>>> applications/product/src/ShipmentScaleApplet.java
>>>>
>>>> applications/securityext/src/org/ofbiz/securityext/thirdparty/truition/TruitionCoReg.java
>>>>
>>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsJXlsViewHandler.java
>>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPdfViewHandler.java
>>>>
>>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPoiXlsViewHandler.java
>>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsXmlViewHandler.java
>>>>
>>>> Regards,
>>>>
>>>> Taher Alkhateeb
>>>>
>
>
Re: Proposal to delete stale java files
Posted by Sharan Foga <sh...@gmail.com>.
Hi Everyone
If we don't compromise on this then we are going to make the
re-factoring effort that Taher is driving even harder. If we want to
clean the code base (and I really think we do) then we need to take the
some hard decisions. I'm sure that this won't be the last discussion
over code removal so let's start getting used to it.
The framework*must *have none of these dependencies (reverse or
otherwise) so if we want to improve the quality of our code then the
truth is - it really needs to go. In fact, for me these type of
integrations fall into the addons category so that is what I think we
should be looking at. If we need it then someone please re-write it as
an OFBiz addon.
We are going to totally transform our current trunk and when we are
finished it will be totally different to what it is today. In the
meantime please remember that we currently have 2 un-released OFBiz
versions 14.12 and 15.12 where the code we are talking about will remain
as it is. This will give us time to complete our transformation work and
also time for our user base time to adjust to what will come.
Thanks
Sharan
On 15/06/16 09:01, Mridul Pathak wrote:
> Yes, accounting/thirdparty has all the third party payment integrations supported by OFBiz. And, order/thridparty seems to have third party tax integration. We should not be deleting these files. I think we should refactor these third party integration files, and move these integrations to specialpurpose rather than keeping them with main applications. A bit off topic but shipping integrations reside with main application code as well, so that again is a candidate to be moved to specialpurpose. Any of such third party application integrations should be maintained separately.
>
> --
> Thanks & Regards,
> Mridul Pathak
> Senior Manager
> HotWax Systems
> http://www.hotwaxsystems.com
>
>> On Jun 15, 2016, at 12:00 PM, Ashish Vijaywargiya <as...@hotwaxsystems.com> wrote:
>>
>> I would prefer to keep Tax and Third Party Payment gateway files(The files
>> that does exists inside cybersource, ideal, orbital, paypal, securepay,
>> verisign etc). If you see some problems in those code base, like code base
>> is not updated based on latest changes then we can update those files.
>> Those files might have been used by so many users that we can't know
>> because we are doing this conversation on Dev mailing list. We should not
>> remove those files.
>>
>> --
>> Kind Regards
>> Ashish Vijaywargiya
>> HotWax Systems - est. 1997
>>
>> On Tue, Jun 14, 2016 at 7:40 PM, Taher Alkhateeb <slidingfilaments@gmail.com
>>> wrote:
>>> Hi Everyone,
>>>
>>> I cannot actually believe it but while I was working on a project (I will
>>> announce later) I discovered in the process that the below files cannot
>>> compile!!! They existed for years in the code base without even being able
>>> to compile. They reference non existent libraries or they have faulty code
>>> (e.g. not importing used code)
>>>
>>> I propose to delete them immediately from trunk
>>>
>>>
>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/cybersource/IcsPaymentServices.java
>>>
>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealEvents.java
>>>
>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealPaymentServiceTest.java
>>>
>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/orbital/OrbitalPaymentServices.java
>>>
>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/paypal/PayPalServices.java
>>>
>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayPaymentServices.java
>>>
>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayServiceTest.java
>>>
>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/verisign/PayflowPro.java
>>>
>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayInputStream.java
>>>
>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayOutputStream.java
>>>
>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeServices.java
>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeWorker.java
>>> applications/content/src/org/ofbiz/content/report
>>>
>>> applications/content/src/org/ofbiz/content/report/JREntityListIteratorDataSource.java
>>>
>>> applications/content/src/org/ofbiz/content/report/JRMapCollectionDataSource.java
>>> applications/order/src/org/ofbiz/order/thirdparty/taxware
>>>
>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareException.java
>>>
>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareServices.java
>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareUTL.java
>>> applications/product/src/ShipmentScaleApplet.java
>>>
>>> applications/securityext/src/org/ofbiz/securityext/thirdparty/truition/TruitionCoReg.java
>>>
>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsJXlsViewHandler.java
>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPdfViewHandler.java
>>>
>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPoiXlsViewHandler.java
>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsXmlViewHandler.java
>>>
>>> Regards,
>>>
>>> Taher Alkhateeb
>>>
Re: Proposal to delete stale java files
Posted by Mridul Pathak <mr...@hotwaxsystems.com>.
Yes, accounting/thirdparty has all the third party payment integrations supported by OFBiz. And, order/thridparty seems to have third party tax integration. We should not be deleting these files. I think we should refactor these third party integration files, and move these integrations to specialpurpose rather than keeping them with main applications. A bit off topic but shipping integrations reside with main application code as well, so that again is a candidate to be moved to specialpurpose. Any of such third party application integrations should be maintained separately.
--
Thanks & Regards,
Mridul Pathak
Senior Manager
HotWax Systems
http://www.hotwaxsystems.com
> On Jun 15, 2016, at 12:00 PM, Ashish Vijaywargiya <as...@hotwaxsystems.com> wrote:
>
> I would prefer to keep Tax and Third Party Payment gateway files(The files
> that does exists inside cybersource, ideal, orbital, paypal, securepay,
> verisign etc). If you see some problems in those code base, like code base
> is not updated based on latest changes then we can update those files.
> Those files might have been used by so many users that we can't know
> because we are doing this conversation on Dev mailing list. We should not
> remove those files.
>
> --
> Kind Regards
> Ashish Vijaywargiya
> HotWax Systems - est. 1997
>
> On Tue, Jun 14, 2016 at 7:40 PM, Taher Alkhateeb <slidingfilaments@gmail.com
>> wrote:
>
>> Hi Everyone,
>>
>> I cannot actually believe it but while I was working on a project (I will
>> announce later) I discovered in the process that the below files cannot
>> compile!!! They existed for years in the code base without even being able
>> to compile. They reference non existent libraries or they have faulty code
>> (e.g. not importing used code)
>>
>> I propose to delete them immediately from trunk
>>
>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/cybersource/IcsPaymentServices.java
>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealEvents.java
>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealPaymentServiceTest.java
>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/orbital/OrbitalPaymentServices.java
>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/paypal/PayPalServices.java
>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayPaymentServices.java
>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayServiceTest.java
>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/verisign/PayflowPro.java
>>
>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayInputStream.java
>>
>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayOutputStream.java
>>
>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeServices.java
>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeWorker.java
>> applications/content/src/org/ofbiz/content/report
>>
>> applications/content/src/org/ofbiz/content/report/JREntityListIteratorDataSource.java
>>
>> applications/content/src/org/ofbiz/content/report/JRMapCollectionDataSource.java
>> applications/order/src/org/ofbiz/order/thirdparty/taxware
>>
>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareException.java
>>
>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareServices.java
>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareUTL.java
>> applications/product/src/ShipmentScaleApplet.java
>>
>> applications/securityext/src/org/ofbiz/securityext/thirdparty/truition/TruitionCoReg.java
>>
>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsJXlsViewHandler.java
>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPdfViewHandler.java
>>
>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPoiXlsViewHandler.java
>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsXmlViewHandler.java
>>
>> Regards,
>>
>> Taher Alkhateeb
>>
Re: Proposal to delete stale java files
Posted by Divesh Dutta <di...@hotwaxsystems.com>.
Yea this makes sense to not to completely delete those thirty party
integration files and move them to special purpose (and make them
pluggable in future with better architechture). So +1 for this proposal.
Thanks
--
Divesh Dutta.
On Wed, Jun 15, 2016 at 1:27 PM, Jacopo Cappellato <
jacopo.cappellato@hotwaxsystems.com> wrote:
> Based on the new comments it seems like that we could isolate the shipment,
> payment and tax integration classes (and artifacts that use them) into
> their own specialpurpose components (waiting for a better pluggable
> components architecture); they will not be compiled by default but each
> component will have its own readme file containing instructions about how
> to deploy and use them.
> As regards the JasperReports*, JRE* and openoffice ones I think they can go
> to Attic since they are old and unmaintained.
>
> Does it make sense? Any volunteers to create the new specialpurpose
> components and upgrade/isolate the shipment/payment/tax integration classes
> into them?
>
> Jacopo
>
> On Wed, Jun 15, 2016 at 9:32 AM, Hans Bakker <h....@antwebsystems.com>
> wrote:
>
> > +1
> >
> >
> > On 15/06/16 13:30, Ashish Vijaywargiya wrote:
> >
> >> I would prefer to keep Tax and Third Party Payment gateway files(The
> files
> >> that does exists inside cybersource, ideal, orbital, paypal, securepay,
> >> verisign etc). If you see some problems in those code base, like code
> base
> >> is not updated based on latest changes then we can update those files.
> >> Those files might have been used by so many users that we can't know
> >> because we are doing this conversation on Dev mailing list. We should
> not
> >> remove those files.
> >>
> >> --
> >> Kind Regards
> >> Ashish Vijaywargiya
> >> HotWax Systems - est. 1997
> >>
> >> On Tue, Jun 14, 2016 at 7:40 PM, Taher Alkhateeb <
> >> slidingfilaments@gmail.com
> >>
> >>> wrote:
> >>>
> >>
> >> Hi Everyone,
> >>>
> >>> I cannot actually believe it but while I was working on a project (I
> will
> >>> announce later) I discovered in the process that the below files cannot
> >>> compile!!! They existed for years in the code base without even being
> >>> able
> >>> to compile. They reference non existent libraries or they have faulty
> >>> code
> >>> (e.g. not importing used code)
> >>>
> >>> I propose to delete them immediately from trunk
> >>>
> >>>
> >>>
> >>>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/cybersource/IcsPaymentServices.java
> >>>
> >>>
> >>>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealEvents.java
> >>>
> >>>
> >>>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealPaymentServiceTest.java
> >>>
> >>>
> >>>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/orbital/OrbitalPaymentServices.java
> >>>
> >>>
> >>>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/paypal/PayPalServices.java
> >>>
> >>>
> >>>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayPaymentServices.java
> >>>
> >>>
> >>>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayServiceTest.java
> >>>
> >>>
> >>>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/verisign/PayflowPro.java
> >>>
> >>>
> >>>
> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayInputStream.java
> >>>
> >>>
> >>>
> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayOutputStream.java
> >>>
> >>>
> >>>
> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeServices.java
> >>>
> >>>
> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeWorker.java
> >>> applications/content/src/org/ofbiz/content/report
> >>>
> >>>
> >>>
> applications/content/src/org/ofbiz/content/report/JREntityListIteratorDataSource.java
> >>>
> >>>
> >>>
> applications/content/src/org/ofbiz/content/report/JRMapCollectionDataSource.java
> >>> applications/order/src/org/ofbiz/order/thirdparty/taxware
> >>>
> >>>
> >>>
> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareException.java
> >>>
> >>>
> >>>
> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareServices.java
> >>>
> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareUTL.java
> >>> applications/product/src/ShipmentScaleApplet.java
> >>>
> >>>
> >>>
> applications/securityext/src/org/ofbiz/securityext/thirdparty/truition/TruitionCoReg.java
> >>>
> >>>
> >>>
> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsJXlsViewHandler.java
> >>>
> >>>
> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPdfViewHandler.java
> >>>
> >>>
> >>>
> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPoiXlsViewHandler.java
> >>>
> >>>
> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsXmlViewHandler.java
> >>>
> >>> Regards,
> >>>
> >>> Taher Alkhateeb
> >>>
> >>>
> >>
> > --
> >
> > Regards,
> >
> > Hans Bakker
> > CEO, http://antwebsystems.com
> >
>
Re: Proposal to delete stale java files
Posted by Mridul Pathak <mr...@hotwaxsystems.com>.
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 <sl...@gmail.com> 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 <
> jacques.le.roux@les7arts.com> 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 <
>>> mridul.pathak@hotwaxsystems.com> 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 <pi...@gmail.com>
>>>>>
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> Moving all 3rd party related integrations solutions from accounting,
>>>>> product and order into 1 special purpose component makes is worse to
>>>>> maintain. Moving those from accounting into one in special purpose,
>>>>> those
>>>>> from product into one and those from order into another just shifts the
>>>>> problem from the base applications stack to a another stack, which is
>>>>> the
>>>>> complexity that results from the total being being bigger than the sum
>>>>> of
>>>>> its parts.
>>>>>
>>>>> I understand and accept that there might be adopters of old release out
>>>>> there that are still on those old releases and use some (or all) of the
>>>>>
>>>> 3rd
>>>>
>>>>> party integrations. But I believe that breaking these sets up in to the
>>>>> smaller components not only makes maintenance less complex but also
>>>>> increases the appeal of OFBiz (visavis completeness and flexibility).
>>>>>
>>>> Given
>>>>
>>>>> that this is in the 'improvement' section of what we do, I understand
>>>>>
>>>> that,
>>>>
>>>>> it won't be back ported to running release branches. So, there is a
>>>>> means
>>>>> to communicate up front and prepare the adopters who want to migrate.
>>>>>
>>>>> Therefore I suggest we split the 3rd party payment solutions
>>>>> integrations
>>>>> up into:
>>>>> /specialpurpose/paypay
>>>>> /specialpurpose/orbital
>>>>> etc
>>>>>
>>>>> and the 3rd party shipment solutions integrations up into:
>>>>> /specialpurpose/dhl
>>>>> /specialpurpose/fedex
>>>>> /specialpurpose/ups
>>>>> etc
>>>>>
>>>>> and the same for the other 3rd party solutions integrations.
>>>>>
>>>>> After all, these functionalities should be optionals, not mandatories
>>>>>
>>>> from
>>>>
>>>>> an integration perspective. Splitting them up will also bring the
>>>>> benefit
>>>>> of easier maintenance, bringing in contributors who are experienced with
>>>>> that piece of software and if adoption/use is 0, an easier path to the
>>>>> attic (in stead of waiting and waiting untill all goes to being unused.
>>>>>
>>>>> Bringing this to separate components in special purpose doesn't mean we
>>>>> need to bring those into the build process (as long as they are not
>>>>>
>>>> fixed).
>>>>
>>>>> Leaving them out of the component-load.xml file (or commented out) will
>>>>> avoid that, and give adopters an opt-in choice.
>>>>>
>>>>> So to recap:
>>>>> +1 on the move out of the base applications stack
>>>>> -1 on the move in catch-all components in another stack.
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Pierre Smits
>>>>>
>>>>> ORRTIZ.COM <http://www.orrtiz.com>
>>>>> OFBiz based solutions & services
>>>>>
>>>>> OFBiz Extensions Marketplace
>>>>> http://oem.ofbizci.net/oci-2/
>>>>>
>>>>> On Thu, Jun 16, 2016 at 7:57 PM, Taher Alkhateeb <
>>>>>
>>>> slidingfilaments@gmail.com
>>>>
>>>>> wrote:
>>>>>> +1 thank you for your dedication and thinking of this
>>>>>> On Jun 16, 2016 8:55 PM, "Mridul Pathak" <
>>>>>>
>>>>> mridul.pathak@hotwaxsystems.com>
>>>>
>>>>> wrote:
>>>>>>
>>>>>> Hi Taher,
>>>>>>>
>>>>>>> I was just trying to suggest that we will have to create two
>>>>>>> components
>>>>>>>
>>>>>> in
>>>>>>
>>>>>>> specialpurpose, one for payment processor related functionality and
>>>>>>> one
>>>>>>>
>>>>>> for
>>>>>>
>>>>>>> tax related functionality and the reason behind it. Which means we
>>>>>>>
>>>>>> should
>>>>
>>>>> probably drop the idea of introducing a directory named “reference” and
>>>>>>> instead create two separate components.
>>>>>>>
>>>>>>> Our main goal here is to move these files out of core applications and
>>>>>>> most of us are fine with moving it to specialpurpose. I think we can
>>>>>>> conclude our approach as most of us seems fine with having two
>>>>>>> separate
>>>>>>> components in specialpurpose which was the original suggestion as
>>>>>>> well.
>>>>>>>
>>>>>>> --
>>>>>>> Thanks & Regards,
>>>>>>> Mridul Pathak
>>>>>>> HotWax Systems
>>>>>>> http://www.hotwaxsystems.com
>>>>>>>
>>>>>>> On Jun 16, 2016, at 8:23 PM, Taher Alkhateeb <
>>>>>>>>
>>>>>>> slidingfilaments@gmail.com>
>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Mridul,
>>>>>>>>
>>>>>>>> Thank you for the detailed and well thought out feedback.
>>>>>>>>
>>>>>>>> I am a little confused however, what is the point you are trying to
>>>>>>>>
>>>>>>> state?
>>>>>>>
>>>>>>>> The only point from my previous email was to suggest avoiding
>>>>>>>> creating
>>>>>>>>
>>>>>>> a
>>>>>>
>>>>>>> directory called reference in the top level ofbiz directory and
>>>>>>>>
>>>>>>> instead
>>>>
>>>>> keep it in /specialpurpose. If you want to keep it in
>>>>>>>> specialpurpose/reference, fine, if you want to keep it in
>>>>>>>> specialpurpose/your-component-here fine, if you want to do anything
>>>>>>>> in
>>>>>>>> specialpurpose then also fine My point was simply to suggest steering
>>>>>>>>
>>>>>>> away
>>>>>>>
>>>>>>>> from ofbiz top level directory.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Taher Alkhateeb
>>>>>>>>
>>>>>>>> On Thu, Jun 16, 2016 at 5:34 PM, Mridul Pathak <
>>>>>>>> mridul.pathak@hotwaxsystems.com> wrote:
>>>>>>>>
>>>>>>>> Hi Taher,
>>>>>>>>>
>>>>>>>>> Payment integration files in accounting/thirdparty are not just
>>>>>>>>>
>>>>>>>> unused
>>>>
>>>>> files and all of it is not dead code. There is the whole
>>>>>>>>>
>>>>>>>> functionality
>>>>
>>>>> built around those files which is very crucial to production delivery
>>>>>>>>>
>>>>>>>> of
>>>>>>
>>>>>>> order management or ecommerce on top of OFBiz. There are many service
>>>>>>>>> definition files whose implementation is written in these java
>>>>>>>>> files.
>>>>>>>>>
>>>>>>>> Some
>>>>>>>
>>>>>>>> examples are,
>>>>>>>>>
>>>>>>>>> accounting/servicedef/services_authorizedotnet.xml
>>>>>>>>> accounting/servicedef/services_clearcommerce.xml
>>>>>>>>> accounting/servicedef/services_cybersource.xml
>>>>>>>>> accounting/servicedef/services_orbital.xml
>>>>>>>>> accounting/servicedef/services_paypal.xml
>>>>>>>>> etc.
>>>>>>>>>
>>>>>>>>> Along with that, many of the configurations needed to use these
>>>>>>>>>
>>>>>>>> payment
>>>>>>
>>>>>>> solutions are maintained in accounting/config/payment.properties
>>>>>>>>>
>>>>>>>> file. A
>>>>>>
>>>>>>> ProductStore in OFBiz as well can be configures to use on of these
>>>>>>>>>
>>>>>>>> payment
>>>>>>>
>>>>>>>> processors.
>>>>>>>>>
>>>>>>>>> Also, these file are intentionally excluded from compile process,
>>>>>>>>> but
>>>>>>>>>
>>>>>>>> can
>>>>>>>
>>>>>>>> be included if you want to use/deliver one of these existing payment
>>>>>>>>> solution in OFBiz in production. Following is the code snippet from
>>>>>>>>> accounting/build.xml,
>>>>>>>>>
>>>>>>>>> <target name="init">
>>>>>>>>> <condition property="verisign-exclude"
>>>>>>>>> value="org/ofbiz/accounting/thirdparty/verisign/**">
>>>>>>>>> <not><available file="lib/payflow.jar"/></not>
>>>>>>>>> </condition>
>>>>>>>>> <patternset id="src.exc.set">
>>>>>>>>> <!-- exclude the payment processor packages; comment this out
>>>>>>>>>
>>>>>>>> to
>>>>>>
>>>>>>> not exclude if you have libs -->
>>>>>>>>> <exclude name="${verisign-exclude}"/>
>>>>>>>>> <exclude
>>>>>>>>>
>>>>>>>> name="org/ofbiz/accounting/thirdparty/cybersource/**"/>
>>>>>>
>>>>>>> <exclude
>>>>>>>>> name="org/ofbiz/accounting/thirdparty/paypal/PayPalServices.java"/>
>>>>>>>>> <exclude name="org/ofbiz/accounting/thirdparty/orbital/**"/>
>>>>>>>>> <exclude
>>>>>>>>> name="org/ofbiz/accounting/thirdparty/securepay/**"/>
>>>>>>>>> <exclude name="org/ofbiz/accounting/thirdparty/ideal/**"/>
>>>>>>>>> </patternset>
>>>>>>>>> </target>
>>>>>>>>>
>>>>>>>>> It clearly mentions that if you have required libraries for any of
>>>>>>>>>
>>>>>>>> the
>>>>
>>>>> third party payment solutions, you could comment out the exclusion.
>>>>>>>>> Usually, when someone needs to use one of the available payment
>>>>>>>>>
>>>>>>>> processor,
>>>>>>>
>>>>>>>> they download the required jar and place it in accounting/lib folder,
>>>>>>>>>
>>>>>>>> make
>>>>>>>
>>>>>>>> the needed changes in build.xml and they are ready to use the
>>>>>>>>>
>>>>>>>> respective
>>>>>>
>>>>>>> payment solution.
>>>>>>>>>
>>>>>>>>> We have used one or the other payment processors in OFBiz many a
>>>>>>>>>
>>>>>>>> times
>>>>
>>>>> to
>>>>>>>
>>>>>>>> deliver payment solutions as part of the software. I believe there
>>>>>>>>>
>>>>>>>> are
>>>>
>>>>> many
>>>>>>>
>>>>>>>> application users and service providers who might be using the
>>>>>>>>>
>>>>>>>> payment
>>>>
>>>>> processor functionality that comes with OFBiz OOTB.
>>>>>>>>>
>>>>>>>>> So, it’s not just about moving some files from core applications to
>>>>>>>>>
>>>>>>>> some
>>>>>>
>>>>>>> other directory because they seems to be unused, the whole
>>>>>>>>>
>>>>>>>> functionality
>>>>>>
>>>>>>> needs to be moved so that current or future users of these
>>>>>>>>>
>>>>>>>> functionalities
>>>>>>>
>>>>>>>> can still use it. And that is the reason if we create a new special
>>>>>>>>>
>>>>>>>> purpose
>>>>>>>
>>>>>>>> component it will help us to keep the functionality intact and usable
>>>>>>>>>
>>>>>>>> at
>>>>>>
>>>>>>> the same time separate it from core applications. That would also
>>>>>>>>>
>>>>>>>> enable us
>>>>>>>
>>>>>>>> to keep such components out of component-load.xml and
>>>>>>>>> specialpurpose/build.xml. A README file would help the user with
>>>>>>>>>
>>>>>>>> directions
>>>>>>>
>>>>>>>> to use it.
>>>>>>>>>
>>>>>>>>> Additionally, I feel that most of these files may need to be
>>>>>>>>> upgraded
>>>>>>>>>
>>>>>>>> and
>>>>>>>
>>>>>>>> needs code refactoring probably because they might usually be left
>>>>>>>>>
>>>>>>>> out
>>>>
>>>>> as
>>>>>>>
>>>>>>>> they do not compile by default with OFBiz.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Thanks & Regards,
>>>>>>>>> Mridul Pathak
>>>>>>>>> HotWax Systems
>>>>>>>>> http://www.hotwaxsystems.com
>>>>>>>>>
>>>>>>>>> On Jun 16, 2016, at 6:44 PM, Taher Alkhateeb <
>>>>>>>>>>
>>>>>>>>> slidingfilaments@gmail.com>
>>>>>>>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hey Folks,
>>>>>>>>>>
>>>>>>>>>> I would prefer to keep dead code away from the top level OFBiz
>>>>>>>>>>
>>>>>>>>> directory.
>>>>>>>
>>>>>>>> If you keep it there then you make it _closer_ to the framework!
>>>>>>>>>>
>>>>>>>>>> Anyway, I don't see a problem with keeping it in specialpurpose!
>>>>>>>>>> You
>>>>>>>>>>
>>>>>>>>> are
>>>>>>>
>>>>>>>> not creating a component, you are just creating a folder called
>>>>>>>>>>
>>>>>>>>> reference
>>>>>>>
>>>>>>>> and adding stuff to it, and you are not adding it to
>>>>>>>>>>
>>>>>>>>> component-load.xml?
>>>>>>>
>>>>>>>> Why is it that you cannot add it there?
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>>
>>>>>>>>>> Taher Alkhateeb
>>>>>>>>>>
>>>>>>>>>> On Thu, Jun 16, 2016 at 3:55 PM, Mridul Pathak <
>>>>>>>>>> mridul.pathak@hotwaxsystems.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Introducing new directory “reference” seems reasonable approach to
>>>>>>>>>>>
>>>>>>>>>> me
>>>>>>
>>>>>>> as
>>>>>>>
>>>>>>>> it is a combined solution to everyone’s views.
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Thanks & Regards,
>>>>>>>>>>> Mridul Pathak
>>>>>>>>>>> Senior Manager
>>>>>>>>>>> HotWax Systems
>>>>>>>>>>> http://www.hotwaxsystems.com
>>>>>>>>>>>
>>>>>>>>>>> On Jun 16, 2016, at 5:56 PM, Jacques Le Roux <
>>>>>>>>>>>>
>>>>>>>>>>> jacques.le.roux@les7arts.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Divesh,
>>>>>>>>>>>>
>>>>>>>>>>>> Le 16/06/2016 à 13:38, Divesh Dutta a écrit :
>>>>>>>>>>>>
>>>>>>>>>>>>> 3- In the case of non-compiling / broken / missing dependencies
>>>>>>>>>>>>>>
>>>>>>>>>>>>> code
>>>>>>>
>>>>>>>> highlight this issue somewhere visible to the programmer
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> (README,
>>>>>>>
>>>>>>>> whatever). Why is this important? Because we need to tell our
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> build
>>>>>>>>>
>>>>>>>>>> scripts
>>>>>>>>>>>>>>>>> and our classpath settings to ignore these files.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The reason why I suggested to keep all of them in
>>>>>>>>>>>>>>>>> /reference/each-component-name-here is to tell the build
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> system
>>>>>>
>>>>>>> to
>>>>>>>
>>>>>>>> ignore
>>>>>>>>>>>
>>>>>>>>>>>> all Java files found in /specialpurpose/reference. If you
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> instead
>>>>>>>
>>>>>>>> break it
>>>>>>>>>>>
>>>>>>>>>>>> up into multiple components, then I need to ignore the files
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> in
>>>>>>
>>>>>>> each
>>>>>>>>>
>>>>>>>>>> component by hand which makes the build script more complex
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> and
>>>>>>
>>>>>>> more prone
>>>>>>>>>>>
>>>>>>>>>>>> to human error and it would add to the confusion.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I agree and I think your initial proposition ("How about
>>>>>>>>>>>>>>> reference/paymentext and reference/whatever-else-you-want?")
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> was
>>>>
>>>>> not
>>>>>>>
>>>>>>>> clearly understood by Pierre and maybe not Divesh. Pierre,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Divesh?
>>>>>>
>>>>>>> Actually Jacques, we cannot create component like
>>>>>>>>>>>>> specialpurpose/reference/paymentext . Other way can be we
>>>>>>>>>>>>>
>>>>>>>>>>>> introduce
>>>>>>
>>>>>>> new
>>>>>>>>>
>>>>>>>>>> directory "reference" in parallel to specialpurpose, applications
>>>>>>>>>>>>>
>>>>>>>>>>>> ,
>>>>>>
>>>>>>> framework . Do you mean to do that ?
>>>>>>>>>>>>>
>>>>>>>>>>>> You are right, and following Taher's idea I missed this point, it
>>>>>>>>>>>>
>>>>>>>>>>> seems
>>>>>>>
>>>>>>>> to me that your proposition of <<introducing a new directory
>>>>>>>>>>>
>>>>>>>>>> "reference" in
>>>>>>>>>
>>>>>>>>>> parallel to specialpurpose, applications ,framework>> is the best
>>>>>>>>>>>
>>>>>>>>>> one
>>>>>>
>>>>>>> so
>>>>>>>
>>>>>>>> far.
>>>>>>>>>>>
>>>>>>>>>>>> It could be also that Taher anticipated on the work (I know) he
>>>>>>>>>>>>
>>>>>>>>>>> will
>>>>>>
>>>>>>> do
>>>>>>>
>>>>>>>> on refactoring the build system and this possibility will be open
>>>>>>>>>>>
>>>>>>>>>> "soon",
>>>>>>>>>
>>>>>>>>>> Taher?
>>>>>>>>>>>
>>>>>>>>>>>> Also as Mridul put it, and you agreed, the "shipping
>>>>>>>>>>>>>
>>>>>>>>>>>> integration/s"
>>>>>>
>>>>>>> which
>>>>>>>>>>>
>>>>>>>>>>>> "doesn’t have the compilation or library reference issues"
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> would
>>>>
>>>>> be
>>>>>>>
>>>>>>>> in its
>>>>>>>>>>>
>>>>>>>>>>>> own independent component/s (ie not under /reference), same for
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> other
>>>>>>>>>
>>>>>>>>>> stuff
>>>>>>>>>>>
>>>>>>>>>>>> with the same status, if exist.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In this case, shipping integration can be under special
>>>>>>>>>>>>> purpose.
>>>>>>>>>>>>>
>>>>>>>>>>>> So
>>>>>>
>>>>>>> specialpurpose/shippingIntegratio.
>>>>>>>>>>>>>
>>>>>>>>>>>> Clearly, nobrainer :)
>>>>>>>>>>>>
>>>>>>>>>>>> Jacques
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Divesh Dutta.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>
>>
Re: Proposal to delete stale java files
Posted by Taher Alkhateeb <sl...@gmail.com>.
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 <
jacopo.cappellato@hotwaxsystems.com> 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 <
> slidingfilaments@gmail.com
> > 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 <
> > slidingfilaments@gmail.com
> > > 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 <
> > > jacques.le.roux@les7arts.com> 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 <
> > >>> mridul.pathak@hotwaxsystems.com> 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 <pi...@gmail.com>
> > >>>>>
> > >>>> wrote:
> > >>>>
> > >>>>> Hi all,
> > >>>>>
> > >>>>> Moving all 3rd party related integrations solutions from
> accounting,
> > >>>>> product and order into 1 special purpose component makes is worse
> to
> > >>>>> maintain. Moving those from accounting into one in special purpose,
> > >>>>> those
> > >>>>> from product into one and those from order into another just shifts
> > the
> > >>>>> problem from the base applications stack to a another stack, which
> is
> > >>>>> the
> > >>>>> complexity that results from the total being being bigger than the
> > sum
> > >>>>> of
> > >>>>> its parts.
> > >>>>>
> > >>>>> I understand and accept that there might be adopters of old release
> > out
> > >>>>> there that are still on those old releases and use some (or all) of
> > the
> > >>>>>
> > >>>> 3rd
> > >>>>
> > >>>>> party integrations. But I believe that breaking these sets up in to
> > the
> > >>>>> smaller components not only makes maintenance less complex but also
> > >>>>> increases the appeal of OFBiz (visavis completeness and
> flexibility).
> > >>>>>
> > >>>> Given
> > >>>>
> > >>>>> that this is in the 'improvement' section of what we do, I
> understand
> > >>>>>
> > >>>> that,
> > >>>>
> > >>>>> it won't be back ported to running release branches. So, there is a
> > >>>>> means
> > >>>>> to communicate up front and prepare the adopters who want to
> migrate.
> > >>>>>
> > >>>>> Therefore I suggest we split the 3rd party payment solutions
> > >>>>> integrations
> > >>>>> up into:
> > >>>>> /specialpurpose/paypay
> > >>>>> /specialpurpose/orbital
> > >>>>> etc
> > >>>>>
> > >>>>> and the 3rd party shipment solutions integrations up into:
> > >>>>> /specialpurpose/dhl
> > >>>>> /specialpurpose/fedex
> > >>>>> /specialpurpose/ups
> > >>>>> etc
> > >>>>>
> > >>>>> and the same for the other 3rd party solutions integrations.
> > >>>>>
> > >>>>> After all, these functionalities should be optionals, not
> mandatories
> > >>>>>
> > >>>> from
> > >>>>
> > >>>>> an integration perspective. Splitting them up will also bring the
> > >>>>> benefit
> > >>>>> of easier maintenance, bringing in contributors who are experienced
> > >>>>> with
> > >>>>> that piece of software and if adoption/use is 0, an easier path to
> > the
> > >>>>> attic (in stead of waiting and waiting untill all goes to being
> > unused.
> > >>>>>
> > >>>>> Bringing this to separate components in special purpose doesn't
> mean
> > we
> > >>>>> need to bring those into the build process (as long as they are not
> > >>>>>
> > >>>> fixed).
> > >>>>
> > >>>>> Leaving them out of the component-load.xml file (or commented out)
> > will
> > >>>>> avoid that, and give adopters an opt-in choice.
> > >>>>>
> > >>>>> So to recap:
> > >>>>> +1 on the move out of the base applications stack
> > >>>>> -1 on the move in catch-all components in another stack.
> > >>>>>
> > >>>>> Best regards,
> > >>>>>
> > >>>>> Pierre Smits
> > >>>>>
> > >>>>> ORRTIZ.COM <http://www.orrtiz.com>
> > >>>>> OFBiz based solutions & services
> > >>>>>
> > >>>>> OFBiz Extensions Marketplace
> > >>>>> http://oem.ofbizci.net/oci-2/
> > >>>>>
> > >>>>> On Thu, Jun 16, 2016 at 7:57 PM, Taher Alkhateeb <
> > >>>>>
> > >>>> slidingfilaments@gmail.com
> > >>>>
> > >>>>> wrote:
> > >>>>>> +1 thank you for your dedication and thinking of this
> > >>>>>> On Jun 16, 2016 8:55 PM, "Mridul Pathak" <
> > >>>>>>
> > >>>>> mridul.pathak@hotwaxsystems.com>
> > >>>>
> > >>>>> wrote:
> > >>>>>>
> > >>>>>> Hi Taher,
> > >>>>>>>
> > >>>>>>> I was just trying to suggest that we will have to create two
> > >>>>>>> components
> > >>>>>>>
> > >>>>>> in
> > >>>>>>
> > >>>>>>> specialpurpose, one for payment processor related functionality
> and
> > >>>>>>> one
> > >>>>>>>
> > >>>>>> for
> > >>>>>>
> > >>>>>>> tax related functionality and the reason behind it. Which means
> we
> > >>>>>>>
> > >>>>>> should
> > >>>>
> > >>>>> probably drop the idea of introducing a directory named “reference”
> > and
> > >>>>>>> instead create two separate components.
> > >>>>>>>
> > >>>>>>> Our main goal here is to move these files out of core
> applications
> > >>>>>>> and
> > >>>>>>> most of us are fine with moving it to specialpurpose. I think we
> > can
> > >>>>>>> conclude our approach as most of us seems fine with having two
> > >>>>>>> separate
> > >>>>>>> components in specialpurpose which was the original suggestion as
> > >>>>>>> well.
> > >>>>>>>
> > >>>>>>> --
> > >>>>>>> Thanks & Regards,
> > >>>>>>> Mridul Pathak
> > >>>>>>> HotWax Systems
> > >>>>>>> http://www.hotwaxsystems.com
> > >>>>>>>
> > >>>>>>> On Jun 16, 2016, at 8:23 PM, Taher Alkhateeb <
> > >>>>>>>>
> > >>>>>>> slidingfilaments@gmail.com>
> > >>>>>>
> > >>>>>>> wrote:
> > >>>>>>>
> > >>>>>>>> Hi Mridul,
> > >>>>>>>>
> > >>>>>>>> Thank you for the detailed and well thought out feedback.
> > >>>>>>>>
> > >>>>>>>> I am a little confused however, what is the point you are trying
> > to
> > >>>>>>>>
> > >>>>>>> state?
> > >>>>>>>
> > >>>>>>>> The only point from my previous email was to suggest avoiding
> > >>>>>>>> creating
> > >>>>>>>>
> > >>>>>>> a
> > >>>>>>
> > >>>>>>> directory called reference in the top level ofbiz directory and
> > >>>>>>>>
> > >>>>>>> instead
> > >>>>
> > >>>>> keep it in /specialpurpose. If you want to keep it in
> > >>>>>>>> specialpurpose/reference, fine, if you want to keep it in
> > >>>>>>>> specialpurpose/your-component-here fine, if you want to do
> > anything
> > >>>>>>>> in
> > >>>>>>>> specialpurpose then also fine My point was simply to suggest
> > >>>>>>>> steering
> > >>>>>>>>
> > >>>>>>> away
> > >>>>>>>
> > >>>>>>>> from ofbiz top level directory.
> > >>>>>>>>
> > >>>>>>>> Regards,
> > >>>>>>>>
> > >>>>>>>> Taher Alkhateeb
> > >>>>>>>>
> > >>>>>>>> On Thu, Jun 16, 2016 at 5:34 PM, Mridul Pathak <
> > >>>>>>>> mridul.pathak@hotwaxsystems.com> wrote:
> > >>>>>>>>
> > >>>>>>>> Hi Taher,
> > >>>>>>>>>
> > >>>>>>>>> Payment integration files in accounting/thirdparty are not just
> > >>>>>>>>>
> > >>>>>>>> unused
> > >>>>
> > >>>>> files and all of it is not dead code. There is the whole
> > >>>>>>>>>
> > >>>>>>>> functionality
> > >>>>
> > >>>>> built around those files which is very crucial to production
> delivery
> > >>>>>>>>>
> > >>>>>>>> of
> > >>>>>>
> > >>>>>>> order management or ecommerce on top of OFBiz. There are many
> > service
> > >>>>>>>>> definition files whose implementation is written in these java
> > >>>>>>>>> files.
> > >>>>>>>>>
> > >>>>>>>> Some
> > >>>>>>>
> > >>>>>>>> examples are,
> > >>>>>>>>>
> > >>>>>>>>> accounting/servicedef/services_authorizedotnet.xml
> > >>>>>>>>> accounting/servicedef/services_clearcommerce.xml
> > >>>>>>>>> accounting/servicedef/services_cybersource.xml
> > >>>>>>>>> accounting/servicedef/services_orbital.xml
> > >>>>>>>>> accounting/servicedef/services_paypal.xml
> > >>>>>>>>> etc.
> > >>>>>>>>>
> > >>>>>>>>> Along with that, many of the configurations needed to use these
> > >>>>>>>>>
> > >>>>>>>> payment
> > >>>>>>
> > >>>>>>> solutions are maintained in accounting/config/payment.properties
> > >>>>>>>>>
> > >>>>>>>> file. A
> > >>>>>>
> > >>>>>>> ProductStore in OFBiz as well can be configures to use on of
> these
> > >>>>>>>>>
> > >>>>>>>> payment
> > >>>>>>>
> > >>>>>>>> processors.
> > >>>>>>>>>
> > >>>>>>>>> Also, these file are intentionally excluded from compile
> process,
> > >>>>>>>>> but
> > >>>>>>>>>
> > >>>>>>>> can
> > >>>>>>>
> > >>>>>>>> be included if you want to use/deliver one of these existing
> > payment
> > >>>>>>>>> solution in OFBiz in production. Following is the code snippet
> > from
> > >>>>>>>>> accounting/build.xml,
> > >>>>>>>>>
> > >>>>>>>>> <target name="init">
> > >>>>>>>>> <condition property="verisign-exclude"
> > >>>>>>>>> value="org/ofbiz/accounting/thirdparty/verisign/**">
> > >>>>>>>>> <not><available file="lib/payflow.jar"/></not>
> > >>>>>>>>> </condition>
> > >>>>>>>>> <patternset id="src.exc.set">
> > >>>>>>>>> <!-- exclude the payment processor packages; comment
> this
> > >>>>>>>>> out
> > >>>>>>>>>
> > >>>>>>>> to
> > >>>>>>
> > >>>>>>> not exclude if you have libs -->
> > >>>>>>>>> <exclude name="${verisign-exclude}"/>
> > >>>>>>>>> <exclude
> > >>>>>>>>>
> > >>>>>>>> name="org/ofbiz/accounting/thirdparty/cybersource/**"/>
> > >>>>>>
> > >>>>>>> <exclude
> > >>>>>>>>>
> > name="org/ofbiz/accounting/thirdparty/paypal/PayPalServices.java"/>
> > >>>>>>>>> <exclude
> > name="org/ofbiz/accounting/thirdparty/orbital/**"/>
> > >>>>>>>>> <exclude
> > >>>>>>>>> name="org/ofbiz/accounting/thirdparty/securepay/**"/>
> > >>>>>>>>> <exclude
> name="org/ofbiz/accounting/thirdparty/ideal/**"/>
> > >>>>>>>>> </patternset>
> > >>>>>>>>> </target>
> > >>>>>>>>>
> > >>>>>>>>> It clearly mentions that if you have required libraries for any
> > of
> > >>>>>>>>>
> > >>>>>>>> the
> > >>>>
> > >>>>> third party payment solutions, you could comment out the exclusion.
> > >>>>>>>>> Usually, when someone needs to use one of the available payment
> > >>>>>>>>>
> > >>>>>>>> processor,
> > >>>>>>>
> > >>>>>>>> they download the required jar and place it in accounting/lib
> > >>>>>>>>> folder,
> > >>>>>>>>>
> > >>>>>>>> make
> > >>>>>>>
> > >>>>>>>> the needed changes in build.xml and they are ready to use the
> > >>>>>>>>>
> > >>>>>>>> respective
> > >>>>>>
> > >>>>>>> payment solution.
> > >>>>>>>>>
> > >>>>>>>>> We have used one or the other payment processors in OFBiz many
> a
> > >>>>>>>>>
> > >>>>>>>> times
> > >>>>
> > >>>>> to
> > >>>>>>>
> > >>>>>>>> deliver payment solutions as part of the software. I believe
> there
> > >>>>>>>>>
> > >>>>>>>> are
> > >>>>
> > >>>>> many
> > >>>>>>>
> > >>>>>>>> application users and service providers who might be using the
> > >>>>>>>>>
> > >>>>>>>> payment
> > >>>>
> > >>>>> processor functionality that comes with OFBiz OOTB.
> > >>>>>>>>>
> > >>>>>>>>> So, it’s not just about moving some files from core
> applications
> > to
> > >>>>>>>>>
> > >>>>>>>> some
> > >>>>>>
> > >>>>>>> other directory because they seems to be unused, the whole
> > >>>>>>>>>
> > >>>>>>>> functionality
> > >>>>>>
> > >>>>>>> needs to be moved so that current or future users of these
> > >>>>>>>>>
> > >>>>>>>> functionalities
> > >>>>>>>
> > >>>>>>>> can still use it. And that is the reason if we create a new
> > special
> > >>>>>>>>>
> > >>>>>>>> purpose
> > >>>>>>>
> > >>>>>>>> component it will help us to keep the functionality intact and
> > >>>>>>>>> usable
> > >>>>>>>>>
> > >>>>>>>> at
> > >>>>>>
> > >>>>>>> the same time separate it from core applications. That would also
> > >>>>>>>>>
> > >>>>>>>> enable us
> > >>>>>>>
> > >>>>>>>> to keep such components out of component-load.xml and
> > >>>>>>>>> specialpurpose/build.xml. A README file would help the user
> with
> > >>>>>>>>>
> > >>>>>>>> directions
> > >>>>>>>
> > >>>>>>>> to use it.
> > >>>>>>>>>
> > >>>>>>>>> Additionally, I feel that most of these files may need to be
> > >>>>>>>>> upgraded
> > >>>>>>>>>
> > >>>>>>>> and
> > >>>>>>>
> > >>>>>>>> needs code refactoring probably because they might usually be
> left
> > >>>>>>>>>
> > >>>>>>>> out
> > >>>>
> > >>>>> as
> > >>>>>>>
> > >>>>>>>> they do not compile by default with OFBiz.
> > >>>>>>>>>
> > >>>>>>>>> --
> > >>>>>>>>> Thanks & Regards,
> > >>>>>>>>> Mridul Pathak
> > >>>>>>>>> HotWax Systems
> > >>>>>>>>> http://www.hotwaxsystems.com
> > >>>>>>>>>
> > >>>>>>>>> On Jun 16, 2016, at 6:44 PM, Taher Alkhateeb <
> > >>>>>>>>>>
> > >>>>>>>>> slidingfilaments@gmail.com>
> > >>>>>>>
> > >>>>>>>> wrote:
> > >>>>>>>>>
> > >>>>>>>>>> Hey Folks,
> > >>>>>>>>>>
> > >>>>>>>>>> I would prefer to keep dead code away from the top level OFBiz
> > >>>>>>>>>>
> > >>>>>>>>> directory.
> > >>>>>>>
> > >>>>>>>> If you keep it there then you make it _closer_ to the framework!
> > >>>>>>>>>>
> > >>>>>>>>>> Anyway, I don't see a problem with keeping it in
> specialpurpose!
> > >>>>>>>>>> You
> > >>>>>>>>>>
> > >>>>>>>>> are
> > >>>>>>>
> > >>>>>>>> not creating a component, you are just creating a folder called
> > >>>>>>>>>>
> > >>>>>>>>> reference
> > >>>>>>>
> > >>>>>>>> and adding stuff to it, and you are not adding it to
> > >>>>>>>>>>
> > >>>>>>>>> component-load.xml?
> > >>>>>>>
> > >>>>>>>> Why is it that you cannot add it there?
> > >>>>>>>>>>
> > >>>>>>>>>> Regards,
> > >>>>>>>>>>
> > >>>>>>>>>> Taher Alkhateeb
> > >>>>>>>>>>
> > >>>>>>>>>> On Thu, Jun 16, 2016 at 3:55 PM, Mridul Pathak <
> > >>>>>>>>>> mridul.pathak@hotwaxsystems.com> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>> Introducing new directory “reference” seems reasonable
> approach
> > to
> > >>>>>>>>>>>
> > >>>>>>>>>> me
> > >>>>>>
> > >>>>>>> as
> > >>>>>>>
> > >>>>>>>> it is a combined solution to everyone’s views.
> > >>>>>>>>>>>
> > >>>>>>>>>>> --
> > >>>>>>>>>>> Thanks & Regards,
> > >>>>>>>>>>> Mridul Pathak
> > >>>>>>>>>>> Senior Manager
> > >>>>>>>>>>> HotWax Systems
> > >>>>>>>>>>> http://www.hotwaxsystems.com
> > >>>>>>>>>>>
> > >>>>>>>>>>> On Jun 16, 2016, at 5:56 PM, Jacques Le Roux <
> > >>>>>>>>>>>>
> > >>>>>>>>>>> jacques.le.roux@les7arts.com> wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>>> Hi Divesh,
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Le 16/06/2016 à 13:38, Divesh Dutta a écrit :
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> 3- In the case of non-compiling / broken / missing
> > dependencies
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>> code
> > >>>>>>>
> > >>>>>>>> highlight this issue somewhere visible to the programmer
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> (README,
> > >>>>>>>
> > >>>>>>>> whatever). Why is this important? Because we need to tell our
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> build
> > >>>>>>>>>
> > >>>>>>>>>> scripts
> > >>>>>>>>>>>>>>>>> and our classpath settings to ignore these files.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> The reason why I suggested to keep all of them in
> > >>>>>>>>>>>>>>>>> /reference/each-component-name-here is to tell the
> build
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> system
> > >>>>>>
> > >>>>>>> to
> > >>>>>>>
> > >>>>>>>> ignore
> > >>>>>>>>>>>
> > >>>>>>>>>>>> all Java files found in /specialpurpose/reference. If you
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> instead
> > >>>>>>>
> > >>>>>>>> break it
> > >>>>>>>>>>>
> > >>>>>>>>>>>> up into multiple components, then I need to ignore the files
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> in
> > >>>>>>
> > >>>>>>> each
> > >>>>>>>>>
> > >>>>>>>>>> component by hand which makes the build script more complex
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> and
> > >>>>>>
> > >>>>>>> more prone
> > >>>>>>>>>>>
> > >>>>>>>>>>>> to human error and it would add to the confusion.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> I agree and I think your initial proposition ("How
> about
> > >>>>>>>>>>>>>>> reference/paymentext and
> > reference/whatever-else-you-want?")
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> was
> > >>>>
> > >>>>> not
> > >>>>>>>
> > >>>>>>>> clearly understood by Pierre and maybe not Divesh. Pierre,
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Divesh?
> > >>>>>>
> > >>>>>>> Actually Jacques, we cannot create component like
> > >>>>>>>>>>>>> specialpurpose/reference/paymentext . Other way can be we
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>> introduce
> > >>>>>>
> > >>>>>>> new
> > >>>>>>>>>
> > >>>>>>>>>> directory "reference" in parallel to specialpurpose,
> > applications
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>> ,
> > >>>>>>
> > >>>>>>> framework . Do you mean to do that ?
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>> You are right, and following Taher's idea I missed this
> point,
> > >>>>>>>>>>>> it
> > >>>>>>>>>>>>
> > >>>>>>>>>>> seems
> > >>>>>>>
> > >>>>>>>> to me that your proposition of <<introducing a new directory
> > >>>>>>>>>>>
> > >>>>>>>>>> "reference" in
> > >>>>>>>>>
> > >>>>>>>>>> parallel to specialpurpose, applications ,framework>> is the
> > best
> > >>>>>>>>>>>
> > >>>>>>>>>> one
> > >>>>>>
> > >>>>>>> so
> > >>>>>>>
> > >>>>>>>> far.
> > >>>>>>>>>>>
> > >>>>>>>>>>>> It could be also that Taher anticipated on the work (I know)
> > he
> > >>>>>>>>>>>>
> > >>>>>>>>>>> will
> > >>>>>>
> > >>>>>>> do
> > >>>>>>>
> > >>>>>>>> on refactoring the build system and this possibility will be
> open
> > >>>>>>>>>>>
> > >>>>>>>>>> "soon",
> > >>>>>>>>>
> > >>>>>>>>>> Taher?
> > >>>>>>>>>>>
> > >>>>>>>>>>>> Also as Mridul put it, and you agreed, the "shipping
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>> integration/s"
> > >>>>>>
> > >>>>>>> which
> > >>>>>>>>>>>
> > >>>>>>>>>>>> "doesn’t have the compilation or library reference issues"
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> would
> > >>>>
> > >>>>> be
> > >>>>>>>
> > >>>>>>>> in its
> > >>>>>>>>>>>
> > >>>>>>>>>>>> own independent component/s (ie not under /reference), same
> > for
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> other
> > >>>>>>>>>
> > >>>>>>>>>> stuff
> > >>>>>>>>>>>
> > >>>>>>>>>>>> with the same status, if exist.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> In this case, shipping integration can be under special
> > >>>>>>>>>>>>> purpose.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>> So
> > >>>>>>
> > >>>>>>> specialpurpose/shippingIntegratio.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>> Clearly, nobrainer :)
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Jacques
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Thanks
> > >>>>>>>>>>>>> --
> > >>>>>>>>>>>>> Divesh Dutta.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>
> > >>>>
> > >>
> > >
> >
>
Re: Proposal to delete stale java files
Posted by Jacopo Cappellato <ja...@hotwaxsystems.com>.
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 <slidingfilaments@gmail.com
> 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 <
> slidingfilaments@gmail.com
> > 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 <
> > jacques.le.roux@les7arts.com> 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 <
> >>> mridul.pathak@hotwaxsystems.com> 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 <pi...@gmail.com>
> >>>>>
> >>>> wrote:
> >>>>
> >>>>> Hi all,
> >>>>>
> >>>>> Moving all 3rd party related integrations solutions from accounting,
> >>>>> product and order into 1 special purpose component makes is worse to
> >>>>> maintain. Moving those from accounting into one in special purpose,
> >>>>> those
> >>>>> from product into one and those from order into another just shifts
> the
> >>>>> problem from the base applications stack to a another stack, which is
> >>>>> the
> >>>>> complexity that results from the total being being bigger than the
> sum
> >>>>> of
> >>>>> its parts.
> >>>>>
> >>>>> I understand and accept that there might be adopters of old release
> out
> >>>>> there that are still on those old releases and use some (or all) of
> the
> >>>>>
> >>>> 3rd
> >>>>
> >>>>> party integrations. But I believe that breaking these sets up in to
> the
> >>>>> smaller components not only makes maintenance less complex but also
> >>>>> increases the appeal of OFBiz (visavis completeness and flexibility).
> >>>>>
> >>>> Given
> >>>>
> >>>>> that this is in the 'improvement' section of what we do, I understand
> >>>>>
> >>>> that,
> >>>>
> >>>>> it won't be back ported to running release branches. So, there is a
> >>>>> means
> >>>>> to communicate up front and prepare the adopters who want to migrate.
> >>>>>
> >>>>> Therefore I suggest we split the 3rd party payment solutions
> >>>>> integrations
> >>>>> up into:
> >>>>> /specialpurpose/paypay
> >>>>> /specialpurpose/orbital
> >>>>> etc
> >>>>>
> >>>>> and the 3rd party shipment solutions integrations up into:
> >>>>> /specialpurpose/dhl
> >>>>> /specialpurpose/fedex
> >>>>> /specialpurpose/ups
> >>>>> etc
> >>>>>
> >>>>> and the same for the other 3rd party solutions integrations.
> >>>>>
> >>>>> After all, these functionalities should be optionals, not mandatories
> >>>>>
> >>>> from
> >>>>
> >>>>> an integration perspective. Splitting them up will also bring the
> >>>>> benefit
> >>>>> of easier maintenance, bringing in contributors who are experienced
> >>>>> with
> >>>>> that piece of software and if adoption/use is 0, an easier path to
> the
> >>>>> attic (in stead of waiting and waiting untill all goes to being
> unused.
> >>>>>
> >>>>> Bringing this to separate components in special purpose doesn't mean
> we
> >>>>> need to bring those into the build process (as long as they are not
> >>>>>
> >>>> fixed).
> >>>>
> >>>>> Leaving them out of the component-load.xml file (or commented out)
> will
> >>>>> avoid that, and give adopters an opt-in choice.
> >>>>>
> >>>>> So to recap:
> >>>>> +1 on the move out of the base applications stack
> >>>>> -1 on the move in catch-all components in another stack.
> >>>>>
> >>>>> Best regards,
> >>>>>
> >>>>> Pierre Smits
> >>>>>
> >>>>> ORRTIZ.COM <http://www.orrtiz.com>
> >>>>> OFBiz based solutions & services
> >>>>>
> >>>>> OFBiz Extensions Marketplace
> >>>>> http://oem.ofbizci.net/oci-2/
> >>>>>
> >>>>> On Thu, Jun 16, 2016 at 7:57 PM, Taher Alkhateeb <
> >>>>>
> >>>> slidingfilaments@gmail.com
> >>>>
> >>>>> wrote:
> >>>>>> +1 thank you for your dedication and thinking of this
> >>>>>> On Jun 16, 2016 8:55 PM, "Mridul Pathak" <
> >>>>>>
> >>>>> mridul.pathak@hotwaxsystems.com>
> >>>>
> >>>>> wrote:
> >>>>>>
> >>>>>> Hi Taher,
> >>>>>>>
> >>>>>>> I was just trying to suggest that we will have to create two
> >>>>>>> components
> >>>>>>>
> >>>>>> in
> >>>>>>
> >>>>>>> specialpurpose, one for payment processor related functionality and
> >>>>>>> one
> >>>>>>>
> >>>>>> for
> >>>>>>
> >>>>>>> tax related functionality and the reason behind it. Which means we
> >>>>>>>
> >>>>>> should
> >>>>
> >>>>> probably drop the idea of introducing a directory named “reference”
> and
> >>>>>>> instead create two separate components.
> >>>>>>>
> >>>>>>> Our main goal here is to move these files out of core applications
> >>>>>>> and
> >>>>>>> most of us are fine with moving it to specialpurpose. I think we
> can
> >>>>>>> conclude our approach as most of us seems fine with having two
> >>>>>>> separate
> >>>>>>> components in specialpurpose which was the original suggestion as
> >>>>>>> well.
> >>>>>>>
> >>>>>>> --
> >>>>>>> Thanks & Regards,
> >>>>>>> Mridul Pathak
> >>>>>>> HotWax Systems
> >>>>>>> http://www.hotwaxsystems.com
> >>>>>>>
> >>>>>>> On Jun 16, 2016, at 8:23 PM, Taher Alkhateeb <
> >>>>>>>>
> >>>>>>> slidingfilaments@gmail.com>
> >>>>>>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> Hi Mridul,
> >>>>>>>>
> >>>>>>>> Thank you for the detailed and well thought out feedback.
> >>>>>>>>
> >>>>>>>> I am a little confused however, what is the point you are trying
> to
> >>>>>>>>
> >>>>>>> state?
> >>>>>>>
> >>>>>>>> The only point from my previous email was to suggest avoiding
> >>>>>>>> creating
> >>>>>>>>
> >>>>>>> a
> >>>>>>
> >>>>>>> directory called reference in the top level ofbiz directory and
> >>>>>>>>
> >>>>>>> instead
> >>>>
> >>>>> keep it in /specialpurpose. If you want to keep it in
> >>>>>>>> specialpurpose/reference, fine, if you want to keep it in
> >>>>>>>> specialpurpose/your-component-here fine, if you want to do
> anything
> >>>>>>>> in
> >>>>>>>> specialpurpose then also fine My point was simply to suggest
> >>>>>>>> steering
> >>>>>>>>
> >>>>>>> away
> >>>>>>>
> >>>>>>>> from ofbiz top level directory.
> >>>>>>>>
> >>>>>>>> Regards,
> >>>>>>>>
> >>>>>>>> Taher Alkhateeb
> >>>>>>>>
> >>>>>>>> On Thu, Jun 16, 2016 at 5:34 PM, Mridul Pathak <
> >>>>>>>> mridul.pathak@hotwaxsystems.com> wrote:
> >>>>>>>>
> >>>>>>>> Hi Taher,
> >>>>>>>>>
> >>>>>>>>> Payment integration files in accounting/thirdparty are not just
> >>>>>>>>>
> >>>>>>>> unused
> >>>>
> >>>>> files and all of it is not dead code. There is the whole
> >>>>>>>>>
> >>>>>>>> functionality
> >>>>
> >>>>> built around those files which is very crucial to production delivery
> >>>>>>>>>
> >>>>>>>> of
> >>>>>>
> >>>>>>> order management or ecommerce on top of OFBiz. There are many
> service
> >>>>>>>>> definition files whose implementation is written in these java
> >>>>>>>>> files.
> >>>>>>>>>
> >>>>>>>> Some
> >>>>>>>
> >>>>>>>> examples are,
> >>>>>>>>>
> >>>>>>>>> accounting/servicedef/services_authorizedotnet.xml
> >>>>>>>>> accounting/servicedef/services_clearcommerce.xml
> >>>>>>>>> accounting/servicedef/services_cybersource.xml
> >>>>>>>>> accounting/servicedef/services_orbital.xml
> >>>>>>>>> accounting/servicedef/services_paypal.xml
> >>>>>>>>> etc.
> >>>>>>>>>
> >>>>>>>>> Along with that, many of the configurations needed to use these
> >>>>>>>>>
> >>>>>>>> payment
> >>>>>>
> >>>>>>> solutions are maintained in accounting/config/payment.properties
> >>>>>>>>>
> >>>>>>>> file. A
> >>>>>>
> >>>>>>> ProductStore in OFBiz as well can be configures to use on of these
> >>>>>>>>>
> >>>>>>>> payment
> >>>>>>>
> >>>>>>>> processors.
> >>>>>>>>>
> >>>>>>>>> Also, these file are intentionally excluded from compile process,
> >>>>>>>>> but
> >>>>>>>>>
> >>>>>>>> can
> >>>>>>>
> >>>>>>>> be included if you want to use/deliver one of these existing
> payment
> >>>>>>>>> solution in OFBiz in production. Following is the code snippet
> from
> >>>>>>>>> accounting/build.xml,
> >>>>>>>>>
> >>>>>>>>> <target name="init">
> >>>>>>>>> <condition property="verisign-exclude"
> >>>>>>>>> value="org/ofbiz/accounting/thirdparty/verisign/**">
> >>>>>>>>> <not><available file="lib/payflow.jar"/></not>
> >>>>>>>>> </condition>
> >>>>>>>>> <patternset id="src.exc.set">
> >>>>>>>>> <!-- exclude the payment processor packages; comment this
> >>>>>>>>> out
> >>>>>>>>>
> >>>>>>>> to
> >>>>>>
> >>>>>>> not exclude if you have libs -->
> >>>>>>>>> <exclude name="${verisign-exclude}"/>
> >>>>>>>>> <exclude
> >>>>>>>>>
> >>>>>>>> name="org/ofbiz/accounting/thirdparty/cybersource/**"/>
> >>>>>>
> >>>>>>> <exclude
> >>>>>>>>>
> name="org/ofbiz/accounting/thirdparty/paypal/PayPalServices.java"/>
> >>>>>>>>> <exclude
> name="org/ofbiz/accounting/thirdparty/orbital/**"/>
> >>>>>>>>> <exclude
> >>>>>>>>> name="org/ofbiz/accounting/thirdparty/securepay/**"/>
> >>>>>>>>> <exclude name="org/ofbiz/accounting/thirdparty/ideal/**"/>
> >>>>>>>>> </patternset>
> >>>>>>>>> </target>
> >>>>>>>>>
> >>>>>>>>> It clearly mentions that if you have required libraries for any
> of
> >>>>>>>>>
> >>>>>>>> the
> >>>>
> >>>>> third party payment solutions, you could comment out the exclusion.
> >>>>>>>>> Usually, when someone needs to use one of the available payment
> >>>>>>>>>
> >>>>>>>> processor,
> >>>>>>>
> >>>>>>>> they download the required jar and place it in accounting/lib
> >>>>>>>>> folder,
> >>>>>>>>>
> >>>>>>>> make
> >>>>>>>
> >>>>>>>> the needed changes in build.xml and they are ready to use the
> >>>>>>>>>
> >>>>>>>> respective
> >>>>>>
> >>>>>>> payment solution.
> >>>>>>>>>
> >>>>>>>>> We have used one or the other payment processors in OFBiz many a
> >>>>>>>>>
> >>>>>>>> times
> >>>>
> >>>>> to
> >>>>>>>
> >>>>>>>> deliver payment solutions as part of the software. I believe there
> >>>>>>>>>
> >>>>>>>> are
> >>>>
> >>>>> many
> >>>>>>>
> >>>>>>>> application users and service providers who might be using the
> >>>>>>>>>
> >>>>>>>> payment
> >>>>
> >>>>> processor functionality that comes with OFBiz OOTB.
> >>>>>>>>>
> >>>>>>>>> So, it’s not just about moving some files from core applications
> to
> >>>>>>>>>
> >>>>>>>> some
> >>>>>>
> >>>>>>> other directory because they seems to be unused, the whole
> >>>>>>>>>
> >>>>>>>> functionality
> >>>>>>
> >>>>>>> needs to be moved so that current or future users of these
> >>>>>>>>>
> >>>>>>>> functionalities
> >>>>>>>
> >>>>>>>> can still use it. And that is the reason if we create a new
> special
> >>>>>>>>>
> >>>>>>>> purpose
> >>>>>>>
> >>>>>>>> component it will help us to keep the functionality intact and
> >>>>>>>>> usable
> >>>>>>>>>
> >>>>>>>> at
> >>>>>>
> >>>>>>> the same time separate it from core applications. That would also
> >>>>>>>>>
> >>>>>>>> enable us
> >>>>>>>
> >>>>>>>> to keep such components out of component-load.xml and
> >>>>>>>>> specialpurpose/build.xml. A README file would help the user with
> >>>>>>>>>
> >>>>>>>> directions
> >>>>>>>
> >>>>>>>> to use it.
> >>>>>>>>>
> >>>>>>>>> Additionally, I feel that most of these files may need to be
> >>>>>>>>> upgraded
> >>>>>>>>>
> >>>>>>>> and
> >>>>>>>
> >>>>>>>> needs code refactoring probably because they might usually be left
> >>>>>>>>>
> >>>>>>>> out
> >>>>
> >>>>> as
> >>>>>>>
> >>>>>>>> they do not compile by default with OFBiz.
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Thanks & Regards,
> >>>>>>>>> Mridul Pathak
> >>>>>>>>> HotWax Systems
> >>>>>>>>> http://www.hotwaxsystems.com
> >>>>>>>>>
> >>>>>>>>> On Jun 16, 2016, at 6:44 PM, Taher Alkhateeb <
> >>>>>>>>>>
> >>>>>>>>> slidingfilaments@gmail.com>
> >>>>>>>
> >>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> Hey Folks,
> >>>>>>>>>>
> >>>>>>>>>> I would prefer to keep dead code away from the top level OFBiz
> >>>>>>>>>>
> >>>>>>>>> directory.
> >>>>>>>
> >>>>>>>> If you keep it there then you make it _closer_ to the framework!
> >>>>>>>>>>
> >>>>>>>>>> Anyway, I don't see a problem with keeping it in specialpurpose!
> >>>>>>>>>> You
> >>>>>>>>>>
> >>>>>>>>> are
> >>>>>>>
> >>>>>>>> not creating a component, you are just creating a folder called
> >>>>>>>>>>
> >>>>>>>>> reference
> >>>>>>>
> >>>>>>>> and adding stuff to it, and you are not adding it to
> >>>>>>>>>>
> >>>>>>>>> component-load.xml?
> >>>>>>>
> >>>>>>>> Why is it that you cannot add it there?
> >>>>>>>>>>
> >>>>>>>>>> Regards,
> >>>>>>>>>>
> >>>>>>>>>> Taher Alkhateeb
> >>>>>>>>>>
> >>>>>>>>>> On Thu, Jun 16, 2016 at 3:55 PM, Mridul Pathak <
> >>>>>>>>>> mridul.pathak@hotwaxsystems.com> wrote:
> >>>>>>>>>>
> >>>>>>>>>> Introducing new directory “reference” seems reasonable approach
> to
> >>>>>>>>>>>
> >>>>>>>>>> me
> >>>>>>
> >>>>>>> as
> >>>>>>>
> >>>>>>>> it is a combined solution to everyone’s views.
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> Thanks & Regards,
> >>>>>>>>>>> Mridul Pathak
> >>>>>>>>>>> Senior Manager
> >>>>>>>>>>> HotWax Systems
> >>>>>>>>>>> http://www.hotwaxsystems.com
> >>>>>>>>>>>
> >>>>>>>>>>> On Jun 16, 2016, at 5:56 PM, Jacques Le Roux <
> >>>>>>>>>>>>
> >>>>>>>>>>> jacques.le.roux@les7arts.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Hi Divesh,
> >>>>>>>>>>>>
> >>>>>>>>>>>> Le 16/06/2016 à 13:38, Divesh Dutta a écrit :
> >>>>>>>>>>>>
> >>>>>>>>>>>>> 3- In the case of non-compiling / broken / missing
> dependencies
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> code
> >>>>>>>
> >>>>>>>> highlight this issue somewhere visible to the programmer
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> (README,
> >>>>>>>
> >>>>>>>> whatever). Why is this important? Because we need to tell our
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> build
> >>>>>>>>>
> >>>>>>>>>> scripts
> >>>>>>>>>>>>>>>>> and our classpath settings to ignore these files.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> The reason why I suggested to keep all of them in
> >>>>>>>>>>>>>>>>> /reference/each-component-name-here is to tell the build
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> system
> >>>>>>
> >>>>>>> to
> >>>>>>>
> >>>>>>>> ignore
> >>>>>>>>>>>
> >>>>>>>>>>>> all Java files found in /specialpurpose/reference. If you
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> instead
> >>>>>>>
> >>>>>>>> break it
> >>>>>>>>>>>
> >>>>>>>>>>>> up into multiple components, then I need to ignore the files
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> in
> >>>>>>
> >>>>>>> each
> >>>>>>>>>
> >>>>>>>>>> component by hand which makes the build script more complex
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> and
> >>>>>>
> >>>>>>> more prone
> >>>>>>>>>>>
> >>>>>>>>>>>> to human error and it would add to the confusion.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I agree and I think your initial proposition ("How about
> >>>>>>>>>>>>>>> reference/paymentext and
> reference/whatever-else-you-want?")
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> was
> >>>>
> >>>>> not
> >>>>>>>
> >>>>>>>> clearly understood by Pierre and maybe not Divesh. Pierre,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Divesh?
> >>>>>>
> >>>>>>> Actually Jacques, we cannot create component like
> >>>>>>>>>>>>> specialpurpose/reference/paymentext . Other way can be we
> >>>>>>>>>>>>>
> >>>>>>>>>>>> introduce
> >>>>>>
> >>>>>>> new
> >>>>>>>>>
> >>>>>>>>>> directory "reference" in parallel to specialpurpose,
> applications
> >>>>>>>>>>>>>
> >>>>>>>>>>>> ,
> >>>>>>
> >>>>>>> framework . Do you mean to do that ?
> >>>>>>>>>>>>>
> >>>>>>>>>>>> You are right, and following Taher's idea I missed this point,
> >>>>>>>>>>>> it
> >>>>>>>>>>>>
> >>>>>>>>>>> seems
> >>>>>>>
> >>>>>>>> to me that your proposition of <<introducing a new directory
> >>>>>>>>>>>
> >>>>>>>>>> "reference" in
> >>>>>>>>>
> >>>>>>>>>> parallel to specialpurpose, applications ,framework>> is the
> best
> >>>>>>>>>>>
> >>>>>>>>>> one
> >>>>>>
> >>>>>>> so
> >>>>>>>
> >>>>>>>> far.
> >>>>>>>>>>>
> >>>>>>>>>>>> It could be also that Taher anticipated on the work (I know)
> he
> >>>>>>>>>>>>
> >>>>>>>>>>> will
> >>>>>>
> >>>>>>> do
> >>>>>>>
> >>>>>>>> on refactoring the build system and this possibility will be open
> >>>>>>>>>>>
> >>>>>>>>>> "soon",
> >>>>>>>>>
> >>>>>>>>>> Taher?
> >>>>>>>>>>>
> >>>>>>>>>>>> Also as Mridul put it, and you agreed, the "shipping
> >>>>>>>>>>>>>
> >>>>>>>>>>>> integration/s"
> >>>>>>
> >>>>>>> which
> >>>>>>>>>>>
> >>>>>>>>>>>> "doesn’t have the compilation or library reference issues"
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> would
> >>>>
> >>>>> be
> >>>>>>>
> >>>>>>>> in its
> >>>>>>>>>>>
> >>>>>>>>>>>> own independent component/s (ie not under /reference), same
> for
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> other
> >>>>>>>>>
> >>>>>>>>>> stuff
> >>>>>>>>>>>
> >>>>>>>>>>>> with the same status, if exist.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> In this case, shipping integration can be under special
> >>>>>>>>>>>>> purpose.
> >>>>>>>>>>>>>
> >>>>>>>>>>>> So
> >>>>>>
> >>>>>>> specialpurpose/shippingIntegratio.
> >>>>>>>>>>>>>
> >>>>>>>>>>>> Clearly, nobrainer :)
> >>>>>>>>>>>>
> >>>>>>>>>>>> Jacques
> >>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Thanks
> >>>>>>>>>>>>> --
> >>>>>>>>>>>>> Divesh Dutta.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>
> >>
> >
>
Re: Proposal to delete stale java files
Posted by Taher Alkhateeb <sl...@gmail.com>.
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 <slidingfilaments@gmail.com
> 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 <
> jacques.le.roux@les7arts.com> 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 <
>>> mridul.pathak@hotwaxsystems.com> 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 <pi...@gmail.com>
>>>>>
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> Moving all 3rd party related integrations solutions from accounting,
>>>>> product and order into 1 special purpose component makes is worse to
>>>>> maintain. Moving those from accounting into one in special purpose,
>>>>> those
>>>>> from product into one and those from order into another just shifts the
>>>>> problem from the base applications stack to a another stack, which is
>>>>> the
>>>>> complexity that results from the total being being bigger than the sum
>>>>> of
>>>>> its parts.
>>>>>
>>>>> I understand and accept that there might be adopters of old release out
>>>>> there that are still on those old releases and use some (or all) of the
>>>>>
>>>> 3rd
>>>>
>>>>> party integrations. But I believe that breaking these sets up in to the
>>>>> smaller components not only makes maintenance less complex but also
>>>>> increases the appeal of OFBiz (visavis completeness and flexibility).
>>>>>
>>>> Given
>>>>
>>>>> that this is in the 'improvement' section of what we do, I understand
>>>>>
>>>> that,
>>>>
>>>>> it won't be back ported to running release branches. So, there is a
>>>>> means
>>>>> to communicate up front and prepare the adopters who want to migrate.
>>>>>
>>>>> Therefore I suggest we split the 3rd party payment solutions
>>>>> integrations
>>>>> up into:
>>>>> /specialpurpose/paypay
>>>>> /specialpurpose/orbital
>>>>> etc
>>>>>
>>>>> and the 3rd party shipment solutions integrations up into:
>>>>> /specialpurpose/dhl
>>>>> /specialpurpose/fedex
>>>>> /specialpurpose/ups
>>>>> etc
>>>>>
>>>>> and the same for the other 3rd party solutions integrations.
>>>>>
>>>>> After all, these functionalities should be optionals, not mandatories
>>>>>
>>>> from
>>>>
>>>>> an integration perspective. Splitting them up will also bring the
>>>>> benefit
>>>>> of easier maintenance, bringing in contributors who are experienced
>>>>> with
>>>>> that piece of software and if adoption/use is 0, an easier path to the
>>>>> attic (in stead of waiting and waiting untill all goes to being unused.
>>>>>
>>>>> Bringing this to separate components in special purpose doesn't mean we
>>>>> need to bring those into the build process (as long as they are not
>>>>>
>>>> fixed).
>>>>
>>>>> Leaving them out of the component-load.xml file (or commented out) will
>>>>> avoid that, and give adopters an opt-in choice.
>>>>>
>>>>> So to recap:
>>>>> +1 on the move out of the base applications stack
>>>>> -1 on the move in catch-all components in another stack.
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Pierre Smits
>>>>>
>>>>> ORRTIZ.COM <http://www.orrtiz.com>
>>>>> OFBiz based solutions & services
>>>>>
>>>>> OFBiz Extensions Marketplace
>>>>> http://oem.ofbizci.net/oci-2/
>>>>>
>>>>> On Thu, Jun 16, 2016 at 7:57 PM, Taher Alkhateeb <
>>>>>
>>>> slidingfilaments@gmail.com
>>>>
>>>>> wrote:
>>>>>> +1 thank you for your dedication and thinking of this
>>>>>> On Jun 16, 2016 8:55 PM, "Mridul Pathak" <
>>>>>>
>>>>> mridul.pathak@hotwaxsystems.com>
>>>>
>>>>> wrote:
>>>>>>
>>>>>> Hi Taher,
>>>>>>>
>>>>>>> I was just trying to suggest that we will have to create two
>>>>>>> components
>>>>>>>
>>>>>> in
>>>>>>
>>>>>>> specialpurpose, one for payment processor related functionality and
>>>>>>> one
>>>>>>>
>>>>>> for
>>>>>>
>>>>>>> tax related functionality and the reason behind it. Which means we
>>>>>>>
>>>>>> should
>>>>
>>>>> probably drop the idea of introducing a directory named “reference” and
>>>>>>> instead create two separate components.
>>>>>>>
>>>>>>> Our main goal here is to move these files out of core applications
>>>>>>> and
>>>>>>> most of us are fine with moving it to specialpurpose. I think we can
>>>>>>> conclude our approach as most of us seems fine with having two
>>>>>>> separate
>>>>>>> components in specialpurpose which was the original suggestion as
>>>>>>> well.
>>>>>>>
>>>>>>> --
>>>>>>> Thanks & Regards,
>>>>>>> Mridul Pathak
>>>>>>> HotWax Systems
>>>>>>> http://www.hotwaxsystems.com
>>>>>>>
>>>>>>> On Jun 16, 2016, at 8:23 PM, Taher Alkhateeb <
>>>>>>>>
>>>>>>> slidingfilaments@gmail.com>
>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Mridul,
>>>>>>>>
>>>>>>>> Thank you for the detailed and well thought out feedback.
>>>>>>>>
>>>>>>>> I am a little confused however, what is the point you are trying to
>>>>>>>>
>>>>>>> state?
>>>>>>>
>>>>>>>> The only point from my previous email was to suggest avoiding
>>>>>>>> creating
>>>>>>>>
>>>>>>> a
>>>>>>
>>>>>>> directory called reference in the top level ofbiz directory and
>>>>>>>>
>>>>>>> instead
>>>>
>>>>> keep it in /specialpurpose. If you want to keep it in
>>>>>>>> specialpurpose/reference, fine, if you want to keep it in
>>>>>>>> specialpurpose/your-component-here fine, if you want to do anything
>>>>>>>> in
>>>>>>>> specialpurpose then also fine My point was simply to suggest
>>>>>>>> steering
>>>>>>>>
>>>>>>> away
>>>>>>>
>>>>>>>> from ofbiz top level directory.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Taher Alkhateeb
>>>>>>>>
>>>>>>>> On Thu, Jun 16, 2016 at 5:34 PM, Mridul Pathak <
>>>>>>>> mridul.pathak@hotwaxsystems.com> wrote:
>>>>>>>>
>>>>>>>> Hi Taher,
>>>>>>>>>
>>>>>>>>> Payment integration files in accounting/thirdparty are not just
>>>>>>>>>
>>>>>>>> unused
>>>>
>>>>> files and all of it is not dead code. There is the whole
>>>>>>>>>
>>>>>>>> functionality
>>>>
>>>>> built around those files which is very crucial to production delivery
>>>>>>>>>
>>>>>>>> of
>>>>>>
>>>>>>> order management or ecommerce on top of OFBiz. There are many service
>>>>>>>>> definition files whose implementation is written in these java
>>>>>>>>> files.
>>>>>>>>>
>>>>>>>> Some
>>>>>>>
>>>>>>>> examples are,
>>>>>>>>>
>>>>>>>>> accounting/servicedef/services_authorizedotnet.xml
>>>>>>>>> accounting/servicedef/services_clearcommerce.xml
>>>>>>>>> accounting/servicedef/services_cybersource.xml
>>>>>>>>> accounting/servicedef/services_orbital.xml
>>>>>>>>> accounting/servicedef/services_paypal.xml
>>>>>>>>> etc.
>>>>>>>>>
>>>>>>>>> Along with that, many of the configurations needed to use these
>>>>>>>>>
>>>>>>>> payment
>>>>>>
>>>>>>> solutions are maintained in accounting/config/payment.properties
>>>>>>>>>
>>>>>>>> file. A
>>>>>>
>>>>>>> ProductStore in OFBiz as well can be configures to use on of these
>>>>>>>>>
>>>>>>>> payment
>>>>>>>
>>>>>>>> processors.
>>>>>>>>>
>>>>>>>>> Also, these file are intentionally excluded from compile process,
>>>>>>>>> but
>>>>>>>>>
>>>>>>>> can
>>>>>>>
>>>>>>>> be included if you want to use/deliver one of these existing payment
>>>>>>>>> solution in OFBiz in production. Following is the code snippet from
>>>>>>>>> accounting/build.xml,
>>>>>>>>>
>>>>>>>>> <target name="init">
>>>>>>>>> <condition property="verisign-exclude"
>>>>>>>>> value="org/ofbiz/accounting/thirdparty/verisign/**">
>>>>>>>>> <not><available file="lib/payflow.jar"/></not>
>>>>>>>>> </condition>
>>>>>>>>> <patternset id="src.exc.set">
>>>>>>>>> <!-- exclude the payment processor packages; comment this
>>>>>>>>> out
>>>>>>>>>
>>>>>>>> to
>>>>>>
>>>>>>> not exclude if you have libs -->
>>>>>>>>> <exclude name="${verisign-exclude}"/>
>>>>>>>>> <exclude
>>>>>>>>>
>>>>>>>> name="org/ofbiz/accounting/thirdparty/cybersource/**"/>
>>>>>>
>>>>>>> <exclude
>>>>>>>>> name="org/ofbiz/accounting/thirdparty/paypal/PayPalServices.java"/>
>>>>>>>>> <exclude name="org/ofbiz/accounting/thirdparty/orbital/**"/>
>>>>>>>>> <exclude
>>>>>>>>> name="org/ofbiz/accounting/thirdparty/securepay/**"/>
>>>>>>>>> <exclude name="org/ofbiz/accounting/thirdparty/ideal/**"/>
>>>>>>>>> </patternset>
>>>>>>>>> </target>
>>>>>>>>>
>>>>>>>>> It clearly mentions that if you have required libraries for any of
>>>>>>>>>
>>>>>>>> the
>>>>
>>>>> third party payment solutions, you could comment out the exclusion.
>>>>>>>>> Usually, when someone needs to use one of the available payment
>>>>>>>>>
>>>>>>>> processor,
>>>>>>>
>>>>>>>> they download the required jar and place it in accounting/lib
>>>>>>>>> folder,
>>>>>>>>>
>>>>>>>> make
>>>>>>>
>>>>>>>> the needed changes in build.xml and they are ready to use the
>>>>>>>>>
>>>>>>>> respective
>>>>>>
>>>>>>> payment solution.
>>>>>>>>>
>>>>>>>>> We have used one or the other payment processors in OFBiz many a
>>>>>>>>>
>>>>>>>> times
>>>>
>>>>> to
>>>>>>>
>>>>>>>> deliver payment solutions as part of the software. I believe there
>>>>>>>>>
>>>>>>>> are
>>>>
>>>>> many
>>>>>>>
>>>>>>>> application users and service providers who might be using the
>>>>>>>>>
>>>>>>>> payment
>>>>
>>>>> processor functionality that comes with OFBiz OOTB.
>>>>>>>>>
>>>>>>>>> So, it’s not just about moving some files from core applications to
>>>>>>>>>
>>>>>>>> some
>>>>>>
>>>>>>> other directory because they seems to be unused, the whole
>>>>>>>>>
>>>>>>>> functionality
>>>>>>
>>>>>>> needs to be moved so that current or future users of these
>>>>>>>>>
>>>>>>>> functionalities
>>>>>>>
>>>>>>>> can still use it. And that is the reason if we create a new special
>>>>>>>>>
>>>>>>>> purpose
>>>>>>>
>>>>>>>> component it will help us to keep the functionality intact and
>>>>>>>>> usable
>>>>>>>>>
>>>>>>>> at
>>>>>>
>>>>>>> the same time separate it from core applications. That would also
>>>>>>>>>
>>>>>>>> enable us
>>>>>>>
>>>>>>>> to keep such components out of component-load.xml and
>>>>>>>>> specialpurpose/build.xml. A README file would help the user with
>>>>>>>>>
>>>>>>>> directions
>>>>>>>
>>>>>>>> to use it.
>>>>>>>>>
>>>>>>>>> Additionally, I feel that most of these files may need to be
>>>>>>>>> upgraded
>>>>>>>>>
>>>>>>>> and
>>>>>>>
>>>>>>>> needs code refactoring probably because they might usually be left
>>>>>>>>>
>>>>>>>> out
>>>>
>>>>> as
>>>>>>>
>>>>>>>> they do not compile by default with OFBiz.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Thanks & Regards,
>>>>>>>>> Mridul Pathak
>>>>>>>>> HotWax Systems
>>>>>>>>> http://www.hotwaxsystems.com
>>>>>>>>>
>>>>>>>>> On Jun 16, 2016, at 6:44 PM, Taher Alkhateeb <
>>>>>>>>>>
>>>>>>>>> slidingfilaments@gmail.com>
>>>>>>>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hey Folks,
>>>>>>>>>>
>>>>>>>>>> I would prefer to keep dead code away from the top level OFBiz
>>>>>>>>>>
>>>>>>>>> directory.
>>>>>>>
>>>>>>>> If you keep it there then you make it _closer_ to the framework!
>>>>>>>>>>
>>>>>>>>>> Anyway, I don't see a problem with keeping it in specialpurpose!
>>>>>>>>>> You
>>>>>>>>>>
>>>>>>>>> are
>>>>>>>
>>>>>>>> not creating a component, you are just creating a folder called
>>>>>>>>>>
>>>>>>>>> reference
>>>>>>>
>>>>>>>> and adding stuff to it, and you are not adding it to
>>>>>>>>>>
>>>>>>>>> component-load.xml?
>>>>>>>
>>>>>>>> Why is it that you cannot add it there?
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>>
>>>>>>>>>> Taher Alkhateeb
>>>>>>>>>>
>>>>>>>>>> On Thu, Jun 16, 2016 at 3:55 PM, Mridul Pathak <
>>>>>>>>>> mridul.pathak@hotwaxsystems.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Introducing new directory “reference” seems reasonable approach to
>>>>>>>>>>>
>>>>>>>>>> me
>>>>>>
>>>>>>> as
>>>>>>>
>>>>>>>> it is a combined solution to everyone’s views.
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Thanks & Regards,
>>>>>>>>>>> Mridul Pathak
>>>>>>>>>>> Senior Manager
>>>>>>>>>>> HotWax Systems
>>>>>>>>>>> http://www.hotwaxsystems.com
>>>>>>>>>>>
>>>>>>>>>>> On Jun 16, 2016, at 5:56 PM, Jacques Le Roux <
>>>>>>>>>>>>
>>>>>>>>>>> jacques.le.roux@les7arts.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Divesh,
>>>>>>>>>>>>
>>>>>>>>>>>> Le 16/06/2016 à 13:38, Divesh Dutta a écrit :
>>>>>>>>>>>>
>>>>>>>>>>>>> 3- In the case of non-compiling / broken / missing dependencies
>>>>>>>>>>>>>>
>>>>>>>>>>>>> code
>>>>>>>
>>>>>>>> highlight this issue somewhere visible to the programmer
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> (README,
>>>>>>>
>>>>>>>> whatever). Why is this important? Because we need to tell our
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> build
>>>>>>>>>
>>>>>>>>>> scripts
>>>>>>>>>>>>>>>>> and our classpath settings to ignore these files.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The reason why I suggested to keep all of them in
>>>>>>>>>>>>>>>>> /reference/each-component-name-here is to tell the build
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> system
>>>>>>
>>>>>>> to
>>>>>>>
>>>>>>>> ignore
>>>>>>>>>>>
>>>>>>>>>>>> all Java files found in /specialpurpose/reference. If you
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> instead
>>>>>>>
>>>>>>>> break it
>>>>>>>>>>>
>>>>>>>>>>>> up into multiple components, then I need to ignore the files
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> in
>>>>>>
>>>>>>> each
>>>>>>>>>
>>>>>>>>>> component by hand which makes the build script more complex
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> and
>>>>>>
>>>>>>> more prone
>>>>>>>>>>>
>>>>>>>>>>>> to human error and it would add to the confusion.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I agree and I think your initial proposition ("How about
>>>>>>>>>>>>>>> reference/paymentext and reference/whatever-else-you-want?")
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> was
>>>>
>>>>> not
>>>>>>>
>>>>>>>> clearly understood by Pierre and maybe not Divesh. Pierre,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Divesh?
>>>>>>
>>>>>>> Actually Jacques, we cannot create component like
>>>>>>>>>>>>> specialpurpose/reference/paymentext . Other way can be we
>>>>>>>>>>>>>
>>>>>>>>>>>> introduce
>>>>>>
>>>>>>> new
>>>>>>>>>
>>>>>>>>>> directory "reference" in parallel to specialpurpose, applications
>>>>>>>>>>>>>
>>>>>>>>>>>> ,
>>>>>>
>>>>>>> framework . Do you mean to do that ?
>>>>>>>>>>>>>
>>>>>>>>>>>> You are right, and following Taher's idea I missed this point,
>>>>>>>>>>>> it
>>>>>>>>>>>>
>>>>>>>>>>> seems
>>>>>>>
>>>>>>>> to me that your proposition of <<introducing a new directory
>>>>>>>>>>>
>>>>>>>>>> "reference" in
>>>>>>>>>
>>>>>>>>>> parallel to specialpurpose, applications ,framework>> is the best
>>>>>>>>>>>
>>>>>>>>>> one
>>>>>>
>>>>>>> so
>>>>>>>
>>>>>>>> far.
>>>>>>>>>>>
>>>>>>>>>>>> It could be also that Taher anticipated on the work (I know) he
>>>>>>>>>>>>
>>>>>>>>>>> will
>>>>>>
>>>>>>> do
>>>>>>>
>>>>>>>> on refactoring the build system and this possibility will be open
>>>>>>>>>>>
>>>>>>>>>> "soon",
>>>>>>>>>
>>>>>>>>>> Taher?
>>>>>>>>>>>
>>>>>>>>>>>> Also as Mridul put it, and you agreed, the "shipping
>>>>>>>>>>>>>
>>>>>>>>>>>> integration/s"
>>>>>>
>>>>>>> which
>>>>>>>>>>>
>>>>>>>>>>>> "doesn’t have the compilation or library reference issues"
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> would
>>>>
>>>>> be
>>>>>>>
>>>>>>>> in its
>>>>>>>>>>>
>>>>>>>>>>>> own independent component/s (ie not under /reference), same for
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> other
>>>>>>>>>
>>>>>>>>>> stuff
>>>>>>>>>>>
>>>>>>>>>>>> with the same status, if exist.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In this case, shipping integration can be under special
>>>>>>>>>>>>> purpose.
>>>>>>>>>>>>>
>>>>>>>>>>>> So
>>>>>>
>>>>>>> specialpurpose/shippingIntegratio.
>>>>>>>>>>>>>
>>>>>>>>>>>> Clearly, nobrainer :)
>>>>>>>>>>>>
>>>>>>>>>>>> Jacques
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Divesh Dutta.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>
>>
>
Re: Proposal to delete stale java files
Posted by Taher Alkhateeb <sl...@gmail.com>.
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 <
jacques.le.roux@les7arts.com> 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 <
>> mridul.pathak@hotwaxsystems.com> 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 <pi...@gmail.com>
>>>>
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> Moving all 3rd party related integrations solutions from accounting,
>>>> product and order into 1 special purpose component makes is worse to
>>>> maintain. Moving those from accounting into one in special purpose,
>>>> those
>>>> from product into one and those from order into another just shifts the
>>>> problem from the base applications stack to a another stack, which is
>>>> the
>>>> complexity that results from the total being being bigger than the sum
>>>> of
>>>> its parts.
>>>>
>>>> I understand and accept that there might be adopters of old release out
>>>> there that are still on those old releases and use some (or all) of the
>>>>
>>> 3rd
>>>
>>>> party integrations. But I believe that breaking these sets up in to the
>>>> smaller components not only makes maintenance less complex but also
>>>> increases the appeal of OFBiz (visavis completeness and flexibility).
>>>>
>>> Given
>>>
>>>> that this is in the 'improvement' section of what we do, I understand
>>>>
>>> that,
>>>
>>>> it won't be back ported to running release branches. So, there is a
>>>> means
>>>> to communicate up front and prepare the adopters who want to migrate.
>>>>
>>>> Therefore I suggest we split the 3rd party payment solutions
>>>> integrations
>>>> up into:
>>>> /specialpurpose/paypay
>>>> /specialpurpose/orbital
>>>> etc
>>>>
>>>> and the 3rd party shipment solutions integrations up into:
>>>> /specialpurpose/dhl
>>>> /specialpurpose/fedex
>>>> /specialpurpose/ups
>>>> etc
>>>>
>>>> and the same for the other 3rd party solutions integrations.
>>>>
>>>> After all, these functionalities should be optionals, not mandatories
>>>>
>>> from
>>>
>>>> an integration perspective. Splitting them up will also bring the
>>>> benefit
>>>> of easier maintenance, bringing in contributors who are experienced with
>>>> that piece of software and if adoption/use is 0, an easier path to the
>>>> attic (in stead of waiting and waiting untill all goes to being unused.
>>>>
>>>> Bringing this to separate components in special purpose doesn't mean we
>>>> need to bring those into the build process (as long as they are not
>>>>
>>> fixed).
>>>
>>>> Leaving them out of the component-load.xml file (or commented out) will
>>>> avoid that, and give adopters an opt-in choice.
>>>>
>>>> So to recap:
>>>> +1 on the move out of the base applications stack
>>>> -1 on the move in catch-all components in another stack.
>>>>
>>>> Best regards,
>>>>
>>>> Pierre Smits
>>>>
>>>> ORRTIZ.COM <http://www.orrtiz.com>
>>>> OFBiz based solutions & services
>>>>
>>>> OFBiz Extensions Marketplace
>>>> http://oem.ofbizci.net/oci-2/
>>>>
>>>> On Thu, Jun 16, 2016 at 7:57 PM, Taher Alkhateeb <
>>>>
>>> slidingfilaments@gmail.com
>>>
>>>> wrote:
>>>>> +1 thank you for your dedication and thinking of this
>>>>> On Jun 16, 2016 8:55 PM, "Mridul Pathak" <
>>>>>
>>>> mridul.pathak@hotwaxsystems.com>
>>>
>>>> wrote:
>>>>>
>>>>> Hi Taher,
>>>>>>
>>>>>> I was just trying to suggest that we will have to create two
>>>>>> components
>>>>>>
>>>>> in
>>>>>
>>>>>> specialpurpose, one for payment processor related functionality and
>>>>>> one
>>>>>>
>>>>> for
>>>>>
>>>>>> tax related functionality and the reason behind it. Which means we
>>>>>>
>>>>> should
>>>
>>>> probably drop the idea of introducing a directory named “reference” and
>>>>>> instead create two separate components.
>>>>>>
>>>>>> Our main goal here is to move these files out of core applications and
>>>>>> most of us are fine with moving it to specialpurpose. I think we can
>>>>>> conclude our approach as most of us seems fine with having two
>>>>>> separate
>>>>>> components in specialpurpose which was the original suggestion as
>>>>>> well.
>>>>>>
>>>>>> --
>>>>>> Thanks & Regards,
>>>>>> Mridul Pathak
>>>>>> HotWax Systems
>>>>>> http://www.hotwaxsystems.com
>>>>>>
>>>>>> On Jun 16, 2016, at 8:23 PM, Taher Alkhateeb <
>>>>>>>
>>>>>> slidingfilaments@gmail.com>
>>>>>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Mridul,
>>>>>>>
>>>>>>> Thank you for the detailed and well thought out feedback.
>>>>>>>
>>>>>>> I am a little confused however, what is the point you are trying to
>>>>>>>
>>>>>> state?
>>>>>>
>>>>>>> The only point from my previous email was to suggest avoiding
>>>>>>> creating
>>>>>>>
>>>>>> a
>>>>>
>>>>>> directory called reference in the top level ofbiz directory and
>>>>>>>
>>>>>> instead
>>>
>>>> keep it in /specialpurpose. If you want to keep it in
>>>>>>> specialpurpose/reference, fine, if you want to keep it in
>>>>>>> specialpurpose/your-component-here fine, if you want to do anything
>>>>>>> in
>>>>>>> specialpurpose then also fine My point was simply to suggest steering
>>>>>>>
>>>>>> away
>>>>>>
>>>>>>> from ofbiz top level directory.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Taher Alkhateeb
>>>>>>>
>>>>>>> On Thu, Jun 16, 2016 at 5:34 PM, Mridul Pathak <
>>>>>>> mridul.pathak@hotwaxsystems.com> wrote:
>>>>>>>
>>>>>>> Hi Taher,
>>>>>>>>
>>>>>>>> Payment integration files in accounting/thirdparty are not just
>>>>>>>>
>>>>>>> unused
>>>
>>>> files and all of it is not dead code. There is the whole
>>>>>>>>
>>>>>>> functionality
>>>
>>>> built around those files which is very crucial to production delivery
>>>>>>>>
>>>>>>> of
>>>>>
>>>>>> order management or ecommerce on top of OFBiz. There are many service
>>>>>>>> definition files whose implementation is written in these java
>>>>>>>> files.
>>>>>>>>
>>>>>>> Some
>>>>>>
>>>>>>> examples are,
>>>>>>>>
>>>>>>>> accounting/servicedef/services_authorizedotnet.xml
>>>>>>>> accounting/servicedef/services_clearcommerce.xml
>>>>>>>> accounting/servicedef/services_cybersource.xml
>>>>>>>> accounting/servicedef/services_orbital.xml
>>>>>>>> accounting/servicedef/services_paypal.xml
>>>>>>>> etc.
>>>>>>>>
>>>>>>>> Along with that, many of the configurations needed to use these
>>>>>>>>
>>>>>>> payment
>>>>>
>>>>>> solutions are maintained in accounting/config/payment.properties
>>>>>>>>
>>>>>>> file. A
>>>>>
>>>>>> ProductStore in OFBiz as well can be configures to use on of these
>>>>>>>>
>>>>>>> payment
>>>>>>
>>>>>>> processors.
>>>>>>>>
>>>>>>>> Also, these file are intentionally excluded from compile process,
>>>>>>>> but
>>>>>>>>
>>>>>>> can
>>>>>>
>>>>>>> be included if you want to use/deliver one of these existing payment
>>>>>>>> solution in OFBiz in production. Following is the code snippet from
>>>>>>>> accounting/build.xml,
>>>>>>>>
>>>>>>>> <target name="init">
>>>>>>>> <condition property="verisign-exclude"
>>>>>>>> value="org/ofbiz/accounting/thirdparty/verisign/**">
>>>>>>>> <not><available file="lib/payflow.jar"/></not>
>>>>>>>> </condition>
>>>>>>>> <patternset id="src.exc.set">
>>>>>>>> <!-- exclude the payment processor packages; comment this out
>>>>>>>>
>>>>>>> to
>>>>>
>>>>>> not exclude if you have libs -->
>>>>>>>> <exclude name="${verisign-exclude}"/>
>>>>>>>> <exclude
>>>>>>>>
>>>>>>> name="org/ofbiz/accounting/thirdparty/cybersource/**"/>
>>>>>
>>>>>> <exclude
>>>>>>>> name="org/ofbiz/accounting/thirdparty/paypal/PayPalServices.java"/>
>>>>>>>> <exclude name="org/ofbiz/accounting/thirdparty/orbital/**"/>
>>>>>>>> <exclude
>>>>>>>> name="org/ofbiz/accounting/thirdparty/securepay/**"/>
>>>>>>>> <exclude name="org/ofbiz/accounting/thirdparty/ideal/**"/>
>>>>>>>> </patternset>
>>>>>>>> </target>
>>>>>>>>
>>>>>>>> It clearly mentions that if you have required libraries for any of
>>>>>>>>
>>>>>>> the
>>>
>>>> third party payment solutions, you could comment out the exclusion.
>>>>>>>> Usually, when someone needs to use one of the available payment
>>>>>>>>
>>>>>>> processor,
>>>>>>
>>>>>>> they download the required jar and place it in accounting/lib folder,
>>>>>>>>
>>>>>>> make
>>>>>>
>>>>>>> the needed changes in build.xml and they are ready to use the
>>>>>>>>
>>>>>>> respective
>>>>>
>>>>>> payment solution.
>>>>>>>>
>>>>>>>> We have used one or the other payment processors in OFBiz many a
>>>>>>>>
>>>>>>> times
>>>
>>>> to
>>>>>>
>>>>>>> deliver payment solutions as part of the software. I believe there
>>>>>>>>
>>>>>>> are
>>>
>>>> many
>>>>>>
>>>>>>> application users and service providers who might be using the
>>>>>>>>
>>>>>>> payment
>>>
>>>> processor functionality that comes with OFBiz OOTB.
>>>>>>>>
>>>>>>>> So, it’s not just about moving some files from core applications to
>>>>>>>>
>>>>>>> some
>>>>>
>>>>>> other directory because they seems to be unused, the whole
>>>>>>>>
>>>>>>> functionality
>>>>>
>>>>>> needs to be moved so that current or future users of these
>>>>>>>>
>>>>>>> functionalities
>>>>>>
>>>>>>> can still use it. And that is the reason if we create a new special
>>>>>>>>
>>>>>>> purpose
>>>>>>
>>>>>>> component it will help us to keep the functionality intact and usable
>>>>>>>>
>>>>>>> at
>>>>>
>>>>>> the same time separate it from core applications. That would also
>>>>>>>>
>>>>>>> enable us
>>>>>>
>>>>>>> to keep such components out of component-load.xml and
>>>>>>>> specialpurpose/build.xml. A README file would help the user with
>>>>>>>>
>>>>>>> directions
>>>>>>
>>>>>>> to use it.
>>>>>>>>
>>>>>>>> Additionally, I feel that most of these files may need to be
>>>>>>>> upgraded
>>>>>>>>
>>>>>>> and
>>>>>>
>>>>>>> needs code refactoring probably because they might usually be left
>>>>>>>>
>>>>>>> out
>>>
>>>> as
>>>>>>
>>>>>>> they do not compile by default with OFBiz.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Thanks & Regards,
>>>>>>>> Mridul Pathak
>>>>>>>> HotWax Systems
>>>>>>>> http://www.hotwaxsystems.com
>>>>>>>>
>>>>>>>> On Jun 16, 2016, at 6:44 PM, Taher Alkhateeb <
>>>>>>>>>
>>>>>>>> slidingfilaments@gmail.com>
>>>>>>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hey Folks,
>>>>>>>>>
>>>>>>>>> I would prefer to keep dead code away from the top level OFBiz
>>>>>>>>>
>>>>>>>> directory.
>>>>>>
>>>>>>> If you keep it there then you make it _closer_ to the framework!
>>>>>>>>>
>>>>>>>>> Anyway, I don't see a problem with keeping it in specialpurpose!
>>>>>>>>> You
>>>>>>>>>
>>>>>>>> are
>>>>>>
>>>>>>> not creating a component, you are just creating a folder called
>>>>>>>>>
>>>>>>>> reference
>>>>>>
>>>>>>> and adding stuff to it, and you are not adding it to
>>>>>>>>>
>>>>>>>> component-load.xml?
>>>>>>
>>>>>>> Why is it that you cannot add it there?
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Taher Alkhateeb
>>>>>>>>>
>>>>>>>>> On Thu, Jun 16, 2016 at 3:55 PM, Mridul Pathak <
>>>>>>>>> mridul.pathak@hotwaxsystems.com> wrote:
>>>>>>>>>
>>>>>>>>> Introducing new directory “reference” seems reasonable approach to
>>>>>>>>>>
>>>>>>>>> me
>>>>>
>>>>>> as
>>>>>>
>>>>>>> it is a combined solution to everyone’s views.
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Thanks & Regards,
>>>>>>>>>> Mridul Pathak
>>>>>>>>>> Senior Manager
>>>>>>>>>> HotWax Systems
>>>>>>>>>> http://www.hotwaxsystems.com
>>>>>>>>>>
>>>>>>>>>> On Jun 16, 2016, at 5:56 PM, Jacques Le Roux <
>>>>>>>>>>>
>>>>>>>>>> jacques.le.roux@les7arts.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Divesh,
>>>>>>>>>>>
>>>>>>>>>>> Le 16/06/2016 à 13:38, Divesh Dutta a écrit :
>>>>>>>>>>>
>>>>>>>>>>>> 3- In the case of non-compiling / broken / missing dependencies
>>>>>>>>>>>>>
>>>>>>>>>>>> code
>>>>>>
>>>>>>> highlight this issue somewhere visible to the programmer
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> (README,
>>>>>>
>>>>>>> whatever). Why is this important? Because we need to tell our
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> build
>>>>>>>>
>>>>>>>>> scripts
>>>>>>>>>>>>>>>> and our classpath settings to ignore these files.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The reason why I suggested to keep all of them in
>>>>>>>>>>>>>>>> /reference/each-component-name-here is to tell the build
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> system
>>>>>
>>>>>> to
>>>>>>
>>>>>>> ignore
>>>>>>>>>>
>>>>>>>>>>> all Java files found in /specialpurpose/reference. If you
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> instead
>>>>>>
>>>>>>> break it
>>>>>>>>>>
>>>>>>>>>>> up into multiple components, then I need to ignore the files
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> in
>>>>>
>>>>>> each
>>>>>>>>
>>>>>>>>> component by hand which makes the build script more complex
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> and
>>>>>
>>>>>> more prone
>>>>>>>>>>
>>>>>>>>>>> to human error and it would add to the confusion.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I agree and I think your initial proposition ("How about
>>>>>>>>>>>>>> reference/paymentext and reference/whatever-else-you-want?")
>>>>>>>>>>>>>>
>>>>>>>>>>>>> was
>>>
>>>> not
>>>>>>
>>>>>>> clearly understood by Pierre and maybe not Divesh. Pierre,
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Divesh?
>>>>>
>>>>>> Actually Jacques, we cannot create component like
>>>>>>>>>>>> specialpurpose/reference/paymentext . Other way can be we
>>>>>>>>>>>>
>>>>>>>>>>> introduce
>>>>>
>>>>>> new
>>>>>>>>
>>>>>>>>> directory "reference" in parallel to specialpurpose, applications
>>>>>>>>>>>>
>>>>>>>>>>> ,
>>>>>
>>>>>> framework . Do you mean to do that ?
>>>>>>>>>>>>
>>>>>>>>>>> You are right, and following Taher's idea I missed this point, it
>>>>>>>>>>>
>>>>>>>>>> seems
>>>>>>
>>>>>>> to me that your proposition of <<introducing a new directory
>>>>>>>>>>
>>>>>>>>> "reference" in
>>>>>>>>
>>>>>>>>> parallel to specialpurpose, applications ,framework>> is the best
>>>>>>>>>>
>>>>>>>>> one
>>>>>
>>>>>> so
>>>>>>
>>>>>>> far.
>>>>>>>>>>
>>>>>>>>>>> It could be also that Taher anticipated on the work (I know) he
>>>>>>>>>>>
>>>>>>>>>> will
>>>>>
>>>>>> do
>>>>>>
>>>>>>> on refactoring the build system and this possibility will be open
>>>>>>>>>>
>>>>>>>>> "soon",
>>>>>>>>
>>>>>>>>> Taher?
>>>>>>>>>>
>>>>>>>>>>> Also as Mridul put it, and you agreed, the "shipping
>>>>>>>>>>>>
>>>>>>>>>>> integration/s"
>>>>>
>>>>>> which
>>>>>>>>>>
>>>>>>>>>>> "doesn’t have the compilation or library reference issues"
>>>>>>>>>>>>>>
>>>>>>>>>>>>> would
>>>
>>>> be
>>>>>>
>>>>>>> in its
>>>>>>>>>>
>>>>>>>>>>> own independent component/s (ie not under /reference), same for
>>>>>>>>>>>>>>
>>>>>>>>>>>>> other
>>>>>>>>
>>>>>>>>> stuff
>>>>>>>>>>
>>>>>>>>>>> with the same status, if exist.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> In this case, shipping integration can be under special
>>>>>>>>>>>> purpose.
>>>>>>>>>>>>
>>>>>>>>>>> So
>>>>>
>>>>>> specialpurpose/shippingIntegratio.
>>>>>>>>>>>>
>>>>>>>>>>> Clearly, nobrainer :)
>>>>>>>>>>>
>>>>>>>>>>> Jacques
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> --
>>>>>>>>>>>> Divesh Dutta.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>
>
Re: Proposal to delete stale java files
Posted by Jacques Le Roux <ja...@les7arts.com>.
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 <
> mridul.pathak@hotwaxsystems.com> wrote:
>
>> Creating payment/shipping/tax solution specific components would introduce
>> 17 new components to specialpurpose and that doesn\u2019t 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\u2019s 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 <pi...@gmail.com>
>> wrote:
>>> Hi all,
>>>
>>> Moving all 3rd party related integrations solutions from accounting,
>>> product and order into 1 special purpose component makes is worse to
>>> maintain. Moving those from accounting into one in special purpose, those
>>> from product into one and those from order into another just shifts the
>>> problem from the base applications stack to a another stack, which is the
>>> complexity that results from the total being being bigger than the sum of
>>> its parts.
>>>
>>> I understand and accept that there might be adopters of old release out
>>> there that are still on those old releases and use some (or all) of the
>> 3rd
>>> party integrations. But I believe that breaking these sets up in to the
>>> smaller components not only makes maintenance less complex but also
>>> increases the appeal of OFBiz (visavis completeness and flexibility).
>> Given
>>> that this is in the 'improvement' section of what we do, I understand
>> that,
>>> it won't be back ported to running release branches. So, there is a means
>>> to communicate up front and prepare the adopters who want to migrate.
>>>
>>> Therefore I suggest we split the 3rd party payment solutions integrations
>>> up into:
>>> /specialpurpose/paypay
>>> /specialpurpose/orbital
>>> etc
>>>
>>> and the 3rd party shipment solutions integrations up into:
>>> /specialpurpose/dhl
>>> /specialpurpose/fedex
>>> /specialpurpose/ups
>>> etc
>>>
>>> and the same for the other 3rd party solutions integrations.
>>>
>>> After all, these functionalities should be optionals, not mandatories
>> from
>>> an integration perspective. Splitting them up will also bring the benefit
>>> of easier maintenance, bringing in contributors who are experienced with
>>> that piece of software and if adoption/use is 0, an easier path to the
>>> attic (in stead of waiting and waiting untill all goes to being unused.
>>>
>>> Bringing this to separate components in special purpose doesn't mean we
>>> need to bring those into the build process (as long as they are not
>> fixed).
>>> Leaving them out of the component-load.xml file (or commented out) will
>>> avoid that, and give adopters an opt-in choice.
>>>
>>> So to recap:
>>> +1 on the move out of the base applications stack
>>> -1 on the move in catch-all components in another stack.
>>>
>>> Best regards,
>>>
>>> Pierre Smits
>>>
>>> ORRTIZ.COM <http://www.orrtiz.com>
>>> OFBiz based solutions & services
>>>
>>> OFBiz Extensions Marketplace
>>> http://oem.ofbizci.net/oci-2/
>>>
>>> On Thu, Jun 16, 2016 at 7:57 PM, Taher Alkhateeb <
>> slidingfilaments@gmail.com
>>>> wrote:
>>>> +1 thank you for your dedication and thinking of this
>>>> On Jun 16, 2016 8:55 PM, "Mridul Pathak" <
>> mridul.pathak@hotwaxsystems.com>
>>>> wrote:
>>>>
>>>>> Hi Taher,
>>>>>
>>>>> I was just trying to suggest that we will have to create two components
>>>> in
>>>>> specialpurpose, one for payment processor related functionality and one
>>>> for
>>>>> tax related functionality and the reason behind it. Which means we
>> should
>>>>> probably drop the idea of introducing a directory named \u201creference\u201d 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 <
>>>> slidingfilaments@gmail.com>
>>>>> wrote:
>>>>>> Hi Mridul,
>>>>>>
>>>>>> Thank you for the detailed and well thought out feedback.
>>>>>>
>>>>>> I am a little confused however, what is the point you are trying to
>>>>> state?
>>>>>> The only point from my previous email was to suggest avoiding creating
>>>> a
>>>>>> directory called reference in the top level ofbiz directory and
>> instead
>>>>>> keep it in /specialpurpose. If you want to keep it in
>>>>>> specialpurpose/reference, fine, if you want to keep it in
>>>>>> specialpurpose/your-component-here fine, if you want to do anything in
>>>>>> specialpurpose then also fine My point was simply to suggest steering
>>>>> away
>>>>>> from ofbiz top level directory.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Taher Alkhateeb
>>>>>>
>>>>>> On Thu, Jun 16, 2016 at 5:34 PM, Mridul Pathak <
>>>>>> mridul.pathak@hotwaxsystems.com> wrote:
>>>>>>
>>>>>>> Hi Taher,
>>>>>>>
>>>>>>> Payment integration files in accounting/thirdparty are not just
>> unused
>>>>>>> files and all of it is not dead code. There is the whole
>> functionality
>>>>>>> built around those files which is very crucial to production delivery
>>>> of
>>>>>>> order management or ecommerce on top of OFBiz. There are many service
>>>>>>> definition files whose implementation is written in these java files.
>>>>> Some
>>>>>>> examples are,
>>>>>>>
>>>>>>> accounting/servicedef/services_authorizedotnet.xml
>>>>>>> accounting/servicedef/services_clearcommerce.xml
>>>>>>> accounting/servicedef/services_cybersource.xml
>>>>>>> accounting/servicedef/services_orbital.xml
>>>>>>> accounting/servicedef/services_paypal.xml
>>>>>>> etc.
>>>>>>>
>>>>>>> Along with that, many of the configurations needed to use these
>>>> payment
>>>>>>> solutions are maintained in accounting/config/payment.properties
>>>> file. A
>>>>>>> ProductStore in OFBiz as well can be configures to use on of these
>>>>> payment
>>>>>>> processors.
>>>>>>>
>>>>>>> Also, these file are intentionally excluded from compile process, but
>>>>> can
>>>>>>> be included if you want to use/deliver one of these existing payment
>>>>>>> solution in OFBiz in production. Following is the code snippet from
>>>>>>> accounting/build.xml,
>>>>>>>
>>>>>>> <target name="init">
>>>>>>> <condition property="verisign-exclude"
>>>>>>> value="org/ofbiz/accounting/thirdparty/verisign/**">
>>>>>>> <not><available file="lib/payflow.jar"/></not>
>>>>>>> </condition>
>>>>>>> <patternset id="src.exc.set">
>>>>>>> <!-- exclude the payment processor packages; comment this out
>>>> to
>>>>>>> not exclude if you have libs -->
>>>>>>> <exclude name="${verisign-exclude}"/>
>>>>>>> <exclude
>>>> name="org/ofbiz/accounting/thirdparty/cybersource/**"/>
>>>>>>> <exclude
>>>>>>> name="org/ofbiz/accounting/thirdparty/paypal/PayPalServices.java"/>
>>>>>>> <exclude name="org/ofbiz/accounting/thirdparty/orbital/**"/>
>>>>>>> <exclude name="org/ofbiz/accounting/thirdparty/securepay/**"/>
>>>>>>> <exclude name="org/ofbiz/accounting/thirdparty/ideal/**"/>
>>>>>>> </patternset>
>>>>>>> </target>
>>>>>>>
>>>>>>> It clearly mentions that if you have required libraries for any of
>> the
>>>>>>> third party payment solutions, you could comment out the exclusion.
>>>>>>> Usually, when someone needs to use one of the available payment
>>>>> processor,
>>>>>>> they download the required jar and place it in accounting/lib folder,
>>>>> make
>>>>>>> the needed changes in build.xml and they are ready to use the
>>>> respective
>>>>>>> payment solution.
>>>>>>>
>>>>>>> We have used one or the other payment processors in OFBiz many a
>> times
>>>>> to
>>>>>>> deliver payment solutions as part of the software. I believe there
>> are
>>>>> many
>>>>>>> application users and service providers who might be using the
>> payment
>>>>>>> processor functionality that comes with OFBiz OOTB.
>>>>>>>
>>>>>>> So, it\u2019s 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 <
>>>>> slidingfilaments@gmail.com>
>>>>>>> wrote:
>>>>>>>> Hey Folks,
>>>>>>>>
>>>>>>>> I would prefer to keep dead code away from the top level OFBiz
>>>>> directory.
>>>>>>>> If you keep it there then you make it _closer_ to the framework!
>>>>>>>>
>>>>>>>> Anyway, I don't see a problem with keeping it in specialpurpose! You
>>>>> are
>>>>>>>> not creating a component, you are just creating a folder called
>>>>> reference
>>>>>>>> and adding stuff to it, and you are not adding it to
>>>>> component-load.xml?
>>>>>>>> Why is it that you cannot add it there?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Taher Alkhateeb
>>>>>>>>
>>>>>>>> On Thu, Jun 16, 2016 at 3:55 PM, Mridul Pathak <
>>>>>>>> mridul.pathak@hotwaxsystems.com> wrote:
>>>>>>>>
>>>>>>>>> Introducing new directory \u201creference\u201d seems reasonable approach to
>>>> me
>>>>> as
>>>>>>>>> it is a combined solution to everyone\u2019s views.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Thanks & Regards,
>>>>>>>>> Mridul Pathak
>>>>>>>>> Senior Manager
>>>>>>>>> HotWax Systems
>>>>>>>>> http://www.hotwaxsystems.com
>>>>>>>>>
>>>>>>>>>> On Jun 16, 2016, at 5:56 PM, Jacques Le Roux <
>>>>>>>>> jacques.le.roux@les7arts.com> wrote:
>>>>>>>>>> Hi Divesh,
>>>>>>>>>>
>>>>>>>>>> Le 16/06/2016 � 13:38, Divesh Dutta a �crit :
>>>>>>>>>>>> 3- In the case of non-compiling / broken / missing dependencies
>>>>> code
>>>>>>>>>>>>>>> highlight this issue somewhere visible to the programmer
>>>>> (README,
>>>>>>>>>>>>>>> whatever). Why is this important? Because we need to tell our
>>>>>>> build
>>>>>>>>>>>>>>> scripts
>>>>>>>>>>>>>>> and our classpath settings to ignore these files.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The reason why I suggested to keep all of them in
>>>>>>>>>>>>>>> /reference/each-component-name-here is to tell the build
>>>> system
>>>>> to
>>>>>>>>> ignore
>>>>>>>>>>>>>>> all Java files found in /specialpurpose/reference. If you
>>>>> instead
>>>>>>>>> break it
>>>>>>>>>>>>>>> up into multiple components, then I need to ignore the files
>>>> in
>>>>>>> each
>>>>>>>>>>>>>>> component by hand which makes the build script more complex
>>>> and
>>>>>>>>> more prone
>>>>>>>>>>>>>>> to human error and it would add to the confusion.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>> I agree and I think your initial proposition ("How about
>>>>>>>>>>>>> reference/paymentext and reference/whatever-else-you-want?")
>> was
>>>>> not
>>>>>>>>>>>>> clearly understood by Pierre and maybe not Divesh. Pierre,
>>>> Divesh?
>>>>>>>>>>> Actually Jacques, we cannot create component like
>>>>>>>>>>> specialpurpose/reference/paymentext . Other way can be we
>>>> introduce
>>>>>>> new
>>>>>>>>>>> directory "reference" in parallel to specialpurpose, applications
>>>> ,
>>>>>>>>>>> framework . Do you mean to do that ?
>>>>>>>>>> You are right, and following Taher's idea I missed this point, it
>>>>> seems
>>>>>>>>> to me that your proposition of <<introducing a new directory
>>>>>>> "reference" in
>>>>>>>>> parallel to specialpurpose, applications ,framework>> is the best
>>>> one
>>>>> so
>>>>>>>>> far.
>>>>>>>>>> It could be also that Taher anticipated on the work (I know) he
>>>> will
>>>>> do
>>>>>>>>> on refactoring the build system and this possibility will be open
>>>>>>> "soon",
>>>>>>>>> Taher?
>>>>>>>>>>> Also as Mridul put it, and you agreed, the "shipping
>>>> integration/s"
>>>>>>>>> which
>>>>>>>>>>>>> "doesn\u2019t 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.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>
Re: Proposal to delete stale java files
Posted by Pierre Smits <pi...@gmail.com>.
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 <
mridul.pathak@hotwaxsystems.com> 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 <pi...@gmail.com>
> wrote:
> >
> > Hi all,
> >
> > Moving all 3rd party related integrations solutions from accounting,
> > product and order into 1 special purpose component makes is worse to
> > maintain. Moving those from accounting into one in special purpose, those
> > from product into one and those from order into another just shifts the
> > problem from the base applications stack to a another stack, which is the
> > complexity that results from the total being being bigger than the sum of
> > its parts.
> >
> > I understand and accept that there might be adopters of old release out
> > there that are still on those old releases and use some (or all) of the
> 3rd
> > party integrations. But I believe that breaking these sets up in to the
> > smaller components not only makes maintenance less complex but also
> > increases the appeal of OFBiz (visavis completeness and flexibility).
> Given
> > that this is in the 'improvement' section of what we do, I understand
> that,
> > it won't be back ported to running release branches. So, there is a means
> > to communicate up front and prepare the adopters who want to migrate.
> >
> > Therefore I suggest we split the 3rd party payment solutions integrations
> > up into:
> > /specialpurpose/paypay
> > /specialpurpose/orbital
> > etc
> >
> > and the 3rd party shipment solutions integrations up into:
> > /specialpurpose/dhl
> > /specialpurpose/fedex
> > /specialpurpose/ups
> > etc
> >
> > and the same for the other 3rd party solutions integrations.
> >
> > After all, these functionalities should be optionals, not mandatories
> from
> > an integration perspective. Splitting them up will also bring the benefit
> > of easier maintenance, bringing in contributors who are experienced with
> > that piece of software and if adoption/use is 0, an easier path to the
> > attic (in stead of waiting and waiting untill all goes to being unused.
> >
> > Bringing this to separate components in special purpose doesn't mean we
> > need to bring those into the build process (as long as they are not
> fixed).
> > Leaving them out of the component-load.xml file (or commented out) will
> > avoid that, and give adopters an opt-in choice.
> >
> > So to recap:
> > +1 on the move out of the base applications stack
> > -1 on the move in catch-all components in another stack.
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > ORRTIZ.COM <http://www.orrtiz.com>
> > OFBiz based solutions & services
> >
> > OFBiz Extensions Marketplace
> > http://oem.ofbizci.net/oci-2/
> >
> > On Thu, Jun 16, 2016 at 7:57 PM, Taher Alkhateeb <
> slidingfilaments@gmail.com
> >> wrote:
> >
> >> +1 thank you for your dedication and thinking of this
> >> On Jun 16, 2016 8:55 PM, "Mridul Pathak" <
> mridul.pathak@hotwaxsystems.com>
> >> wrote:
> >>
> >>> Hi Taher,
> >>>
> >>> I was just trying to suggest that we will have to create two components
> >> in
> >>> specialpurpose, one for payment processor related functionality and one
> >> for
> >>> tax related functionality and the reason behind it. Which means we
> should
> >>> probably drop the idea of introducing a directory named “reference” and
> >>> instead create two separate components.
> >>>
> >>> Our main goal here is to move these files out of core applications and
> >>> most of us are fine with moving it to specialpurpose. I think we can
> >>> conclude our approach as most of us seems fine with having two separate
> >>> components in specialpurpose which was the original suggestion as well.
> >>>
> >>> --
> >>> Thanks & Regards,
> >>> Mridul Pathak
> >>> HotWax Systems
> >>> http://www.hotwaxsystems.com
> >>>
> >>>> On Jun 16, 2016, at 8:23 PM, Taher Alkhateeb <
> >> slidingfilaments@gmail.com>
> >>> wrote:
> >>>>
> >>>> Hi Mridul,
> >>>>
> >>>> Thank you for the detailed and well thought out feedback.
> >>>>
> >>>> I am a little confused however, what is the point you are trying to
> >>> state?
> >>>> The only point from my previous email was to suggest avoiding creating
> >> a
> >>>> directory called reference in the top level ofbiz directory and
> instead
> >>>> keep it in /specialpurpose. If you want to keep it in
> >>>> specialpurpose/reference, fine, if you want to keep it in
> >>>> specialpurpose/your-component-here fine, if you want to do anything in
> >>>> specialpurpose then also fine My point was simply to suggest steering
> >>> away
> >>>> from ofbiz top level directory.
> >>>>
> >>>> Regards,
> >>>>
> >>>> Taher Alkhateeb
> >>>>
> >>>> On Thu, Jun 16, 2016 at 5:34 PM, Mridul Pathak <
> >>>> mridul.pathak@hotwaxsystems.com> wrote:
> >>>>
> >>>>> Hi Taher,
> >>>>>
> >>>>> Payment integration files in accounting/thirdparty are not just
> unused
> >>>>> files and all of it is not dead code. There is the whole
> functionality
> >>>>> built around those files which is very crucial to production delivery
> >> of
> >>>>> order management or ecommerce on top of OFBiz. There are many service
> >>>>> definition files whose implementation is written in these java files.
> >>> Some
> >>>>> examples are,
> >>>>>
> >>>>> accounting/servicedef/services_authorizedotnet.xml
> >>>>> accounting/servicedef/services_clearcommerce.xml
> >>>>> accounting/servicedef/services_cybersource.xml
> >>>>> accounting/servicedef/services_orbital.xml
> >>>>> accounting/servicedef/services_paypal.xml
> >>>>> etc.
> >>>>>
> >>>>> Along with that, many of the configurations needed to use these
> >> payment
> >>>>> solutions are maintained in accounting/config/payment.properties
> >> file. A
> >>>>> ProductStore in OFBiz as well can be configures to use on of these
> >>> payment
> >>>>> processors.
> >>>>>
> >>>>> Also, these file are intentionally excluded from compile process, but
> >>> can
> >>>>> be included if you want to use/deliver one of these existing payment
> >>>>> solution in OFBiz in production. Following is the code snippet from
> >>>>> accounting/build.xml,
> >>>>>
> >>>>> <target name="init">
> >>>>> <condition property="verisign-exclude"
> >>>>> value="org/ofbiz/accounting/thirdparty/verisign/**">
> >>>>> <not><available file="lib/payflow.jar"/></not>
> >>>>> </condition>
> >>>>> <patternset id="src.exc.set">
> >>>>> <!-- exclude the payment processor packages; comment this out
> >> to
> >>>>> not exclude if you have libs -->
> >>>>> <exclude name="${verisign-exclude}"/>
> >>>>> <exclude
> >> name="org/ofbiz/accounting/thirdparty/cybersource/**"/>
> >>>>> <exclude
> >>>>> name="org/ofbiz/accounting/thirdparty/paypal/PayPalServices.java"/>
> >>>>> <exclude name="org/ofbiz/accounting/thirdparty/orbital/**"/>
> >>>>> <exclude name="org/ofbiz/accounting/thirdparty/securepay/**"/>
> >>>>> <exclude name="org/ofbiz/accounting/thirdparty/ideal/**"/>
> >>>>> </patternset>
> >>>>> </target>
> >>>>>
> >>>>> It clearly mentions that if you have required libraries for any of
> the
> >>>>> third party payment solutions, you could comment out the exclusion.
> >>>>> Usually, when someone needs to use one of the available payment
> >>> processor,
> >>>>> they download the required jar and place it in accounting/lib folder,
> >>> make
> >>>>> the needed changes in build.xml and they are ready to use the
> >> respective
> >>>>> payment solution.
> >>>>>
> >>>>> We have used one or the other payment processors in OFBiz many a
> times
> >>> to
> >>>>> deliver payment solutions as part of the software. I believe there
> are
> >>> many
> >>>>> application users and service providers who might be using the
> payment
> >>>>> processor functionality that comes with OFBiz OOTB.
> >>>>>
> >>>>> So, it’s not just about moving some files from core applications to
> >> some
> >>>>> other directory because they seems to be unused, the whole
> >> functionality
> >>>>> needs to be moved so that current or future users of these
> >>> functionalities
> >>>>> can still use it. And that is the reason if we create a new special
> >>> purpose
> >>>>> component it will help us to keep the functionality intact and usable
> >> at
> >>>>> the same time separate it from core applications. That would also
> >>> enable us
> >>>>> to keep such components out of component-load.xml and
> >>>>> specialpurpose/build.xml. A README file would help the user with
> >>> directions
> >>>>> to use it.
> >>>>>
> >>>>> Additionally, I feel that most of these files may need to be upgraded
> >>> and
> >>>>> needs code refactoring probably because they might usually be left
> out
> >>> as
> >>>>> they do not compile by default with OFBiz.
> >>>>>
> >>>>> --
> >>>>> Thanks & Regards,
> >>>>> Mridul Pathak
> >>>>> HotWax Systems
> >>>>> http://www.hotwaxsystems.com
> >>>>>
> >>>>>> On Jun 16, 2016, at 6:44 PM, Taher Alkhateeb <
> >>> slidingfilaments@gmail.com>
> >>>>> wrote:
> >>>>>>
> >>>>>> Hey Folks,
> >>>>>>
> >>>>>> I would prefer to keep dead code away from the top level OFBiz
> >>> directory.
> >>>>>> If you keep it there then you make it _closer_ to the framework!
> >>>>>>
> >>>>>> Anyway, I don't see a problem with keeping it in specialpurpose! You
> >>> are
> >>>>>> not creating a component, you are just creating a folder called
> >>> reference
> >>>>>> and adding stuff to it, and you are not adding it to
> >>> component-load.xml?
> >>>>>> Why is it that you cannot add it there?
> >>>>>>
> >>>>>> Regards,
> >>>>>>
> >>>>>> Taher Alkhateeb
> >>>>>>
> >>>>>> On Thu, Jun 16, 2016 at 3:55 PM, Mridul Pathak <
> >>>>>> mridul.pathak@hotwaxsystems.com> wrote:
> >>>>>>
> >>>>>>> Introducing new directory “reference” seems reasonable approach to
> >> me
> >>> as
> >>>>>>> it is a combined solution to everyone’s views.
> >>>>>>>
> >>>>>>> --
> >>>>>>> Thanks & Regards,
> >>>>>>> Mridul Pathak
> >>>>>>> Senior Manager
> >>>>>>> HotWax Systems
> >>>>>>> http://www.hotwaxsystems.com
> >>>>>>>
> >>>>>>>> On Jun 16, 2016, at 5:56 PM, Jacques Le Roux <
> >>>>>>> jacques.le.roux@les7arts.com> wrote:
> >>>>>>>>
> >>>>>>>> Hi Divesh,
> >>>>>>>>
> >>>>>>>> Le 16/06/2016 à 13:38, Divesh Dutta a écrit :
> >>>>>>>>>> 3- In the case of non-compiling / broken / missing dependencies
> >>> code
> >>>>>>>>>>>>> highlight this issue somewhere visible to the programmer
> >>> (README,
> >>>>>>>>>>>>> whatever). Why is this important? Because we need to tell our
> >>>>> build
> >>>>>>>>>>>>> scripts
> >>>>>>>>>>>>> and our classpath settings to ignore these files.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> The reason why I suggested to keep all of them in
> >>>>>>>>>>>>> /reference/each-component-name-here is to tell the build
> >> system
> >>> to
> >>>>>>> ignore
> >>>>>>>>>>>>> all Java files found in /specialpurpose/reference. If you
> >>> instead
> >>>>>>> break it
> >>>>>>>>>>>>> up into multiple components, then I need to ignore the files
> >> in
> >>>>> each
> >>>>>>>>>>>>> component by hand which makes the build script more complex
> >> and
> >>>>>>> more prone
> >>>>>>>>>>>>> to human error and it would add to the confusion.
> >>>>>>>>>>>>>
> >>>>>>>>>>> I agree and I think your initial proposition ("How about
> >>>>>>>>>>> reference/paymentext and reference/whatever-else-you-want?")
> was
> >>> not
> >>>>>>>>>>> clearly understood by Pierre and maybe not Divesh. Pierre,
> >> Divesh?
> >>>>>>>>>>>
> >>>>>>>>> Actually Jacques, we cannot create component like
> >>>>>>>>> specialpurpose/reference/paymentext . Other way can be we
> >> introduce
> >>>>> new
> >>>>>>>>> directory "reference" in parallel to specialpurpose, applications
> >> ,
> >>>>>>>>> framework . Do you mean to do that ?
> >>>>>>>>
> >>>>>>>> You are right, and following Taher's idea I missed this point, it
> >>> seems
> >>>>>>> to me that your proposition of <<introducing a new directory
> >>>>> "reference" in
> >>>>>>> parallel to specialpurpose, applications ,framework>> is the best
> >> one
> >>> so
> >>>>>>> far.
> >>>>>>>> It could be also that Taher anticipated on the work (I know) he
> >> will
> >>> do
> >>>>>>> on refactoring the build system and this possibility will be open
> >>>>> "soon",
> >>>>>>> Taher?
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Also as Mridul put it, and you agreed, the "shipping
> >> integration/s"
> >>>>>>> which
> >>>>>>>>>>> "doesn’t have the compilation or library reference issues"
> would
> >>> be
> >>>>>>> in its
> >>>>>>>>>>> own independent component/s (ie not under /reference), same for
> >>>>> other
> >>>>>>> stuff
> >>>>>>>>>>> with the same status, if exist.
> >>>>>>>>> In this case, shipping integration can be under special purpose.
> >> So
> >>>>>>>>> specialpurpose/shippingIntegratio.
> >>>>>>>>
> >>>>>>>> Clearly, nobrainer :)
> >>>>>>>>
> >>>>>>>> Jacques
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Thanks
> >>>>>>>>> --
> >>>>>>>>> Divesh Dutta.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>
>
>
Re: Proposal to delete stale java files
Posted by Mridul Pathak <mr...@hotwaxsystems.com>.
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 <pi...@gmail.com> wrote:
>
> Hi all,
>
> Moving all 3rd party related integrations solutions from accounting,
> product and order into 1 special purpose component makes is worse to
> maintain. Moving those from accounting into one in special purpose, those
> from product into one and those from order into another just shifts the
> problem from the base applications stack to a another stack, which is the
> complexity that results from the total being being bigger than the sum of
> its parts.
>
> I understand and accept that there might be adopters of old release out
> there that are still on those old releases and use some (or all) of the 3rd
> party integrations. But I believe that breaking these sets up in to the
> smaller components not only makes maintenance less complex but also
> increases the appeal of OFBiz (visavis completeness and flexibility). Given
> that this is in the 'improvement' section of what we do, I understand that,
> it won't be back ported to running release branches. So, there is a means
> to communicate up front and prepare the adopters who want to migrate.
>
> Therefore I suggest we split the 3rd party payment solutions integrations
> up into:
> /specialpurpose/paypay
> /specialpurpose/orbital
> etc
>
> and the 3rd party shipment solutions integrations up into:
> /specialpurpose/dhl
> /specialpurpose/fedex
> /specialpurpose/ups
> etc
>
> and the same for the other 3rd party solutions integrations.
>
> After all, these functionalities should be optionals, not mandatories from
> an integration perspective. Splitting them up will also bring the benefit
> of easier maintenance, bringing in contributors who are experienced with
> that piece of software and if adoption/use is 0, an easier path to the
> attic (in stead of waiting and waiting untill all goes to being unused.
>
> Bringing this to separate components in special purpose doesn't mean we
> need to bring those into the build process (as long as they are not fixed).
> Leaving them out of the component-load.xml file (or commented out) will
> avoid that, and give adopters an opt-in choice.
>
> So to recap:
> +1 on the move out of the base applications stack
> -1 on the move in catch-all components in another stack.
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM <http://www.orrtiz.com>
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Thu, Jun 16, 2016 at 7:57 PM, Taher Alkhateeb <slidingfilaments@gmail.com
>> wrote:
>
>> +1 thank you for your dedication and thinking of this
>> On Jun 16, 2016 8:55 PM, "Mridul Pathak" <mr...@hotwaxsystems.com>
>> wrote:
>>
>>> Hi Taher,
>>>
>>> I was just trying to suggest that we will have to create two components
>> in
>>> specialpurpose, one for payment processor related functionality and one
>> for
>>> tax related functionality and the reason behind it. Which means we should
>>> probably drop the idea of introducing a directory named “reference” and
>>> instead create two separate components.
>>>
>>> Our main goal here is to move these files out of core applications and
>>> most of us are fine with moving it to specialpurpose. I think we can
>>> conclude our approach as most of us seems fine with having two separate
>>> components in specialpurpose which was the original suggestion as well.
>>>
>>> --
>>> Thanks & Regards,
>>> Mridul Pathak
>>> HotWax Systems
>>> http://www.hotwaxsystems.com
>>>
>>>> On Jun 16, 2016, at 8:23 PM, Taher Alkhateeb <
>> slidingfilaments@gmail.com>
>>> wrote:
>>>>
>>>> Hi Mridul,
>>>>
>>>> Thank you for the detailed and well thought out feedback.
>>>>
>>>> I am a little confused however, what is the point you are trying to
>>> state?
>>>> The only point from my previous email was to suggest avoiding creating
>> a
>>>> directory called reference in the top level ofbiz directory and instead
>>>> keep it in /specialpurpose. If you want to keep it in
>>>> specialpurpose/reference, fine, if you want to keep it in
>>>> specialpurpose/your-component-here fine, if you want to do anything in
>>>> specialpurpose then also fine My point was simply to suggest steering
>>> away
>>>> from ofbiz top level directory.
>>>>
>>>> Regards,
>>>>
>>>> Taher Alkhateeb
>>>>
>>>> On Thu, Jun 16, 2016 at 5:34 PM, Mridul Pathak <
>>>> mridul.pathak@hotwaxsystems.com> wrote:
>>>>
>>>>> Hi Taher,
>>>>>
>>>>> Payment integration files in accounting/thirdparty are not just unused
>>>>> files and all of it is not dead code. There is the whole functionality
>>>>> built around those files which is very crucial to production delivery
>> of
>>>>> order management or ecommerce on top of OFBiz. There are many service
>>>>> definition files whose implementation is written in these java files.
>>> Some
>>>>> examples are,
>>>>>
>>>>> accounting/servicedef/services_authorizedotnet.xml
>>>>> accounting/servicedef/services_clearcommerce.xml
>>>>> accounting/servicedef/services_cybersource.xml
>>>>> accounting/servicedef/services_orbital.xml
>>>>> accounting/servicedef/services_paypal.xml
>>>>> etc.
>>>>>
>>>>> Along with that, many of the configurations needed to use these
>> payment
>>>>> solutions are maintained in accounting/config/payment.properties
>> file. A
>>>>> ProductStore in OFBiz as well can be configures to use on of these
>>> payment
>>>>> processors.
>>>>>
>>>>> Also, these file are intentionally excluded from compile process, but
>>> can
>>>>> be included if you want to use/deliver one of these existing payment
>>>>> solution in OFBiz in production. Following is the code snippet from
>>>>> accounting/build.xml,
>>>>>
>>>>> <target name="init">
>>>>> <condition property="verisign-exclude"
>>>>> value="org/ofbiz/accounting/thirdparty/verisign/**">
>>>>> <not><available file="lib/payflow.jar"/></not>
>>>>> </condition>
>>>>> <patternset id="src.exc.set">
>>>>> <!-- exclude the payment processor packages; comment this out
>> to
>>>>> not exclude if you have libs -->
>>>>> <exclude name="${verisign-exclude}"/>
>>>>> <exclude
>> name="org/ofbiz/accounting/thirdparty/cybersource/**"/>
>>>>> <exclude
>>>>> name="org/ofbiz/accounting/thirdparty/paypal/PayPalServices.java"/>
>>>>> <exclude name="org/ofbiz/accounting/thirdparty/orbital/**"/>
>>>>> <exclude name="org/ofbiz/accounting/thirdparty/securepay/**"/>
>>>>> <exclude name="org/ofbiz/accounting/thirdparty/ideal/**"/>
>>>>> </patternset>
>>>>> </target>
>>>>>
>>>>> It clearly mentions that if you have required libraries for any of the
>>>>> third party payment solutions, you could comment out the exclusion.
>>>>> Usually, when someone needs to use one of the available payment
>>> processor,
>>>>> they download the required jar and place it in accounting/lib folder,
>>> make
>>>>> the needed changes in build.xml and they are ready to use the
>> respective
>>>>> payment solution.
>>>>>
>>>>> We have used one or the other payment processors in OFBiz many a times
>>> to
>>>>> deliver payment solutions as part of the software. I believe there are
>>> many
>>>>> application users and service providers who might be using the payment
>>>>> processor functionality that comes with OFBiz OOTB.
>>>>>
>>>>> So, it’s not just about moving some files from core applications to
>> some
>>>>> other directory because they seems to be unused, the whole
>> functionality
>>>>> needs to be moved so that current or future users of these
>>> functionalities
>>>>> can still use it. And that is the reason if we create a new special
>>> purpose
>>>>> component it will help us to keep the functionality intact and usable
>> at
>>>>> the same time separate it from core applications. That would also
>>> enable us
>>>>> to keep such components out of component-load.xml and
>>>>> specialpurpose/build.xml. A README file would help the user with
>>> directions
>>>>> to use it.
>>>>>
>>>>> Additionally, I feel that most of these files may need to be upgraded
>>> and
>>>>> needs code refactoring probably because they might usually be left out
>>> as
>>>>> they do not compile by default with OFBiz.
>>>>>
>>>>> --
>>>>> Thanks & Regards,
>>>>> Mridul Pathak
>>>>> HotWax Systems
>>>>> http://www.hotwaxsystems.com
>>>>>
>>>>>> On Jun 16, 2016, at 6:44 PM, Taher Alkhateeb <
>>> slidingfilaments@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> Hey Folks,
>>>>>>
>>>>>> I would prefer to keep dead code away from the top level OFBiz
>>> directory.
>>>>>> If you keep it there then you make it _closer_ to the framework!
>>>>>>
>>>>>> Anyway, I don't see a problem with keeping it in specialpurpose! You
>>> are
>>>>>> not creating a component, you are just creating a folder called
>>> reference
>>>>>> and adding stuff to it, and you are not adding it to
>>> component-load.xml?
>>>>>> Why is it that you cannot add it there?
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Taher Alkhateeb
>>>>>>
>>>>>> On Thu, Jun 16, 2016 at 3:55 PM, Mridul Pathak <
>>>>>> mridul.pathak@hotwaxsystems.com> wrote:
>>>>>>
>>>>>>> Introducing new directory “reference” seems reasonable approach to
>> me
>>> as
>>>>>>> it is a combined solution to everyone’s views.
>>>>>>>
>>>>>>> --
>>>>>>> Thanks & Regards,
>>>>>>> Mridul Pathak
>>>>>>> Senior Manager
>>>>>>> HotWax Systems
>>>>>>> http://www.hotwaxsystems.com
>>>>>>>
>>>>>>>> On Jun 16, 2016, at 5:56 PM, Jacques Le Roux <
>>>>>>> jacques.le.roux@les7arts.com> wrote:
>>>>>>>>
>>>>>>>> Hi Divesh,
>>>>>>>>
>>>>>>>> Le 16/06/2016 à 13:38, Divesh Dutta a écrit :
>>>>>>>>>> 3- In the case of non-compiling / broken / missing dependencies
>>> code
>>>>>>>>>>>>> highlight this issue somewhere visible to the programmer
>>> (README,
>>>>>>>>>>>>> whatever). Why is this important? Because we need to tell our
>>>>> build
>>>>>>>>>>>>> scripts
>>>>>>>>>>>>> and our classpath settings to ignore these files.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The reason why I suggested to keep all of them in
>>>>>>>>>>>>> /reference/each-component-name-here is to tell the build
>> system
>>> to
>>>>>>> ignore
>>>>>>>>>>>>> all Java files found in /specialpurpose/reference. If you
>>> instead
>>>>>>> break it
>>>>>>>>>>>>> up into multiple components, then I need to ignore the files
>> in
>>>>> each
>>>>>>>>>>>>> component by hand which makes the build script more complex
>> and
>>>>>>> more prone
>>>>>>>>>>>>> to human error and it would add to the confusion.
>>>>>>>>>>>>>
>>>>>>>>>>> I agree and I think your initial proposition ("How about
>>>>>>>>>>> reference/paymentext and reference/whatever-else-you-want?") was
>>> not
>>>>>>>>>>> clearly understood by Pierre and maybe not Divesh. Pierre,
>> Divesh?
>>>>>>>>>>>
>>>>>>>>> Actually Jacques, we cannot create component like
>>>>>>>>> specialpurpose/reference/paymentext . Other way can be we
>> introduce
>>>>> new
>>>>>>>>> directory "reference" in parallel to specialpurpose, applications
>> ,
>>>>>>>>> framework . Do you mean to do that ?
>>>>>>>>
>>>>>>>> You are right, and following Taher's idea I missed this point, it
>>> seems
>>>>>>> to me that your proposition of <<introducing a new directory
>>>>> "reference" in
>>>>>>> parallel to specialpurpose, applications ,framework>> is the best
>> one
>>> so
>>>>>>> far.
>>>>>>>> It could be also that Taher anticipated on the work (I know) he
>> will
>>> do
>>>>>>> on refactoring the build system and this possibility will be open
>>>>> "soon",
>>>>>>> Taher?
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Also as Mridul put it, and you agreed, the "shipping
>> integration/s"
>>>>>>> which
>>>>>>>>>>> "doesn’t have the compilation or library reference issues" would
>>> be
>>>>>>> in its
>>>>>>>>>>> own independent component/s (ie not under /reference), same for
>>>>> other
>>>>>>> stuff
>>>>>>>>>>> with the same status, if exist.
>>>>>>>>> In this case, shipping integration can be under special purpose.
>> So
>>>>>>>>> specialpurpose/shippingIntegratio.
>>>>>>>>
>>>>>>>> Clearly, nobrainer :)
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> --
>>>>>>>>> Divesh Dutta.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>>
Re: Proposal to delete stale java files
Posted by Pierre Smits <pi...@gmail.com>.
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 <slidingfilaments@gmail.com
> wrote:
> +1 thank you for your dedication and thinking of this
> On Jun 16, 2016 8:55 PM, "Mridul Pathak" <mr...@hotwaxsystems.com>
> wrote:
>
> > Hi Taher,
> >
> > I was just trying to suggest that we will have to create two components
> in
> > specialpurpose, one for payment processor related functionality and one
> for
> > tax related functionality and the reason behind it. Which means we should
> > probably drop the idea of introducing a directory named “reference” and
> > instead create two separate components.
> >
> > Our main goal here is to move these files out of core applications and
> > most of us are fine with moving it to specialpurpose. I think we can
> > conclude our approach as most of us seems fine with having two separate
> > components in specialpurpose which was the original suggestion as well.
> >
> > --
> > Thanks & Regards,
> > Mridul Pathak
> > HotWax Systems
> > http://www.hotwaxsystems.com
> >
> > > On Jun 16, 2016, at 8:23 PM, Taher Alkhateeb <
> slidingfilaments@gmail.com>
> > wrote:
> > >
> > > Hi Mridul,
> > >
> > > Thank you for the detailed and well thought out feedback.
> > >
> > > I am a little confused however, what is the point you are trying to
> > state?
> > > The only point from my previous email was to suggest avoiding creating
> a
> > > directory called reference in the top level ofbiz directory and instead
> > > keep it in /specialpurpose. If you want to keep it in
> > > specialpurpose/reference, fine, if you want to keep it in
> > > specialpurpose/your-component-here fine, if you want to do anything in
> > > specialpurpose then also fine My point was simply to suggest steering
> > away
> > > from ofbiz top level directory.
> > >
> > > Regards,
> > >
> > > Taher Alkhateeb
> > >
> > > On Thu, Jun 16, 2016 at 5:34 PM, Mridul Pathak <
> > > mridul.pathak@hotwaxsystems.com> wrote:
> > >
> > >> Hi Taher,
> > >>
> > >> Payment integration files in accounting/thirdparty are not just unused
> > >> files and all of it is not dead code. There is the whole functionality
> > >> built around those files which is very crucial to production delivery
> of
> > >> order management or ecommerce on top of OFBiz. There are many service
> > >> definition files whose implementation is written in these java files.
> > Some
> > >> examples are,
> > >>
> > >> accounting/servicedef/services_authorizedotnet.xml
> > >> accounting/servicedef/services_clearcommerce.xml
> > >> accounting/servicedef/services_cybersource.xml
> > >> accounting/servicedef/services_orbital.xml
> > >> accounting/servicedef/services_paypal.xml
> > >> etc.
> > >>
> > >> Along with that, many of the configurations needed to use these
> payment
> > >> solutions are maintained in accounting/config/payment.properties
> file. A
> > >> ProductStore in OFBiz as well can be configures to use on of these
> > payment
> > >> processors.
> > >>
> > >> Also, these file are intentionally excluded from compile process, but
> > can
> > >> be included if you want to use/deliver one of these existing payment
> > >> solution in OFBiz in production. Following is the code snippet from
> > >> accounting/build.xml,
> > >>
> > >> <target name="init">
> > >> <condition property="verisign-exclude"
> > >> value="org/ofbiz/accounting/thirdparty/verisign/**">
> > >> <not><available file="lib/payflow.jar"/></not>
> > >> </condition>
> > >> <patternset id="src.exc.set">
> > >> <!-- exclude the payment processor packages; comment this out
> to
> > >> not exclude if you have libs -->
> > >> <exclude name="${verisign-exclude}"/>
> > >> <exclude
> name="org/ofbiz/accounting/thirdparty/cybersource/**"/>
> > >> <exclude
> > >> name="org/ofbiz/accounting/thirdparty/paypal/PayPalServices.java"/>
> > >> <exclude name="org/ofbiz/accounting/thirdparty/orbital/**"/>
> > >> <exclude name="org/ofbiz/accounting/thirdparty/securepay/**"/>
> > >> <exclude name="org/ofbiz/accounting/thirdparty/ideal/**"/>
> > >> </patternset>
> > >> </target>
> > >>
> > >> It clearly mentions that if you have required libraries for any of the
> > >> third party payment solutions, you could comment out the exclusion.
> > >> Usually, when someone needs to use one of the available payment
> > processor,
> > >> they download the required jar and place it in accounting/lib folder,
> > make
> > >> the needed changes in build.xml and they are ready to use the
> respective
> > >> payment solution.
> > >>
> > >> We have used one or the other payment processors in OFBiz many a times
> > to
> > >> deliver payment solutions as part of the software. I believe there are
> > many
> > >> application users and service providers who might be using the payment
> > >> processor functionality that comes with OFBiz OOTB.
> > >>
> > >> So, it’s not just about moving some files from core applications to
> some
> > >> other directory because they seems to be unused, the whole
> functionality
> > >> needs to be moved so that current or future users of these
> > functionalities
> > >> can still use it. And that is the reason if we create a new special
> > purpose
> > >> component it will help us to keep the functionality intact and usable
> at
> > >> the same time separate it from core applications. That would also
> > enable us
> > >> to keep such components out of component-load.xml and
> > >> specialpurpose/build.xml. A README file would help the user with
> > directions
> > >> to use it.
> > >>
> > >> Additionally, I feel that most of these files may need to be upgraded
> > and
> > >> needs code refactoring probably because they might usually be left out
> > as
> > >> they do not compile by default with OFBiz.
> > >>
> > >> --
> > >> Thanks & Regards,
> > >> Mridul Pathak
> > >> HotWax Systems
> > >> http://www.hotwaxsystems.com
> > >>
> > >>> On Jun 16, 2016, at 6:44 PM, Taher Alkhateeb <
> > slidingfilaments@gmail.com>
> > >> wrote:
> > >>>
> > >>> Hey Folks,
> > >>>
> > >>> I would prefer to keep dead code away from the top level OFBiz
> > directory.
> > >>> If you keep it there then you make it _closer_ to the framework!
> > >>>
> > >>> Anyway, I don't see a problem with keeping it in specialpurpose! You
> > are
> > >>> not creating a component, you are just creating a folder called
> > reference
> > >>> and adding stuff to it, and you are not adding it to
> > component-load.xml?
> > >>> Why is it that you cannot add it there?
> > >>>
> > >>> Regards,
> > >>>
> > >>> Taher Alkhateeb
> > >>>
> > >>> On Thu, Jun 16, 2016 at 3:55 PM, Mridul Pathak <
> > >>> mridul.pathak@hotwaxsystems.com> wrote:
> > >>>
> > >>>> Introducing new directory “reference” seems reasonable approach to
> me
> > as
> > >>>> it is a combined solution to everyone’s views.
> > >>>>
> > >>>> --
> > >>>> Thanks & Regards,
> > >>>> Mridul Pathak
> > >>>> Senior Manager
> > >>>> HotWax Systems
> > >>>> http://www.hotwaxsystems.com
> > >>>>
> > >>>>> On Jun 16, 2016, at 5:56 PM, Jacques Le Roux <
> > >>>> jacques.le.roux@les7arts.com> wrote:
> > >>>>>
> > >>>>> Hi Divesh,
> > >>>>>
> > >>>>> Le 16/06/2016 à 13:38, Divesh Dutta a écrit :
> > >>>>>>> 3- In the case of non-compiling / broken / missing dependencies
> > code
> > >>>>>>>>>> highlight this issue somewhere visible to the programmer
> > (README,
> > >>>>>>>>>> whatever). Why is this important? Because we need to tell our
> > >> build
> > >>>>>>>>>> scripts
> > >>>>>>>>>> and our classpath settings to ignore these files.
> > >>>>>>>>>>
> > >>>>>>>>>> The reason why I suggested to keep all of them in
> > >>>>>>>>>> /reference/each-component-name-here is to tell the build
> system
> > to
> > >>>> ignore
> > >>>>>>>>>> all Java files found in /specialpurpose/reference. If you
> > instead
> > >>>> break it
> > >>>>>>>>>> up into multiple components, then I need to ignore the files
> in
> > >> each
> > >>>>>>>>>> component by hand which makes the build script more complex
> and
> > >>>> more prone
> > >>>>>>>>>> to human error and it would add to the confusion.
> > >>>>>>>>>>
> > >>>>>>>> I agree and I think your initial proposition ("How about
> > >>>>>>>> reference/paymentext and reference/whatever-else-you-want?") was
> > not
> > >>>>>>>> clearly understood by Pierre and maybe not Divesh. Pierre,
> Divesh?
> > >>>>>>>>
> > >>>>>> Actually Jacques, we cannot create component like
> > >>>>>> specialpurpose/reference/paymentext . Other way can be we
> introduce
> > >> new
> > >>>>>> directory "reference" in parallel to specialpurpose, applications
> ,
> > >>>>>> framework . Do you mean to do that ?
> > >>>>>
> > >>>>> You are right, and following Taher's idea I missed this point, it
> > seems
> > >>>> to me that your proposition of <<introducing a new directory
> > >> "reference" in
> > >>>> parallel to specialpurpose, applications ,framework>> is the best
> one
> > so
> > >>>> far.
> > >>>>> It could be also that Taher anticipated on the work (I know) he
> will
> > do
> > >>>> on refactoring the build system and this possibility will be open
> > >> "soon",
> > >>>> Taher?
> > >>>>>
> > >>>>>>
> > >>>>>> Also as Mridul put it, and you agreed, the "shipping
> integration/s"
> > >>>> which
> > >>>>>>>> "doesn’t have the compilation or library reference issues" would
> > be
> > >>>> in its
> > >>>>>>>> own independent component/s (ie not under /reference), same for
> > >> other
> > >>>> stuff
> > >>>>>>>> with the same status, if exist.
> > >>>>>> In this case, shipping integration can be under special purpose.
> So
> > >>>>>> specialpurpose/shippingIntegratio.
> > >>>>>
> > >>>>> Clearly, nobrainer :)
> > >>>>>
> > >>>>> Jacques
> > >>>>>>
> > >>>>>>
> > >>>>>> Thanks
> > >>>>>> --
> > >>>>>> Divesh Dutta.
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>>
> > >>
> > >>
> >
> >
>
Re: Proposal to delete stale java files
Posted by Taher Alkhateeb <sl...@gmail.com>.
+1 thank you for your dedication and thinking of this
On Jun 16, 2016 8:55 PM, "Mridul Pathak" <mr...@hotwaxsystems.com>
wrote:
> Hi Taher,
>
> I was just trying to suggest that we will have to create two components in
> specialpurpose, one for payment processor related functionality and one for
> tax related functionality and the reason behind it. Which means we should
> probably drop the idea of introducing a directory named “reference” and
> instead create two separate components.
>
> Our main goal here is to move these files out of core applications and
> most of us are fine with moving it to specialpurpose. I think we can
> conclude our approach as most of us seems fine with having two separate
> components in specialpurpose which was the original suggestion as well.
>
> --
> Thanks & Regards,
> Mridul Pathak
> HotWax Systems
> http://www.hotwaxsystems.com
>
> > On Jun 16, 2016, at 8:23 PM, Taher Alkhateeb <sl...@gmail.com>
> wrote:
> >
> > Hi Mridul,
> >
> > Thank you for the detailed and well thought out feedback.
> >
> > I am a little confused however, what is the point you are trying to
> state?
> > The only point from my previous email was to suggest avoiding creating a
> > directory called reference in the top level ofbiz directory and instead
> > keep it in /specialpurpose. If you want to keep it in
> > specialpurpose/reference, fine, if you want to keep it in
> > specialpurpose/your-component-here fine, if you want to do anything in
> > specialpurpose then also fine My point was simply to suggest steering
> away
> > from ofbiz top level directory.
> >
> > Regards,
> >
> > Taher Alkhateeb
> >
> > On Thu, Jun 16, 2016 at 5:34 PM, Mridul Pathak <
> > mridul.pathak@hotwaxsystems.com> wrote:
> >
> >> Hi Taher,
> >>
> >> Payment integration files in accounting/thirdparty are not just unused
> >> files and all of it is not dead code. There is the whole functionality
> >> built around those files which is very crucial to production delivery of
> >> order management or ecommerce on top of OFBiz. There are many service
> >> definition files whose implementation is written in these java files.
> Some
> >> examples are,
> >>
> >> accounting/servicedef/services_authorizedotnet.xml
> >> accounting/servicedef/services_clearcommerce.xml
> >> accounting/servicedef/services_cybersource.xml
> >> accounting/servicedef/services_orbital.xml
> >> accounting/servicedef/services_paypal.xml
> >> etc.
> >>
> >> Along with that, many of the configurations needed to use these payment
> >> solutions are maintained in accounting/config/payment.properties file. A
> >> ProductStore in OFBiz as well can be configures to use on of these
> payment
> >> processors.
> >>
> >> Also, these file are intentionally excluded from compile process, but
> can
> >> be included if you want to use/deliver one of these existing payment
> >> solution in OFBiz in production. Following is the code snippet from
> >> accounting/build.xml,
> >>
> >> <target name="init">
> >> <condition property="verisign-exclude"
> >> value="org/ofbiz/accounting/thirdparty/verisign/**">
> >> <not><available file="lib/payflow.jar"/></not>
> >> </condition>
> >> <patternset id="src.exc.set">
> >> <!-- exclude the payment processor packages; comment this out to
> >> not exclude if you have libs -->
> >> <exclude name="${verisign-exclude}"/>
> >> <exclude name="org/ofbiz/accounting/thirdparty/cybersource/**"/>
> >> <exclude
> >> name="org/ofbiz/accounting/thirdparty/paypal/PayPalServices.java"/>
> >> <exclude name="org/ofbiz/accounting/thirdparty/orbital/**"/>
> >> <exclude name="org/ofbiz/accounting/thirdparty/securepay/**"/>
> >> <exclude name="org/ofbiz/accounting/thirdparty/ideal/**"/>
> >> </patternset>
> >> </target>
> >>
> >> It clearly mentions that if you have required libraries for any of the
> >> third party payment solutions, you could comment out the exclusion.
> >> Usually, when someone needs to use one of the available payment
> processor,
> >> they download the required jar and place it in accounting/lib folder,
> make
> >> the needed changes in build.xml and they are ready to use the respective
> >> payment solution.
> >>
> >> We have used one or the other payment processors in OFBiz many a times
> to
> >> deliver payment solutions as part of the software. I believe there are
> many
> >> application users and service providers who might be using the payment
> >> processor functionality that comes with OFBiz OOTB.
> >>
> >> So, it’s not just about moving some files from core applications to some
> >> other directory because they seems to be unused, the whole functionality
> >> needs to be moved so that current or future users of these
> functionalities
> >> can still use it. And that is the reason if we create a new special
> purpose
> >> component it will help us to keep the functionality intact and usable at
> >> the same time separate it from core applications. That would also
> enable us
> >> to keep such components out of component-load.xml and
> >> specialpurpose/build.xml. A README file would help the user with
> directions
> >> to use it.
> >>
> >> Additionally, I feel that most of these files may need to be upgraded
> and
> >> needs code refactoring probably because they might usually be left out
> as
> >> they do not compile by default with OFBiz.
> >>
> >> --
> >> Thanks & Regards,
> >> Mridul Pathak
> >> HotWax Systems
> >> http://www.hotwaxsystems.com
> >>
> >>> On Jun 16, 2016, at 6:44 PM, Taher Alkhateeb <
> slidingfilaments@gmail.com>
> >> wrote:
> >>>
> >>> Hey Folks,
> >>>
> >>> I would prefer to keep dead code away from the top level OFBiz
> directory.
> >>> If you keep it there then you make it _closer_ to the framework!
> >>>
> >>> Anyway, I don't see a problem with keeping it in specialpurpose! You
> are
> >>> not creating a component, you are just creating a folder called
> reference
> >>> and adding stuff to it, and you are not adding it to
> component-load.xml?
> >>> Why is it that you cannot add it there?
> >>>
> >>> Regards,
> >>>
> >>> Taher Alkhateeb
> >>>
> >>> On Thu, Jun 16, 2016 at 3:55 PM, Mridul Pathak <
> >>> mridul.pathak@hotwaxsystems.com> wrote:
> >>>
> >>>> Introducing new directory “reference” seems reasonable approach to me
> as
> >>>> it is a combined solution to everyone’s views.
> >>>>
> >>>> --
> >>>> Thanks & Regards,
> >>>> Mridul Pathak
> >>>> Senior Manager
> >>>> HotWax Systems
> >>>> http://www.hotwaxsystems.com
> >>>>
> >>>>> On Jun 16, 2016, at 5:56 PM, Jacques Le Roux <
> >>>> jacques.le.roux@les7arts.com> wrote:
> >>>>>
> >>>>> Hi Divesh,
> >>>>>
> >>>>> Le 16/06/2016 à 13:38, Divesh Dutta a écrit :
> >>>>>>> 3- In the case of non-compiling / broken / missing dependencies
> code
> >>>>>>>>>> highlight this issue somewhere visible to the programmer
> (README,
> >>>>>>>>>> whatever). Why is this important? Because we need to tell our
> >> build
> >>>>>>>>>> scripts
> >>>>>>>>>> and our classpath settings to ignore these files.
> >>>>>>>>>>
> >>>>>>>>>> The reason why I suggested to keep all of them in
> >>>>>>>>>> /reference/each-component-name-here is to tell the build system
> to
> >>>> ignore
> >>>>>>>>>> all Java files found in /specialpurpose/reference. If you
> instead
> >>>> break it
> >>>>>>>>>> up into multiple components, then I need to ignore the files in
> >> each
> >>>>>>>>>> component by hand which makes the build script more complex and
> >>>> more prone
> >>>>>>>>>> to human error and it would add to the confusion.
> >>>>>>>>>>
> >>>>>>>> I agree and I think your initial proposition ("How about
> >>>>>>>> reference/paymentext and reference/whatever-else-you-want?") was
> not
> >>>>>>>> clearly understood by Pierre and maybe not Divesh. Pierre, Divesh?
> >>>>>>>>
> >>>>>> Actually Jacques, we cannot create component like
> >>>>>> specialpurpose/reference/paymentext . Other way can be we introduce
> >> new
> >>>>>> directory "reference" in parallel to specialpurpose, applications ,
> >>>>>> framework . Do you mean to do that ?
> >>>>>
> >>>>> You are right, and following Taher's idea I missed this point, it
> seems
> >>>> to me that your proposition of <<introducing a new directory
> >> "reference" in
> >>>> parallel to specialpurpose, applications ,framework>> is the best one
> so
> >>>> far.
> >>>>> It could be also that Taher anticipated on the work (I know) he will
> do
> >>>> on refactoring the build system and this possibility will be open
> >> "soon",
> >>>> Taher?
> >>>>>
> >>>>>>
> >>>>>> Also as Mridul put it, and you agreed, the "shipping integration/s"
> >>>> which
> >>>>>>>> "doesn’t have the compilation or library reference issues" would
> be
> >>>> in its
> >>>>>>>> own independent component/s (ie not under /reference), same for
> >> other
> >>>> stuff
> >>>>>>>> with the same status, if exist.
> >>>>>> In this case, shipping integration can be under special purpose. So
> >>>>>> specialpurpose/shippingIntegratio.
> >>>>>
> >>>>> Clearly, nobrainer :)
> >>>>>
> >>>>> Jacques
> >>>>>>
> >>>>>>
> >>>>>> Thanks
> >>>>>> --
> >>>>>> Divesh Dutta.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>
> >>
>
>
Re: Proposal to delete stale java files
Posted by Mridul Pathak <mr...@hotwaxsystems.com>.
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 <sl...@gmail.com> wrote:
>
> Hi Mridul,
>
> Thank you for the detailed and well thought out feedback.
>
> I am a little confused however, what is the point you are trying to state?
> The only point from my previous email was to suggest avoiding creating a
> directory called reference in the top level ofbiz directory and instead
> keep it in /specialpurpose. If you want to keep it in
> specialpurpose/reference, fine, if you want to keep it in
> specialpurpose/your-component-here fine, if you want to do anything in
> specialpurpose then also fine My point was simply to suggest steering away
> from ofbiz top level directory.
>
> Regards,
>
> Taher Alkhateeb
>
> On Thu, Jun 16, 2016 at 5:34 PM, Mridul Pathak <
> mridul.pathak@hotwaxsystems.com> wrote:
>
>> Hi Taher,
>>
>> Payment integration files in accounting/thirdparty are not just unused
>> files and all of it is not dead code. There is the whole functionality
>> built around those files which is very crucial to production delivery of
>> order management or ecommerce on top of OFBiz. There are many service
>> definition files whose implementation is written in these java files. Some
>> examples are,
>>
>> accounting/servicedef/services_authorizedotnet.xml
>> accounting/servicedef/services_clearcommerce.xml
>> accounting/servicedef/services_cybersource.xml
>> accounting/servicedef/services_orbital.xml
>> accounting/servicedef/services_paypal.xml
>> etc.
>>
>> Along with that, many of the configurations needed to use these payment
>> solutions are maintained in accounting/config/payment.properties file. A
>> ProductStore in OFBiz as well can be configures to use on of these payment
>> processors.
>>
>> Also, these file are intentionally excluded from compile process, but can
>> be included if you want to use/deliver one of these existing payment
>> solution in OFBiz in production. Following is the code snippet from
>> accounting/build.xml,
>>
>> <target name="init">
>> <condition property="verisign-exclude"
>> value="org/ofbiz/accounting/thirdparty/verisign/**">
>> <not><available file="lib/payflow.jar"/></not>
>> </condition>
>> <patternset id="src.exc.set">
>> <!-- exclude the payment processor packages; comment this out to
>> not exclude if you have libs -->
>> <exclude name="${verisign-exclude}"/>
>> <exclude name="org/ofbiz/accounting/thirdparty/cybersource/**"/>
>> <exclude
>> name="org/ofbiz/accounting/thirdparty/paypal/PayPalServices.java"/>
>> <exclude name="org/ofbiz/accounting/thirdparty/orbital/**"/>
>> <exclude name="org/ofbiz/accounting/thirdparty/securepay/**"/>
>> <exclude name="org/ofbiz/accounting/thirdparty/ideal/**"/>
>> </patternset>
>> </target>
>>
>> It clearly mentions that if you have required libraries for any of the
>> third party payment solutions, you could comment out the exclusion.
>> Usually, when someone needs to use one of the available payment processor,
>> they download the required jar and place it in accounting/lib folder, make
>> the needed changes in build.xml and they are ready to use the respective
>> payment solution.
>>
>> We have used one or the other payment processors in OFBiz many a times to
>> deliver payment solutions as part of the software. I believe there are many
>> application users and service providers who might be using the payment
>> processor functionality that comes with OFBiz OOTB.
>>
>> So, it’s not just about moving some files from core applications to some
>> other directory because they seems to be unused, the whole functionality
>> needs to be moved so that current or future users of these functionalities
>> can still use it. And that is the reason if we create a new special purpose
>> component it will help us to keep the functionality intact and usable at
>> the same time separate it from core applications. That would also enable us
>> to keep such components out of component-load.xml and
>> specialpurpose/build.xml. A README file would help the user with directions
>> to use it.
>>
>> Additionally, I feel that most of these files may need to be upgraded and
>> needs code refactoring probably because they might usually be left out as
>> they do not compile by default with OFBiz.
>>
>> --
>> Thanks & Regards,
>> Mridul Pathak
>> HotWax Systems
>> http://www.hotwaxsystems.com
>>
>>> On Jun 16, 2016, at 6:44 PM, Taher Alkhateeb <sl...@gmail.com>
>> wrote:
>>>
>>> Hey Folks,
>>>
>>> I would prefer to keep dead code away from the top level OFBiz directory.
>>> If you keep it there then you make it _closer_ to the framework!
>>>
>>> Anyway, I don't see a problem with keeping it in specialpurpose! You are
>>> not creating a component, you are just creating a folder called reference
>>> and adding stuff to it, and you are not adding it to component-load.xml?
>>> Why is it that you cannot add it there?
>>>
>>> Regards,
>>>
>>> Taher Alkhateeb
>>>
>>> On Thu, Jun 16, 2016 at 3:55 PM, Mridul Pathak <
>>> mridul.pathak@hotwaxsystems.com> wrote:
>>>
>>>> Introducing new directory “reference” seems reasonable approach to me as
>>>> it is a combined solution to everyone’s views.
>>>>
>>>> --
>>>> Thanks & Regards,
>>>> Mridul Pathak
>>>> Senior Manager
>>>> HotWax Systems
>>>> http://www.hotwaxsystems.com
>>>>
>>>>> On Jun 16, 2016, at 5:56 PM, Jacques Le Roux <
>>>> jacques.le.roux@les7arts.com> wrote:
>>>>>
>>>>> Hi Divesh,
>>>>>
>>>>> Le 16/06/2016 à 13:38, Divesh Dutta a écrit :
>>>>>>> 3- In the case of non-compiling / broken / missing dependencies code
>>>>>>>>>> highlight this issue somewhere visible to the programmer (README,
>>>>>>>>>> whatever). Why is this important? Because we need to tell our
>> build
>>>>>>>>>> scripts
>>>>>>>>>> and our classpath settings to ignore these files.
>>>>>>>>>>
>>>>>>>>>> The reason why I suggested to keep all of them in
>>>>>>>>>> /reference/each-component-name-here is to tell the build system to
>>>> ignore
>>>>>>>>>> all Java files found in /specialpurpose/reference. If you instead
>>>> break it
>>>>>>>>>> up into multiple components, then I need to ignore the files in
>> each
>>>>>>>>>> component by hand which makes the build script more complex and
>>>> more prone
>>>>>>>>>> to human error and it would add to the confusion.
>>>>>>>>>>
>>>>>>>> I agree and I think your initial proposition ("How about
>>>>>>>> reference/paymentext and reference/whatever-else-you-want?") was not
>>>>>>>> clearly understood by Pierre and maybe not Divesh. Pierre, Divesh?
>>>>>>>>
>>>>>> Actually Jacques, we cannot create component like
>>>>>> specialpurpose/reference/paymentext . Other way can be we introduce
>> new
>>>>>> directory "reference" in parallel to specialpurpose, applications ,
>>>>>> framework . Do you mean to do that ?
>>>>>
>>>>> You are right, and following Taher's idea I missed this point, it seems
>>>> to me that your proposition of <<introducing a new directory
>> "reference" in
>>>> parallel to specialpurpose, applications ,framework>> is the best one so
>>>> far.
>>>>> It could be also that Taher anticipated on the work (I know) he will do
>>>> on refactoring the build system and this possibility will be open
>> "soon",
>>>> Taher?
>>>>>
>>>>>>
>>>>>> Also as Mridul put it, and you agreed, the "shipping integration/s"
>>>> which
>>>>>>>> "doesn’t have the compilation or library reference issues" would be
>>>> in its
>>>>>>>> own independent component/s (ie not under /reference), same for
>> other
>>>> stuff
>>>>>>>> with the same status, if exist.
>>>>>> In this case, shipping integration can be under special purpose. So
>>>>>> specialpurpose/shippingIntegratio.
>>>>>
>>>>> Clearly, nobrainer :)
>>>>>
>>>>> Jacques
>>>>>>
>>>>>>
>>>>>> Thanks
>>>>>> --
>>>>>> Divesh Dutta.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>
>>
Re: Proposal to delete stale java files
Posted by Taher Alkhateeb <sl...@gmail.com>.
Hi Mridul,
Thank you for the detailed and well thought out feedback.
I am a little confused however, what is the point you are trying to state?
The only point from my previous email was to suggest avoiding creating a
directory called reference in the top level ofbiz directory and instead
keep it in /specialpurpose. If you want to keep it in
specialpurpose/reference, fine, if you want to keep it in
specialpurpose/your-component-here fine, if you want to do anything in
specialpurpose then also fine My point was simply to suggest steering away
from ofbiz top level directory.
Regards,
Taher Alkhateeb
On Thu, Jun 16, 2016 at 5:34 PM, Mridul Pathak <
mridul.pathak@hotwaxsystems.com> wrote:
> Hi Taher,
>
> Payment integration files in accounting/thirdparty are not just unused
> files and all of it is not dead code. There is the whole functionality
> built around those files which is very crucial to production delivery of
> order management or ecommerce on top of OFBiz. There are many service
> definition files whose implementation is written in these java files. Some
> examples are,
>
> accounting/servicedef/services_authorizedotnet.xml
> accounting/servicedef/services_clearcommerce.xml
> accounting/servicedef/services_cybersource.xml
> accounting/servicedef/services_orbital.xml
> accounting/servicedef/services_paypal.xml
> etc.
>
> Along with that, many of the configurations needed to use these payment
> solutions are maintained in accounting/config/payment.properties file. A
> ProductStore in OFBiz as well can be configures to use on of these payment
> processors.
>
> Also, these file are intentionally excluded from compile process, but can
> be included if you want to use/deliver one of these existing payment
> solution in OFBiz in production. Following is the code snippet from
> accounting/build.xml,
>
> <target name="init">
> <condition property="verisign-exclude"
> value="org/ofbiz/accounting/thirdparty/verisign/**">
> <not><available file="lib/payflow.jar"/></not>
> </condition>
> <patternset id="src.exc.set">
> <!-- exclude the payment processor packages; comment this out to
> not exclude if you have libs -->
> <exclude name="${verisign-exclude}"/>
> <exclude name="org/ofbiz/accounting/thirdparty/cybersource/**"/>
> <exclude
> name="org/ofbiz/accounting/thirdparty/paypal/PayPalServices.java"/>
> <exclude name="org/ofbiz/accounting/thirdparty/orbital/**"/>
> <exclude name="org/ofbiz/accounting/thirdparty/securepay/**"/>
> <exclude name="org/ofbiz/accounting/thirdparty/ideal/**"/>
> </patternset>
> </target>
>
> It clearly mentions that if you have required libraries for any of the
> third party payment solutions, you could comment out the exclusion.
> Usually, when someone needs to use one of the available payment processor,
> they download the required jar and place it in accounting/lib folder, make
> the needed changes in build.xml and they are ready to use the respective
> payment solution.
>
> We have used one or the other payment processors in OFBiz many a times to
> deliver payment solutions as part of the software. I believe there are many
> application users and service providers who might be using the payment
> processor functionality that comes with OFBiz OOTB.
>
> So, it’s not just about moving some files from core applications to some
> other directory because they seems to be unused, the whole functionality
> needs to be moved so that current or future users of these functionalities
> can still use it. And that is the reason if we create a new special purpose
> component it will help us to keep the functionality intact and usable at
> the same time separate it from core applications. That would also enable us
> to keep such components out of component-load.xml and
> specialpurpose/build.xml. A README file would help the user with directions
> to use it.
>
> Additionally, I feel that most of these files may need to be upgraded and
> needs code refactoring probably because they might usually be left out as
> they do not compile by default with OFBiz.
>
> --
> Thanks & Regards,
> Mridul Pathak
> HotWax Systems
> http://www.hotwaxsystems.com
>
> > On Jun 16, 2016, at 6:44 PM, Taher Alkhateeb <sl...@gmail.com>
> wrote:
> >
> > Hey Folks,
> >
> > I would prefer to keep dead code away from the top level OFBiz directory.
> > If you keep it there then you make it _closer_ to the framework!
> >
> > Anyway, I don't see a problem with keeping it in specialpurpose! You are
> > not creating a component, you are just creating a folder called reference
> > and adding stuff to it, and you are not adding it to component-load.xml?
> > Why is it that you cannot add it there?
> >
> > Regards,
> >
> > Taher Alkhateeb
> >
> > On Thu, Jun 16, 2016 at 3:55 PM, Mridul Pathak <
> > mridul.pathak@hotwaxsystems.com> wrote:
> >
> >> Introducing new directory “reference” seems reasonable approach to me as
> >> it is a combined solution to everyone’s views.
> >>
> >> --
> >> Thanks & Regards,
> >> Mridul Pathak
> >> Senior Manager
> >> HotWax Systems
> >> http://www.hotwaxsystems.com
> >>
> >>> On Jun 16, 2016, at 5:56 PM, Jacques Le Roux <
> >> jacques.le.roux@les7arts.com> wrote:
> >>>
> >>> Hi Divesh,
> >>>
> >>> Le 16/06/2016 à 13:38, Divesh Dutta a écrit :
> >>>>> 3- In the case of non-compiling / broken / missing dependencies code
> >>>>>>>> highlight this issue somewhere visible to the programmer (README,
> >>>>>>>> whatever). Why is this important? Because we need to tell our
> build
> >>>>>>>> scripts
> >>>>>>>> and our classpath settings to ignore these files.
> >>>>>>>>
> >>>>>>>> The reason why I suggested to keep all of them in
> >>>>>>>> /reference/each-component-name-here is to tell the build system to
> >> ignore
> >>>>>>>> all Java files found in /specialpurpose/reference. If you instead
> >> break it
> >>>>>>>> up into multiple components, then I need to ignore the files in
> each
> >>>>>>>> component by hand which makes the build script more complex and
> >> more prone
> >>>>>>>> to human error and it would add to the confusion.
> >>>>>>>>
> >>>>>> I agree and I think your initial proposition ("How about
> >>>>>> reference/paymentext and reference/whatever-else-you-want?") was not
> >>>>>> clearly understood by Pierre and maybe not Divesh. Pierre, Divesh?
> >>>>>>
> >>>> Actually Jacques, we cannot create component like
> >>>> specialpurpose/reference/paymentext . Other way can be we introduce
> new
> >>>> directory "reference" in parallel to specialpurpose, applications ,
> >>>> framework . Do you mean to do that ?
> >>>
> >>> You are right, and following Taher's idea I missed this point, it seems
> >> to me that your proposition of <<introducing a new directory
> "reference" in
> >> parallel to specialpurpose, applications ,framework>> is the best one so
> >> far.
> >>> It could be also that Taher anticipated on the work (I know) he will do
> >> on refactoring the build system and this possibility will be open
> "soon",
> >> Taher?
> >>>
> >>>>
> >>>> Also as Mridul put it, and you agreed, the "shipping integration/s"
> >> which
> >>>>>> "doesn’t have the compilation or library reference issues" would be
> >> in its
> >>>>>> own independent component/s (ie not under /reference), same for
> other
> >> stuff
> >>>>>> with the same status, if exist.
> >>>> In this case, shipping integration can be under special purpose. So
> >>>> specialpurpose/shippingIntegratio.
> >>>
> >>> Clearly, nobrainer :)
> >>>
> >>> Jacques
> >>>>
> >>>>
> >>>> Thanks
> >>>> --
> >>>> Divesh Dutta.
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >>
>
>
Re: Proposal to delete stale java files
Posted by Mridul Pathak <mr...@hotwaxsystems.com>.
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 <sl...@gmail.com> wrote:
>
> Hey Folks,
>
> I would prefer to keep dead code away from the top level OFBiz directory.
> If you keep it there then you make it _closer_ to the framework!
>
> Anyway, I don't see a problem with keeping it in specialpurpose! You are
> not creating a component, you are just creating a folder called reference
> and adding stuff to it, and you are not adding it to component-load.xml?
> Why is it that you cannot add it there?
>
> Regards,
>
> Taher Alkhateeb
>
> On Thu, Jun 16, 2016 at 3:55 PM, Mridul Pathak <
> mridul.pathak@hotwaxsystems.com> wrote:
>
>> Introducing new directory “reference” seems reasonable approach to me as
>> it is a combined solution to everyone’s views.
>>
>> --
>> Thanks & Regards,
>> Mridul Pathak
>> Senior Manager
>> HotWax Systems
>> http://www.hotwaxsystems.com
>>
>>> On Jun 16, 2016, at 5:56 PM, Jacques Le Roux <
>> jacques.le.roux@les7arts.com> wrote:
>>>
>>> Hi Divesh,
>>>
>>> Le 16/06/2016 à 13:38, Divesh Dutta a écrit :
>>>>> 3- In the case of non-compiling / broken / missing dependencies code
>>>>>>>> highlight this issue somewhere visible to the programmer (README,
>>>>>>>> whatever). Why is this important? Because we need to tell our build
>>>>>>>> scripts
>>>>>>>> and our classpath settings to ignore these files.
>>>>>>>>
>>>>>>>> The reason why I suggested to keep all of them in
>>>>>>>> /reference/each-component-name-here is to tell the build system to
>> ignore
>>>>>>>> all Java files found in /specialpurpose/reference. If you instead
>> break it
>>>>>>>> up into multiple components, then I need to ignore the files in each
>>>>>>>> component by hand which makes the build script more complex and
>> more prone
>>>>>>>> to human error and it would add to the confusion.
>>>>>>>>
>>>>>> I agree and I think your initial proposition ("How about
>>>>>> reference/paymentext and reference/whatever-else-you-want?") was not
>>>>>> clearly understood by Pierre and maybe not Divesh. Pierre, Divesh?
>>>>>>
>>>> Actually Jacques, we cannot create component like
>>>> specialpurpose/reference/paymentext . Other way can be we introduce new
>>>> directory "reference" in parallel to specialpurpose, applications ,
>>>> framework . Do you mean to do that ?
>>>
>>> You are right, and following Taher's idea I missed this point, it seems
>> to me that your proposition of <<introducing a new directory "reference" in
>> parallel to specialpurpose, applications ,framework>> is the best one so
>> far.
>>> It could be also that Taher anticipated on the work (I know) he will do
>> on refactoring the build system and this possibility will be open "soon",
>> Taher?
>>>
>>>>
>>>> Also as Mridul put it, and you agreed, the "shipping integration/s"
>> which
>>>>>> "doesn’t have the compilation or library reference issues" would be
>> in its
>>>>>> own independent component/s (ie not under /reference), same for other
>> stuff
>>>>>> with the same status, if exist.
>>>> In this case, shipping integration can be under special purpose. So
>>>> specialpurpose/shippingIntegratio.
>>>
>>> Clearly, nobrainer :)
>>>
>>> Jacques
>>>>
>>>>
>>>> Thanks
>>>> --
>>>> Divesh Dutta.
>>>>
>>>>
>>>>
>>>
>>
>>
Re: Proposal to delete stale java files
Posted by Taher Alkhateeb <sl...@gmail.com>.
Hey Folks,
I would prefer to keep dead code away from the top level OFBiz directory.
If you keep it there then you make it _closer_ to the framework!
Anyway, I don't see a problem with keeping it in specialpurpose! You are
not creating a component, you are just creating a folder called reference
and adding stuff to it, and you are not adding it to component-load.xml?
Why is it that you cannot add it there?
Regards,
Taher Alkhateeb
On Thu, Jun 16, 2016 at 3:55 PM, Mridul Pathak <
mridul.pathak@hotwaxsystems.com> wrote:
> Introducing new directory “reference” seems reasonable approach to me as
> it is a combined solution to everyone’s views.
>
> --
> Thanks & Regards,
> Mridul Pathak
> Senior Manager
> HotWax Systems
> http://www.hotwaxsystems.com
>
> > On Jun 16, 2016, at 5:56 PM, Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
> >
> > Hi Divesh,
> >
> > Le 16/06/2016 à 13:38, Divesh Dutta a écrit :
> >>> 3- In the case of non-compiling / broken / missing dependencies code
> >>>> >>highlight this issue somewhere visible to the programmer (README,
> >>>> >>whatever). Why is this important? Because we need to tell our build
> >>>> >>scripts
> >>>> >>and our classpath settings to ignore these files.
> >>>> >>
> >>>> >>The reason why I suggested to keep all of them in
> >>>> >>/reference/each-component-name-here is to tell the build system to
> ignore
> >>>> >>all Java files found in /specialpurpose/reference. If you instead
> break it
> >>>> >>up into multiple components, then I need to ignore the files in each
> >>>> >>component by hand which makes the build script more complex and
> more prone
> >>>> >>to human error and it would add to the confusion.
> >>>> >>
> >>> >I agree and I think your initial proposition ("How about
> >>> >reference/paymentext and reference/whatever-else-you-want?") was not
> >>> >clearly understood by Pierre and maybe not Divesh. Pierre, Divesh?
> >>> >
> >> Actually Jacques, we cannot create component like
> >> specialpurpose/reference/paymentext . Other way can be we introduce new
> >> directory "reference" in parallel to specialpurpose, applications ,
> >> framework . Do you mean to do that ?
> >
> > You are right, and following Taher's idea I missed this point, it seems
> to me that your proposition of <<introducing a new directory "reference" in
> parallel to specialpurpose, applications ,framework>> is the best one so
> far.
> > It could be also that Taher anticipated on the work (I know) he will do
> on refactoring the build system and this possibility will be open "soon",
> Taher?
> >
> >>
> >> Also as Mridul put it, and you agreed, the "shipping integration/s"
> which
> >>> >"doesn’t have the compilation or library reference issues" would be
> in its
> >>> >own independent component/s (ie not under /reference), same for other
> stuff
> >>> >with the same status, if exist.
> >> In this case, shipping integration can be under special purpose. So
> >> specialpurpose/shippingIntegratio.
> >
> > Clearly, nobrainer :)
> >
> > Jacques
> >>
> >>
> >> Thanks
> >> --
> >> Divesh Dutta.
> >>
> >>
> >>
> >
>
>
Re: Proposal to delete stale java files
Posted by Mridul Pathak <mr...@hotwaxsystems.com>.
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 <ja...@les7arts.com> wrote:
>
> Hi Divesh,
>
> Le 16/06/2016 à 13:38, Divesh Dutta a écrit :
>>> 3- In the case of non-compiling / broken / missing dependencies code
>>>> >>highlight this issue somewhere visible to the programmer (README,
>>>> >>whatever). Why is this important? Because we need to tell our build
>>>> >>scripts
>>>> >>and our classpath settings to ignore these files.
>>>> >>
>>>> >>The reason why I suggested to keep all of them in
>>>> >>/reference/each-component-name-here is to tell the build system to ignore
>>>> >>all Java files found in /specialpurpose/reference. If you instead break it
>>>> >>up into multiple components, then I need to ignore the files in each
>>>> >>component by hand which makes the build script more complex and more prone
>>>> >>to human error and it would add to the confusion.
>>>> >>
>>> >I agree and I think your initial proposition ("How about
>>> >reference/paymentext and reference/whatever-else-you-want?") was not
>>> >clearly understood by Pierre and maybe not Divesh. Pierre, Divesh?
>>> >
>> Actually Jacques, we cannot create component like
>> specialpurpose/reference/paymentext . Other way can be we introduce new
>> directory "reference" in parallel to specialpurpose, applications ,
>> framework . Do you mean to do that ?
>
> You are right, and following Taher's idea I missed this point, it seems to me that your proposition of <<introducing a new directory "reference" in parallel to specialpurpose, applications ,framework>> is the best one so far.
> It could be also that Taher anticipated on the work (I know) he will do on refactoring the build system and this possibility will be open "soon", Taher?
>
>>
>> Also as Mridul put it, and you agreed, the "shipping integration/s" which
>>> >"doesn’t have the compilation or library reference issues" would be in its
>>> >own independent component/s (ie not under /reference), same for other stuff
>>> >with the same status, if exist.
>> In this case, shipping integration can be under special purpose. So
>> specialpurpose/shippingIntegratio.
>
> Clearly, nobrainer :)
>
> Jacques
>>
>>
>> Thanks
>> --
>> Divesh Dutta.
>>
>>
>>
>
Re: Proposal to delete stale java files
Posted by Jacques Le Roux <ja...@les7arts.com>.
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\u2019t 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.
>
>
>
Re: Proposal to delete stale java files
Posted by Divesh Dutta <di...@hotwaxsystems.com>.
On Thu, Jun 16, 2016 at 4:45 PM, Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:
> Le 16/06/2016 à 12:41, Taher Alkhateeb a écrit :
>
>> Hi Divesh and everyone,
>>
>> Nicely summarized, thank you for your input.
>>
>> I don't have any strong opinion on how to structure things. The important
>> thing for me whatever you decide to do is the following:
>>
>> 1- Keep dead / irrelevant code away from the framework and core
>> applications
>>
> +1
>
>> 2- Keep peripheral or non-core functionality away from framework and core
>> applications.
>>
> +1
+1 for above points.
>
> 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 ?
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.
Thanks
--
Divesh Dutta.
>
>
> Jacques
>
> So, although I still prefer to have one place for all non-compiling code,
>> if you can satisfy the above mentioned items, then at least we have a
>> middle ground even though the build scripts and classpath settings will be
>> more complex.
>>
>> Regards,
>>
>> Taher Alkhateeb
>>
>> On Thu, Jun 16, 2016 at 1:24 PM, Divesh Dutta <
>> divesh.dutta@hotwaxsystems.com> wrote:
>>
>> Thanks Pierre and Jacques for your views. I agree with Jacques that we
>>> should not create new repos and I agree with Pierre that code can be
>>> logically grouped based on business functionality.
>>>
>>> So there are two views going on:
>>>
>>> 1) Initially Taher was suggesting to remove all the codes and then when
>>> we
>>> discussed that there are lots of users who are using those codes, he
>>> suggested to create specialpurpose/reference component for non-compiling
>>> code and rest in their own components.
>>>
>>>
>>> 2) Create components in special purpose for each logical business
>>> functionality. So for eg: Payment integration specific codes can be in
>>> new
>>> component. Shipment integration code can be in its own component. This
>>> way
>>> we will logically group the business purpose specific codes and they can
>>> be further used as addons in future.
>>>
>>>
>>> So it seems that most of the code which are non-compilable are candidate
>>> of
>>> new components (for eg: tax integration, payment integration etc. ). And
>>> there are less java files which are non-compilable. Some code (java
>>> files)
>>> which are compilable can also be new component for eg: shipping
>>> integration. And all these can be separate addons in future when we have
>>> the architecture support for it. There is no such code which is
>>> non-compilable and not a candidate new component and that code will have
>>> to
>>> sit inside OFBiz (either in framework of applications.)
>>>
>>> So I think we can go with #2 where we can also add details in read me
>>> file
>>> of these components that which files of the components are dependent on
>>> which jars etc.
>>>
>>>
>>> Thanks
>>> --
>>> Divesh Dutta.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Jun 16, 2016 at 2:48 PM, Jacques Le Roux <
>>> jacques.le.roux@les7arts.com> wrote:
>>>
>>> As Ashish and some others mentioned, those are still needed by some of
>>>>
>>> our
>>>
>>>> users.
>>>> Of course we need to maintain them (logically more those who are
>>>> interested) but we can't neglect our users based on code
>>>> cleaning/refactoring.
>>>> And if we mix all in a ball of mud it, the cost of maintaining it will
>>>> be
>>>> increased. So agree with you on this part Pierre, and we need 1st to
>>>> separate things surgically and then decide about the parts.
>>>>
>>>> But, I don't like the idea of having them in "repos" (I guess you svn
>>>> branches or GitHub repo/branches?) because they would be disconnected.
>>>> I still can remember the effect of dropping the specialpurpose
>>>> component,
>>>> but ecommerce, in R13.07 (OK they were still in svn, see?)
>>>> I mean once things are disconnected, and as long as we don't have a
>>>> good/fast/reliable technical way to connect them, they tend to be
>>>>
>>> forgotten
>>>
>>>> (see what we initially discuss here), not maintained and finally
>>>> garbage.
>>>>
>>>> On the other hand, as soon as we will have a solid way to support
>>>> addons,
>>>> those will be perfect addons.
>>>> And no, I'm not speaking out of thin air, we (PMC) are currently
>>>> discussing about deep modifications in the project which should help
>>>> support, creation and adoption of addons (hint: look at Moqui, though we
>>>> don't want to incorporate Moqui framework)
>>>> Of course it's not for tomorrow, but we need to take time to decide on
>>>> crucial choices.
>>>>
>>>> As I said already dropping the bathwater with the baby is not a solution
>>>>
>>> :)
>>>
>>>> Jacques
>>>>
>>>>
>>>>
>>>> Le 16/06/2016 à 10:56, Pierre Smits a écrit :
>>>>
>>>> I suggest that we do not put code in a new catch all component
>>>>>
>>>> (reference)
>>>
>>>> for just the mere purpose of preserving it. All code elements are
>>>>>
>>>> related
>>>
>>>> to a set specific business functionality. I'd rather see that each has
>>>>>
>>>> its
>>>
>>>> own component.
>>>>>
>>>>> Also, rather than putting these in the special purpose folder and from
>>>>> there pushing them into releases (where adopters would need to delete
>>>>>
>>>> them
>>>
>>>> from when they don't want those), I would prefer to see them in separate
>>>>> repos so that the can be developed from there and if need can be
>>>>> integrated
>>>>> in a deployed OFBiz instance at will. That way we create more
>>>>>
>>>> flexibility
>>>
>>>> for our adopters and enhance the appeal.
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Pierre Smits
>>>>>
>>>>> ORRTIZ.COM <http://www.orrtiz.com>
>>>>> OFBiz based solutions & services
>>>>>
>>>>> OFBiz Extensions Marketplace
>>>>> http://oem.ofbizci.net/oci-2/
>>>>>
>>>>> On Wed, Jun 15, 2016 at 1:23 PM, Taher Alkhateeb <
>>>>> slidingfilaments@gmail.com
>>>>>
>>>>> wrote:
>>>>>> Hi Mridul,
>>>>>>
>>>>>> Ahh I see that makes sense. Yeah sure we put non-compiling stuff
>>>>>> regardless of origin in specialpurpose/reference and the rest in their
>>>>>> own
>>>>>> components.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Mridul Pathak [mailto:mridul.pathak@hotwaxsystems.com]
>>>>>> Sent: 15 June 2016 14:19
>>>>>> To: dev@ofbiz.apache.org
>>>>>> Cc: Mridul Pathak
>>>>>> Subject: Re: Proposal to delete stale java files
>>>>>>
>>>>>> Hi Taher,
>>>>>>
>>>>>> I would like to make sure that I am understanding your proposal
>>>>>> correctly.
>>>>>>
>>>>>> Are you proposing to create a specialpurpose component named
>>>>>>
>>>>> “reference”
>>>
>>>> which would have all the code that can be referenced but not compiled,
>>>>>>
>>>>> no
>>>
>>>> matter what domain it is?
>>>>>>
>>>>>> If that is the case, we have discussed about moving shipping
>>>>>>
>>>>> integrations
>>>
>>>> to specialpurpose component as well, and that code doesn’t have the
>>>>>> compilation or library reference issues as listed in this thread, so I
>>>>>> think that should go in it's own component.
>>>>>>
>>>>>> --
>>>>>> Thanks & Regards,
>>>>>> Mridul Pathak
>>>>>> Senior Manager
>>>>>> HotWax Systems
>>>>>> http://www.hotwaxsystems.com
>>>>>>
>>>>>> On Jun 15, 2016, at 3:01 PM, Taher Alkhateeb <
>>>>>>
>>>>> slidingfilaments@gmail.com
>>>
>>>> wrote:
>>>>>>
>>>>>> Hi Mridul,
>>>>>>>
>>>>>>> How about reference/paymentext and reference/whatever-else-you-want?
>>>>>>> So the top level directory is called reference to indicate to people
>>>>>>> that this is just for reference and will not compile. Also, this way
>>>>>>> we keep all reference material under one directory to avoid polluting
>>>>>>> the directory tree. My 2 cents.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Taher Alkhateeb
>>>>>>>
>>>>>>> On Wed, Jun 15, 2016 at 12:27 PM, Mridul Pathak <
>>>>>>> mridul.pathak@hotwaxsystems.com <mailto:
>>>>>>>
>>>>>> mridul.pathak@hotwaxsystems.com
>>>
>>>> wrote:
>>>>>>
>>>>>> Hi Taher,
>>>>>>>
>>>>>>>> Sure, I’ll take care of deleting rest of the files as well.
>>>>>>>>
>>>>>>>> Also, we could name these specialpurpose component(s) as paymentext,
>>>>>>>>
>>>>>>>> etc.
>>>>>>> and mention in README file that these are extensions to OFBiz and
>>>>>>>
>>>>>>>> does not compile directly.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Thanks & Regards,
>>>>>>>> Mridul Pathak
>>>>>>>> HotWax Systems
>>>>>>>> http://www.hotwaxsystems.com
>>>>>>>>
>>>>>>>> On Jun 15, 2016, at 2:37 PM, Taher Alkhateeb
>>>>>>>>
>>>>>>>>> <sl...@gmail.com>
>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi Mridul and everyone,
>>>>>>>>>
>>>>>>>>> Thank you all for your inputs. May I also ask you Mridul while you
>>>>>>>>> are
>>>>>>>>>
>>>>>>>>> at it to delete the rest of the files so the whole task resides
>>>>>>>> with
>>>>>>>> you to avoid crossing any wires.
>>>>>>>>
>>>>>>>> Also, I suggest to name that component into something like archives
>>>>>>>>> or
>>>>>>>>>
>>>>>>>>> reference and put a README file that says this component does not
>>>>>>>> compile and it holds this stuff. This way it is easy to isolate that
>>>>>>>> component from the build system.
>>>>>>>>
>>>>>>>> Thank you all again for your contributions.
>>>>>>>>>
>>>>>>>>> Taher Alkhateeb
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Mridul Pathak [mailto:mridul.pathak@hotwaxsystems.com
>>>>>>>>>
>>>>>>>> <mailto:
>>>
>>>> mridul.pathak@hotwaxsystems.com> <mailto:
>>>>>>>>
>>>>>>> mridul.pathak@hotwaxsystems.com
>>>>>>>
>>>>>>>> <ma...@hotwaxsystems.com>>]
>>>>>>>>
>>>>>>>> Sent: 15 June 2016 11:09
>>>>>>>>> To: dev@ofbiz.apache.org <ma...@ofbiz.apache.org>
>>>>>>>>> <mailto:dev@ofbiz.apache.org <ma...@ofbiz.apache.org>>
>>>>>>>>> Cc: Mridul Pathak
>>>>>>>>> Subject: Re: Proposal to delete stale java files
>>>>>>>>>
>>>>>>>>> I would like to volunteer for this change (moving payment, shipping
>>>>>>>>> and
>>>>>>>>>
>>>>>>>>> tax integrations to specialpurpose).
>>>>>>>>
>>>>>>>> --
>>>>>>>>> Mridul Pathak
>>>>>>>>>
>>>>>>>>> On Wednesday 15 June 2016, Jacopo Cappellato <
>>>>>>>>>
>>>>>>>>> jacopo.cappellato@hotwaxsystems.com <mailto:
>>>>>>>>
>>>>>>>> jacopo.cappellato@hotwaxsystems.com>> wrote:
>>>>>>> Based on the new comments it seems like that we could isolate the
>>>>>>>
>>>>>>>> shipment, payment and tax integration classes (and artifacts that
>>>>>>>>>> use
>>>>>>>>>> them) into their own specialpurpose components (waiting for a
>>>>>>>>>> better pluggable components architecture); they will not be
>>>>>>>>>> compiled by default but each component will have its own readme
>>>>>>>>>> file containing instructions about how to deploy and use them.
>>>>>>>>>> As regards the JasperReports*, JRE* and openoffice ones I think
>>>>>>>>>> they can go to Attic since they are old and unmaintained.
>>>>>>>>>>
>>>>>>>>>> Does it make sense? Any volunteers to create the new
>>>>>>>>>> specialpurpose
>>>>>>>>>> components and upgrade/isolate the shipment/payment/tax
>>>>>>>>>> integration
>>>>>>>>>> classes into them?
>>>>>>>>>>
>>>>>>>>>> Jacopo
>>>>>>>>>>
>>>>>>>>>> On Wed, Jun 15, 2016 at 9:32 AM, Hans Bakker
>>>>>>>>>> <h.bakker@antwebsystems.com <ma...@antwebsystems.com>
>>>>>>>>>> <mailto:h.bakker@antwebsystems.com
>>>>>>>>>> <ma...@antwebsystems.com>>
>>>>>>>>>>
>>>>>>>>>> <javascript:;>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> +1
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 15/06/16 13:30, Ashish Vijaywargiya wrote:
>>>>>>>>>>>
>>>>>>>>>>> I would prefer to keep Tax and Third Party Payment gateway
>>>>>>>>>>>
>>>>>>>>>>>> files(The
>>>>>>>>>>>>
>>>>>>>>>>>> files
>>>>>>>>>>> that does exists inside cybersource, ideal, orbital, paypal,
>>>>>>>>>>>
>>>>>>>>>>>> securepay, verisign etc). If you see some problems in those code
>>>>>>>>>>>> base, like code
>>>>>>>>>>>>
>>>>>>>>>>>> base
>>>>>>>>>>> is not updated based on latest changes then we can update those
>>>>>>>>>>> files.
>>>>>>>>>>>
>>>>>>>>>> Those files might have been used by so many users that we can't
>>>>>>>
>>>>>>>> know because we are doing this conversation on Dev mailing list.
>>>>>>>>>>>> We should
>>>>>>>>>>>>
>>>>>>>>>>>> not
>>>>>>>>>>> remove those files.
>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Kind Regards
>>>>>>>>>>>> Ashish Vijaywargiya
>>>>>>>>>>>> HotWax Systems - est. 1997
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Jun 14, 2016 at 7:40 PM, Taher Alkhateeb <
>>>>>>>>>>>> slidingfilaments@gmail.com <javascript:;>
>>>>>>>>>>>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Everyone,
>>>>>>>>>>>>> I cannot actually believe it but while I was working on a
>>>>>>>>>>>>> project (I
>>>>>>>>>>>>>
>>>>>>>>>>>>> will
>>>>>>>>>>>>
>>>>>>>>>>> announce later) I discovered in the process that the below files
>>>>>>>>>>>
>>>>>>>>>>>> cannot compile!!! They existed for years in the code base
>>>>>>>>>>>>> without even being able to compile. They reference non existent
>>>>>>>>>>>>> libraries or they have faulty code (e.g. not importing used
>>>>>>>>>>>>> code)
>>>>>>>>>>>>>
>>>>>>>>>>>>> I propose to delete them immediately from trunk
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/cyberso
>>>>>>>>>> urc
>>>>>>>>>> e/IcsPaymentServices.java
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/I
>>>>>>>>>> dea
>>>>>>>>>> lEvents.java
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/I
>>>>>>>>>> dea
>>>>>>>>>> lPaymentServiceTest.java
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/orbital
>>>>>>>>>> /Or
>>>>>>>>>> bitalPaymentServices.java
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/paypal/
>>>>>>>>>> Pay
>>>>>>>>>> PalServices.java
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securep
>>>>>>>>>> ay/
>>>>>>>>>> SecurePayPaymentServices.java
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securep
>>>>>>>>>> ay/
>>>>>>>>>> SecurePayServiceTest.java
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/verisig
>>>>>>>>>> n/P
>>>>>>>>>> ayflowPro.java
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByt
>>>>>>>>>> eAr
>>>>>>>>>> rayInputStream.java
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByt
>>>>>>>>>> eAr
>>>>>>>>>> rayOutputStream.java
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeSer
>>>>>>>>>> vic
>>>>>>>>>> es.java
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeWor
>>>>>>>>>> ker
>>>>>>>>>> .java
>>>>>>>>>>
>>>>>>>>>> applications/content/src/org/ofbiz/content/report
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>> applications/content/src/org/ofbiz/content/report/JREntityListItera
>>>>>>>>>> tor
>>>>>>>>>> DataSource.java
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>> applications/content/src/org/ofbiz/content/report/JRMapCollectionDa
>>>>>>>>>> taS
>>>>>>>>>> ource.java
>>>>>>>>>>
>>>>>>>>>> applications/order/src/org/ofbiz/order/thirdparty/taxware
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareEx
>>>>>>>>>> cep
>>>>>>>>>> tion.java
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareSe
>>>>>>>>>> rvi
>>>>>>>>>> ces.java
>>>>>>>>>>
>>>>>>>>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareUT
>>>>>>>>>> L.j
>>>>>>>>>> ava
>>>>>>>>>>
>>>>>>>>>> applications/product/src/ShipmentScaleApplet.java
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>> applications/securityext/src/org/ofbiz/securityext/thirdparty/truit
>>>>>>>>>> ion
>>>>>>>>>> /TruitionCoReg.java
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsJXlsViewHan
>>>>>>>>>> dle
>>>>>>>>>> r.java
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPdfViewHand
>>>>>>>>>> ler
>>>>>>>>>> .java
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPoiXlsViewH
>>>>>>>>>> and
>>>>>>>>>> ler.java
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsXmlViewHand
>>>>>>>>>> ler
>>>>>>>>>> .java
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>>>
>>>>>>>>>>>> Taher Alkhateeb
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>
>>>>>>>>>>> Hans Bakker
>>>>>>>>>>> CEO, http://antwebsystems.com
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>> Mridul Pathak
>>>>>>>>> Senior Manager
>>>>>>>>> HotWax Systems
>>>>>>>>> http://www.hotwaxsystems.com
>>>>>>>>> direct: +91-942592692
>>>>>>>>>
>>>>>>>>>
>>>>>>
>
Re: Proposal to delete stale java files
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 16/06/2016 � 12:41, Taher Alkhateeb a �crit :
> Hi Divesh and everyone,
>
> Nicely summarized, thank you for your input.
>
> I don't have any strong opinion on how to structure things. The important
> thing for me whatever you decide to do is the following:
>
> 1- Keep dead / irrelevant code away from the framework and core applications
+1
> 2- Keep peripheral or non-core functionality away from framework and core
> applications.
+1
> 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?
Also as Mridul put it, and you agreed, the "shipping integration/s" which "doesn\u2019t 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.
Jacques
> So, although I still prefer to have one place for all non-compiling code,
> if you can satisfy the above mentioned items, then at least we have a
> middle ground even though the build scripts and classpath settings will be
> more complex.
>
> Regards,
>
> Taher Alkhateeb
>
> On Thu, Jun 16, 2016 at 1:24 PM, Divesh Dutta <
> divesh.dutta@hotwaxsystems.com> wrote:
>
>> Thanks Pierre and Jacques for your views. I agree with Jacques that we
>> should not create new repos and I agree with Pierre that code can be
>> logically grouped based on business functionality.
>>
>> So there are two views going on:
>>
>> 1) Initially Taher was suggesting to remove all the codes and then when we
>> discussed that there are lots of users who are using those codes, he
>> suggested to create specialpurpose/reference component for non-compiling
>> code and rest in their own components.
>>
>>
>> 2) Create components in special purpose for each logical business
>> functionality. So for eg: Payment integration specific codes can be in new
>> component. Shipment integration code can be in its own component. This way
>> we will logically group the business purpose specific codes and they can
>> be further used as addons in future.
>>
>>
>> So it seems that most of the code which are non-compilable are candidate of
>> new components (for eg: tax integration, payment integration etc. ). And
>> there are less java files which are non-compilable. Some code (java files)
>> which are compilable can also be new component for eg: shipping
>> integration. And all these can be separate addons in future when we have
>> the architecture support for it. There is no such code which is
>> non-compilable and not a candidate new component and that code will have to
>> sit inside OFBiz (either in framework of applications.)
>>
>> So I think we can go with #2 where we can also add details in read me file
>> of these components that which files of the components are dependent on
>> which jars etc.
>>
>>
>> Thanks
>> --
>> Divesh Dutta.
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Jun 16, 2016 at 2:48 PM, Jacques Le Roux <
>> jacques.le.roux@les7arts.com> wrote:
>>
>>> As Ashish and some others mentioned, those are still needed by some of
>> our
>>> users.
>>> Of course we need to maintain them (logically more those who are
>>> interested) but we can't neglect our users based on code
>>> cleaning/refactoring.
>>> And if we mix all in a ball of mud it, the cost of maintaining it will be
>>> increased. So agree with you on this part Pierre, and we need 1st to
>>> separate things surgically and then decide about the parts.
>>>
>>> But, I don't like the idea of having them in "repos" (I guess you svn
>>> branches or GitHub repo/branches?) because they would be disconnected.
>>> I still can remember the effect of dropping the specialpurpose component,
>>> but ecommerce, in R13.07 (OK they were still in svn, see?)
>>> I mean once things are disconnected, and as long as we don't have a
>>> good/fast/reliable technical way to connect them, they tend to be
>> forgotten
>>> (see what we initially discuss here), not maintained and finally garbage.
>>>
>>> On the other hand, as soon as we will have a solid way to support addons,
>>> those will be perfect addons.
>>> And no, I'm not speaking out of thin air, we (PMC) are currently
>>> discussing about deep modifications in the project which should help
>>> support, creation and adoption of addons (hint: look at Moqui, though we
>>> don't want to incorporate Moqui framework)
>>> Of course it's not for tomorrow, but we need to take time to decide on
>>> crucial choices.
>>>
>>> As I said already dropping the bathwater with the baby is not a solution
>> :)
>>> Jacques
>>>
>>>
>>>
>>> Le 16/06/2016 � 10:56, Pierre Smits a �crit :
>>>
>>>> I suggest that we do not put code in a new catch all component
>> (reference)
>>>> for just the mere purpose of preserving it. All code elements are
>> related
>>>> to a set specific business functionality. I'd rather see that each has
>> its
>>>> own component.
>>>>
>>>> Also, rather than putting these in the special purpose folder and from
>>>> there pushing them into releases (where adopters would need to delete
>> them
>>>> from when they don't want those), I would prefer to see them in separate
>>>> repos so that the can be developed from there and if need can be
>>>> integrated
>>>> in a deployed OFBiz instance at will. That way we create more
>> flexibility
>>>> for our adopters and enhance the appeal.
>>>>
>>>> Best regards,
>>>>
>>>> Pierre Smits
>>>>
>>>> ORRTIZ.COM <http://www.orrtiz.com>
>>>> OFBiz based solutions & services
>>>>
>>>> OFBiz Extensions Marketplace
>>>> http://oem.ofbizci.net/oci-2/
>>>>
>>>> On Wed, Jun 15, 2016 at 1:23 PM, Taher Alkhateeb <
>>>> slidingfilaments@gmail.com
>>>>
>>>>> wrote:
>>>>> Hi Mridul,
>>>>>
>>>>> Ahh I see that makes sense. Yeah sure we put non-compiling stuff
>>>>> regardless of origin in specialpurpose/reference and the rest in their
>>>>> own
>>>>> components.
>>>>>
>>>>> Regards,
>>>>>
>>>>> -----Original Message-----
>>>>> From: Mridul Pathak [mailto:mridul.pathak@hotwaxsystems.com]
>>>>> Sent: 15 June 2016 14:19
>>>>> To: dev@ofbiz.apache.org
>>>>> Cc: Mridul Pathak
>>>>> Subject: Re: Proposal to delete stale java files
>>>>>
>>>>> Hi Taher,
>>>>>
>>>>> I would like to make sure that I am understanding your proposal
>>>>> correctly.
>>>>>
>>>>> Are you proposing to create a specialpurpose component named
>> \u201creference\u201d
>>>>> which would have all the code that can be referenced but not compiled,
>> no
>>>>> matter what domain it is?
>>>>>
>>>>> If that is the case, we have discussed about moving shipping
>> integrations
>>>>> to specialpurpose component as well, and that code doesn\u2019t have the
>>>>> compilation or library reference issues as listed in this thread, so I
>>>>> think that should go in it's own component.
>>>>>
>>>>> --
>>>>> Thanks & Regards,
>>>>> Mridul Pathak
>>>>> Senior Manager
>>>>> HotWax Systems
>>>>> http://www.hotwaxsystems.com
>>>>>
>>>>> On Jun 15, 2016, at 3:01 PM, Taher Alkhateeb <
>> slidingfilaments@gmail.com
>>>>> wrote:
>>>>>
>>>>>> Hi Mridul,
>>>>>>
>>>>>> How about reference/paymentext and reference/whatever-else-you-want?
>>>>>> So the top level directory is called reference to indicate to people
>>>>>> that this is just for reference and will not compile. Also, this way
>>>>>> we keep all reference material under one directory to avoid polluting
>>>>>> the directory tree. My 2 cents.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Taher Alkhateeb
>>>>>>
>>>>>> On Wed, Jun 15, 2016 at 12:27 PM, Mridul Pathak <
>>>>>> mridul.pathak@hotwaxsystems.com <mailto:
>> mridul.pathak@hotwaxsystems.com
>>>>> wrote:
>>>>>
>>>>>> Hi Taher,
>>>>>>> Sure, I\u2019ll take care of deleting rest of the files as well.
>>>>>>>
>>>>>>> Also, we could name these specialpurpose component(s) as paymentext,
>>>>>>>
>>>>>> etc.
>>>>>> and mention in README file that these are extensions to OFBiz and
>>>>>>> does not compile directly.
>>>>>>>
>>>>>>> --
>>>>>>> Thanks & Regards,
>>>>>>> Mridul Pathak
>>>>>>> HotWax Systems
>>>>>>> http://www.hotwaxsystems.com
>>>>>>>
>>>>>>> On Jun 15, 2016, at 2:37 PM, Taher Alkhateeb
>>>>>>>> <sl...@gmail.com>
>>>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Mridul and everyone,
>>>>>>>>
>>>>>>>> Thank you all for your inputs. May I also ask you Mridul while you
>>>>>>>> are
>>>>>>>>
>>>>>>> at it to delete the rest of the files so the whole task resides with
>>>>>>> you to avoid crossing any wires.
>>>>>>>
>>>>>>>> Also, I suggest to name that component into something like archives
>>>>>>>> or
>>>>>>>>
>>>>>>> reference and put a README file that says this component does not
>>>>>>> compile and it holds this stuff. This way it is easy to isolate that
>>>>>>> component from the build system.
>>>>>>>
>>>>>>>> Thank you all again for your contributions.
>>>>>>>>
>>>>>>>> Taher Alkhateeb
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Mridul Pathak [mailto:mridul.pathak@hotwaxsystems.com
>> <mailto:
>>>>>>> mridul.pathak@hotwaxsystems.com> <mailto:
>>>>>> mridul.pathak@hotwaxsystems.com
>>>>>>> <ma...@hotwaxsystems.com>>]
>>>>>>>
>>>>>>>> Sent: 15 June 2016 11:09
>>>>>>>> To: dev@ofbiz.apache.org <ma...@ofbiz.apache.org>
>>>>>>>> <mailto:dev@ofbiz.apache.org <ma...@ofbiz.apache.org>>
>>>>>>>> Cc: Mridul Pathak
>>>>>>>> Subject: Re: Proposal to delete stale java files
>>>>>>>>
>>>>>>>> I would like to volunteer for this change (moving payment, shipping
>>>>>>>> and
>>>>>>>>
>>>>>>> tax integrations to specialpurpose).
>>>>>>>
>>>>>>>> --
>>>>>>>> Mridul Pathak
>>>>>>>>
>>>>>>>> On Wednesday 15 June 2016, Jacopo Cappellato <
>>>>>>>>
>>>>>>> jacopo.cappellato@hotwaxsystems.com <mailto:
>>>>>>>
>>>>>> jacopo.cappellato@hotwaxsystems.com>> wrote:
>>>>>> Based on the new comments it seems like that we could isolate the
>>>>>>>>> shipment, payment and tax integration classes (and artifacts that
>>>>>>>>> use
>>>>>>>>> them) into their own specialpurpose components (waiting for a
>>>>>>>>> better pluggable components architecture); they will not be
>>>>>>>>> compiled by default but each component will have its own readme
>>>>>>>>> file containing instructions about how to deploy and use them.
>>>>>>>>> As regards the JasperReports*, JRE* and openoffice ones I think
>>>>>>>>> they can go to Attic since they are old and unmaintained.
>>>>>>>>>
>>>>>>>>> Does it make sense? Any volunteers to create the new specialpurpose
>>>>>>>>> components and upgrade/isolate the shipment/payment/tax integration
>>>>>>>>> classes into them?
>>>>>>>>>
>>>>>>>>> Jacopo
>>>>>>>>>
>>>>>>>>> On Wed, Jun 15, 2016 at 9:32 AM, Hans Bakker
>>>>>>>>> <h.bakker@antwebsystems.com <ma...@antwebsystems.com>
>>>>>>>>> <mailto:h.bakker@antwebsystems.com
>>>>>>>>> <ma...@antwebsystems.com>>
>>>>>>>>>
>>>>>>>> <javascript:;>>
>>>>>>>> wrote:
>>>>>>>>> +1
>>>>>>>>>>
>>>>>>>>>> On 15/06/16 13:30, Ashish Vijaywargiya wrote:
>>>>>>>>>>
>>>>>>>>>> I would prefer to keep Tax and Third Party Payment gateway
>>>>>>>>>>> files(The
>>>>>>>>>>>
>>>>>>>>>> files
>>>>>>>>>> that does exists inside cybersource, ideal, orbital, paypal,
>>>>>>>>>>> securepay, verisign etc). If you see some problems in those code
>>>>>>>>>>> base, like code
>>>>>>>>>>>
>>>>>>>>>> base
>>>>>>>>>> is not updated based on latest changes then we can update those
>>>>>>>>>> files.
>>>>>> Those files might have been used by so many users that we can't
>>>>>>>>>>> know because we are doing this conversation on Dev mailing list.
>>>>>>>>>>> We should
>>>>>>>>>>>
>>>>>>>>>> not
>>>>>>>>>> remove those files.
>>>>>>>>>>> --
>>>>>>>>>>> Kind Regards
>>>>>>>>>>> Ashish Vijaywargiya
>>>>>>>>>>> HotWax Systems - est. 1997
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Jun 14, 2016 at 7:40 PM, Taher Alkhateeb <
>>>>>>>>>>> slidingfilaments@gmail.com <javascript:;>
>>>>>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>> Hi Everyone,
>>>>>>>>>>>> I cannot actually believe it but while I was working on a
>>>>>>>>>>>> project (I
>>>>>>>>>>>>
>>>>>>>>>>> will
>>>>>>>>>> announce later) I discovered in the process that the below files
>>>>>>>>>>>> cannot compile!!! They existed for years in the code base
>>>>>>>>>>>> without even being able to compile. They reference non existent
>>>>>>>>>>>> libraries or they have faulty code (e.g. not importing used
>>>>>>>>>>>> code)
>>>>>>>>>>>>
>>>>>>>>>>>> I propose to delete them immediately from trunk
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/cyberso
>>>>>>>>> urc
>>>>>>>>> e/IcsPaymentServices.java
>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/I
>>>>>>>>> dea
>>>>>>>>> lEvents.java
>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/I
>>>>>>>>> dea
>>>>>>>>> lPaymentServiceTest.java
>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/orbital
>>>>>>>>> /Or
>>>>>>>>> bitalPaymentServices.java
>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/paypal/
>>>>>>>>> Pay
>>>>>>>>> PalServices.java
>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securep
>>>>>>>>> ay/
>>>>>>>>> SecurePayPaymentServices.java
>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securep
>>>>>>>>> ay/
>>>>>>>>> SecurePayServiceTest.java
>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/verisig
>>>>>>>>> n/P
>>>>>>>>> ayflowPro.java
>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByt
>>>>>>>>> eAr
>>>>>>>>> rayInputStream.java
>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByt
>>>>>>>>> eAr
>>>>>>>>> rayOutputStream.java
>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeSer
>>>>>>>>> vic
>>>>>>>>> es.java
>>>>>>>>>
>>>>>>>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeWor
>>>>>>>>> ker
>>>>>>>>> .java
>>>>>>>>>
>>>>>>>>>> applications/content/src/org/ofbiz/content/report
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>> applications/content/src/org/ofbiz/content/report/JREntityListItera
>>>>>>>>> tor
>>>>>>>>> DataSource.java
>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>> applications/content/src/org/ofbiz/content/report/JRMapCollectionDa
>>>>>>>>> taS
>>>>>>>>> ource.java
>>>>>>>>>
>>>>>>>>>> applications/order/src/org/ofbiz/order/thirdparty/taxware
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareEx
>>>>>>>>> cep
>>>>>>>>> tion.java
>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareSe
>>>>>>>>> rvi
>>>>>>>>> ces.java
>>>>>>>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareUT
>>>>>>>>> L.j
>>>>>>>>> ava
>>>>>>>>>
>>>>>>>>>> applications/product/src/ShipmentScaleApplet.java
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>> applications/securityext/src/org/ofbiz/securityext/thirdparty/truit
>>>>>>>>> ion
>>>>>>>>> /TruitionCoReg.java
>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsJXlsViewHan
>>>>>>>>> dle
>>>>>>>>> r.java
>>>>>>>>>
>>>>>>>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPdfViewHand
>>>>>>>>> ler
>>>>>>>>> .java
>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPoiXlsViewH
>>>>>>>>> and
>>>>>>>>> ler.java
>>>>>>>>>
>>>>>>>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsXmlViewHand
>>>>>>>>> ler
>>>>>>>>> .java
>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>>>> Taher Alkhateeb
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>> Regards,
>>>>>>>>>>
>>>>>>>>>> Hans Bakker
>>>>>>>>>> CEO, http://antwebsystems.com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> --
>>>>>>>> Mridul Pathak
>>>>>>>> Senior Manager
>>>>>>>> HotWax Systems
>>>>>>>> http://www.hotwaxsystems.com
>>>>>>>> direct: +91-942592692
>>>>>>>>
>>>>>
Re: Proposal to delete stale java files
Posted by Taher Alkhateeb <sl...@gmail.com>.
Hi Divesh and everyone,
Nicely summarized, thank you for your input.
I don't have any strong opinion on how to structure things. The important
thing for me whatever you decide to do is the following:
1- Keep dead / irrelevant code away from the framework and core applications
2- Keep peripheral or non-core functionality away from framework and core
applications.
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.
So, although I still prefer to have one place for all non-compiling code,
if you can satisfy the above mentioned items, then at least we have a
middle ground even though the build scripts and classpath settings will be
more complex.
Regards,
Taher Alkhateeb
On Thu, Jun 16, 2016 at 1:24 PM, Divesh Dutta <
divesh.dutta@hotwaxsystems.com> wrote:
> Thanks Pierre and Jacques for your views. I agree with Jacques that we
> should not create new repos and I agree with Pierre that code can be
> logically grouped based on business functionality.
>
> So there are two views going on:
>
> 1) Initially Taher was suggesting to remove all the codes and then when we
> discussed that there are lots of users who are using those codes, he
> suggested to create specialpurpose/reference component for non-compiling
> code and rest in their own components.
>
>
> 2) Create components in special purpose for each logical business
> functionality. So for eg: Payment integration specific codes can be in new
> component. Shipment integration code can be in its own component. This way
> we will logically group the business purpose specific codes and they can
> be further used as addons in future.
>
>
> So it seems that most of the code which are non-compilable are candidate of
> new components (for eg: tax integration, payment integration etc. ). And
> there are less java files which are non-compilable. Some code (java files)
> which are compilable can also be new component for eg: shipping
> integration. And all these can be separate addons in future when we have
> the architecture support for it. There is no such code which is
> non-compilable and not a candidate new component and that code will have to
> sit inside OFBiz (either in framework of applications.)
>
> So I think we can go with #2 where we can also add details in read me file
> of these components that which files of the components are dependent on
> which jars etc.
>
>
> Thanks
> --
> Divesh Dutta.
>
>
>
>
>
>
>
> On Thu, Jun 16, 2016 at 2:48 PM, Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
>
> > As Ashish and some others mentioned, those are still needed by some of
> our
> > users.
> > Of course we need to maintain them (logically more those who are
> > interested) but we can't neglect our users based on code
> > cleaning/refactoring.
> > And if we mix all in a ball of mud it, the cost of maintaining it will be
> > increased. So agree with you on this part Pierre, and we need 1st to
> > separate things surgically and then decide about the parts.
> >
> > But, I don't like the idea of having them in "repos" (I guess you svn
> > branches or GitHub repo/branches?) because they would be disconnected.
> > I still can remember the effect of dropping the specialpurpose component,
> > but ecommerce, in R13.07 (OK they were still in svn, see?)
> > I mean once things are disconnected, and as long as we don't have a
> > good/fast/reliable technical way to connect them, they tend to be
> forgotten
> > (see what we initially discuss here), not maintained and finally garbage.
> >
> > On the other hand, as soon as we will have a solid way to support addons,
> > those will be perfect addons.
> > And no, I'm not speaking out of thin air, we (PMC) are currently
> > discussing about deep modifications in the project which should help
> > support, creation and adoption of addons (hint: look at Moqui, though we
> > don't want to incorporate Moqui framework)
> > Of course it's not for tomorrow, but we need to take time to decide on
> > crucial choices.
> >
> > As I said already dropping the bathwater with the baby is not a solution
> :)
> >
> > Jacques
> >
> >
> >
> > Le 16/06/2016 à 10:56, Pierre Smits a écrit :
> >
> >> I suggest that we do not put code in a new catch all component
> (reference)
> >> for just the mere purpose of preserving it. All code elements are
> related
> >> to a set specific business functionality. I'd rather see that each has
> its
> >> own component.
> >>
> >> Also, rather than putting these in the special purpose folder and from
> >> there pushing them into releases (where adopters would need to delete
> them
> >> from when they don't want those), I would prefer to see them in separate
> >> repos so that the can be developed from there and if need can be
> >> integrated
> >> in a deployed OFBiz instance at will. That way we create more
> flexibility
> >> for our adopters and enhance the appeal.
> >>
> >> Best regards,
> >>
> >> Pierre Smits
> >>
> >> ORRTIZ.COM <http://www.orrtiz.com>
> >> OFBiz based solutions & services
> >>
> >> OFBiz Extensions Marketplace
> >> http://oem.ofbizci.net/oci-2/
> >>
> >> On Wed, Jun 15, 2016 at 1:23 PM, Taher Alkhateeb <
> >> slidingfilaments@gmail.com
> >>
> >>> wrote:
> >>> Hi Mridul,
> >>>
> >>> Ahh I see that makes sense. Yeah sure we put non-compiling stuff
> >>> regardless of origin in specialpurpose/reference and the rest in their
> >>> own
> >>> components.
> >>>
> >>> Regards,
> >>>
> >>> -----Original Message-----
> >>> From: Mridul Pathak [mailto:mridul.pathak@hotwaxsystems.com]
> >>> Sent: 15 June 2016 14:19
> >>> To: dev@ofbiz.apache.org
> >>> Cc: Mridul Pathak
> >>> Subject: Re: Proposal to delete stale java files
> >>>
> >>> Hi Taher,
> >>>
> >>> I would like to make sure that I am understanding your proposal
> >>> correctly.
> >>>
> >>> Are you proposing to create a specialpurpose component named
> “reference”
> >>> which would have all the code that can be referenced but not compiled,
> no
> >>> matter what domain it is?
> >>>
> >>> If that is the case, we have discussed about moving shipping
> integrations
> >>> to specialpurpose component as well, and that code doesn’t have the
> >>> compilation or library reference issues as listed in this thread, so I
> >>> think that should go in it's own component.
> >>>
> >>> --
> >>> Thanks & Regards,
> >>> Mridul Pathak
> >>> Senior Manager
> >>> HotWax Systems
> >>> http://www.hotwaxsystems.com
> >>>
> >>> On Jun 15, 2016, at 3:01 PM, Taher Alkhateeb <
> slidingfilaments@gmail.com
> >>>> >
> >>>>
> >>> wrote:
> >>>
> >>>> Hi Mridul,
> >>>>
> >>>> How about reference/paymentext and reference/whatever-else-you-want?
> >>>> So the top level directory is called reference to indicate to people
> >>>> that this is just for reference and will not compile. Also, this way
> >>>> we keep all reference material under one directory to avoid polluting
> >>>> the directory tree. My 2 cents.
> >>>>
> >>>> Regards,
> >>>>
> >>>> Taher Alkhateeb
> >>>>
> >>>> On Wed, Jun 15, 2016 at 12:27 PM, Mridul Pathak <
> >>>> mridul.pathak@hotwaxsystems.com <mailto:
> mridul.pathak@hotwaxsystems.com
> >>>> >>
> >>>>
> >>> wrote:
> >>>
> >>>> Hi Taher,
> >>>>>
> >>>>> Sure, I’ll take care of deleting rest of the files as well.
> >>>>>
> >>>>> Also, we could name these specialpurpose component(s) as paymentext,
> >>>>>
> >>>> etc.
> >>>
> >>>> and mention in README file that these are extensions to OFBiz and
> >>>>> does not compile directly.
> >>>>>
> >>>>> --
> >>>>> Thanks & Regards,
> >>>>> Mridul Pathak
> >>>>> HotWax Systems
> >>>>> http://www.hotwaxsystems.com
> >>>>>
> >>>>> On Jun 15, 2016, at 2:37 PM, Taher Alkhateeb
> >>>>>> <sl...@gmail.com>
> >>>>>>
> >>>>> wrote:
> >>>>>
> >>>>>> Hi Mridul and everyone,
> >>>>>>
> >>>>>> Thank you all for your inputs. May I also ask you Mridul while you
> >>>>>> are
> >>>>>>
> >>>>> at it to delete the rest of the files so the whole task resides with
> >>>>> you to avoid crossing any wires.
> >>>>>
> >>>>>> Also, I suggest to name that component into something like archives
> >>>>>> or
> >>>>>>
> >>>>> reference and put a README file that says this component does not
> >>>>> compile and it holds this stuff. This way it is easy to isolate that
> >>>>> component from the build system.
> >>>>>
> >>>>>> Thank you all again for your contributions.
> >>>>>>
> >>>>>> Taher Alkhateeb
> >>>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Mridul Pathak [mailto:mridul.pathak@hotwaxsystems.com
> <mailto:
> >>>>>>
> >>>>> mridul.pathak@hotwaxsystems.com> <mailto:
> >>>
> >>>> mridul.pathak@hotwaxsystems.com
> >>>>> <ma...@hotwaxsystems.com>>]
> >>>>>
> >>>>>> Sent: 15 June 2016 11:09
> >>>>>> To: dev@ofbiz.apache.org <ma...@ofbiz.apache.org>
> >>>>>> <mailto:dev@ofbiz.apache.org <ma...@ofbiz.apache.org>>
> >>>>>> Cc: Mridul Pathak
> >>>>>> Subject: Re: Proposal to delete stale java files
> >>>>>>
> >>>>>> I would like to volunteer for this change (moving payment, shipping
> >>>>>> and
> >>>>>>
> >>>>> tax integrations to specialpurpose).
> >>>>>
> >>>>>> --
> >>>>>> Mridul Pathak
> >>>>>>
> >>>>>> On Wednesday 15 June 2016, Jacopo Cappellato <
> >>>>>>
> >>>>> jacopo.cappellato@hotwaxsystems.com <mailto:
> >>>>>
> >>>> jacopo.cappellato@hotwaxsystems.com>> wrote:
> >>>
> >>>> Based on the new comments it seems like that we could isolate the
> >>>>>>> shipment, payment and tax integration classes (and artifacts that
> >>>>>>> use
> >>>>>>> them) into their own specialpurpose components (waiting for a
> >>>>>>> better pluggable components architecture); they will not be
> >>>>>>> compiled by default but each component will have its own readme
> >>>>>>> file containing instructions about how to deploy and use them.
> >>>>>>> As regards the JasperReports*, JRE* and openoffice ones I think
> >>>>>>> they can go to Attic since they are old and unmaintained.
> >>>>>>>
> >>>>>>> Does it make sense? Any volunteers to create the new specialpurpose
> >>>>>>> components and upgrade/isolate the shipment/payment/tax integration
> >>>>>>> classes into them?
> >>>>>>>
> >>>>>>> Jacopo
> >>>>>>>
> >>>>>>> On Wed, Jun 15, 2016 at 9:32 AM, Hans Bakker
> >>>>>>> <h.bakker@antwebsystems.com <ma...@antwebsystems.com>
> >>>>>>> <mailto:h.bakker@antwebsystems.com
> >>>>>>> <ma...@antwebsystems.com>>
> >>>>>>>
> >>>>>> <javascript:;>>
> >>>>>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> +1
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 15/06/16 13:30, Ashish Vijaywargiya wrote:
> >>>>>>>>
> >>>>>>>> I would prefer to keep Tax and Third Party Payment gateway
> >>>>>>>>> files(The
> >>>>>>>>>
> >>>>>>>> files
> >>>>>>>
> >>>>>>>> that does exists inside cybersource, ideal, orbital, paypal,
> >>>>>>>>> securepay, verisign etc). If you see some problems in those code
> >>>>>>>>> base, like code
> >>>>>>>>>
> >>>>>>>> base
> >>>>>>>
> >>>>>>>> is not updated based on latest changes then we can update those
> >>>>>>>>>
> >>>>>>>> files.
> >>>
> >>>> Those files might have been used by so many users that we can't
> >>>>>>>>> know because we are doing this conversation on Dev mailing list.
> >>>>>>>>> We should
> >>>>>>>>>
> >>>>>>>> not
> >>>>>>>
> >>>>>>>> remove those files.
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Kind Regards
> >>>>>>>>> Ashish Vijaywargiya
> >>>>>>>>> HotWax Systems - est. 1997
> >>>>>>>>>
> >>>>>>>>> On Tue, Jun 14, 2016 at 7:40 PM, Taher Alkhateeb <
> >>>>>>>>> slidingfilaments@gmail.com <javascript:;>
> >>>>>>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> Hi Everyone,
> >>>>>>>>>
> >>>>>>>>>> I cannot actually believe it but while I was working on a
> >>>>>>>>>> project (I
> >>>>>>>>>>
> >>>>>>>>> will
> >>>>>>>
> >>>>>>>> announce later) I discovered in the process that the below files
> >>>>>>>>>> cannot compile!!! They existed for years in the code base
> >>>>>>>>>> without even being able to compile. They reference non existent
> >>>>>>>>>> libraries or they have faulty code (e.g. not importing used
> >>>>>>>>>> code)
> >>>>>>>>>>
> >>>>>>>>>> I propose to delete them immediately from trunk
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/cyberso
> >>>>>>> urc
> >>>>>>> e/IcsPaymentServices.java
> >>>>>>>
> >>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/I
> >>>>>>> dea
> >>>>>>> lEvents.java
> >>>>>>>
> >>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/I
> >>>>>>> dea
> >>>>>>> lPaymentServiceTest.java
> >>>>>>>
> >>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/orbital
> >>>>>>> /Or
> >>>>>>> bitalPaymentServices.java
> >>>>>>>
> >>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/paypal/
> >>>>>>> Pay
> >>>>>>> PalServices.java
> >>>>>>>
> >>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securep
> >>>>>>> ay/
> >>>>>>> SecurePayPaymentServices.java
> >>>>>>>
> >>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securep
> >>>>>>> ay/
> >>>>>>> SecurePayServiceTest.java
> >>>>>>>
> >>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/verisig
> >>>>>>> n/P
> >>>>>>> ayflowPro.java
> >>>>>>>
> >>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByt
> >>>>>>> eAr
> >>>>>>> rayInputStream.java
> >>>>>>>
> >>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByt
> >>>>>>> eAr
> >>>>>>> rayOutputStream.java
> >>>>>>>
> >>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeSer
> >>>>>>> vic
> >>>>>>> es.java
> >>>>>>>
> >>>>>>>>
> >>>>>>>>>>
> >>>>>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeWor
> >>>>>>> ker
> >>>>>>> .java
> >>>>>>>
> >>>>>>>> applications/content/src/org/ofbiz/content/report
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> applications/content/src/org/ofbiz/content/report/JREntityListItera
> >>>>>>> tor
> >>>>>>> DataSource.java
> >>>>>>>
> >>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> applications/content/src/org/ofbiz/content/report/JRMapCollectionDa
> >>>>>>> taS
> >>>>>>> ource.java
> >>>>>>>
> >>>>>>>> applications/order/src/org/ofbiz/order/thirdparty/taxware
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareEx
> >>>>>>> cep
> >>>>>>> tion.java
> >>>>>>>
> >>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareSe
> >>>>>>> rvi
> >>>>>>> ces.java
> >>>>>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareUT
> >>>>>>> L.j
> >>>>>>> ava
> >>>>>>>
> >>>>>>>> applications/product/src/ShipmentScaleApplet.java
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> applications/securityext/src/org/ofbiz/securityext/thirdparty/truit
> >>>>>>> ion
> >>>>>>> /TruitionCoReg.java
> >>>>>>>
> >>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsJXlsViewHan
> >>>>>>> dle
> >>>>>>> r.java
> >>>>>>>
> >>>>>>>>
> >>>>>>>>>>
> >>>>>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPdfViewHand
> >>>>>>> ler
> >>>>>>> .java
> >>>>>>>
> >>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPoiXlsViewH
> >>>>>>> and
> >>>>>>> ler.java
> >>>>>>>
> >>>>>>>>
> >>>>>>>>>>
> >>>>>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsXmlViewHand
> >>>>>>> ler
> >>>>>>> .java
> >>>>>>>
> >>>>>>>> Regards,
> >>>>>>>>>>
> >>>>>>>>>> Taher Alkhateeb
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>
> >>>>>>>> Regards,
> >>>>>>>>
> >>>>>>>> Hans Bakker
> >>>>>>>> CEO, http://antwebsystems.com
> >>>>>>>>
> >>>>>>>>
> >>>>>> --
> >>>>>> Mridul Pathak
> >>>>>> Senior Manager
> >>>>>> HotWax Systems
> >>>>>> http://www.hotwaxsystems.com
> >>>>>> direct: +91-942592692
> >>>>>>
> >>>>>
> >>>
> >>>
> >
>
Re: Proposal to delete stale java files
Posted by Divesh Dutta <di...@hotwaxsystems.com>.
Thanks Pierre and Jacques for your views. I agree with Jacques that we
should not create new repos and I agree with Pierre that code can be
logically grouped based on business functionality.
So there are two views going on:
1) Initially Taher was suggesting to remove all the codes and then when we
discussed that there are lots of users who are using those codes, he
suggested to create specialpurpose/reference component for non-compiling
code and rest in their own components.
2) Create components in special purpose for each logical business
functionality. So for eg: Payment integration specific codes can be in new
component. Shipment integration code can be in its own component. This way
we will logically group the business purpose specific codes and they can
be further used as addons in future.
So it seems that most of the code which are non-compilable are candidate of
new components (for eg: tax integration, payment integration etc. ). And
there are less java files which are non-compilable. Some code (java files)
which are compilable can also be new component for eg: shipping
integration. And all these can be separate addons in future when we have
the architecture support for it. There is no such code which is
non-compilable and not a candidate new component and that code will have to
sit inside OFBiz (either in framework of applications.)
So I think we can go with #2 where we can also add details in read me file
of these components that which files of the components are dependent on
which jars etc.
Thanks
--
Divesh Dutta.
On Thu, Jun 16, 2016 at 2:48 PM, Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:
> As Ashish and some others mentioned, those are still needed by some of our
> users.
> Of course we need to maintain them (logically more those who are
> interested) but we can't neglect our users based on code
> cleaning/refactoring.
> And if we mix all in a ball of mud it, the cost of maintaining it will be
> increased. So agree with you on this part Pierre, and we need 1st to
> separate things surgically and then decide about the parts.
>
> But, I don't like the idea of having them in "repos" (I guess you svn
> branches or GitHub repo/branches?) because they would be disconnected.
> I still can remember the effect of dropping the specialpurpose component,
> but ecommerce, in R13.07 (OK they were still in svn, see?)
> I mean once things are disconnected, and as long as we don't have a
> good/fast/reliable technical way to connect them, they tend to be forgotten
> (see what we initially discuss here), not maintained and finally garbage.
>
> On the other hand, as soon as we will have a solid way to support addons,
> those will be perfect addons.
> And no, I'm not speaking out of thin air, we (PMC) are currently
> discussing about deep modifications in the project which should help
> support, creation and adoption of addons (hint: look at Moqui, though we
> don't want to incorporate Moqui framework)
> Of course it's not for tomorrow, but we need to take time to decide on
> crucial choices.
>
> As I said already dropping the bathwater with the baby is not a solution :)
>
> Jacques
>
>
>
> Le 16/06/2016 à 10:56, Pierre Smits a écrit :
>
>> I suggest that we do not put code in a new catch all component (reference)
>> for just the mere purpose of preserving it. All code elements are related
>> to a set specific business functionality. I'd rather see that each has its
>> own component.
>>
>> Also, rather than putting these in the special purpose folder and from
>> there pushing them into releases (where adopters would need to delete them
>> from when they don't want those), I would prefer to see them in separate
>> repos so that the can be developed from there and if need can be
>> integrated
>> in a deployed OFBiz instance at will. That way we create more flexibility
>> for our adopters and enhance the appeal.
>>
>> Best regards,
>>
>> Pierre Smits
>>
>> ORRTIZ.COM <http://www.orrtiz.com>
>> OFBiz based solutions & services
>>
>> OFBiz Extensions Marketplace
>> http://oem.ofbizci.net/oci-2/
>>
>> On Wed, Jun 15, 2016 at 1:23 PM, Taher Alkhateeb <
>> slidingfilaments@gmail.com
>>
>>> wrote:
>>> Hi Mridul,
>>>
>>> Ahh I see that makes sense. Yeah sure we put non-compiling stuff
>>> regardless of origin in specialpurpose/reference and the rest in their
>>> own
>>> components.
>>>
>>> Regards,
>>>
>>> -----Original Message-----
>>> From: Mridul Pathak [mailto:mridul.pathak@hotwaxsystems.com]
>>> Sent: 15 June 2016 14:19
>>> To: dev@ofbiz.apache.org
>>> Cc: Mridul Pathak
>>> Subject: Re: Proposal to delete stale java files
>>>
>>> Hi Taher,
>>>
>>> I would like to make sure that I am understanding your proposal
>>> correctly.
>>>
>>> Are you proposing to create a specialpurpose component named “reference”
>>> which would have all the code that can be referenced but not compiled, no
>>> matter what domain it is?
>>>
>>> If that is the case, we have discussed about moving shipping integrations
>>> to specialpurpose component as well, and that code doesn’t have the
>>> compilation or library reference issues as listed in this thread, so I
>>> think that should go in it's own component.
>>>
>>> --
>>> Thanks & Regards,
>>> Mridul Pathak
>>> Senior Manager
>>> HotWax Systems
>>> http://www.hotwaxsystems.com
>>>
>>> On Jun 15, 2016, at 3:01 PM, Taher Alkhateeb <slidingfilaments@gmail.com
>>>> >
>>>>
>>> wrote:
>>>
>>>> Hi Mridul,
>>>>
>>>> How about reference/paymentext and reference/whatever-else-you-want?
>>>> So the top level directory is called reference to indicate to people
>>>> that this is just for reference and will not compile. Also, this way
>>>> we keep all reference material under one directory to avoid polluting
>>>> the directory tree. My 2 cents.
>>>>
>>>> Regards,
>>>>
>>>> Taher Alkhateeb
>>>>
>>>> On Wed, Jun 15, 2016 at 12:27 PM, Mridul Pathak <
>>>> mridul.pathak@hotwaxsystems.com <mailto:mridul.pathak@hotwaxsystems.com
>>>> >>
>>>>
>>> wrote:
>>>
>>>> Hi Taher,
>>>>>
>>>>> Sure, I’ll take care of deleting rest of the files as well.
>>>>>
>>>>> Also, we could name these specialpurpose component(s) as paymentext,
>>>>>
>>>> etc.
>>>
>>>> and mention in README file that these are extensions to OFBiz and
>>>>> does not compile directly.
>>>>>
>>>>> --
>>>>> Thanks & Regards,
>>>>> Mridul Pathak
>>>>> HotWax Systems
>>>>> http://www.hotwaxsystems.com
>>>>>
>>>>> On Jun 15, 2016, at 2:37 PM, Taher Alkhateeb
>>>>>> <sl...@gmail.com>
>>>>>>
>>>>> wrote:
>>>>>
>>>>>> Hi Mridul and everyone,
>>>>>>
>>>>>> Thank you all for your inputs. May I also ask you Mridul while you
>>>>>> are
>>>>>>
>>>>> at it to delete the rest of the files so the whole task resides with
>>>>> you to avoid crossing any wires.
>>>>>
>>>>>> Also, I suggest to name that component into something like archives
>>>>>> or
>>>>>>
>>>>> reference and put a README file that says this component does not
>>>>> compile and it holds this stuff. This way it is easy to isolate that
>>>>> component from the build system.
>>>>>
>>>>>> Thank you all again for your contributions.
>>>>>>
>>>>>> Taher Alkhateeb
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Mridul Pathak [mailto:mridul.pathak@hotwaxsystems.com <mailto:
>>>>>>
>>>>> mridul.pathak@hotwaxsystems.com> <mailto:
>>>
>>>> mridul.pathak@hotwaxsystems.com
>>>>> <ma...@hotwaxsystems.com>>]
>>>>>
>>>>>> Sent: 15 June 2016 11:09
>>>>>> To: dev@ofbiz.apache.org <ma...@ofbiz.apache.org>
>>>>>> <mailto:dev@ofbiz.apache.org <ma...@ofbiz.apache.org>>
>>>>>> Cc: Mridul Pathak
>>>>>> Subject: Re: Proposal to delete stale java files
>>>>>>
>>>>>> I would like to volunteer for this change (moving payment, shipping
>>>>>> and
>>>>>>
>>>>> tax integrations to specialpurpose).
>>>>>
>>>>>> --
>>>>>> Mridul Pathak
>>>>>>
>>>>>> On Wednesday 15 June 2016, Jacopo Cappellato <
>>>>>>
>>>>> jacopo.cappellato@hotwaxsystems.com <mailto:
>>>>>
>>>> jacopo.cappellato@hotwaxsystems.com>> wrote:
>>>
>>>> Based on the new comments it seems like that we could isolate the
>>>>>>> shipment, payment and tax integration classes (and artifacts that
>>>>>>> use
>>>>>>> them) into their own specialpurpose components (waiting for a
>>>>>>> better pluggable components architecture); they will not be
>>>>>>> compiled by default but each component will have its own readme
>>>>>>> file containing instructions about how to deploy and use them.
>>>>>>> As regards the JasperReports*, JRE* and openoffice ones I think
>>>>>>> they can go to Attic since they are old and unmaintained.
>>>>>>>
>>>>>>> Does it make sense? Any volunteers to create the new specialpurpose
>>>>>>> components and upgrade/isolate the shipment/payment/tax integration
>>>>>>> classes into them?
>>>>>>>
>>>>>>> Jacopo
>>>>>>>
>>>>>>> On Wed, Jun 15, 2016 at 9:32 AM, Hans Bakker
>>>>>>> <h.bakker@antwebsystems.com <ma...@antwebsystems.com>
>>>>>>> <mailto:h.bakker@antwebsystems.com
>>>>>>> <ma...@antwebsystems.com>>
>>>>>>>
>>>>>> <javascript:;>>
>>>>>
>>>>>> wrote:
>>>>>>>
>>>>>>> +1
>>>>>>>>
>>>>>>>>
>>>>>>>> On 15/06/16 13:30, Ashish Vijaywargiya wrote:
>>>>>>>>
>>>>>>>> I would prefer to keep Tax and Third Party Payment gateway
>>>>>>>>> files(The
>>>>>>>>>
>>>>>>>> files
>>>>>>>
>>>>>>>> that does exists inside cybersource, ideal, orbital, paypal,
>>>>>>>>> securepay, verisign etc). If you see some problems in those code
>>>>>>>>> base, like code
>>>>>>>>>
>>>>>>>> base
>>>>>>>
>>>>>>>> is not updated based on latest changes then we can update those
>>>>>>>>>
>>>>>>>> files.
>>>
>>>> Those files might have been used by so many users that we can't
>>>>>>>>> know because we are doing this conversation on Dev mailing list.
>>>>>>>>> We should
>>>>>>>>>
>>>>>>>> not
>>>>>>>
>>>>>>>> remove those files.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Kind Regards
>>>>>>>>> Ashish Vijaywargiya
>>>>>>>>> HotWax Systems - est. 1997
>>>>>>>>>
>>>>>>>>> On Tue, Jun 14, 2016 at 7:40 PM, Taher Alkhateeb <
>>>>>>>>> slidingfilaments@gmail.com <javascript:;>
>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Everyone,
>>>>>>>>>
>>>>>>>>>> I cannot actually believe it but while I was working on a
>>>>>>>>>> project (I
>>>>>>>>>>
>>>>>>>>> will
>>>>>>>
>>>>>>>> announce later) I discovered in the process that the below files
>>>>>>>>>> cannot compile!!! They existed for years in the code base
>>>>>>>>>> without even being able to compile. They reference non existent
>>>>>>>>>> libraries or they have faulty code (e.g. not importing used
>>>>>>>>>> code)
>>>>>>>>>>
>>>>>>>>>> I propose to delete them immediately from trunk
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/cyberso
>>>>>>> urc
>>>>>>> e/IcsPaymentServices.java
>>>>>>>
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/I
>>>>>>> dea
>>>>>>> lEvents.java
>>>>>>>
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/I
>>>>>>> dea
>>>>>>> lPaymentServiceTest.java
>>>>>>>
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/orbital
>>>>>>> /Or
>>>>>>> bitalPaymentServices.java
>>>>>>>
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/paypal/
>>>>>>> Pay
>>>>>>> PalServices.java
>>>>>>>
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securep
>>>>>>> ay/
>>>>>>> SecurePayPaymentServices.java
>>>>>>>
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securep
>>>>>>> ay/
>>>>>>> SecurePayServiceTest.java
>>>>>>>
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/verisig
>>>>>>> n/P
>>>>>>> ayflowPro.java
>>>>>>>
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByt
>>>>>>> eAr
>>>>>>> rayInputStream.java
>>>>>>>
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByt
>>>>>>> eAr
>>>>>>> rayOutputStream.java
>>>>>>>
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeSer
>>>>>>> vic
>>>>>>> es.java
>>>>>>>
>>>>>>>>
>>>>>>>>>>
>>>>>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeWor
>>>>>>> ker
>>>>>>> .java
>>>>>>>
>>>>>>>> applications/content/src/org/ofbiz/content/report
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> applications/content/src/org/ofbiz/content/report/JREntityListItera
>>>>>>> tor
>>>>>>> DataSource.java
>>>>>>>
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> applications/content/src/org/ofbiz/content/report/JRMapCollectionDa
>>>>>>> taS
>>>>>>> ource.java
>>>>>>>
>>>>>>>> applications/order/src/org/ofbiz/order/thirdparty/taxware
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareEx
>>>>>>> cep
>>>>>>> tion.java
>>>>>>>
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareSe
>>>>>>> rvi
>>>>>>> ces.java
>>>>>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareUT
>>>>>>> L.j
>>>>>>> ava
>>>>>>>
>>>>>>>> applications/product/src/ShipmentScaleApplet.java
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> applications/securityext/src/org/ofbiz/securityext/thirdparty/truit
>>>>>>> ion
>>>>>>> /TruitionCoReg.java
>>>>>>>
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsJXlsViewHan
>>>>>>> dle
>>>>>>> r.java
>>>>>>>
>>>>>>>>
>>>>>>>>>>
>>>>>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPdfViewHand
>>>>>>> ler
>>>>>>> .java
>>>>>>>
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPoiXlsViewH
>>>>>>> and
>>>>>>> ler.java
>>>>>>>
>>>>>>>>
>>>>>>>>>>
>>>>>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsXmlViewHand
>>>>>>> ler
>>>>>>> .java
>>>>>>>
>>>>>>>> Regards,
>>>>>>>>>>
>>>>>>>>>> Taher Alkhateeb
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Hans Bakker
>>>>>>>> CEO, http://antwebsystems.com
>>>>>>>>
>>>>>>>>
>>>>>> --
>>>>>> Mridul Pathak
>>>>>> Senior Manager
>>>>>> HotWax Systems
>>>>>> http://www.hotwaxsystems.com
>>>>>> direct: +91-942592692
>>>>>>
>>>>>
>>>
>>>
>
Re: Proposal to delete stale java files
Posted by Jacques Le Roux <ja...@les7arts.com>.
As Ashish and some others mentioned, those are still needed by some of our users.
Of course we need to maintain them (logically more those who are interested) but we can't neglect our users based on code cleaning/refactoring.
And if we mix all in a ball of mud it, the cost of maintaining it will be increased. So agree with you on this part Pierre, and we need 1st to
separate things surgically and then decide about the parts.
But, I don't like the idea of having them in "repos" (I guess you svn branches or GitHub repo/branches?) because they would be disconnected.
I still can remember the effect of dropping the specialpurpose component, but ecommerce, in R13.07 (OK they were still in svn, see?)
I mean once things are disconnected, and as long as we don't have a good/fast/reliable technical way to connect them, they tend to be forgotten (see
what we initially discuss here), not maintained and finally garbage.
On the other hand, as soon as we will have a solid way to support addons, those will be perfect addons.
And no, I'm not speaking out of thin air, we (PMC) are currently discussing about deep modifications in the project which should help support,
creation and adoption of addons (hint: look at Moqui, though we don't want to incorporate Moqui framework)
Of course it's not for tomorrow, but we need to take time to decide on crucial choices.
As I said already dropping the bathwater with the baby is not a solution :)
Jacques
Le 16/06/2016 � 10:56, Pierre Smits a �crit :
> I suggest that we do not put code in a new catch all component (reference)
> for just the mere purpose of preserving it. All code elements are related
> to a set specific business functionality. I'd rather see that each has its
> own component.
>
> Also, rather than putting these in the special purpose folder and from
> there pushing them into releases (where adopters would need to delete them
> from when they don't want those), I would prefer to see them in separate
> repos so that the can be developed from there and if need can be integrated
> in a deployed OFBiz instance at will. That way we create more flexibility
> for our adopters and enhance the appeal.
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM <http://www.orrtiz.com>
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Wed, Jun 15, 2016 at 1:23 PM, Taher Alkhateeb <slidingfilaments@gmail.com
>> wrote:
>> Hi Mridul,
>>
>> Ahh I see that makes sense. Yeah sure we put non-compiling stuff
>> regardless of origin in specialpurpose/reference and the rest in their own
>> components.
>>
>> Regards,
>>
>> -----Original Message-----
>> From: Mridul Pathak [mailto:mridul.pathak@hotwaxsystems.com]
>> Sent: 15 June 2016 14:19
>> To: dev@ofbiz.apache.org
>> Cc: Mridul Pathak
>> Subject: Re: Proposal to delete stale java files
>>
>> Hi Taher,
>>
>> I would like to make sure that I am understanding your proposal correctly.
>>
>> Are you proposing to create a specialpurpose component named \u201creference\u201d
>> which would have all the code that can be referenced but not compiled, no
>> matter what domain it is?
>>
>> If that is the case, we have discussed about moving shipping integrations
>> to specialpurpose component as well, and that code doesn\u2019t have the
>> compilation or library reference issues as listed in this thread, so I
>> think that should go in it's own component.
>>
>> --
>> Thanks & Regards,
>> Mridul Pathak
>> Senior Manager
>> HotWax Systems
>> http://www.hotwaxsystems.com
>>
>>> On Jun 15, 2016, at 3:01 PM, Taher Alkhateeb <sl...@gmail.com>
>> wrote:
>>> Hi Mridul,
>>>
>>> How about reference/paymentext and reference/whatever-else-you-want?
>>> So the top level directory is called reference to indicate to people
>>> that this is just for reference and will not compile. Also, this way
>>> we keep all reference material under one directory to avoid polluting
>>> the directory tree. My 2 cents.
>>>
>>> Regards,
>>>
>>> Taher Alkhateeb
>>>
>>> On Wed, Jun 15, 2016 at 12:27 PM, Mridul Pathak <
>>> mridul.pathak@hotwaxsystems.com <ma...@hotwaxsystems.com>>
>> wrote:
>>>> Hi Taher,
>>>>
>>>> Sure, I\u2019ll take care of deleting rest of the files as well.
>>>>
>>>> Also, we could name these specialpurpose component(s) as paymentext,
>> etc.
>>>> and mention in README file that these are extensions to OFBiz and
>>>> does not compile directly.
>>>>
>>>> --
>>>> Thanks & Regards,
>>>> Mridul Pathak
>>>> HotWax Systems
>>>> http://www.hotwaxsystems.com
>>>>
>>>>> On Jun 15, 2016, at 2:37 PM, Taher Alkhateeb
>>>>> <sl...@gmail.com>
>>>> wrote:
>>>>> Hi Mridul and everyone,
>>>>>
>>>>> Thank you all for your inputs. May I also ask you Mridul while you
>>>>> are
>>>> at it to delete the rest of the files so the whole task resides with
>>>> you to avoid crossing any wires.
>>>>> Also, I suggest to name that component into something like archives
>>>>> or
>>>> reference and put a README file that says this component does not
>>>> compile and it holds this stuff. This way it is easy to isolate that
>>>> component from the build system.
>>>>> Thank you all again for your contributions.
>>>>>
>>>>> Taher Alkhateeb
>>>>>
>>>>> -----Original Message-----
>>>>> From: Mridul Pathak [mailto:mridul.pathak@hotwaxsystems.com <mailto:
>> mridul.pathak@hotwaxsystems.com> <mailto:
>>>> mridul.pathak@hotwaxsystems.com
>>>> <ma...@hotwaxsystems.com>>]
>>>>> Sent: 15 June 2016 11:09
>>>>> To: dev@ofbiz.apache.org <ma...@ofbiz.apache.org>
>>>>> <mailto:dev@ofbiz.apache.org <ma...@ofbiz.apache.org>>
>>>>> Cc: Mridul Pathak
>>>>> Subject: Re: Proposal to delete stale java files
>>>>>
>>>>> I would like to volunteer for this change (moving payment, shipping
>>>>> and
>>>> tax integrations to specialpurpose).
>>>>> --
>>>>> Mridul Pathak
>>>>>
>>>>> On Wednesday 15 June 2016, Jacopo Cappellato <
>>>> jacopo.cappellato@hotwaxsystems.com <mailto:
>> jacopo.cappellato@hotwaxsystems.com>> wrote:
>>>>>> Based on the new comments it seems like that we could isolate the
>>>>>> shipment, payment and tax integration classes (and artifacts that
>>>>>> use
>>>>>> them) into their own specialpurpose components (waiting for a
>>>>>> better pluggable components architecture); they will not be
>>>>>> compiled by default but each component will have its own readme
>>>>>> file containing instructions about how to deploy and use them.
>>>>>> As regards the JasperReports*, JRE* and openoffice ones I think
>>>>>> they can go to Attic since they are old and unmaintained.
>>>>>>
>>>>>> Does it make sense? Any volunteers to create the new specialpurpose
>>>>>> components and upgrade/isolate the shipment/payment/tax integration
>>>>>> classes into them?
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>> On Wed, Jun 15, 2016 at 9:32 AM, Hans Bakker
>>>>>> <h.bakker@antwebsystems.com <ma...@antwebsystems.com>
>>>>>> <mailto:h.bakker@antwebsystems.com
>>>>>> <ma...@antwebsystems.com>>
>>>> <javascript:;>>
>>>>>> wrote:
>>>>>>
>>>>>>> +1
>>>>>>>
>>>>>>>
>>>>>>> On 15/06/16 13:30, Ashish Vijaywargiya wrote:
>>>>>>>
>>>>>>>> I would prefer to keep Tax and Third Party Payment gateway
>>>>>>>> files(The
>>>>>> files
>>>>>>>> that does exists inside cybersource, ideal, orbital, paypal,
>>>>>>>> securepay, verisign etc). If you see some problems in those code
>>>>>>>> base, like code
>>>>>> base
>>>>>>>> is not updated based on latest changes then we can update those
>> files.
>>>>>>>> Those files might have been used by so many users that we can't
>>>>>>>> know because we are doing this conversation on Dev mailing list.
>>>>>>>> We should
>>>>>> not
>>>>>>>> remove those files.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Kind Regards
>>>>>>>> Ashish Vijaywargiya
>>>>>>>> HotWax Systems - est. 1997
>>>>>>>>
>>>>>>>> On Tue, Jun 14, 2016 at 7:40 PM, Taher Alkhateeb <
>>>>>>>> slidingfilaments@gmail.com <javascript:;>
>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>> Hi Everyone,
>>>>>>>>> I cannot actually believe it but while I was working on a
>>>>>>>>> project (I
>>>>>> will
>>>>>>>>> announce later) I discovered in the process that the below files
>>>>>>>>> cannot compile!!! They existed for years in the code base
>>>>>>>>> without even being able to compile. They reference non existent
>>>>>>>>> libraries or they have faulty code (e.g. not importing used
>>>>>>>>> code)
>>>>>>>>>
>>>>>>>>> I propose to delete them immediately from trunk
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/cyberso
>>>>>> urc
>>>>>> e/IcsPaymentServices.java
>>>>>>>>>
>>>>>>>>>
>>>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/I
>>>>>> dea
>>>>>> lEvents.java
>>>>>>>>>
>>>>>>>>>
>>>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/I
>>>>>> dea
>>>>>> lPaymentServiceTest.java
>>>>>>>>>
>>>>>>>>>
>>>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/orbital
>>>>>> /Or
>>>>>> bitalPaymentServices.java
>>>>>>>>>
>>>>>>>>>
>>>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/paypal/
>>>>>> Pay
>>>>>> PalServices.java
>>>>>>>>>
>>>>>>>>>
>>>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securep
>>>>>> ay/
>>>>>> SecurePayPaymentServices.java
>>>>>>>>>
>>>>>>>>>
>>>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securep
>>>>>> ay/
>>>>>> SecurePayServiceTest.java
>>>>>>>>>
>>>>>>>>>
>>>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/verisig
>>>>>> n/P
>>>>>> ayflowPro.java
>>>>>>>>>
>>>>>>>>>
>>>>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByt
>>>>>> eAr
>>>>>> rayInputStream.java
>>>>>>>>>
>>>>>>>>>
>>>>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByt
>>>>>> eAr
>>>>>> rayOutputStream.java
>>>>>>>>>
>>>>>>>>>
>>>>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeSer
>>>>>> vic
>>>>>> es.java
>>>>>>>>>
>>>>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeWor
>>>>>> ker
>>>>>> .java
>>>>>>>>> applications/content/src/org/ofbiz/content/report
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>> applications/content/src/org/ofbiz/content/report/JREntityListItera
>>>>>> tor
>>>>>> DataSource.java
>>>>>>>>>
>>>>>>>>>
>>>>>> applications/content/src/org/ofbiz/content/report/JRMapCollectionDa
>>>>>> taS
>>>>>> ource.java
>>>>>>>>> applications/order/src/org/ofbiz/order/thirdparty/taxware
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareEx
>>>>>> cep
>>>>>> tion.java
>>>>>>>>>
>>>>>>>>>
>>>>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareSe
>>>>>> rvi
>>>>>> ces.java
>>>>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareUT
>>>>>> L.j
>>>>>> ava
>>>>>>>>> applications/product/src/ShipmentScaleApplet.java
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>> applications/securityext/src/org/ofbiz/securityext/thirdparty/truit
>>>>>> ion
>>>>>> /TruitionCoReg.java
>>>>>>>>>
>>>>>>>>>
>>>>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsJXlsViewHan
>>>>>> dle
>>>>>> r.java
>>>>>>>>>
>>>>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPdfViewHand
>>>>>> ler
>>>>>> .java
>>>>>>>>>
>>>>>>>>>
>>>>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPoiXlsViewH
>>>>>> and
>>>>>> ler.java
>>>>>>>>>
>>>>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsXmlViewHand
>>>>>> ler
>>>>>> .java
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Taher Alkhateeb
>>>>>>>>>
>>>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Hans Bakker
>>>>>>> CEO, http://antwebsystems.com
>>>>>>>
>>>>>
>>>>> --
>>>>> Mridul Pathak
>>>>> Senior Manager
>>>>> HotWax Systems
>>>>> http://www.hotwaxsystems.com
>>>>> direct: +91-942592692
>>
>>
Re: Proposal to delete stale java files
Posted by Pierre Smits <pi...@gmail.com>.
I suggest that we do not put code in a new catch all component (reference)
for just the mere purpose of preserving it. All code elements are related
to a set specific business functionality. I'd rather see that each has its
own component.
Also, rather than putting these in the special purpose folder and from
there pushing them into releases (where adopters would need to delete them
from when they don't want those), I would prefer to see them in separate
repos so that the can be developed from there and if need can be integrated
in a deployed OFBiz instance at will. That way we create more flexibility
for our adopters and enhance the appeal.
Best regards,
Pierre Smits
ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services
OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/
On Wed, Jun 15, 2016 at 1:23 PM, Taher Alkhateeb <slidingfilaments@gmail.com
> wrote:
> Hi Mridul,
>
> Ahh I see that makes sense. Yeah sure we put non-compiling stuff
> regardless of origin in specialpurpose/reference and the rest in their own
> components.
>
> Regards,
>
> -----Original Message-----
> From: Mridul Pathak [mailto:mridul.pathak@hotwaxsystems.com]
> Sent: 15 June 2016 14:19
> To: dev@ofbiz.apache.org
> Cc: Mridul Pathak
> Subject: Re: Proposal to delete stale java files
>
> Hi Taher,
>
> I would like to make sure that I am understanding your proposal correctly.
>
> Are you proposing to create a specialpurpose component named “reference”
> which would have all the code that can be referenced but not compiled, no
> matter what domain it is?
>
> If that is the case, we have discussed about moving shipping integrations
> to specialpurpose component as well, and that code doesn’t have the
> compilation or library reference issues as listed in this thread, so I
> think that should go in it's own component.
>
> --
> Thanks & Regards,
> Mridul Pathak
> Senior Manager
> HotWax Systems
> http://www.hotwaxsystems.com
>
> > On Jun 15, 2016, at 3:01 PM, Taher Alkhateeb <sl...@gmail.com>
> wrote:
> >
> > Hi Mridul,
> >
> > How about reference/paymentext and reference/whatever-else-you-want?
> > So the top level directory is called reference to indicate to people
> > that this is just for reference and will not compile. Also, this way
> > we keep all reference material under one directory to avoid polluting
> > the directory tree. My 2 cents.
> >
> > Regards,
> >
> > Taher Alkhateeb
> >
> > On Wed, Jun 15, 2016 at 12:27 PM, Mridul Pathak <
> > mridul.pathak@hotwaxsystems.com <ma...@hotwaxsystems.com>>
> wrote:
> >
> >> Hi Taher,
> >>
> >> Sure, I’ll take care of deleting rest of the files as well.
> >>
> >> Also, we could name these specialpurpose component(s) as paymentext,
> etc.
> >> and mention in README file that these are extensions to OFBiz and
> >> does not compile directly.
> >>
> >> --
> >> Thanks & Regards,
> >> Mridul Pathak
> >> HotWax Systems
> >> http://www.hotwaxsystems.com
> >>
> >>> On Jun 15, 2016, at 2:37 PM, Taher Alkhateeb
> >>> <sl...@gmail.com>
> >> wrote:
> >>>
> >>> Hi Mridul and everyone,
> >>>
> >>> Thank you all for your inputs. May I also ask you Mridul while you
> >>> are
> >> at it to delete the rest of the files so the whole task resides with
> >> you to avoid crossing any wires.
> >>>
> >>> Also, I suggest to name that component into something like archives
> >>> or
> >> reference and put a README file that says this component does not
> >> compile and it holds this stuff. This way it is easy to isolate that
> >> component from the build system.
> >>>
> >>> Thank you all again for your contributions.
> >>>
> >>> Taher Alkhateeb
> >>>
> >>> -----Original Message-----
> >>> From: Mridul Pathak [mailto:mridul.pathak@hotwaxsystems.com <mailto:
> mridul.pathak@hotwaxsystems.com> <mailto:
> >> mridul.pathak@hotwaxsystems.com
> >> <ma...@hotwaxsystems.com>>]
> >>> Sent: 15 June 2016 11:09
> >>> To: dev@ofbiz.apache.org <ma...@ofbiz.apache.org>
> >>> <mailto:dev@ofbiz.apache.org <ma...@ofbiz.apache.org>>
> >>> Cc: Mridul Pathak
> >>> Subject: Re: Proposal to delete stale java files
> >>>
> >>> I would like to volunteer for this change (moving payment, shipping
> >>> and
> >> tax integrations to specialpurpose).
> >>>
> >>> --
> >>> Mridul Pathak
> >>>
> >>> On Wednesday 15 June 2016, Jacopo Cappellato <
> >> jacopo.cappellato@hotwaxsystems.com <mailto:
> jacopo.cappellato@hotwaxsystems.com>> wrote:
> >>>
> >>>> Based on the new comments it seems like that we could isolate the
> >>>> shipment, payment and tax integration classes (and artifacts that
> >>>> use
> >>>> them) into their own specialpurpose components (waiting for a
> >>>> better pluggable components architecture); they will not be
> >>>> compiled by default but each component will have its own readme
> >>>> file containing instructions about how to deploy and use them.
> >>>> As regards the JasperReports*, JRE* and openoffice ones I think
> >>>> they can go to Attic since they are old and unmaintained.
> >>>>
> >>>> Does it make sense? Any volunteers to create the new specialpurpose
> >>>> components and upgrade/isolate the shipment/payment/tax integration
> >>>> classes into them?
> >>>>
> >>>> Jacopo
> >>>>
> >>>> On Wed, Jun 15, 2016 at 9:32 AM, Hans Bakker
> >>>> <h.bakker@antwebsystems.com <ma...@antwebsystems.com>
> >>>> <mailto:h.bakker@antwebsystems.com
> >>>> <ma...@antwebsystems.com>>
> >> <javascript:;>>
> >>>> wrote:
> >>>>
> >>>>> +1
> >>>>>
> >>>>>
> >>>>> On 15/06/16 13:30, Ashish Vijaywargiya wrote:
> >>>>>
> >>>>>> I would prefer to keep Tax and Third Party Payment gateway
> >>>>>> files(The
> >>>> files
> >>>>>> that does exists inside cybersource, ideal, orbital, paypal,
> >>>>>> securepay, verisign etc). If you see some problems in those code
> >>>>>> base, like code
> >>>> base
> >>>>>> is not updated based on latest changes then we can update those
> files.
> >>>>>> Those files might have been used by so many users that we can't
> >>>>>> know because we are doing this conversation on Dev mailing list.
> >>>>>> We should
> >>>> not
> >>>>>> remove those files.
> >>>>>>
> >>>>>> --
> >>>>>> Kind Regards
> >>>>>> Ashish Vijaywargiya
> >>>>>> HotWax Systems - est. 1997
> >>>>>>
> >>>>>> On Tue, Jun 14, 2016 at 7:40 PM, Taher Alkhateeb <
> >>>>>> slidingfilaments@gmail.com <javascript:;>
> >>>>>>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>
> >>>>>> Hi Everyone,
> >>>>>>>
> >>>>>>> I cannot actually believe it but while I was working on a
> >>>>>>> project (I
> >>>> will
> >>>>>>> announce later) I discovered in the process that the below files
> >>>>>>> cannot compile!!! They existed for years in the code base
> >>>>>>> without even being able to compile. They reference non existent
> >>>>>>> libraries or they have faulty code (e.g. not importing used
> >>>>>>> code)
> >>>>>>>
> >>>>>>> I propose to delete them immediately from trunk
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/cyberso
> >>>> urc
> >>>> e/IcsPaymentServices.java
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/I
> >>>> dea
> >>>> lEvents.java
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/I
> >>>> dea
> >>>> lPaymentServiceTest.java
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/orbital
> >>>> /Or
> >>>> bitalPaymentServices.java
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/paypal/
> >>>> Pay
> >>>> PalServices.java
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securep
> >>>> ay/
> >>>> SecurePayPaymentServices.java
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securep
> >>>> ay/
> >>>> SecurePayServiceTest.java
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/verisig
> >>>> n/P
> >>>> ayflowPro.java
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByt
> >>>> eAr
> >>>> rayInputStream.java
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByt
> >>>> eAr
> >>>> rayOutputStream.java
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeSer
> >>>> vic
> >>>> es.java
> >>>>>>>
> >>>>>>>
> >>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeWor
> >>>> ker
> >>>> .java
> >>>>>>> applications/content/src/org/ofbiz/content/report
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>> applications/content/src/org/ofbiz/content/report/JREntityListItera
> >>>> tor
> >>>> DataSource.java
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>> applications/content/src/org/ofbiz/content/report/JRMapCollectionDa
> >>>> taS
> >>>> ource.java
> >>>>>>> applications/order/src/org/ofbiz/order/thirdparty/taxware
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareEx
> >>>> cep
> >>>> tion.java
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareSe
> >>>> rvi
> >>>> ces.java
> >>>>>>>
> >>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareUT
> >>>> L.j
> >>>> ava
> >>>>>>> applications/product/src/ShipmentScaleApplet.java
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>> applications/securityext/src/org/ofbiz/securityext/thirdparty/truit
> >>>> ion
> >>>> /TruitionCoReg.java
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsJXlsViewHan
> >>>> dle
> >>>> r.java
> >>>>>>>
> >>>>>>>
> >>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPdfViewHand
> >>>> ler
> >>>> .java
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPoiXlsViewH
> >>>> and
> >>>> ler.java
> >>>>>>>
> >>>>>>>
> >>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsXmlViewHand
> >>>> ler
> >>>> .java
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>>
> >>>>>>> Taher Alkhateeb
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>> --
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>> Hans Bakker
> >>>>> CEO, http://antwebsystems.com
> >>>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Mridul Pathak
> >>> Senior Manager
> >>> HotWax Systems
> >>> http://www.hotwaxsystems.com
> >>> direct: +91-942592692
>
>
>
RE: Proposal to delete stale java files
Posted by Taher Alkhateeb <sl...@gmail.com>.
Hi Mridul,
Ahh I see that makes sense. Yeah sure we put non-compiling stuff regardless of origin in specialpurpose/reference and the rest in their own components.
Regards,
-----Original Message-----
From: Mridul Pathak [mailto:mridul.pathak@hotwaxsystems.com]
Sent: 15 June 2016 14:19
To: dev@ofbiz.apache.org
Cc: Mridul Pathak
Subject: Re: Proposal to delete stale java files
Hi Taher,
I would like to make sure that I am understanding your proposal correctly.
Are you proposing to create a specialpurpose component named “reference” which would have all the code that can be referenced but not compiled, no matter what domain it is?
If that is the case, we have discussed about moving shipping integrations to specialpurpose component as well, and that code doesn’t have the compilation or library reference issues as listed in this thread, so I think that should go in it's own component.
--
Thanks & Regards,
Mridul Pathak
Senior Manager
HotWax Systems
http://www.hotwaxsystems.com
> On Jun 15, 2016, at 3:01 PM, Taher Alkhateeb <sl...@gmail.com> wrote:
>
> Hi Mridul,
>
> How about reference/paymentext and reference/whatever-else-you-want?
> So the top level directory is called reference to indicate to people
> that this is just for reference and will not compile. Also, this way
> we keep all reference material under one directory to avoid polluting
> the directory tree. My 2 cents.
>
> Regards,
>
> Taher Alkhateeb
>
> On Wed, Jun 15, 2016 at 12:27 PM, Mridul Pathak <
> mridul.pathak@hotwaxsystems.com <ma...@hotwaxsystems.com>> wrote:
>
>> Hi Taher,
>>
>> Sure, I’ll take care of deleting rest of the files as well.
>>
>> Also, we could name these specialpurpose component(s) as paymentext, etc.
>> and mention in README file that these are extensions to OFBiz and
>> does not compile directly.
>>
>> --
>> Thanks & Regards,
>> Mridul Pathak
>> HotWax Systems
>> http://www.hotwaxsystems.com
>>
>>> On Jun 15, 2016, at 2:37 PM, Taher Alkhateeb
>>> <sl...@gmail.com>
>> wrote:
>>>
>>> Hi Mridul and everyone,
>>>
>>> Thank you all for your inputs. May I also ask you Mridul while you
>>> are
>> at it to delete the rest of the files so the whole task resides with
>> you to avoid crossing any wires.
>>>
>>> Also, I suggest to name that component into something like archives
>>> or
>> reference and put a README file that says this component does not
>> compile and it holds this stuff. This way it is easy to isolate that
>> component from the build system.
>>>
>>> Thank you all again for your contributions.
>>>
>>> Taher Alkhateeb
>>>
>>> -----Original Message-----
>>> From: Mridul Pathak [mailto:mridul.pathak@hotwaxsystems.com <ma...@hotwaxsystems.com> <mailto:
>> mridul.pathak@hotwaxsystems.com
>> <ma...@hotwaxsystems.com>>]
>>> Sent: 15 June 2016 11:09
>>> To: dev@ofbiz.apache.org <ma...@ofbiz.apache.org>
>>> <mailto:dev@ofbiz.apache.org <ma...@ofbiz.apache.org>>
>>> Cc: Mridul Pathak
>>> Subject: Re: Proposal to delete stale java files
>>>
>>> I would like to volunteer for this change (moving payment, shipping
>>> and
>> tax integrations to specialpurpose).
>>>
>>> --
>>> Mridul Pathak
>>>
>>> On Wednesday 15 June 2016, Jacopo Cappellato <
>> jacopo.cappellato@hotwaxsystems.com <ma...@hotwaxsystems.com>> wrote:
>>>
>>>> Based on the new comments it seems like that we could isolate the
>>>> shipment, payment and tax integration classes (and artifacts that
>>>> use
>>>> them) into their own specialpurpose components (waiting for a
>>>> better pluggable components architecture); they will not be
>>>> compiled by default but each component will have its own readme
>>>> file containing instructions about how to deploy and use them.
>>>> As regards the JasperReports*, JRE* and openoffice ones I think
>>>> they can go to Attic since they are old and unmaintained.
>>>>
>>>> Does it make sense? Any volunteers to create the new specialpurpose
>>>> components and upgrade/isolate the shipment/payment/tax integration
>>>> classes into them?
>>>>
>>>> Jacopo
>>>>
>>>> On Wed, Jun 15, 2016 at 9:32 AM, Hans Bakker
>>>> <h.bakker@antwebsystems.com <ma...@antwebsystems.com>
>>>> <mailto:h.bakker@antwebsystems.com
>>>> <ma...@antwebsystems.com>>
>> <javascript:;>>
>>>> wrote:
>>>>
>>>>> +1
>>>>>
>>>>>
>>>>> On 15/06/16 13:30, Ashish Vijaywargiya wrote:
>>>>>
>>>>>> I would prefer to keep Tax and Third Party Payment gateway
>>>>>> files(The
>>>> files
>>>>>> that does exists inside cybersource, ideal, orbital, paypal,
>>>>>> securepay, verisign etc). If you see some problems in those code
>>>>>> base, like code
>>>> base
>>>>>> is not updated based on latest changes then we can update those files.
>>>>>> Those files might have been used by so many users that we can't
>>>>>> know because we are doing this conversation on Dev mailing list.
>>>>>> We should
>>>> not
>>>>>> remove those files.
>>>>>>
>>>>>> --
>>>>>> Kind Regards
>>>>>> Ashish Vijaywargiya
>>>>>> HotWax Systems - est. 1997
>>>>>>
>>>>>> On Tue, Jun 14, 2016 at 7:40 PM, Taher Alkhateeb <
>>>>>> slidingfilaments@gmail.com <javascript:;>
>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>
>>>>>> Hi Everyone,
>>>>>>>
>>>>>>> I cannot actually believe it but while I was working on a
>>>>>>> project (I
>>>> will
>>>>>>> announce later) I discovered in the process that the below files
>>>>>>> cannot compile!!! They existed for years in the code base
>>>>>>> without even being able to compile. They reference non existent
>>>>>>> libraries or they have faulty code (e.g. not importing used
>>>>>>> code)
>>>>>>>
>>>>>>> I propose to delete them immediately from trunk
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/cyberso
>>>> urc
>>>> e/IcsPaymentServices.java
>>>>>>>
>>>>>>>
>>>>>>>
>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/I
>>>> dea
>>>> lEvents.java
>>>>>>>
>>>>>>>
>>>>>>>
>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/I
>>>> dea
>>>> lPaymentServiceTest.java
>>>>>>>
>>>>>>>
>>>>>>>
>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/orbital
>>>> /Or
>>>> bitalPaymentServices.java
>>>>>>>
>>>>>>>
>>>>>>>
>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/paypal/
>>>> Pay
>>>> PalServices.java
>>>>>>>
>>>>>>>
>>>>>>>
>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securep
>>>> ay/
>>>> SecurePayPaymentServices.java
>>>>>>>
>>>>>>>
>>>>>>>
>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securep
>>>> ay/
>>>> SecurePayServiceTest.java
>>>>>>>
>>>>>>>
>>>>>>>
>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/verisig
>>>> n/P
>>>> ayflowPro.java
>>>>>>>
>>>>>>>
>>>>>>>
>>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByt
>>>> eAr
>>>> rayInputStream.java
>>>>>>>
>>>>>>>
>>>>>>>
>>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByt
>>>> eAr
>>>> rayOutputStream.java
>>>>>>>
>>>>>>>
>>>>>>>
>>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeSer
>>>> vic
>>>> es.java
>>>>>>>
>>>>>>>
>>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeWor
>>>> ker
>>>> .java
>>>>>>> applications/content/src/org/ofbiz/content/report
>>>>>>>
>>>>>>>
>>>>>>>
>>>> applications/content/src/org/ofbiz/content/report/JREntityListItera
>>>> tor
>>>> DataSource.java
>>>>>>>
>>>>>>>
>>>>>>>
>>>> applications/content/src/org/ofbiz/content/report/JRMapCollectionDa
>>>> taS
>>>> ource.java
>>>>>>> applications/order/src/org/ofbiz/order/thirdparty/taxware
>>>>>>>
>>>>>>>
>>>>>>>
>>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareEx
>>>> cep
>>>> tion.java
>>>>>>>
>>>>>>>
>>>>>>>
>>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareSe
>>>> rvi
>>>> ces.java
>>>>>>>
>>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareUT
>>>> L.j
>>>> ava
>>>>>>> applications/product/src/ShipmentScaleApplet.java
>>>>>>>
>>>>>>>
>>>>>>>
>>>> applications/securityext/src/org/ofbiz/securityext/thirdparty/truit
>>>> ion
>>>> /TruitionCoReg.java
>>>>>>>
>>>>>>>
>>>>>>>
>>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsJXlsViewHan
>>>> dle
>>>> r.java
>>>>>>>
>>>>>>>
>>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPdfViewHand
>>>> ler
>>>> .java
>>>>>>>
>>>>>>>
>>>>>>>
>>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPoiXlsViewH
>>>> and
>>>> ler.java
>>>>>>>
>>>>>>>
>>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsXmlViewHand
>>>> ler
>>>> .java
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Taher Alkhateeb
>>>>>>>
>>>>>>>
>>>>>>
>>>>> --
>>>>>
>>>>> Regards,
>>>>>
>>>>> Hans Bakker
>>>>> CEO, http://antwebsystems.com
>>>>>
>>>>
>>>
>>>
>>> --
>>> Mridul Pathak
>>> Senior Manager
>>> HotWax Systems
>>> http://www.hotwaxsystems.com
>>> direct: +91-942592692
Re: Proposal to delete stale java files
Posted by Mridul Pathak <mr...@hotwaxsystems.com>.
Hi Taher,
I would like to make sure that I am understanding your proposal correctly.
Are you proposing to create a specialpurpose component named “reference” which would have all the code that can be referenced but not compiled, no matter what domain it is?
If that is the case, we have discussed about moving shipping integrations to specialpurpose component as well, and that code doesn’t have the compilation or library reference issues as listed in this thread, so I think that should go in it's own component.
--
Thanks & Regards,
Mridul Pathak
Senior Manager
HotWax Systems
http://www.hotwaxsystems.com
> On Jun 15, 2016, at 3:01 PM, Taher Alkhateeb <sl...@gmail.com> wrote:
>
> Hi Mridul,
>
> How about reference/paymentext and reference/whatever-else-you-want? So the
> top level directory is called reference to indicate to people that this is
> just for reference and will not compile. Also, this way we keep all
> reference material under one directory to avoid polluting the directory
> tree. My 2 cents.
>
> Regards,
>
> Taher Alkhateeb
>
> On Wed, Jun 15, 2016 at 12:27 PM, Mridul Pathak <
> mridul.pathak@hotwaxsystems.com <ma...@hotwaxsystems.com>> wrote:
>
>> Hi Taher,
>>
>> Sure, I’ll take care of deleting rest of the files as well.
>>
>> Also, we could name these specialpurpose component(s) as paymentext, etc.
>> and mention in README file that these are extensions to OFBiz and does not
>> compile directly.
>>
>> --
>> Thanks & Regards,
>> Mridul Pathak
>> HotWax Systems
>> http://www.hotwaxsystems.com
>>
>>> On Jun 15, 2016, at 2:37 PM, Taher Alkhateeb <sl...@gmail.com>
>> wrote:
>>>
>>> Hi Mridul and everyone,
>>>
>>> Thank you all for your inputs. May I also ask you Mridul while you are
>> at it to delete the rest of the files so the whole task resides with you to
>> avoid crossing any wires.
>>>
>>> Also, I suggest to name that component into something like archives or
>> reference and put a README file that says this component does not compile
>> and it holds this stuff. This way it is easy to isolate that component from
>> the build system.
>>>
>>> Thank you all again for your contributions.
>>>
>>> Taher Alkhateeb
>>>
>>> -----Original Message-----
>>> From: Mridul Pathak [mailto:mridul.pathak@hotwaxsystems.com <ma...@hotwaxsystems.com> <mailto:
>> mridul.pathak@hotwaxsystems.com <ma...@hotwaxsystems.com>>]
>>> Sent: 15 June 2016 11:09
>>> To: dev@ofbiz.apache.org <ma...@ofbiz.apache.org> <mailto:dev@ofbiz.apache.org <ma...@ofbiz.apache.org>>
>>> Cc: Mridul Pathak
>>> Subject: Re: Proposal to delete stale java files
>>>
>>> I would like to volunteer for this change (moving payment, shipping and
>> tax integrations to specialpurpose).
>>>
>>> --
>>> Mridul Pathak
>>>
>>> On Wednesday 15 June 2016, Jacopo Cappellato <
>> jacopo.cappellato@hotwaxsystems.com <ma...@hotwaxsystems.com>> wrote:
>>>
>>>> Based on the new comments it seems like that we could isolate the
>>>> shipment, payment and tax integration classes (and artifacts that use
>>>> them) into their own specialpurpose components (waiting for a better
>>>> pluggable components architecture); they will not be compiled by
>>>> default but each component will have its own readme file containing
>>>> instructions about how to deploy and use them.
>>>> As regards the JasperReports*, JRE* and openoffice ones I think they
>>>> can go to Attic since they are old and unmaintained.
>>>>
>>>> Does it make sense? Any volunteers to create the new specialpurpose
>>>> components and upgrade/isolate the shipment/payment/tax integration
>>>> classes into them?
>>>>
>>>> Jacopo
>>>>
>>>> On Wed, Jun 15, 2016 at 9:32 AM, Hans Bakker
>>>> <h.bakker@antwebsystems.com <ma...@antwebsystems.com> <mailto:h.bakker@antwebsystems.com <ma...@antwebsystems.com>>
>> <javascript:;>>
>>>> wrote:
>>>>
>>>>> +1
>>>>>
>>>>>
>>>>> On 15/06/16 13:30, Ashish Vijaywargiya wrote:
>>>>>
>>>>>> I would prefer to keep Tax and Third Party Payment gateway
>>>>>> files(The
>>>> files
>>>>>> that does exists inside cybersource, ideal, orbital, paypal,
>>>>>> securepay, verisign etc). If you see some problems in those code
>>>>>> base, like code
>>>> base
>>>>>> is not updated based on latest changes then we can update those files.
>>>>>> Those files might have been used by so many users that we can't
>>>>>> know because we are doing this conversation on Dev mailing list. We
>>>>>> should
>>>> not
>>>>>> remove those files.
>>>>>>
>>>>>> --
>>>>>> Kind Regards
>>>>>> Ashish Vijaywargiya
>>>>>> HotWax Systems - est. 1997
>>>>>>
>>>>>> On Tue, Jun 14, 2016 at 7:40 PM, Taher Alkhateeb <
>>>>>> slidingfilaments@gmail.com <javascript:;>
>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>
>>>>>> Hi Everyone,
>>>>>>>
>>>>>>> I cannot actually believe it but while I was working on a project
>>>>>>> (I
>>>> will
>>>>>>> announce later) I discovered in the process that the below files
>>>>>>> cannot compile!!! They existed for years in the code base without
>>>>>>> even being able to compile. They reference non existent libraries
>>>>>>> or they have faulty code (e.g. not importing used code)
>>>>>>>
>>>>>>> I propose to delete them immediately from trunk
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/cybersourc
>>>> e/IcsPaymentServices.java
>>>>>>>
>>>>>>>
>>>>>>>
>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/Idea
>>>> lEvents.java
>>>>>>>
>>>>>>>
>>>>>>>
>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/Idea
>>>> lPaymentServiceTest.java
>>>>>>>
>>>>>>>
>>>>>>>
>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/orbital/Or
>>>> bitalPaymentServices.java
>>>>>>>
>>>>>>>
>>>>>>>
>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/paypal/Pay
>>>> PalServices.java
>>>>>>>
>>>>>>>
>>>>>>>
>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/
>>>> SecurePayPaymentServices.java
>>>>>>>
>>>>>>>
>>>>>>>
>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/
>>>> SecurePayServiceTest.java
>>>>>>>
>>>>>>>
>>>>>>>
>>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/verisign/P
>>>> ayflowPro.java
>>>>>>>
>>>>>>>
>>>>>>>
>>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteAr
>>>> rayInputStream.java
>>>>>>>
>>>>>>>
>>>>>>>
>>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteAr
>>>> rayOutputStream.java
>>>>>>>
>>>>>>>
>>>>>>>
>>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeServic
>>>> es.java
>>>>>>>
>>>>>>>
>>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeWorker
>>>> .java
>>>>>>> applications/content/src/org/ofbiz/content/report
>>>>>>>
>>>>>>>
>>>>>>>
>>>> applications/content/src/org/ofbiz/content/report/JREntityListIterator
>>>> DataSource.java
>>>>>>>
>>>>>>>
>>>>>>>
>>>> applications/content/src/org/ofbiz/content/report/JRMapCollectionDataS
>>>> ource.java
>>>>>>> applications/order/src/org/ofbiz/order/thirdparty/taxware
>>>>>>>
>>>>>>>
>>>>>>>
>>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareExcep
>>>> tion.java
>>>>>>>
>>>>>>>
>>>>>>>
>>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareServi
>>>> ces.java
>>>>>>>
>>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareUTL.j
>>>> ava
>>>>>>> applications/product/src/ShipmentScaleApplet.java
>>>>>>>
>>>>>>>
>>>>>>>
>>>> applications/securityext/src/org/ofbiz/securityext/thirdparty/truition
>>>> /TruitionCoReg.java
>>>>>>>
>>>>>>>
>>>>>>>
>>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsJXlsViewHandle
>>>> r.java
>>>>>>>
>>>>>>>
>>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPdfViewHandler
>>>> .java
>>>>>>>
>>>>>>>
>>>>>>>
>>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPoiXlsViewHand
>>>> ler.java
>>>>>>>
>>>>>>>
>>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsXmlViewHandler
>>>> .java
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Taher Alkhateeb
>>>>>>>
>>>>>>>
>>>>>>
>>>>> --
>>>>>
>>>>> Regards,
>>>>>
>>>>> Hans Bakker
>>>>> CEO, http://antwebsystems.com
>>>>>
>>>>
>>>
>>>
>>> --
>>> Mridul Pathak
>>> Senior Manager
>>> HotWax Systems
>>> http://www.hotwaxsystems.com
>>> direct: +91-942592692
Re: Proposal to delete stale java files
Posted by Taher Alkhateeb <sl...@gmail.com>.
Hi Mridul,
How about reference/paymentext and reference/whatever-else-you-want? So the
top level directory is called reference to indicate to people that this is
just for reference and will not compile. Also, this way we keep all
reference material under one directory to avoid polluting the directory
tree. My 2 cents.
Regards,
Taher Alkhateeb
On Wed, Jun 15, 2016 at 12:27 PM, Mridul Pathak <
mridul.pathak@hotwaxsystems.com> wrote:
> Hi Taher,
>
> Sure, I’ll take care of deleting rest of the files as well.
>
> Also, we could name these specialpurpose component(s) as paymentext, etc.
> and mention in README file that these are extensions to OFBiz and does not
> compile directly.
>
> --
> Thanks & Regards,
> Mridul Pathak
> HotWax Systems
> http://www.hotwaxsystems.com
>
> > On Jun 15, 2016, at 2:37 PM, Taher Alkhateeb <sl...@gmail.com>
> wrote:
> >
> > Hi Mridul and everyone,
> >
> > Thank you all for your inputs. May I also ask you Mridul while you are
> at it to delete the rest of the files so the whole task resides with you to
> avoid crossing any wires.
> >
> > Also, I suggest to name that component into something like archives or
> reference and put a README file that says this component does not compile
> and it holds this stuff. This way it is easy to isolate that component from
> the build system.
> >
> > Thank you all again for your contributions.
> >
> > Taher Alkhateeb
> >
> > -----Original Message-----
> > From: Mridul Pathak [mailto:mridul.pathak@hotwaxsystems.com <mailto:
> mridul.pathak@hotwaxsystems.com>]
> > Sent: 15 June 2016 11:09
> > To: dev@ofbiz.apache.org <ma...@ofbiz.apache.org>
> > Cc: Mridul Pathak
> > Subject: Re: Proposal to delete stale java files
> >
> > I would like to volunteer for this change (moving payment, shipping and
> tax integrations to specialpurpose).
> >
> > --
> > Mridul Pathak
> >
> > On Wednesday 15 June 2016, Jacopo Cappellato <
> jacopo.cappellato@hotwaxsystems.com> wrote:
> >
> >> Based on the new comments it seems like that we could isolate the
> >> shipment, payment and tax integration classes (and artifacts that use
> >> them) into their own specialpurpose components (waiting for a better
> >> pluggable components architecture); they will not be compiled by
> >> default but each component will have its own readme file containing
> >> instructions about how to deploy and use them.
> >> As regards the JasperReports*, JRE* and openoffice ones I think they
> >> can go to Attic since they are old and unmaintained.
> >>
> >> Does it make sense? Any volunteers to create the new specialpurpose
> >> components and upgrade/isolate the shipment/payment/tax integration
> >> classes into them?
> >>
> >> Jacopo
> >>
> >> On Wed, Jun 15, 2016 at 9:32 AM, Hans Bakker
> >> <h.bakker@antwebsystems.com <ma...@antwebsystems.com>
> <javascript:;>>
> >> wrote:
> >>
> >>> +1
> >>>
> >>>
> >>> On 15/06/16 13:30, Ashish Vijaywargiya wrote:
> >>>
> >>>> I would prefer to keep Tax and Third Party Payment gateway
> >>>> files(The
> >> files
> >>>> that does exists inside cybersource, ideal, orbital, paypal,
> >>>> securepay, verisign etc). If you see some problems in those code
> >>>> base, like code
> >> base
> >>>> is not updated based on latest changes then we can update those files.
> >>>> Those files might have been used by so many users that we can't
> >>>> know because we are doing this conversation on Dev mailing list. We
> >>>> should
> >> not
> >>>> remove those files.
> >>>>
> >>>> --
> >>>> Kind Regards
> >>>> Ashish Vijaywargiya
> >>>> HotWax Systems - est. 1997
> >>>>
> >>>> On Tue, Jun 14, 2016 at 7:40 PM, Taher Alkhateeb <
> >>>> slidingfilaments@gmail.com <javascript:;>
> >>>>
> >>>>> wrote:
> >>>>>
> >>>>
> >>>> Hi Everyone,
> >>>>>
> >>>>> I cannot actually believe it but while I was working on a project
> >>>>> (I
> >> will
> >>>>> announce later) I discovered in the process that the below files
> >>>>> cannot compile!!! They existed for years in the code base without
> >>>>> even being able to compile. They reference non existent libraries
> >>>>> or they have faulty code (e.g. not importing used code)
> >>>>>
> >>>>> I propose to delete them immediately from trunk
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >> applications/accounting/src/org/ofbiz/accounting/thirdparty/cybersourc
> >> e/IcsPaymentServices.java
> >>>>>
> >>>>>
> >>>>>
> >> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/Idea
> >> lEvents.java
> >>>>>
> >>>>>
> >>>>>
> >> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/Idea
> >> lPaymentServiceTest.java
> >>>>>
> >>>>>
> >>>>>
> >> applications/accounting/src/org/ofbiz/accounting/thirdparty/orbital/Or
> >> bitalPaymentServices.java
> >>>>>
> >>>>>
> >>>>>
> >> applications/accounting/src/org/ofbiz/accounting/thirdparty/paypal/Pay
> >> PalServices.java
> >>>>>
> >>>>>
> >>>>>
> >> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/
> >> SecurePayPaymentServices.java
> >>>>>
> >>>>>
> >>>>>
> >> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/
> >> SecurePayServiceTest.java
> >>>>>
> >>>>>
> >>>>>
> >> applications/accounting/src/org/ofbiz/accounting/thirdparty/verisign/P
> >> ayflowPro.java
> >>>>>
> >>>>>
> >>>>>
> >> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteAr
> >> rayInputStream.java
> >>>>>
> >>>>>
> >>>>>
> >> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteAr
> >> rayOutputStream.java
> >>>>>
> >>>>>
> >>>>>
> >> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeServic
> >> es.java
> >>>>>
> >>>>>
> >> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeWorker
> >> .java
> >>>>> applications/content/src/org/ofbiz/content/report
> >>>>>
> >>>>>
> >>>>>
> >> applications/content/src/org/ofbiz/content/report/JREntityListIterator
> >> DataSource.java
> >>>>>
> >>>>>
> >>>>>
> >> applications/content/src/org/ofbiz/content/report/JRMapCollectionDataS
> >> ource.java
> >>>>> applications/order/src/org/ofbiz/order/thirdparty/taxware
> >>>>>
> >>>>>
> >>>>>
> >> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareExcep
> >> tion.java
> >>>>>
> >>>>>
> >>>>>
> >> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareServi
> >> ces.java
> >>>>>
> >> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareUTL.j
> >> ava
> >>>>> applications/product/src/ShipmentScaleApplet.java
> >>>>>
> >>>>>
> >>>>>
> >> applications/securityext/src/org/ofbiz/securityext/thirdparty/truition
> >> /TruitionCoReg.java
> >>>>>
> >>>>>
> >>>>>
> >> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsJXlsViewHandle
> >> r.java
> >>>>>
> >>>>>
> >> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPdfViewHandler
> >> .java
> >>>>>
> >>>>>
> >>>>>
> >> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPoiXlsViewHand
> >> ler.java
> >>>>>
> >>>>>
> >> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsXmlViewHandler
> >> .java
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>> Taher Alkhateeb
> >>>>>
> >>>>>
> >>>>
> >>> --
> >>>
> >>> Regards,
> >>>
> >>> Hans Bakker
> >>> CEO, http://antwebsystems.com
> >>>
> >>
> >
> >
> > --
> > Mridul Pathak
> > Senior Manager
> > HotWax Systems
> > http://www.hotwaxsystems.com
> > direct: +91-942592692
>
>
Re: Proposal to delete stale java files
Posted by Mridul Pathak <mr...@hotwaxsystems.com>.
Hi Taher,
Sure, I’ll take care of deleting rest of the files as well.
Also, we could name these specialpurpose component(s) as paymentext, etc. and mention in README file that these are extensions to OFBiz and does not compile directly.
--
Thanks & Regards,
Mridul Pathak
HotWax Systems
http://www.hotwaxsystems.com
> On Jun 15, 2016, at 2:37 PM, Taher Alkhateeb <sl...@gmail.com> wrote:
>
> Hi Mridul and everyone,
>
> Thank you all for your inputs. May I also ask you Mridul while you are at it to delete the rest of the files so the whole task resides with you to avoid crossing any wires.
>
> Also, I suggest to name that component into something like archives or reference and put a README file that says this component does not compile and it holds this stuff. This way it is easy to isolate that component from the build system.
>
> Thank you all again for your contributions.
>
> Taher Alkhateeb
>
> -----Original Message-----
> From: Mridul Pathak [mailto:mridul.pathak@hotwaxsystems.com <ma...@hotwaxsystems.com>]
> Sent: 15 June 2016 11:09
> To: dev@ofbiz.apache.org <ma...@ofbiz.apache.org>
> Cc: Mridul Pathak
> Subject: Re: Proposal to delete stale java files
>
> I would like to volunteer for this change (moving payment, shipping and tax integrations to specialpurpose).
>
> --
> Mridul Pathak
>
> On Wednesday 15 June 2016, Jacopo Cappellato < jacopo.cappellato@hotwaxsystems.com> wrote:
>
>> Based on the new comments it seems like that we could isolate the
>> shipment, payment and tax integration classes (and artifacts that use
>> them) into their own specialpurpose components (waiting for a better
>> pluggable components architecture); they will not be compiled by
>> default but each component will have its own readme file containing
>> instructions about how to deploy and use them.
>> As regards the JasperReports*, JRE* and openoffice ones I think they
>> can go to Attic since they are old and unmaintained.
>>
>> Does it make sense? Any volunteers to create the new specialpurpose
>> components and upgrade/isolate the shipment/payment/tax integration
>> classes into them?
>>
>> Jacopo
>>
>> On Wed, Jun 15, 2016 at 9:32 AM, Hans Bakker
>> <h.bakker@antwebsystems.com <ma...@antwebsystems.com> <javascript:;>>
>> wrote:
>>
>>> +1
>>>
>>>
>>> On 15/06/16 13:30, Ashish Vijaywargiya wrote:
>>>
>>>> I would prefer to keep Tax and Third Party Payment gateway
>>>> files(The
>> files
>>>> that does exists inside cybersource, ideal, orbital, paypal,
>>>> securepay, verisign etc). If you see some problems in those code
>>>> base, like code
>> base
>>>> is not updated based on latest changes then we can update those files.
>>>> Those files might have been used by so many users that we can't
>>>> know because we are doing this conversation on Dev mailing list. We
>>>> should
>> not
>>>> remove those files.
>>>>
>>>> --
>>>> Kind Regards
>>>> Ashish Vijaywargiya
>>>> HotWax Systems - est. 1997
>>>>
>>>> On Tue, Jun 14, 2016 at 7:40 PM, Taher Alkhateeb <
>>>> slidingfilaments@gmail.com <javascript:;>
>>>>
>>>>> wrote:
>>>>>
>>>>
>>>> Hi Everyone,
>>>>>
>>>>> I cannot actually believe it but while I was working on a project
>>>>> (I
>> will
>>>>> announce later) I discovered in the process that the below files
>>>>> cannot compile!!! They existed for years in the code base without
>>>>> even being able to compile. They reference non existent libraries
>>>>> or they have faulty code (e.g. not importing used code)
>>>>>
>>>>> I propose to delete them immediately from trunk
>>>>>
>>>>>
>>>>>
>>>>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/cybersourc
>> e/IcsPaymentServices.java
>>>>>
>>>>>
>>>>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/Idea
>> lEvents.java
>>>>>
>>>>>
>>>>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/Idea
>> lPaymentServiceTest.java
>>>>>
>>>>>
>>>>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/orbital/Or
>> bitalPaymentServices.java
>>>>>
>>>>>
>>>>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/paypal/Pay
>> PalServices.java
>>>>>
>>>>>
>>>>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/
>> SecurePayPaymentServices.java
>>>>>
>>>>>
>>>>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/
>> SecurePayServiceTest.java
>>>>>
>>>>>
>>>>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/verisign/P
>> ayflowPro.java
>>>>>
>>>>>
>>>>>
>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteAr
>> rayInputStream.java
>>>>>
>>>>>
>>>>>
>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteAr
>> rayOutputStream.java
>>>>>
>>>>>
>>>>>
>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeServic
>> es.java
>>>>>
>>>>>
>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeWorker
>> .java
>>>>> applications/content/src/org/ofbiz/content/report
>>>>>
>>>>>
>>>>>
>> applications/content/src/org/ofbiz/content/report/JREntityListIterator
>> DataSource.java
>>>>>
>>>>>
>>>>>
>> applications/content/src/org/ofbiz/content/report/JRMapCollectionDataS
>> ource.java
>>>>> applications/order/src/org/ofbiz/order/thirdparty/taxware
>>>>>
>>>>>
>>>>>
>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareExcep
>> tion.java
>>>>>
>>>>>
>>>>>
>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareServi
>> ces.java
>>>>>
>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareUTL.j
>> ava
>>>>> applications/product/src/ShipmentScaleApplet.java
>>>>>
>>>>>
>>>>>
>> applications/securityext/src/org/ofbiz/securityext/thirdparty/truition
>> /TruitionCoReg.java
>>>>>
>>>>>
>>>>>
>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsJXlsViewHandle
>> r.java
>>>>>
>>>>>
>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPdfViewHandler
>> .java
>>>>>
>>>>>
>>>>>
>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPoiXlsViewHand
>> ler.java
>>>>>
>>>>>
>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsXmlViewHandler
>> .java
>>>>>
>>>>> Regards,
>>>>>
>>>>> Taher Alkhateeb
>>>>>
>>>>>
>>>>
>>> --
>>>
>>> Regards,
>>>
>>> Hans Bakker
>>> CEO, http://antwebsystems.com
>>>
>>
>
>
> --
> Mridul Pathak
> Senior Manager
> HotWax Systems
> http://www.hotwaxsystems.com
> direct: +91-942592692
RE: Proposal to delete stale java files
Posted by Taher Alkhateeb <sl...@gmail.com>.
Hi Mridul and everyone,
Thank you all for your inputs. May I also ask you Mridul while you are at it to delete the rest of the files so the whole task resides with you to avoid crossing any wires.
Also, I suggest to name that component into something like archives or reference and put a README file that says this component does not compile and it holds this stuff. This way it is easy to isolate that component from the build system.
Thank you all again for your contributions.
Taher Alkhateeb
-----Original Message-----
From: Mridul Pathak [mailto:mridul.pathak@hotwaxsystems.com]
Sent: 15 June 2016 11:09
To: dev@ofbiz.apache.org
Cc: Mridul Pathak
Subject: Re: Proposal to delete stale java files
I would like to volunteer for this change (moving payment, shipping and tax integrations to specialpurpose).
--
Mridul Pathak
On Wednesday 15 June 2016, Jacopo Cappellato < jacopo.cappellato@hotwaxsystems.com> wrote:
> Based on the new comments it seems like that we could isolate the
> shipment, payment and tax integration classes (and artifacts that use
> them) into their own specialpurpose components (waiting for a better
> pluggable components architecture); they will not be compiled by
> default but each component will have its own readme file containing
> instructions about how to deploy and use them.
> As regards the JasperReports*, JRE* and openoffice ones I think they
> can go to Attic since they are old and unmaintained.
>
> Does it make sense? Any volunteers to create the new specialpurpose
> components and upgrade/isolate the shipment/payment/tax integration
> classes into them?
>
> Jacopo
>
> On Wed, Jun 15, 2016 at 9:32 AM, Hans Bakker
> <h.bakker@antwebsystems.com <javascript:;>>
> wrote:
>
> > +1
> >
> >
> > On 15/06/16 13:30, Ashish Vijaywargiya wrote:
> >
> >> I would prefer to keep Tax and Third Party Payment gateway
> >> files(The
> files
> >> that does exists inside cybersource, ideal, orbital, paypal,
> >> securepay, verisign etc). If you see some problems in those code
> >> base, like code
> base
> >> is not updated based on latest changes then we can update those files.
> >> Those files might have been used by so many users that we can't
> >> know because we are doing this conversation on Dev mailing list. We
> >> should
> not
> >> remove those files.
> >>
> >> --
> >> Kind Regards
> >> Ashish Vijaywargiya
> >> HotWax Systems - est. 1997
> >>
> >> On Tue, Jun 14, 2016 at 7:40 PM, Taher Alkhateeb <
> >> slidingfilaments@gmail.com <javascript:;>
> >>
> >>> wrote:
> >>>
> >>
> >> Hi Everyone,
> >>>
> >>> I cannot actually believe it but while I was working on a project
> >>> (I
> will
> >>> announce later) I discovered in the process that the below files
> >>> cannot compile!!! They existed for years in the code base without
> >>> even being able to compile. They reference non existent libraries
> >>> or they have faulty code (e.g. not importing used code)
> >>>
> >>> I propose to delete them immediately from trunk
> >>>
> >>>
> >>>
> >>>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/cybersourc
> e/IcsPaymentServices.java
> >>>
> >>>
> >>>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/Idea
> lEvents.java
> >>>
> >>>
> >>>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/Idea
> lPaymentServiceTest.java
> >>>
> >>>
> >>>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/orbital/Or
> bitalPaymentServices.java
> >>>
> >>>
> >>>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/paypal/Pay
> PalServices.java
> >>>
> >>>
> >>>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/
> SecurePayPaymentServices.java
> >>>
> >>>
> >>>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/
> SecurePayServiceTest.java
> >>>
> >>>
> >>>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/verisign/P
> ayflowPro.java
> >>>
> >>>
> >>>
> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteAr
> rayInputStream.java
> >>>
> >>>
> >>>
> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteAr
> rayOutputStream.java
> >>>
> >>>
> >>>
> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeServic
> es.java
> >>>
> >>>
> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeWorker
> .java
> >>> applications/content/src/org/ofbiz/content/report
> >>>
> >>>
> >>>
> applications/content/src/org/ofbiz/content/report/JREntityListIterator
> DataSource.java
> >>>
> >>>
> >>>
> applications/content/src/org/ofbiz/content/report/JRMapCollectionDataS
> ource.java
> >>> applications/order/src/org/ofbiz/order/thirdparty/taxware
> >>>
> >>>
> >>>
> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareExcep
> tion.java
> >>>
> >>>
> >>>
> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareServi
> ces.java
> >>>
> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareUTL.j
> ava
> >>> applications/product/src/ShipmentScaleApplet.java
> >>>
> >>>
> >>>
> applications/securityext/src/org/ofbiz/securityext/thirdparty/truition
> /TruitionCoReg.java
> >>>
> >>>
> >>>
> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsJXlsViewHandle
> r.java
> >>>
> >>>
> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPdfViewHandler
> .java
> >>>
> >>>
> >>>
> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPoiXlsViewHand
> ler.java
> >>>
> >>>
> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsXmlViewHandler
> .java
> >>>
> >>> Regards,
> >>>
> >>> Taher Alkhateeb
> >>>
> >>>
> >>
> > --
> >
> > Regards,
> >
> > Hans Bakker
> > CEO, http://antwebsystems.com
> >
>
--
Mridul Pathak
Senior Manager
HotWax Systems
http://www.hotwaxsystems.com
direct: +91-942592692
Re: Proposal to delete stale java files
Posted by Mridul Pathak <mr...@hotwaxsystems.com>.
I would like to volunteer for this change (moving payment, shipping and tax
integrations to specialpurpose).
--
Mridul Pathak
On Wednesday 15 June 2016, Jacopo Cappellato <
jacopo.cappellato@hotwaxsystems.com> wrote:
> Based on the new comments it seems like that we could isolate the shipment,
> payment and tax integration classes (and artifacts that use them) into
> their own specialpurpose components (waiting for a better pluggable
> components architecture); they will not be compiled by default but each
> component will have its own readme file containing instructions about how
> to deploy and use them.
> As regards the JasperReports*, JRE* and openoffice ones I think they can go
> to Attic since they are old and unmaintained.
>
> Does it make sense? Any volunteers to create the new specialpurpose
> components and upgrade/isolate the shipment/payment/tax integration classes
> into them?
>
> Jacopo
>
> On Wed, Jun 15, 2016 at 9:32 AM, Hans Bakker <h.bakker@antwebsystems.com
> <javascript:;>>
> wrote:
>
> > +1
> >
> >
> > On 15/06/16 13:30, Ashish Vijaywargiya wrote:
> >
> >> I would prefer to keep Tax and Third Party Payment gateway files(The
> files
> >> that does exists inside cybersource, ideal, orbital, paypal, securepay,
> >> verisign etc). If you see some problems in those code base, like code
> base
> >> is not updated based on latest changes then we can update those files.
> >> Those files might have been used by so many users that we can't know
> >> because we are doing this conversation on Dev mailing list. We should
> not
> >> remove those files.
> >>
> >> --
> >> Kind Regards
> >> Ashish Vijaywargiya
> >> HotWax Systems - est. 1997
> >>
> >> On Tue, Jun 14, 2016 at 7:40 PM, Taher Alkhateeb <
> >> slidingfilaments@gmail.com <javascript:;>
> >>
> >>> wrote:
> >>>
> >>
> >> Hi Everyone,
> >>>
> >>> I cannot actually believe it but while I was working on a project (I
> will
> >>> announce later) I discovered in the process that the below files cannot
> >>> compile!!! They existed for years in the code base without even being
> >>> able
> >>> to compile. They reference non existent libraries or they have faulty
> >>> code
> >>> (e.g. not importing used code)
> >>>
> >>> I propose to delete them immediately from trunk
> >>>
> >>>
> >>>
> >>>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/cybersource/IcsPaymentServices.java
> >>>
> >>>
> >>>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealEvents.java
> >>>
> >>>
> >>>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealPaymentServiceTest.java
> >>>
> >>>
> >>>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/orbital/OrbitalPaymentServices.java
> >>>
> >>>
> >>>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/paypal/PayPalServices.java
> >>>
> >>>
> >>>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayPaymentServices.java
> >>>
> >>>
> >>>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayServiceTest.java
> >>>
> >>>
> >>>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/verisign/PayflowPro.java
> >>>
> >>>
> >>>
> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayInputStream.java
> >>>
> >>>
> >>>
> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayOutputStream.java
> >>>
> >>>
> >>>
> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeServices.java
> >>>
> >>>
> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeWorker.java
> >>> applications/content/src/org/ofbiz/content/report
> >>>
> >>>
> >>>
> applications/content/src/org/ofbiz/content/report/JREntityListIteratorDataSource.java
> >>>
> >>>
> >>>
> applications/content/src/org/ofbiz/content/report/JRMapCollectionDataSource.java
> >>> applications/order/src/org/ofbiz/order/thirdparty/taxware
> >>>
> >>>
> >>>
> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareException.java
> >>>
> >>>
> >>>
> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareServices.java
> >>>
> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareUTL.java
> >>> applications/product/src/ShipmentScaleApplet.java
> >>>
> >>>
> >>>
> applications/securityext/src/org/ofbiz/securityext/thirdparty/truition/TruitionCoReg.java
> >>>
> >>>
> >>>
> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsJXlsViewHandler.java
> >>>
> >>>
> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPdfViewHandler.java
> >>>
> >>>
> >>>
> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPoiXlsViewHandler.java
> >>>
> >>>
> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsXmlViewHandler.java
> >>>
> >>> Regards,
> >>>
> >>> Taher Alkhateeb
> >>>
> >>>
> >>
> > --
> >
> > Regards,
> >
> > Hans Bakker
> > CEO, http://antwebsystems.com
> >
>
--
Mridul Pathak
Senior Manager
HotWax Systems
http://www.hotwaxsystems.com
direct: +91-942592692
Re: Proposal to delete stale java files
Posted by Jacopo Cappellato <ja...@hotwaxsystems.com>.
Based on the new comments it seems like that we could isolate the shipment,
payment and tax integration classes (and artifacts that use them) into
their own specialpurpose components (waiting for a better pluggable
components architecture); they will not be compiled by default but each
component will have its own readme file containing instructions about how
to deploy and use them.
As regards the JasperReports*, JRE* and openoffice ones I think they can go
to Attic since they are old and unmaintained.
Does it make sense? Any volunteers to create the new specialpurpose
components and upgrade/isolate the shipment/payment/tax integration classes
into them?
Jacopo
On Wed, Jun 15, 2016 at 9:32 AM, Hans Bakker <h....@antwebsystems.com>
wrote:
> +1
>
>
> On 15/06/16 13:30, Ashish Vijaywargiya wrote:
>
>> I would prefer to keep Tax and Third Party Payment gateway files(The files
>> that does exists inside cybersource, ideal, orbital, paypal, securepay,
>> verisign etc). If you see some problems in those code base, like code base
>> is not updated based on latest changes then we can update those files.
>> Those files might have been used by so many users that we can't know
>> because we are doing this conversation on Dev mailing list. We should not
>> remove those files.
>>
>> --
>> Kind Regards
>> Ashish Vijaywargiya
>> HotWax Systems - est. 1997
>>
>> On Tue, Jun 14, 2016 at 7:40 PM, Taher Alkhateeb <
>> slidingfilaments@gmail.com
>>
>>> wrote:
>>>
>>
>> Hi Everyone,
>>>
>>> I cannot actually believe it but while I was working on a project (I will
>>> announce later) I discovered in the process that the below files cannot
>>> compile!!! They existed for years in the code base without even being
>>> able
>>> to compile. They reference non existent libraries or they have faulty
>>> code
>>> (e.g. not importing used code)
>>>
>>> I propose to delete them immediately from trunk
>>>
>>>
>>>
>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/cybersource/IcsPaymentServices.java
>>>
>>>
>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealEvents.java
>>>
>>>
>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealPaymentServiceTest.java
>>>
>>>
>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/orbital/OrbitalPaymentServices.java
>>>
>>>
>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/paypal/PayPalServices.java
>>>
>>>
>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayPaymentServices.java
>>>
>>>
>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayServiceTest.java
>>>
>>>
>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/verisign/PayflowPro.java
>>>
>>>
>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayInputStream.java
>>>
>>>
>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayOutputStream.java
>>>
>>>
>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeServices.java
>>>
>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeWorker.java
>>> applications/content/src/org/ofbiz/content/report
>>>
>>>
>>> applications/content/src/org/ofbiz/content/report/JREntityListIteratorDataSource.java
>>>
>>>
>>> applications/content/src/org/ofbiz/content/report/JRMapCollectionDataSource.java
>>> applications/order/src/org/ofbiz/order/thirdparty/taxware
>>>
>>>
>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareException.java
>>>
>>>
>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareServices.java
>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareUTL.java
>>> applications/product/src/ShipmentScaleApplet.java
>>>
>>>
>>> applications/securityext/src/org/ofbiz/securityext/thirdparty/truition/TruitionCoReg.java
>>>
>>>
>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsJXlsViewHandler.java
>>>
>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPdfViewHandler.java
>>>
>>>
>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPoiXlsViewHandler.java
>>>
>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsXmlViewHandler.java
>>>
>>> Regards,
>>>
>>> Taher Alkhateeb
>>>
>>>
>>
> --
>
> Regards,
>
> Hans Bakker
> CEO, http://antwebsystems.com
>
Re: Proposal to delete stale java files
Posted by Hans Bakker <h....@antwebsystems.com>.
+1
On 15/06/16 13:30, Ashish Vijaywargiya wrote:
> I would prefer to keep Tax and Third Party Payment gateway files(The files
> that does exists inside cybersource, ideal, orbital, paypal, securepay,
> verisign etc). If you see some problems in those code base, like code base
> is not updated based on latest changes then we can update those files.
> Those files might have been used by so many users that we can't know
> because we are doing this conversation on Dev mailing list. We should not
> remove those files.
>
> --
> Kind Regards
> Ashish Vijaywargiya
> HotWax Systems - est. 1997
>
> On Tue, Jun 14, 2016 at 7:40 PM, Taher Alkhateeb <slidingfilaments@gmail.com
>> wrote:
>
>> Hi Everyone,
>>
>> I cannot actually believe it but while I was working on a project (I will
>> announce later) I discovered in the process that the below files cannot
>> compile!!! They existed for years in the code base without even being able
>> to compile. They reference non existent libraries or they have faulty code
>> (e.g. not importing used code)
>>
>> I propose to delete them immediately from trunk
>>
>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/cybersource/IcsPaymentServices.java
>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealEvents.java
>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealPaymentServiceTest.java
>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/orbital/OrbitalPaymentServices.java
>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/paypal/PayPalServices.java
>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayPaymentServices.java
>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayServiceTest.java
>>
>> applications/accounting/src/org/ofbiz/accounting/thirdparty/verisign/PayflowPro.java
>>
>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayInputStream.java
>>
>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayOutputStream.java
>>
>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeServices.java
>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeWorker.java
>> applications/content/src/org/ofbiz/content/report
>>
>> applications/content/src/org/ofbiz/content/report/JREntityListIteratorDataSource.java
>>
>> applications/content/src/org/ofbiz/content/report/JRMapCollectionDataSource.java
>> applications/order/src/org/ofbiz/order/thirdparty/taxware
>>
>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareException.java
>>
>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareServices.java
>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareUTL.java
>> applications/product/src/ShipmentScaleApplet.java
>>
>> applications/securityext/src/org/ofbiz/securityext/thirdparty/truition/TruitionCoReg.java
>>
>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsJXlsViewHandler.java
>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPdfViewHandler.java
>>
>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPoiXlsViewHandler.java
>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsXmlViewHandler.java
>>
>> Regards,
>>
>> Taher Alkhateeb
>>
>
--
Regards,
Hans Bakker
CEO, http://antwebsystems.com
Re: Proposal to delete stale java files
Posted by Ashish Vijaywargiya <as...@hotwaxsystems.com>.
I would prefer to keep Tax and Third Party Payment gateway files(The files
that does exists inside cybersource, ideal, orbital, paypal, securepay,
verisign etc). If you see some problems in those code base, like code base
is not updated based on latest changes then we can update those files.
Those files might have been used by so many users that we can't know
because we are doing this conversation on Dev mailing list. We should not
remove those files.
--
Kind Regards
Ashish Vijaywargiya
HotWax Systems - est. 1997
On Tue, Jun 14, 2016 at 7:40 PM, Taher Alkhateeb <slidingfilaments@gmail.com
> wrote:
> Hi Everyone,
>
> I cannot actually believe it but while I was working on a project (I will
> announce later) I discovered in the process that the below files cannot
> compile!!! They existed for years in the code base without even being able
> to compile. They reference non existent libraries or they have faulty code
> (e.g. not importing used code)
>
> I propose to delete them immediately from trunk
>
>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/cybersource/IcsPaymentServices.java
>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealEvents.java
>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealPaymentServiceTest.java
>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/orbital/OrbitalPaymentServices.java
>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/paypal/PayPalServices.java
>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayPaymentServices.java
>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayServiceTest.java
>
> applications/accounting/src/org/ofbiz/accounting/thirdparty/verisign/PayflowPro.java
>
> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayInputStream.java
>
> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayOutputStream.java
>
> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeServices.java
> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeWorker.java
> applications/content/src/org/ofbiz/content/report
>
> applications/content/src/org/ofbiz/content/report/JREntityListIteratorDataSource.java
>
> applications/content/src/org/ofbiz/content/report/JRMapCollectionDataSource.java
> applications/order/src/org/ofbiz/order/thirdparty/taxware
>
> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareException.java
>
> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareServices.java
> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareUTL.java
> applications/product/src/ShipmentScaleApplet.java
>
> applications/securityext/src/org/ofbiz/securityext/thirdparty/truition/TruitionCoReg.java
>
> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsJXlsViewHandler.java
> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPdfViewHandler.java
>
> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPoiXlsViewHandler.java
> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsXmlViewHandler.java
>
> Regards,
>
> Taher Alkhateeb
>