Renaming AccountingConfig.properties file to accounting.properties

[Pierre Smits]

Hi All,

In the accounting component we have in the config folder the
AccountingConfig.properties file. This file contains 6 settings that are
used in accounting (of course), order and product. These settings are
referenced 16 times in other files.

In relation to OFBIZ-6164 <https://issues.apache.org/jira/browse/OFBIZ-6164>
I would like to change this file name into 'accounting.properties' to bring
it more in line with how other component generic properties files are
named, which seems to be in following convention:

<applicationname>.properties


Example of that convention are: content.properties, catalog.properties,
sfa.properties

What do you think?

Best regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

[Pierre Smits]

The same can be applied to the following .properties files:


   - in applications stack
      - securityext: truition.properties -> securityext.properties
      - workeffort: workeffortsearch.properties -> workeffort.properties
   - in special purpose stack
      - ebay: ebayExport.properties -> ebay.properties
      - ebaystore: EbayStore.properties -> ebaystore.properties
      - googlebase: googleBaseExport.properties -> googlebase.properties
      - googlecheckout: googleCheckout.properties ->
      googlecheckout.properties
      - lucene: search.properties -> lucene.properties
      - pos: parameters.properties -> pos.properties
      - scrum: revision.properties -> scrum.properties

Best regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

[Nicolas Malin-2]

This make sense and I like each element that homogenize OFBiz ;)

But I propose to keep old file with deprecated information.

# Dear developper, this file is now deprecated plus use
component.properties instead of. Own apologies for all inconvenience

Nicolas

Le 20/03/2015 15:03, Pierre Smits a écrit :

> The same can be applied to the following .properties files:
>
>
>     - in applications stack
>        - securityext: truition.properties -> securityext.properties
>        - workeffort: workeffortsearch.properties -> workeffort.properties
>     - in special purpose stack
>        - ebay: ebayExport.properties -> ebay.properties
>        - ebaystore: EbayStore.properties -> ebaystore.properties
>        - googlebase: googleBaseExport.properties -> googlebase.properties
>        - googlecheckout: googleCheckout.properties ->
>        googlecheckout.properties
>        - lucene: search.properties -> lucene.properties
>        - pos: parameters.properties -> pos.properties
>        - scrum: revision.properties -> scrum.properties
>
> Best regards,
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>

[Pierre Smits]

Nicolas,

Keeping the old file in doesn't exactly make sense. We use SVN to track
changes, and with issues registered in JIRA we can report in an easy manner
what kind of changes are effected in a release.

If we do this in a case-by-case (or per file) way, we make the change
visible. And it will surely come in play when people are considering
upgrading to a new major release.
Please keep in mind, this is an improvement. Thus not intended to go into
releases of current running release branches (12.x, 13,x). It could go in
r14.x, but that is not up to me.

Best regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Fri, Mar 20, 2015 at 9:05 PM, Nicolas Malin <[hidden email]>
wrote:

> This make sense and I like each element that homogenize OFBiz ;)
>
> But I propose to keep old file with deprecated information.
>
> # Dear developper, this file is now deprecated plus use
> component.properties instead of. Own apologies for all inconvenience
>
> Nicolas
>
> Le 20/03/2015 15:03, Pierre Smits a écrit :
>
>> The same can be applied to the following .properties files:
>>
>>
>>     - in applications stack
>>        - securityext: truition.properties -> securityext.properties
>>        - workeffort: workeffortsearch.properties -> workeffort.properties
>>     - in special purpose stack
>>        - ebay: ebayExport.properties -> ebay.properties
>>        - ebaystore: EbayStore.properties -> ebaystore.properties
>>        - googlebase: googleBaseExport.properties -> googlebase.properties
>>        - googlecheckout: googleCheckout.properties ->
>>        googlecheckout.properties
>>        - lucene: search.properties -> lucene.properties
>>        - pos: parameters.properties -> pos.properties
>>        - scrum: revision.properties -> scrum.properties
>>
>> Best regards,
>>
>> Pierre Smits
>>
>> *ORRTIZ.COM <http://www.orrtiz.com>*
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
>>
>>
>

[Jacques Le Roux]

When there are no confusions, that sounds good to me. I see no reasons why securityext properties file should be named truition.properties!

  Jacques

Le 20/03/2015 15:03, Pierre Smits a écrit :

> The same can be applied to the following .properties files:
>
>
>     - in applications stack
>        - securityext: truition.properties -> securityext.properties
>        - workeffort: workeffortsearch.properties -> workeffort.properties
>     - in special purpose stack
>        - ebay: ebayExport.properties -> ebay.properties
>        - ebaystore: EbayStore.properties -> ebaystore.properties
>        - googlebase: googleBaseExport.properties -> googlebase.properties
>        - googlecheckout: googleCheckout.properties ->
>        googlecheckout.properties
>        - lucene: search.properties -> lucene.properties
>        - pos: parameters.properties -> pos.properties
>        - scrum: revision.properties -> scrum.properties
>
> Best regards,
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>

[Pierre Smits]

We'll have to discuss it on a case by case scenario when it comes to that.
One potential I see is related to the pos component. In the start component
in the framework stack there is already pos.properties file.

Best regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Sat, Mar 21, 2015 at 6:05 PM, Jacques Le Roux <
[hidden email]> wrote:

> When there are no confusions, that sounds good to me. I see no reasons why
> securityext properties file should be named truition.properties!
>
>  Jacques
>
> Le 20/03/2015 15:03, Pierre Smits a écrit :
>
>> The same can be applied to the following .properties files:
>>
>>
>>     - in applications stack
>>        - securityext: truition.properties -> securityext.properties
>>        - workeffort: workeffortsearch.properties -> workeffort.properties
>>     - in special purpose stack
>>        - ebay: ebayExport.properties -> ebay.properties
>>        - ebaystore: EbayStore.properties -> ebaystore.properties
>>        - googlebase: googleBaseExport.properties -> googlebase.properties
>>        - googlecheckout: googleCheckout.properties ->
>>        googlecheckout.properties
>>        - lucene: search.properties -> lucene.properties
>>        - pos: parameters.properties -> pos.properties
>>        - scrum: revision.properties -> scrum.properties
>>
>> Best regards,
>>
>> Pierre Smits
>>
>> *ORRTIZ.COM <http://www.orrtiz.com>*
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
>>
>>

[Jacques Le Roux]

Yes there might be special cases, the POS is one of them indeed. We could certainly rename parameters.properties (the others should not change) to
pos.properties, but not sure it's worth it.
Exceptions should not prevent us to move forward, but when you think about it; renaming properties files according to components names is not a
priority...

Instead of diluting our scarce forces, we should try 1st to correctly identify the priorities and stick to them as a community.
This is something I have pesonaly some difficulties to do. So I guess it's even harder for a community. We should always think about that w/o
neglecting the minor things.

One rule I found to work not so bad for me is the 2 minutes rule. If you can do it in 2 minutes, don't delay or plan it, do it right away.
I have just pushed the 2 minutes to 10. You can barely do something serious in a project like OFBiz in 2 minutes! Of course you can't also do 10
mintues tasks all the day ;)

If nobody is against the idea, we should create an improvement Jira issue and set it as trivial. We will then corner the edge cases, like the POS you
spotted, there.

Jacques

Le 21/03/2015 20:28, Pierre Smits a écrit :

> We'll have to discuss it on a case by case scenario when it comes to that.
> One potential I see is related to the pos component. In the start component
> in the framework stack there is already pos.properties file.
>
> Best regards,
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Sat, Mar 21, 2015 at 6:05 PM, Jacques Le Roux <
> [hidden email]> wrote:
>
>> When there are no confusions, that sounds good to me. I see no reasons why
>> securityext properties file should be named truition.properties!
>>
>>   Jacques
>>
>> Le 20/03/2015 15:03, Pierre Smits a écrit :
>>
>>> The same can be applied to the following .properties files:
>>>
>>>
>>>      - in applications stack
>>>         - securityext: truition.properties -> securityext.properties
>>>         - workeffort: workeffortsearch.properties -> workeffort.properties
>>>      - in special purpose stack
>>>         - ebay: ebayExport.properties -> ebay.properties
>>>         - ebaystore: EbayStore.properties -> ebaystore.properties
>>>         - googlebase: googleBaseExport.properties -> googlebase.properties
>>>         - googlecheckout: googleCheckout.properties ->
>>>         googlecheckout.properties
>>>         - lucene: search.properties -> lucene.properties
>>>         - pos: parameters.properties -> pos.properties
>>>         - scrum: revision.properties -> scrum.properties
>>>
>>> Best regards,
>>>
>>> Pierre Smits
>>>
>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>> Services & Solutions for Cloud-
>>> Based Manufacturing, Professional
>>> Services and Retail & Trade
>>> http://www.orrtiz.com
>>>
>>>

[Nicolas Malin-2]

I know for the svn, it's not the problem.
I prefer keep the deprecated file on branch 14.x and remove them on the
next stable candidate branch.
It leaves the time to production site to adapt their patch.

Nicolas

Le 21/03/2015 00:42, Pierre Smits a écrit :

> Nicolas,
>
> Keeping the old file in doesn't exactly make sense. We use SVN to track
> changes, and with issues registered in JIRA we can report in an easy manner
> what kind of changes are effected in a release.
>
> If we do this in a case-by-case (or per file) way, we make the change
> visible. And it will surely come in play when people are considering
> upgrading to a new major release.
> Please keep in mind, this is an improvement. Thus not intended to go into
> releases of current running release branches (12.x, 13,x). It could go in
> r14.x, but that is not up to me.
>
> Best regards,
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
> Le 21/03/2015 00:42, Pierre Smits a écrit :
>> Nicolas,
>>
>> Keeping the old file in doesn't exactly make sense. We use SVN to track
>> changes, and with issues registered in JIRA we can report in an easy manner
>> what kind of changes are effected in a release.
>>
>> If we do this in a case-by-case (or per file) way, we make the change
>> visible. And it will surely come in play when people are considering
>> upgrading to a new major release.
>> Please keep in mind, this is an improvement. Thus not intended to go into
>> releases of current running release branches (12.x, 13,x). It could go in
>> r14.x, but that is not up to me.
>>
>> Best regards,
>>
>> Pierre Smits
>>
>> *ORRTIZ.COM <http://www.orrtiz.com>*
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
>>
>> On Fri, Mar 20, 2015 at 9:05 PM, Nicolas Malin <[hidden email]>
>> wrote:
>>
>>> This make sense and I like each element that homogenize OFBiz ;)
>>>
>>> But I propose to keep old file with deprecated information.
>>>
>>> # Dear developper, this file is now deprecated plus use
>>> component.properties instead of. Own apologies for all inconvenience
>>>
>>> Nicolas
>>>
>>> Le 20/03/2015 15:03, Pierre Smits a écrit :
>>>
>>>> The same can be applied to the following .properties files:
>>>>
>>>>
>>>>      - in applications stack
>>>>         - securityext: truition.properties -> securityext.properties
>>>>         - workeffort: workeffortsearch.properties -> workeffort.properties
>>>>      - in special purpose stack
>>>>         - ebay: ebayExport.properties -> ebay.properties
>>>>         - ebaystore: EbayStore.properties -> ebaystore.properties
>>>>         - googlebase: googleBaseExport.properties -> googlebase.properties
>>>>         - googlecheckout: googleCheckout.properties ->
>>>>         googlecheckout.properties
>>>>         - lucene: search.properties -> lucene.properties
>>>>         - pos: parameters.properties -> pos.properties
>>>>         - scrum: revision.properties -> scrum.properties
>>>>
>>>> Best regards,
>>>>
>>>> Pierre Smits
>>>>
>>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>>> Services & Solutions for Cloud-
>>>> Based Manufacturing, Professional
>>>> Services and Retail & Trade
>>>> Le 21/03/2015 00:42, Pierre Smits a écrit :
>>>>> Nicolas,
>>>>>
>>>>> Keeping the old file in doesn't exactly make sense. We use SVN to track
>>>>> changes, and with issues registered in JIRA we can report in an easy manner
>>>>> what kind of changes are effected in a release.
>>>>>
>>>>> If we do this in a case-by-case (or per file) way, we make the change
>>>>> visible. And it will surely come in play when people are considering
>>>>> upgrading to a new major release.
>>>>> Please keep in mind, this is an improvement. Thus not intended to go into
>>>>> releases of current running release branches (12.x, 13,x). It could go in
>>>>> r14.x, but that is not up to me.
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Pierre Smits
>>>>>
>>>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>>>> Services & Solutions for Cloud-
>>>>> Based Manufacturing, Professional
>>>>> Services and Retail & Trade
>>>>> http://www.orrtiz.com
>>>>>
>>>>> On Fri, Mar 20, 2015 at 9:05 PM, Nicolas Malin <[hidden email]>
>>>>> wrote:
>>>>>
>>>>>> This make sense and I like each element that homogenize OFBiz ;)
>>>>>>
>>>>>> But I propose to keep old file with deprecated information.
>>>>>>
>>>>>> # Dear developper, this file is now deprecated plus use
>>>>>> component.properties instead of. Own apologies for all inconvenience
>>>>>>
>>>>>> Nicolas
>>>>>>
>>>>>> Le 20/03/2015 15:03, Pierre Smits a écrit :
>>>>>>
>>>>>>> The same can be applied to the following .properties files:
>>>>>>>
>>>>>>>
>>>>>>>      - in applications stack
>>>>>>>         - securityext: truition.properties -> securityext.properties
>>>>>>>         - workeffort: workeffortsearch.properties -> workeffort.properties
>>>>>>>      - in special purpose stack
>>>>>>>         - ebay: ebayExport.properties -> ebay.properties
>>>>>>>         - ebaystore: EbayStore.properties -> ebaystore.properties
>>>>>>>         - googlebase: googleBaseExport.properties -> googlebase.properties
>>>>>>>         - googlecheckout: googleCheckout.properties ->
>>>>>>>         googlecheckout.properties
>>>>>>>         - lucene: search.properties -> lucene.properties
>>>>>>>         - pos: parameters.properties -> pos.properties
>>>>>>>         - scrum: revision.properties -> scrum.properties
>>>>>>>
>>>>>>> Best regards,
>>>>>>>
>>>>>>> Pierre Smits
>>>>>>>
>>>>>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>>>>>> Services & Solutions for Cloud-
>>>>>>> Based Manufacturing, Professional
>>>>>>> Services and Retail & Trade
>>>>>>> http://www.orrtiz.com
>>>>>>>
>>>>>>>
>>>> http://www.orrtiz.com
>>>>
>>>>
>
> On Fri, Mar 20, 2015 at 9:05 PM, Nicolas Malin <[hidden email]>
> wrote:
>
>> This make sense and I like each element that homogenize OFBiz ;)
>>
>> But I propose to keep old file with deprecated information.
>>
>> # Dear developper, this file is now deprecated plus use
>> component.properties instead of. Own apologies for all inconvenience
>>
>> Nicolas
>>
>> Le 20/03/2015 15:03, Pierre Smits a écrit :
>>
>>> The same can be applied to the following .properties files:
>>>
>>>
>>>      - in applications stack
>>>         - securityext: truition.properties -> securityext.properties
>>>         - workeffort: workeffortsearch.properties -> workeffort.properties
>>>      - in special purpose stack
>>>         - ebay: ebayExport.properties -> ebay.properties
>>>         - ebaystore: EbayStore.properties -> ebaystore.properties
>>>         - googlebase: googleBaseExport.properties -> googlebase.properties
>>>         - googlecheckout: googleCheckout.properties ->
>>>         googlecheckout.properties
>>>         - lucene: search.properties -> lucene.properties
>>>         - pos: parameters.properties -> pos.properties
>>>         - scrum: revision.properties -> scrum.properties
>>>
>>> Best regards,
>>>
>>> Pierre Smits
>>>
>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>> Services & Solutions for Cloud-
>>> Based Manufacturing, Professional
>>> Services and Retail & Trade
>>> http://www.orrtiz.com
>>>
>>>