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 < [email protected]> 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 < >> [email protected] >> >>> 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:[email protected]] >>> Sent: 15 June 2016 14:19 >>> To: [email protected] >>> 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 <[email protected] >>>> > >>>> >>> 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 < >>>> [email protected] <mailto:[email protected] >>>> >> >>>> >>> 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 >>>>>> <[email protected]> >>>>>> >>>>> 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:[email protected] <mailto: >>>>>> >>>>> [email protected]> <mailto: >>> >>>> [email protected] >>>>> <mailto:[email protected]>>] >>>>> >>>>>> Sent: 15 June 2016 11:09 >>>>>> To: [email protected] <mailto:[email protected]> >>>>>> <mailto:[email protected] <mailto:[email protected]>> >>>>>> 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 < >>>>>> >>>>> [email protected] <mailto: >>>>> >>>> [email protected]>> 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 >>>>>>> <[email protected] <mailto:[email protected]> >>>>>>> <mailto:[email protected] >>>>>>> <mailto:[email protected]>> >>>>>>> >>>>>> <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 < >>>>>>>>> [email protected] <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 >>>>>> >>>>> >>> >>> >
