Re: Proposal to delete stale java files

Hi Taher, Yes, I think it’s the right time for the movement. Below are the JIRA ticket links for the overall work discussed in this thread. Delete stale java files from applications and framework Move 3rd party payment integrations from

Re: Proposal to delete stale java files

I see, if that is the case then we should continue disabling them but do so in the components' own build.gradle file to make the build cleaner. On Wed, Jul 27, 2016 at 3:58 PM, Jacopo Cappellato < jacopo.cappell...@hotwaxsystems.com> wrote: > Hmmm... not sure about this because jars with

Re: Proposal to delete stale java files

Hmmm... not sure about this because jars with incompatible licenses should not be required to build a release. Jacopo On Wed, Jul 27, 2016 at 2:18 PM, Taher Alkhateeb wrote: > Actually, I think you can also enable these files and declare whatever > proprietary

Re: Proposal to delete stale java files

Actually, I think you can also enable these files and declare whatever proprietary libraries you need since they will be pulled from an external repository, please correct me if I'm wrong anyone I'm not the best guy to speak legalese in here. On Wed, Jul 27, 2016 at 3:07 PM, Taher Alkhateeb

Re: Proposal to delete stale java files

Hi Mridul, Everyone, Now that we have a stable running build, perhaps it's time to move forward with this discussion? All the excluded java files are listed in the master build.gradle. If you move them to specialpurpose we can figure out a simple solution to hide these exclusions away from the

Re: Proposal to delete stale java files

This needs to be carefully reviewed indeed (I did not yet) Jacques Le 18/06/2016 à 13:00, Pierre Smits a écrit : I agree that there are common patterns. And the common patterns should be in the base component, to enable the payment and shipment solution integrations. These integration

Re: Proposal to delete stale java files

I agree that there are common patterns. And the common patterns should be in the base component, to enable the payment and shipment solution integrations. These integration solutions should be optional when implementing an OFBiz setup. An example please evaluate the MultiSafepay integration

Re: Proposal to delete stale java files

Creating payment/shipping/tax solution specific components would introduce 17 new components to specialpurpose and that doesn’t seems like a favorable approach. These integrations usually share a common code pattern and in longer vision we could possibly implement payment/shipping integration

Re: Proposal to delete stale java files

Hi all, Moving all 3rd party related integrations solutions from accounting, product and order into 1 special purpose component makes is worse to maintain. Moving those from accounting into one in special purpose, those from product into one and those from order into another just shifts the

Re: Proposal to delete stale java files

+1 thank you for your dedication and thinking of this On Jun 16, 2016 8:55 PM, "Mridul Pathak" wrote: > Hi Taher, > > I was just trying to suggest that we will have to create two components in > specialpurpose, one for payment processor related functionality and

Re: Proposal to delete stale java files

Hi Taher, I was just trying to suggest that we will have to create two components in specialpurpose, one for payment processor related functionality and one for tax related functionality and the reason behind it. Which means we should probably drop the idea of introducing a directory named

Re: Proposal to delete stale java files

Hi Mridul, Thank you for the detailed and well thought out feedback. I am a little confused however, what is the point you are trying to state? The only point from my previous email was to suggest avoiding creating a directory called reference in the top level ofbiz directory and instead keep it

Re: Proposal to delete stale java files

Hi Taher, Payment integration files in accounting/thirdparty are not just unused files and all of it is not dead code. There is the whole functionality built around those files which is very crucial to production delivery of order management or ecommerce on top of OFBiz. There are many service

Re: Proposal to delete stale java files

Hey Folks, I would prefer to keep dead code away from the top level OFBiz directory. If you keep it there then you make it _closer_ to the framework! Anyway, I don't see a problem with keeping it in specialpurpose! You are not creating a component, you are just creating a folder called reference

Re: Proposal to delete stale java files

Introducing new directory “reference” seems reasonable approach to me as it is a combined solution to everyone’s views. -- Thanks & Regards, Mridul Pathak Senior Manager HotWax Systems http://www.hotwaxsystems.com > On Jun 16, 2016, at 5:56 PM, Jacques Le Roux >

Re: Proposal to delete stale java files

Hi Divesh, Le 16/06/2016 à 13:38, Divesh Dutta a écrit : 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

Re: Proposal to delete stale java files

l 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

Re: Proposal to delete stale java files

com] Sent: 15 June 2016 14:19 To: dev@ofbiz.apache.org 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

Re: Proposal to delete stale java files

rds, > >> > >> Pierre Smits > >> > >> ORRTIZ.COM <http://www.orrtiz.com> > >> OFBiz based solutions & services > >> > >> OFBiz Extensions Marketplace > >> http://oem.ofbizci.net/oci-2/ > >> > >> On Wed,

Re: Proposal to delete stale java files

t;> 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, >>> >>> -O

Re: Proposal to delete stale java files

ent: 15 June 2016 14:19 To: dev@ofbiz.apache.org 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 hav

Re: Proposal to delete stale java files

pat...@hotwaxsystems.com] > Sent: 15 June 2016 14:19 > To: dev@ofbiz.apache.org > 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 t

RE: Proposal to delete stale java files

@ofbiz.apache.org 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

Re: Proposal to delete stale java files

ent from >> the build system. >>> >>> Thank you all again for your contributions. >>> >>> Taher Alkhateeb >>> >>> -Original Message- >>> From: Mridul Pathak [mailto:mridul.pat...@hotwaxsystems.com >>> <mailto:mridul.

Re: Proposal to delete stale java files

Nicely said, thanks Sharan :) Jacques Le 15/06/2016 à 09:14, Sharan Foga a écrit : Hi Everyone If we don't compromise on this then we are going to make the re-factoring effort that Taher is driving even harder. If we want to clean the code base (and I really think we do) then we need to take

Re: Proposal to delete stale java files

gain for your contributions. > > > > Taher Alkhateeb > > > > -Original Message- > > From: Mridul Pathak [mailto:mridul.pat...@hotwaxsystems.com mridul.pat...@hotwaxsystems.com>] > > Sent: 15 June 2016 11:09 > > To: dev@ofbiz.apache.org <m

Re: Proposal to delete stale java files

To: dev@ofbiz.apache.org <mailto:dev@ofbiz.apache.org> > 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 Pa

RE: Proposal to delete stale java files

] Sent: 15 June 2016 11:09 To: dev@ofbiz.apache.org 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

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 < jacopo.cappell...@hotwaxsystems.com> wrote: > Based on the new comments it seems like that we could isolate the shipment,

Re: Proposal to delete stale java files

Yea this makes sense to not to completely delete those thirty party integration files and move them to special purpose (and make them pluggable in future with better architechture). So +1 for this proposal. Thanks -- Divesh Dutta. On Wed, Jun 15, 2016 at 1:27 PM, Jacopo Cappellato <

Re: Proposal to delete stale java files

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

Re: Proposal to delete stale java files

+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

Re: Proposal to delete stale java files

That's indeed the way it should be done, waiting for a way to have real addons support in OFBiz. Then OFBiz will be able to compete with its open source concurrents, notably and mostly Oddo when we speak about addons. Jacques Le 15/06/2016 à 09:01, Mridul Pathak a écrit : Yes,

Re: Proposal to delete stale java files

Hi Everyone If we don't compromise on this then we are going to make the re-factoring effort that Taher is driving even harder. If we want to clean the code base (and I really think we do) then we need to take the some hard decisions. I'm sure that this won't be the last discussion over code

Re: Proposal to delete stale java files

Yes, accounting/thirdparty has all the third party payment integrations supported by OFBiz. And, order/thridparty seems to have third party tax integration. We should not be deleting these files. I think we should refactor these third party integration files, and move these integrations to

Re: Proposal to delete stale java files

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

Re: Proposal to delete stale java files

Hi Taher, I am not sure about other Java files if they are heavily used or not, but PayPalServices.java and PayflowPro.java are the two files which I think lots of people use. So, I will recommend keeping them. If needed we can talk on problems in this file, and fix them. Thanks -- Divesh Dutta.

Re: Proposal to delete stale java files

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 <

Re: Proposal to delete stale java files

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

Re: Proposal to delete stale java files

The point is the Attic is only documenting things which are removed but still in the repo (in the past) https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Attic Jacques Le 14/06/2016 à 19:19, Taher Alkhateeb a écrit : Hi Jacques Pierre and everyone, OFBiz suffers from code

Re: Proposal to delete stale java files

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

Re: Proposal to delete stale java files

+1 Exactly what the project needs. Code hoarding is a big issue whenever "old programmers" get together (me included). We know that it is actually saved in the SCM but we remember the old days before SCM when hoarding made sense. Clear out anything that does not compile or does not get

Re: Proposal to delete stale java files

Hi Jacques Pierre and everyone, OFBiz suffers from code hoarding. A LOT of that code is badly written, non functional, or just a bare minimum POC. Thinking of OFBiz as full of features that would shrink is not very realistic, here is why: - If it was broken for years, then nobody is using it

Re: Proposal to delete stale java files

Yes indeed, IIRW we crossed that with Ideal to Attic action and that's why it's still waiting, not as simple as it looks Jacques Le 14/06/2016 à 19:01, Pierre Smits a écrit : As the majority of the referenced java files are related to 3rd party solutions integrations, we should have done the

Re: Proposal to delete stale java files

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

Re: Proposal to delete stale java files

This is now mostly history and I agree we should get rid of them if nobody complains. The best place for them would be Attic as we use to do and mentioned by Pierre for Ideal. I'd though like to keep the ShipmentScaleApplet.java file (blocked by NPL licence). Because, though I never used it

Re: Proposal to delete stale java files

I don't know if we should keep them, I don't have a strong opinion but if we decide to keep them they should be maintained and updated (otherwise they should go): my comment was simply to add some background. Jacopo On Tue, Jun 14, 2016 at 4:22 PM, Taher Alkhateeb

Re: Proposal to delete stale java files

Taher, all, With respect to the /thirdparty/ideal functionality there already JIRA issues registered (https://issues.apache.org/jira/browse/OFBIZ-5303, etc). Best regards, Pierre Smits ORRTIZ.COM OFBiz based solutions & services OFBiz Extensions Marketplace

Re: Proposal to delete stale java files

Hi Jacopo, Does that mean we should keep them? Mind you some of them have incorrect code (not importing EntityQuery for example). I'm not sure we want to keep dead code in trunk, unless people are using it? Regards, Taher Alkhateeb On Tue, Jun 14, 2016 at 5:18 PM, Jacopo Cappellato <

Re: Proposal to delete stale java files

Hi Taher, some background: these classes depends on jar files that have an incompatible license that cannot be distributed with OFBiz; that is why they are there but they are not built. Jacopo On Tue, Jun 14, 2016 at 4:10 PM, Taher Alkhateeb wrote: > Hi Everyone,