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