This is an interesting conversation; removing the classes (and the artifacts that use them) and documenting the removal in our Attic page for history and future reference seems to me a good compromise for the various point of views.
Jacopo On Tue, Jun 14, 2016 at 11:34 PM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > Le 14/06/2016 à 19:56, Ron Wheeler a écrit : > >> Poorly documented, non-functioning code is not an attractive feature that >> will draw new users. >> >> If there are pieces that are being removed that you think are worth >> remembering, write a wiki note (it can be searched by Google) documenting >> these partially implemented features that can be recovered from the SCM if >> anyone cares in the future. >> >> The attic is a compromise to make hoarders feel comfortable but putting >> junk in the attic with no documentation about why things were written, why >> they are not finished or currently not used, is of questionable value. >> Non-functioning code that may be written to older standards or, worse yet, >> bad programming practices is just dangerous. >> > > Better than throwing the baby with the bathwater, as we say in French (in > other words remove without any mentions but in the commit log, good luck to > find anything there). You never know and would be surprised by what can > happen sometimes... > > >> Is anyone willing to QC the code placed in the attic? >> > > This could happen, again who knows and who can say better? We all know we > have limited capable resources. > > Jacques > > >> Ron >> >> >> On 14/06/2016 1:01 PM, Pierre Smits wrote: >> >>> As the majority of the referenced java files are related to 3rd party >>> solutions integrations, we should have done the smart thing and that is >>> provide them as optional Proof of Concept components. In stead we >>> had/have >>> them as almost hard coded functionalities. Removing these from the code >>> base in trunk involves more. It means also removing the elements that >>> access these (directly and indirectly), including screen and form >>> widgets, >>> templates, services and request and view map uris. >>> >>> But if we remove them from the code base (to the attic), before long the >>> knowledge will be lost and the feature set of OFBiz will shrink. Some may >>> not care about that, but it will - again - make the uphill adoption >>> battle >>> more difficult. >>> >>> Best regards, >>> >>> Pierre Smits >>> >>> ORRTIZ.COM <http://www.orrtiz.com> >>> OFBiz based solutions & services >>> >>> OFBiz Extensions Marketplace >>> http://oem.ofbizci.net/oci-2/ >>> >>> On Tue, Jun 14, 2016 at 4:10 PM, Taher Alkhateeb < >>> slidingfilame...@gmail.com >>> >>>> wrote: >>>> Hi Everyone, >>>> >>>> I cannot actually believe it but while I was working on a project (I >>>> will >>>> announce later) I discovered in the process that the below files cannot >>>> compile!!! They existed for years in the code base without even being >>>> able >>>> to compile. They reference non existent libraries or they have faulty >>>> code >>>> (e.g. not importing used code) >>>> >>>> I propose to delete them immediately from trunk >>>> >>>> >>>> >>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/cybersource/IcsPaymentServices.java >>>> >>>> >>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealEvents.java >>>> >>>> >>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealPaymentServiceTest.java >>>> >>>> >>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/orbital/OrbitalPaymentServices.java >>>> >>>> >>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/paypal/PayPalServices.java >>>> >>>> >>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayPaymentServices.java >>>> >>>> >>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayServiceTest.java >>>> >>>> >>>> applications/accounting/src/org/ofbiz/accounting/thirdparty/verisign/PayflowPro.java >>>> >>>> >>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayInputStream.java >>>> >>>> >>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayOutputStream.java >>>> >>>> >>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeServices.java >>>> >>>> applications/content/src/org/ofbiz/content/openoffice/OpenOfficeWorker.java >>>> applications/content/src/org/ofbiz/content/report >>>> >>>> >>>> applications/content/src/org/ofbiz/content/report/JREntityListIteratorDataSource.java >>>> >>>> >>>> applications/content/src/org/ofbiz/content/report/JRMapCollectionDataSource.java >>>> applications/order/src/org/ofbiz/order/thirdparty/taxware >>>> >>>> >>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareException.java >>>> >>>> >>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareServices.java >>>> >>>> applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareUTL.java >>>> applications/product/src/ShipmentScaleApplet.java >>>> >>>> >>>> applications/securityext/src/org/ofbiz/securityext/thirdparty/truition/TruitionCoReg.java >>>> >>>> >>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsJXlsViewHandler.java >>>> >>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPdfViewHandler.java >>>> >>>> >>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPoiXlsViewHandler.java >>>> >>>> framework/webapp/src/org/ofbiz/webapp/view/JasperReportsXmlViewHandler.java >>>> >>>> Regards, >>>> >>>> Taher Alkhateeb >>>> >>>> >> >> >