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
>>>>
>>>>
>>
>>
>

Reply via email to