Re: svn commit: r1804224 - /ofbiz/ofbiz-plugins/trunk/birt/src/main/java/org/apache/ofbiz/birt/flexible/BirtUtil.java

2017-08-06 Thread Aditya Sharma
Pardon me for the typo *Deepak

Thanks and Regards,

*Aditya Sharma* | Enterprise Software Engineer
HotWax Systems 


On Sun, Aug 6, 2017 at 1:01 PM, Aditya Sharma  wrote:

> Hi Depak,
>
> I think we can just remove these lines instead of replacing them as these
> field types are already mapped with Birt data type & got redundant now.
>
> private final static Map entityFieldTypeBirtTypeMap =
> MapUtils.unmodifiableMap(UtilMisc.toMap(
> *"id", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,*
> "url", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
> "name", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
> *"id", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,*
> "value", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
> "email", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
> "comment", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
> *"id-long",DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,*
> *"id-vlong", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,*
> "very-long", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
> "indicator", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
> "very-short", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
> "tel-number", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
> *"id-long", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,*
> *"id-vlong", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,*
> "description", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
> "long-varchar", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
> "short-varchar", DesignChoiceConstants.COLUMN_D
> ATA_TYPE_STRING,
> "credit-card-date", DesignChoiceConstants.COLUMN_D
> ATA_TYPE_STRING,
> "credit-card-number", DesignChoiceConstants.COLUMN_D
> ATA_TYPE_STRING,
> "date-time", DesignChoiceConstants.COLUMN_DATA_TYPE_DATETIME,
> "date", DesignChoiceConstants.COLUMN_DATA_TYPE_DATE,
> "time", DesignChoiceConstants.COLUMN_DATA_TYPE_TIME,
> "currency-amount", DesignChoiceConstants.COLUMN_D
> ATA_TYPE_DECIMAL,
> "currency-precise", DesignChoiceConstants.COLUMN_D
> ATA_TYPE_DECIMAL,
> "fixed-point", DesignChoiceConstants.COLUMN_DATA_TYPE_DECIMAL,
> "floating-point", DesignChoiceConstants.COLUMN_D
> ATA_TYPE_DECIMAL,
> "numeric", DesignChoiceConstants.COLUMN_DATA_TYPE_INTEGER,
> "object", DesignChoiceConstants.COLUMN_DATA_TYPE_JAVA_OBJECT,
> "blob", DesignChoiceConstants.COLUMN_DATA_TYPE_BLOB));
>
> Thanks and Regards,
>
> *Aditya Sharma* | Enterprise Software Engineer
> HotWax Systems 
> 
>
> On Sun, Aug 6, 2017 at 11:22 AM,  wrote:
>
>> Author: deepak
>> Date: Sun Aug  6 05:52:43 2017
>> New Revision: 1804224
>>
>> URL: http://svn.apache.org/viewvc?rev=1804224=rev
>> Log:
>> Improved: Removed ne references from BirtUtil class file (OFBIZ-9351)
>> Thanks Aditya for your contribution.
>> I removed them but forgot to commit :)
>>
>> Modified:
>> ofbiz/ofbiz-plugins/trunk/birt/src/main/java/org/apache/ofbi
>> z/birt/flexible/BirtUtil.java
>>
>> Modified: ofbiz/ofbiz-plugins/trunk/birt/src/main/java/org/apache/ofbi
>> z/birt/flexible/BirtUtil.java
>> URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-plugins/trunk/birt/
>> src/main/java/org/apache/ofbiz/birt/flexible/BirtUtil.java?r
>> ev=1804224=1804223=1804224=diff
>> 
>> ==
>> --- 
>> ofbiz/ofbiz-plugins/trunk/birt/src/main/java/org/apache/ofbiz/birt/flexible/BirtUtil.java
>> (original)
>> +++ 
>> ofbiz/ofbiz-plugins/trunk/birt/src/main/java/org/apache/ofbiz/birt/flexible/BirtUtil.java
>> Sun Aug  6 05:52:43 2017
>> @@ -47,7 +47,7 @@ public final class BirtUtil {
>>  "id", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
>>  "url", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
>>  "name", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
>> -"id-ne", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
>> +"id", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
>>  "value", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
>>  "email", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
>>  "comment", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
>> @@ -57,8 +57,8 @@ public final class BirtUtil {
>>  "indicator", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
>>  "very-short", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
>>  "tel-number", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
>> -  

Re: svn commit: r1804224 - /ofbiz/ofbiz-plugins/trunk/birt/src/main/java/org/apache/ofbiz/birt/flexible/BirtUtil.java

2017-08-06 Thread Aditya Sharma
Hi Depak,

I think we can just remove these lines instead of replacing them as these
field types are already mapped with Birt data type & got redundant now.

private final static Map entityFieldTypeBirtTypeMap =
MapUtils.unmodifiableMap(UtilMisc.toMap(
*"id", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,*
"url", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
"name", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
*"id", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,*
"value", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
"email", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
"comment", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
*"id-long",DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,*
*"id-vlong", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,*
"very-long", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
"indicator", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
"very-short", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
"tel-number", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
*"id-long", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,*
*"id-vlong", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,*
"description", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
"long-varchar", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
"short-varchar", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
"credit-card-date",
DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
"credit-card-number",
DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
"date-time", DesignChoiceConstants.COLUMN_DATA_TYPE_DATETIME,
"date", DesignChoiceConstants.COLUMN_DATA_TYPE_DATE,
"time", DesignChoiceConstants.COLUMN_DATA_TYPE_TIME,
"currency-amount",
DesignChoiceConstants.COLUMN_DATA_TYPE_DECIMAL,
"currency-precise",
DesignChoiceConstants.COLUMN_DATA_TYPE_DECIMAL,
"fixed-point", DesignChoiceConstants.COLUMN_DATA_TYPE_DECIMAL,
"floating-point",
DesignChoiceConstants.COLUMN_DATA_TYPE_DECIMAL,
"numeric", DesignChoiceConstants.COLUMN_DATA_TYPE_INTEGER,
"object", DesignChoiceConstants.COLUMN_DATA_TYPE_JAVA_OBJECT,
"blob", DesignChoiceConstants.COLUMN_DATA_TYPE_BLOB));

Thanks and Regards,

*Aditya Sharma* | Enterprise Software Engineer
HotWax Systems 


On Sun, Aug 6, 2017 at 11:22 AM,  wrote:

> Author: deepak
> Date: Sun Aug  6 05:52:43 2017
> New Revision: 1804224
>
> URL: http://svn.apache.org/viewvc?rev=1804224=rev
> Log:
> Improved: Removed ne references from BirtUtil class file (OFBIZ-9351)
> Thanks Aditya for your contribution.
> I removed them but forgot to commit :)
>
> Modified:
> ofbiz/ofbiz-plugins/trunk/birt/src/main/java/org/apache/
> ofbiz/birt/flexible/BirtUtil.java
>
> Modified: ofbiz/ofbiz-plugins/trunk/birt/src/main/java/org/apache/
> ofbiz/birt/flexible/BirtUtil.java
> URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-plugins/trunk/
> birt/src/main/java/org/apache/ofbiz/birt/flexible/BirtUtil.
> java?rev=1804224=1804223=1804224=diff
> 
> ==
> --- ofbiz/ofbiz-plugins/trunk/birt/src/main/java/org/apache/
> ofbiz/birt/flexible/BirtUtil.java (original)
> +++ ofbiz/ofbiz-plugins/trunk/birt/src/main/java/org/apache/
> ofbiz/birt/flexible/BirtUtil.java Sun Aug  6 05:52:43 2017
> @@ -47,7 +47,7 @@ public final class BirtUtil {
>  "id", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
>  "url", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
>  "name", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
> -"id-ne", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
> +"id", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
>  "value", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
>  "email", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
>  "comment", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
> @@ -57,8 +57,8 @@ public final class BirtUtil {
>  "indicator", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
>  "very-short", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
>  "tel-number", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
> -"id-long-ne", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
> -"id-vlong-ne", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
> +"id-long", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
> +"id-vlong", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
>  "description", DesignChoiceConstants.COLUMN_DATA_TYPE_STRING,
>  "long-varchar", DesignChoiceConstants.COLUMN_
> 

Re: Rule to deprecated a service

2017-08-06 Thread Taher Alkhateeb
Hmmm I am not sure if comments are the most appropriate form for
deprecation. Usually deprecation is useful when it is programmatic because
it goes beyond raw text to logging warnings and highlighting by tools. You
want the system to constantly remind you (both the developer and author) to
get rid of the deprecated code.

However if this entails a lot of code changes (not sure) then I think it
might be useful to wait until we refactor the rest of the core components
(entity engine, service engine, etc ...)

On Aug 6, 2017 8:47 AM, "Deepak Dixit" 
wrote:

> Hi Nicolas,
>
> Idea is to mark service deprecated is looks good to me,
> What I think instead of adding deprecated as engine we can set annotation
> for deprecated service like we set in java, annotation can be simple
> comment or xml annotation.
>
> And ideally we have to mark services deprecate instead of removing, with
> expected release on which we will remove this deprecated code.
>
>
> Thanks & Regards
> --
> Deepak Dixit
> www.hotwaxsystems.com
> www.hotwax.co
>
> On Sat, Aug 5, 2017 at 1:34 AM, Nicolas Malin 
> wrote:
>
> > Hello with the thread https://lists.apache.org/
> thread.html/Zoz5yfpkrfcxts1
> > and the voluntary to have a good coherence on crud service name,
> >
> > I would be have your suggest to manage old name and deprecated process.
> >
> > I review the issue OFBIZ-9550 [1] that contains this problematic :
> >
> > - > + >
> > Currently I follow this process :
> >
> > * duplicate the service definition
> > * Rename the duplicate with the correct name
> > * Set "DEPRECATED : use ${new service} instead" in the service
> description
> > * implement on old service definition : return error("use ${new service}
> > instead") to help developer to correct their specific code.
> >
> > I image that we can create a generic code to return the error and change
> > the old service definition like this :
> >
> >  > default-entity-name="MarketingCampaignPromo" engine="deprecated"
> > invoke="create" auth="true">
> >  Deprecated please replace by
> > createMarketingCampaignPromo
> >  
> >  
> >  
> >
> > And deprecated engine return always error with the service description.
> >
> > After a new ofbiz stable branche creation, we remove all deprecated
> > service ?
> >
> > Any suggests, othet ideas, comments ?
> >
> > Cheers,
> >
> > Nicolas
> >
> > [1] https://issues.apache.org/jira/browse/OFBIZ-9550
> >
> > --
> > logoNrd 
> > Nicolas Malin
> > The apache way  : *Openness* Technical
> > decisions are made publicly
> > informat...@nereide.fr
> > 8 rue des Déportés 37000 TOURS, 02 47 50 30 54
> >
> > Apache OFBiz |The Apache Way <
> > http://theapacheway.com/>|ofbiz-fr |réseau LE
> <
> > http://www.libre-entreprise.org/>
> >
>


Re: Rule to deprecated a service

2017-08-06 Thread Jacques Le Roux

I agree with Nicolas and Taher,

A POC would help to remove hesitations

Jacques


Le 06/08/2017 à 08:03, Taher Alkhateeb a écrit :

Hmmm I am not sure if comments are the most appropriate form for
deprecation. Usually deprecation is useful when it is programmatic because
it goes beyond raw text to logging warnings and highlighting by tools. You
want the system to constantly remind you (both the developer and author) to
get rid of the deprecated code.

However if this entails a lot of code changes (not sure) then I think it
might be useful to wait until we refactor the rest of the core components
(entity engine, service engine, etc ...)

On Aug 6, 2017 8:47 AM, "Deepak Dixit" 
wrote:


Hi Nicolas,

Idea is to mark service deprecated is looks good to me,
What I think instead of adding deprecated as engine we can set annotation
for deprecated service like we set in java, annotation can be simple
comment or xml annotation.

And ideally we have to mark services deprecate instead of removing, with
expected release on which we will remove this deprecated code.


Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com
www.hotwax.co

On Sat, Aug 5, 2017 at 1:34 AM, Nicolas Malin 
wrote:


Hello with the thread https://lists.apache.org/

thread.html/Zoz5yfpkrfcxts1

and the voluntary to have a good coherence on crud service name,

I would be have your suggest to manage old name and deprecated process.

I review the issue OFBIZ-9550 [1] that contains this problematic :

-
description

* implement on old service definition : return error("use ${new service}
instead") to help developer to correct their specific code.

I image that we can create a generic code to return the error and change
the old service definition like this :

 
  Deprecated please replace by
createMarketingCampaignPromo
  
  
  

And deprecated engine return always error with the service description.

After a new ofbiz stable branche creation, we remove all deprecated
service ?

Any suggests, othet ideas, comments ?

Cheers,

Nicolas

[1] https://issues.apache.org/jira/browse/OFBIZ-9550

--
logoNrd 
 Nicolas Malin
The apache way  : *Openness* Technical
decisions are made publicly
informat...@nereide.fr
8 rue des Déportés 37000 TOURS, 02 47 50 30 54

Apache OFBiz |The Apache Way <
http://theapacheway.com/>|ofbiz-fr |réseau LE

<

http://www.libre-entreprise.org/>





Re: Rule to deprecated a service

2017-08-06 Thread Nicolas Malin

Thanks for your return Deepak and Taher.

I suggested to use comment to deprecated because it's really fast to 
implement with a combination of process and small modification code.


Like Taher, just I found not enough just a comment. What do you think 
about add a new xml element to service


 Explain the 
reason


and on the modelService, when a deprecate is parsed and when the service 
is call we put on log a warning :


WARN the service oldServiceName is now deprecated please use 
theNewService, the reason is ${Explain the reason}


Nicolas


Le 06/08/2017 à 08:03, Taher Alkhateeb a écrit :

Hmmm I am not sure if comments are the most appropriate form for
deprecation. Usually deprecation is useful when it is programmatic because
it goes beyond raw text to logging warnings and highlighting by tools. You
want the system to constantly remind you (both the developer and author) to
get rid of the deprecated code.

However if this entails a lot of code changes (not sure) then I think it
might be useful to wait until we refactor the rest of the core components
(entity engine, service engine, etc ...)

On Aug 6, 2017 8:47 AM, "Deepak Dixit" 
wrote:


Hi Nicolas,

Idea is to mark service deprecated is looks good to me,
What I think instead of adding deprecated as engine we can set annotation
for deprecated service like we set in java, annotation can be simple
comment or xml annotation.

And ideally we have to mark services deprecate instead of removing, with
expected release on which we will remove this deprecated code.


Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com
www.hotwax.co

On Sat, Aug 5, 2017 at 1:34 AM, Nicolas Malin 
wrote:


Hello with the thread https://lists.apache.org/

thread.html/Zoz5yfpkrfcxts1

and the voluntary to have a good coherence on crud service name,

I would be have your suggest to manage old name and deprecated process.

I review the issue OFBIZ-9550 [1] that contains this problematic :

-
description

* implement on old service definition : return error("use ${new service}
instead") to help developer to correct their specific code.

I image that we can create a generic code to return the error and change
the old service definition like this :

 
  Deprecated please replace by
createMarketingCampaignPromo
  
  
  

And deprecated engine return always error with the service description.

After a new ofbiz stable branche creation, we remove all deprecated
service ?

Any suggests, othet ideas, comments ?

Cheers,

Nicolas

[1] https://issues.apache.org/jira/browse/OFBIZ-9550

--
logoNrd 
 Nicolas Malin
The apache way  : *Openness* Technical
decisions are made publicly
informat...@nereide.fr
8 rue des Déportés 37000 TOURS, 02 47 50 30 54

Apache OFBiz |The Apache Way <
http://theapacheway.com/>|ofbiz-fr |réseau LE

<

http://www.libre-entreprise.org/>





Re: Rule to deprecated a service

2017-08-06 Thread Jacques Le Roux

+1

Jacques


Le 06/08/2017 à 19:04, Nicolas Malin a écrit :

Thanks for your return Deepak and Taher.

I suggested to use comment to deprecated because it's really fast to implement 
with a combination of process and small modification code.

Like Taher, just I found not enough just a comment. What do you think about add 
a new xml element to service

 Explain the 
reason

and on the modelService, when a deprecate is parsed and when the service is 
call we put on log a warning :

WARN the service oldServiceName is now deprecated please use theNewService, the 
reason is ${Explain the reason}

Nicolas


Le 06/08/2017 à 08:03, Taher Alkhateeb a écrit :

Hmmm I am not sure if comments are the most appropriate form for
deprecation. Usually deprecation is useful when it is programmatic because
it goes beyond raw text to logging warnings and highlighting by tools. You
want the system to constantly remind you (both the developer and author) to
get rid of the deprecated code.

However if this entails a lot of code changes (not sure) then I think it
might be useful to wait until we refactor the rest of the core components
(entity engine, service engine, etc ...)

On Aug 6, 2017 8:47 AM, "Deepak Dixit" 
wrote:


Hi Nicolas,

Idea is to mark service deprecated is looks good to me,
What I think instead of adding deprecated as engine we can set annotation
for deprecated service like we set in java, annotation can be simple
comment or xml annotation.

And ideally we have to mark services deprecate instead of removing, with
expected release on which we will remove this deprecated code.


Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com
www.hotwax.co

On Sat, Aug 5, 2017 at 1:34 AM, Nicolas Malin 
wrote:


Hello with the thread https://lists.apache.org/

thread.html/Zoz5yfpkrfcxts1

and the voluntary to have a good coherence on crud service name,

I would be have your suggest to manage old name and deprecated process.

I review the issue OFBIZ-9550 [1] that contains this problematic :

-
description

* implement on old service definition : return error("use ${new service}
instead") to help developer to correct their specific code.

I image that we can create a generic code to return the error and change
the old service definition like this :

 
  Deprecated please replace by
createMarketingCampaignPromo
  
  
  

And deprecated engine return always error with the service description.

After a new ofbiz stable branche creation, we remove all deprecated
service ?

Any suggests, othet ideas, comments ?

Cheers,

Nicolas

[1] https://issues.apache.org/jira/browse/OFBIZ-9550

--
logoNrd 
 Nicolas Malin
The apache way  : *Openness* Technical
decisions are made publicly
informat...@nereide.fr
8 rue des Déportés 37000 TOURS, 02 47 50 30 54

Apache OFBiz |The Apache Way <
http://theapacheway.com/>|ofbiz-fr |réseau LE

<

http://www.libre-entreprise.org/>








Re: Rule to deprecated a service

2017-08-06 Thread Scott Gray
+1 for logging a warning instead of an error

+1 for using an element to deprecate. Although I'd prefer "deprecated" for
the element name and I'd prefer "use-instead" for the attribute name.
Would keep us consistent with java conventions, @deprecated and the text is
often "use X instead".  I think having "service" in the attribute name is
unnecessary because the service engine only deals in services anyway.  The
attribute should be optional because sometimes services marked for removal
won't have a replacement, in the case of a major refactor.

Also, I think it would be a good idea to replace the attribute definitions
on the old service to use the "implements" element which would point to the
new service.  It would help keep them aligned with each other for future
changes without duplication.

Some additional nice to haves:
- Add a "since" attribute to the "deprecated" element that would contain
either a date or a release candidate version string.  This would make it
easier for us to know when the service can be removed. (I can't remember
the policy for deprecation,  remove after the next release or after two?)
- For webtools, add a strikethrough on the service name in the Service List
screen and add the information to the UI in the service definition screen.

Regards
Scott

On 7/08/2017 05:04, "Nicolas Malin"  wrote:

Thanks for your return Deepak and Taher.

I suggested to use comment to deprecated because it's really fast to
implement with a combination of process and small modification code.

Like Taher, just I found not enough just a comment. What do you think about
add a new xml element to service

 Explain the
reason

and on the modelService, when a deprecate is parsed and when the service is
call we put on log a warning :

WARN the service oldServiceName is now deprecated please use theNewService,
the reason is ${Explain the reason}

Nicolas



Le 06/08/2017 à 08:03, Taher Alkhateeb a écrit :

> Hmmm I am not sure if comments are the most appropriate form for
> deprecation. Usually deprecation is useful when it is programmatic because
> it goes beyond raw text to logging warnings and highlighting by tools. You
> want the system to constantly remind you (both the developer and author) to
> get rid of the deprecated code.
>
> However if this entails a lot of code changes (not sure) then I think it
> might be useful to wait until we refactor the rest of the core components
> (entity engine, service engine, etc ...)
>
> On Aug 6, 2017 8:47 AM, "Deepak Dixit" 
> wrote:
>
> Hi Nicolas,
>>
>> Idea is to mark service deprecated is looks good to me,
>> What I think instead of adding deprecated as engine we can set annotation
>> for deprecated service like we set in java, annotation can be simple
>> comment or xml annotation.
>>
>> And ideally we have to mark services deprecate instead of removing, with
>> expected release on which we will remove this deprecated code.
>>
>>
>> Thanks & Regards
>> --
>> Deepak Dixit
>> www.hotwaxsystems.com
>> www.hotwax.co
>>
>> On Sat, Aug 5, 2017 at 1:34 AM, Nicolas Malin 
>> wrote:
>>
>> Hello with the thread https://lists.apache.org/
>>>
>> thread.html/Zoz5yfpkrfcxts1
>>
>>> and the voluntary to have a good coherence on crud service name,
>>>
>>> I would be have your suggest to manage old name and deprecated process.
>>>
>>> I review the issue OFBIZ-9550 [1] that contains this problematic :
>>>
>>> ->> +>>
>>> Currently I follow this process :
>>>
>>> * duplicate the service definition
>>> * Rename the duplicate with the correct name
>>> * Set "DEPRECATED : use ${new service} instead" in the service
>>>
>> description
>>
>>> * implement on old service definition : return error("use ${new service}
>>> instead") to help developer to correct their specific code.
>>>
>>> I image that we can create a generic code to return the error and change
>>> the old service definition like this :
>>>
>>>  >> default-entity-name="MarketingCampaignPromo" engine="deprecated"
>>> invoke="create" auth="true">
>>>   Deprecated please replace by
>>> createMarketingCampaignPromo
>>>   
>>>   
>>>   
>>>
>>> And deprecated engine return always error with the service description.
>>>
>>> After a new ofbiz stable branche creation, we remove all deprecated
>>> service ?
>>>
>>> Any suggests, othet ideas, comments ?
>>>
>>> Cheers,
>>>
>>> Nicolas
>>>
>>> [1] https://issues.apache.org/jira/browse/OFBIZ-9550
>>>
>>> --
>>> logoNrd 
>>>  Nicolas Malin
>>> The apache way  : *Openness* Technical
>>> decisions are made publicly
>>> informat...@nereide.fr
>>> 8 rue des Déportés 37000 TOURS, 02 47 50 30 54
>>>
>>> Apache OFBiz |The Apache Way <
>>> http://theapacheway.com/>|ofbiz-fr |réseau LE
>>>
>> <
>>
>>> http://www.libre-entreprise.org/>
>>>
>>>