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 <slidingfilame...@gmail.comwrote: Hi Mridul, Ahh I see that makes sense. Yeah sure we put non-compiling stuff regardless of origin in specialpurpose/reference and the rest in their own components. Regards, -----Original Message----- From: Mridul Pathak [mailto:mridul.pat...@hotwaxsystems.com] Sent: 15 June 2016 14:19 To: dev@ofbiz.apache.org Cc: Mridul Pathak Subject: Re: Proposal to delete stale java files Hi Taher, I would like to make sure that I am understanding your proposal correctly. Are you proposing to create a specialpurpose component named “reference” which would have all the code that can be referenced but not compiled, no matter what domain it is? If that is the case, we have discussed about moving shipping integrations to specialpurpose component as well, and that code doesn’t have the compilation or library reference issues as listed in this thread, so I think that should go in it's own component. -- Thanks & Regards, Mridul Pathak Senior Manager HotWax Systems http://www.hotwaxsystems.comOn Jun 15, 2016, at 3:01 PM, Taher Alkhateeb <slidingfilame...@gmail.com>wrote:Hi Mridul, How about reference/paymentext and reference/whatever-else-you-want? So the top level directory is called reference to indicate to people that this is just for reference and will not compile. Also, this way we keep all reference material under one directory to avoid polluting the directory tree. My 2 cents. Regards, Taher Alkhateeb On Wed, Jun 15, 2016 at 12:27 PM, Mridul Pathak < mridul.pat...@hotwaxsystems.com <mailto:mridul.pat...@hotwaxsystems.com>>wrote:Hi Taher, Sure, I’ll take care of deleting rest of the files as well. Also, we could name these specialpurpose component(s) as paymentext,etc.and mention in README file that these are extensions to OFBiz and does not compile directly. -- Thanks & Regards, Mridul Pathak HotWax Systems http://www.hotwaxsystems.comOn Jun 15, 2016, at 2:37 PM, Taher Alkhateeb <slidingfilame...@gmail.com>wrote:Hi Mridul and everyone, Thank you all for your inputs. May I also ask you Mridul while you areat 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 orreference and put a README file that says this component does not compile and it holds this stuff. This way it is easy to isolate that component from the build system.Thank you all again for your contributions. Taher Alkhateeb -----Original Message----- From: Mridul Pathak [mailto:mridul.pat...@hotwaxsystems.com <mailto:mridul.pat...@hotwaxsystems.com> <mailto:mridul.pat...@hotwaxsystems.com <mailto:mridul.pat...@hotwaxsystems.com>>]Sent: 15 June 2016 11:09 To: dev@ofbiz.apache.org <mailto:dev@ofbiz.apache.org> <mailto:dev@ofbiz.apache.org <mailto:dev@ofbiz.apache.org>> Cc: Mridul Pathak Subject: Re: Proposal to delete stale java files I would like to volunteer for this change (moving payment, shipping andtax integrations to specialpurpose).-- Mridul Pathak On Wednesday 15 June 2016, Jacopo Cappellato <jacopo.cappell...@hotwaxsystems.com <mailto:jacopo.cappell...@hotwaxsystems.com>> wrote:Based on the new comments it seems like that we could isolate the shipment, payment and tax integration classes (and artifacts that use them) into their own specialpurpose components (waiting for a better pluggable components architecture); they will not be compiled by default but each component will have its own readme file containing instructions about how to deploy and use them. As regards the JasperReports*, JRE* and openoffice ones I think they can go to Attic since they are old and unmaintained. Does it make sense? Any volunteers to create the new specialpurpose components and upgrade/isolate the shipment/payment/tax integration classes into them? Jacopo On Wed, Jun 15, 2016 at 9:32 AM, Hans Bakker <h.bak...@antwebsystems.com <mailto:h.bak...@antwebsystems.com> <mailto:h.bak...@antwebsystems.com <mailto:h.bak...@antwebsystems.com>><javascript:;>>wrote:+1 On 15/06/16 13:30, Ashish Vijaywargiya wrote:I would prefer to keep Tax and Third Party Payment gateway files(Thefilesthat does exists inside cybersource, ideal, orbital, paypal, securepay, verisign etc). If you see some problems in those code base, like codebaseis not updated based on latest changes then we can update thosefiles.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 shouldnotremove those files. -- Kind Regards Ashish Vijaywargiya HotWax Systems - est. 1997 On Tue, Jun 14, 2016 at 7:40 PM, Taher Alkhateeb < slidingfilame...@gmail.com <javascript:;>wrote:Hi Everyone,I cannot actually believe it but while I was working on a project (Iwillannounce 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 trunkapplications/accounting/src/org/ofbiz/accounting/thirdparty/cyberso urc e/IcsPaymentServices.javaapplications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/I dea lEvents.javaapplications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/I dea lPaymentServiceTest.javaapplications/accounting/src/org/ofbiz/accounting/thirdparty/orbital /Or bitalPaymentServices.javaapplications/accounting/src/org/ofbiz/accounting/thirdparty/paypal/ Pay PalServices.javaapplications/accounting/src/org/ofbiz/accounting/thirdparty/securep ay/ SecurePayPaymentServices.javaapplications/accounting/src/org/ofbiz/accounting/thirdparty/securep ay/ SecurePayServiceTest.javaapplications/accounting/src/org/ofbiz/accounting/thirdparty/verisig n/P ayflowPro.javaapplications/content/src/org/ofbiz/content/openoffice/OpenOfficeByt eAr rayInputStream.javaapplications/content/src/org/ofbiz/content/openoffice/OpenOfficeByt eAr rayOutputStream.javaapplications/content/src/org/ofbiz/content/openoffice/OpenOfficeSer vic es.javaapplications/content/src/org/ofbiz/content/openoffice/OpenOfficeWor ker .javaapplications/content/src/org/ofbiz/content/reportapplications/content/src/org/ofbiz/content/report/JREntityListItera tor DataSource.javaapplications/content/src/org/ofbiz/content/report/JRMapCollectionDa taS ource.javaapplications/order/src/org/ofbiz/order/thirdparty/taxwareapplications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareEx cep tion.javaapplications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareSe rvi ces.java applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareUT L.j avaapplications/product/src/ShipmentScaleApplet.javaapplications/securityext/src/org/ofbiz/securityext/thirdparty/truit ion /TruitionCoReg.javaframework/webapp/src/org/ofbiz/webapp/view/JasperReportsJXlsViewHan dle r.javaframework/webapp/src/org/ofbiz/webapp/view/JasperReportsPdfViewHand ler .javaframework/webapp/src/org/ofbiz/webapp/view/JasperReportsPoiXlsViewH and ler.javaframework/webapp/src/org/ofbiz/webapp/view/JasperReportsXmlViewHand ler .javaRegards, Taher Alkhateeb-- Regards, Hans Bakker CEO, http://antwebsystems.com-- Mridul Pathak Senior Manager HotWax Systems http://www.hotwaxsystems.com direct: +91-942592692
