On Thu, Jun 16, 2016 at 4:45 PM, Jacques Le Roux <
[email protected]> wrote:
> Le 16/06/2016 à 12:41, Taher Alkhateeb a écrit :
>
>> 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
>>
> +1
>
>> 2- Keep peripheral or non-core functionality away from framework and core
>> applications.
>>
> +1
+1 for above points.
>
> 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.
>>
> I agree and I think your initial proposition ("How about
> reference/paymentext and reference/whatever-else-you-want?") was not
> clearly understood by Pierre and maybe not Divesh. Pierre, Divesh?
>
Actually Jacques, we cannot create component like
specialpurpose/reference/paymentext . Other way can be we introduce new
directory "reference" in parallel to specialpurpose, applications ,
framework . Do you mean to do that ?
Also as Mridul put it, and you agreed, the "shipping integration/s" which
> "doesn’t have the compilation or library reference issues" would be in its
> own independent component/s (ie not under /reference), same for other stuff
> with the same status, if exist.
In this case, shipping integration can be under special purpose. So
specialpurpose/shippingIntegratio.
Thanks
--
Divesh Dutta.
>
>
> Jacques
>
> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>
>
