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 < [email protected]> 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 < > [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 > >>>>>> > >>>>> > >>> > >>> > > >
