Re: Proposal to delete stale java files

[Jacques Le Roux]

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

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 <
divesh.du...@hotwaxsystems.com> 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 <
jacques.le.r...@les7arts.com> 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 <
slidingfilame...@gmail.com

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:mridul.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 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 <
slidingfilame...@gmail.com
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 <
mridul.pat...@hotwaxsystems.com <mailto:
mridul.pat...@hotwaxsystems.com
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
<slidingfilame...@gmail.com>

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:mridul.pat...@hotwaxsystems.com
<mailto:
mridul.pat...@hotwaxsystems.com> <mailto:
mridul.pat...@hotwaxsystems.com
<mailto:mridul.pat...@hotwaxsystems.com>>]

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

On Wednesday 15 June 2016, Jacopo Cappellato <

jacopo.cappell...@hotwaxsystems.com <mailto:

jacopo.cappell...@hotwaxsystems.com>> 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
<h.bak...@antwebsystems.com <mailto:h.bak...@antwebsystems.com>
<mailto:h.bak...@antwebsystems.com
<mailto:h.bak...@antwebsystems.com>>

<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 <
slidingfilame...@gmail.com <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