Rule to deprecated a service

[Nicolas Malin-2]

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 :

-    <service name="addPromoToMarketingCampaign" ...
+    <service name="createMarketingCampaignPromo" ...

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 :

     <service name="addPromoToMarketingCampaign" default-entity-name="MarketingCampaignPromo" engine="deprecated" invoke="create" auth="true">
          <description>Deprecated please replace by createMarketingCampaignPromo</description>
          <auto-attributes include="pk" mode="IN" optional="false"/>
          <auto-attributes include="nonpk" mode="IN" optional="true"/>
      </service>

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 <https://nereide.fr/>
        Nicolas Malin
The apache way <http://theapacheway.com/> : *Openness* Technical
decisions are made publicly
[hidden email]
8 rue des Déportés 37000 TOURS, 02 47 50 30 54

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

[Deepak Dixit-3]

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 <[hidden email]>
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 :
>
> -    <service name="addPromoToMarketingCampaign" ...
> +    <service name="createMarketingCampaignPromo" ...
>
> 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 :
>
>     <service name="addPromoToMarketingCampaign"
> default-entity-name="MarketingCampaignPromo" engine="deprecated"
> invoke="create" auth="true">
>          <description>Deprecated please replace by
> createMarketingCampaignPromo</description>
>          <auto-attributes include="pk" mode="IN" optional="false"/>
>          <auto-attributes include="nonpk" mode="IN" optional="true"/>
>      </service>
>
> 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 <https://nereide.fr/>
>         Nicolas Malin
> The apache way <http://theapacheway.com/> : *Openness* Technical
> decisions are made publicly
> [hidden email]
> 8 rue des Déportés 37000 TOURS, 02 47 50 30 54
>
> Apache OFBiz <http://ofbiz.apache.org/>|The Apache Way <
> http://theapacheway.com/>|ofbiz-fr <http://www.ofbiz-fr.org/>|réseau LE <
> http://www.libre-entreprise.org/>
>

[taher]

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" <[hidden email]>
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 <[hidden email]>
> 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 :
> >
> > -    <service name="addPromoToMarketingCampaign" ...
> > +    <service name="createMarketingCampaignPromo" ...
> >
> > 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 :
> >
> >     <service name="addPromoToMarketingCampaign"
> > default-entity-name="MarketingCampaignPromo" engine="deprecated"
> > invoke="create" auth="true">
> >          <description>Deprecated please replace by
> > createMarketingCampaignPromo</description>
> >          <auto-attributes include="pk" mode="IN" optional="false"/>
> >          <auto-attributes include="nonpk" mode="IN" optional="true"/>
> >      </service>
> >
> > 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 <https://nereide.fr/>
> >         Nicolas Malin
> > The apache way <http://theapacheway.com/> : *Openness* Technical
> > decisions are made publicly
> > [hidden email]
> > 8 rue des Déportés 37000 TOURS, 02 47 50 30 54
> >
> > Apache OFBiz <http://ofbiz.apache.org/>|The Apache Way <
> > http://theapacheway.com/>|ofbiz-fr <http://www.ofbiz-fr.org/>|réseau LE
> <
> > http://www.libre-entreprise.org/>
> >
>

[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" <[hidden email]>
> 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 <[hidden email]>
>> 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 :
>>>
>>> -    <service name="addPromoToMarketingCampaign" ...
>>> +    <service name="createMarketingCampaignPromo" ...
>>>
>>> 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 :
>>>
>>>      <service name="addPromoToMarketingCampaign"
>>> default-entity-name="MarketingCampaignPromo" engine="deprecated"
>>> invoke="create" auth="true">
>>>           <description>Deprecated please replace by
>>> createMarketingCampaignPromo</description>
>>>           <auto-attributes include="pk" mode="IN" optional="false"/>
>>>           <auto-attributes include="nonpk" mode="IN" optional="true"/>
>>>       </service>
>>>
>>> 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 <https://nereide.fr/>
>>>          Nicolas Malin
>>> The apache way <http://theapacheway.com/> : *Openness* Technical
>>> decisions are made publicly
>>> [hidden email]
>>> 8 rue des Déportés 37000 TOURS, 02 47 50 30 54
>>>
>>> Apache OFBiz <http://ofbiz.apache.org/>|The Apache Way <
>>> http://theapacheway.com/>|ofbiz-fr <http://www.ofbiz-fr.org/>|réseau LE
>> <
>>> http://www.libre-entreprise.org/>
>>>

[Nicolas Malin-2]

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

<deprecate replace-by-service="theNewServiceName"> Explain the
reason</deprecated>

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" <[hidden email]>
> 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 <[hidden email]>
>> 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 :
>>>
>>> -    <service name="addPromoToMarketingCampaign" ...
>>> +    <service name="createMarketingCampaignPromo" ...
>>>
>>> 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 :
>>>
>>>      <service name="addPromoToMarketingCampaign"
>>> default-entity-name="MarketingCampaignPromo" engine="deprecated"
>>> invoke="create" auth="true">
>>>           <description>Deprecated please replace by
>>> createMarketingCampaignPromo</description>
>>>           <auto-attributes include="pk" mode="IN" optional="false"/>
>>>           <auto-attributes include="nonpk" mode="IN" optional="true"/>
>>>       </service>
>>>
>>> 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 <https://nereide.fr/>
>>>          Nicolas Malin
>>> The apache way <http://theapacheway.com/> : *Openness* Technical
>>> decisions are made publicly
>>> [hidden email]
>>> 8 rue des Déportés 37000 TOURS, 02 47 50 30 54
>>>
>>> Apache OFBiz <http://ofbiz.apache.org/>|The Apache Way <
>>> http://theapacheway.com/>|ofbiz-fr <http://www.ofbiz-fr.org/>|réseau LE
>> <
>>> http://www.libre-entreprise.org/>
>>>

[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
>
> <deprecate replace-by-service="theNewServiceName"> Explain the reason</deprecated>
>
> 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" <[hidden email]>
>> 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 <[hidden email]>
>>> 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 :
>>>>
>>>> -    <service name="addPromoToMarketingCampaign" ...
>>>> +    <service name="createMarketingCampaignPromo" ...
>>>>
>>>> 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 :
>>>>
>>>>      <service name="addPromoToMarketingCampaign"
>>>> default-entity-name="MarketingCampaignPromo" engine="deprecated"
>>>> invoke="create" auth="true">
>>>>           <description>Deprecated please replace by
>>>> createMarketingCampaignPromo</description>
>>>>           <auto-attributes include="pk" mode="IN" optional="false"/>
>>>>           <auto-attributes include="nonpk" mode="IN" optional="true"/>
>>>>       </service>
>>>>
>>>> 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 <https://nereide.fr/>
>>>>          Nicolas Malin
>>>> The apache way <http://theapacheway.com/> : *Openness* Technical
>>>> decisions are made publicly
>>>> [hidden email]
>>>> 8 rue des Déportés 37000 TOURS, 02 47 50 30 54
>>>>
>>>> Apache OFBiz <http://ofbiz.apache.org/>|The Apache Way <
>>>> http://theapacheway.com/>|ofbiz-fr <http://www.ofbiz-fr.org/>|réseau LE
>>> <
>>>> http://www.libre-entreprise.org/>
>>>>
>
>

[Scott Gray-3]

+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" <[hidden email]> 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

<deprecate replace-by-service="theNewServiceName"> Explain the
reason</deprecated>

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" <[hidden email]>
> 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 <[hidden email]>
>> 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 :
>>>
>>> -    <service name="addPromoToMarketingCampaign" ...
>>> +    <service name="createMarketingCampaignPromo" ...
>>>
>>> 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 :
>>>
>>>      <service name="addPromoToMarketingCampaign"
>>> default-entity-name="MarketingCampaignPromo" engine="deprecated"
>>> invoke="create" auth="true">
>>>           <description>Deprecated please replace by
>>> createMarketingCampaignPromo</description>
>>>           <auto-attributes include="pk" mode="IN" optional="false"/>
>>>           <auto-attributes include="nonpk" mode="IN" optional="true"/>
>>>       </service>
>>>
>>> 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 <https://nereide.fr/>
>>>          Nicolas Malin
>>> The apache way <http://theapacheway.com/> : *Openness* Technical
>>> decisions are made publicly
>>> [hidden email]
>>> 8 rue des Déportés 37000 TOURS, 02 47 50 30 54
>>>
>>> Apache OFBiz <http://ofbiz.apache.org/>|The Apache Way <
>>> http://theapacheway.com/>|ofbiz-fr <http://www.ofbiz-fr.org/>|réseau LE
>>>
>> <
>>
>>> http://www.libre-entreprise.org/>
>>>
>>>

[Jacques Le Roux]

Nice suggestions

Thanks Scott

Jacques


Le 07/08/2017 à 00:02, Scott Gray a écrit :

> +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" <[hidden email]> 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
>
> <deprecate replace-by-service="theNewServiceName"> Explain the
> reason</deprecated>
>
> 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" <[hidden email]>
>> 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 <[hidden email]>
>>> 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 :
>>>>
>>>> -    <service name="addPromoToMarketingCampaign" ...
>>>> +    <service name="createMarketingCampaignPromo" ...
>>>>
>>>> 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 :
>>>>
>>>>       <service name="addPromoToMarketingCampaign"
>>>> default-entity-name="MarketingCampaignPromo" engine="deprecated"
>>>> invoke="create" auth="true">
>>>>            <description>Deprecated please replace by
>>>> createMarketingCampaignPromo</description>
>>>>            <auto-attributes include="pk" mode="IN" optional="false"/>
>>>>            <auto-attributes include="nonpk" mode="IN" optional="true"/>
>>>>        </service>
>>>>
>>>> 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 <https://nereide.fr/>
>>>>           Nicolas Malin
>>>> The apache way <http://theapacheway.com/> : *Openness* Technical
>>>> decisions are made publicly
>>>> [hidden email]
>>>> 8 rue des Déportés 37000 TOURS, 02 47 50 30 54
>>>>
>>>> Apache OFBiz <http://ofbiz.apache.org/>|The Apache Way <
>>>> http://theapacheway.com/>|ofbiz-fr <http://www.ofbiz-fr.org/>|réseau LE
>>>>
>>> <
>>>
>>>> http://www.libre-entreprise.org/>
>>>>
>>>>

[Nicolas Malin-2]

Thanks Scott, your suggestions complete like a charm this theme :)

I will implement the deprecated service process and complete the
documentation for the future

Nicolas


Le 07/08/2017 à 09:05, Jacques Le Roux a écrit :

> Nice suggestions
>
> Thanks Scott
>
> Jacques
>
>
> Le 07/08/2017 à 00:02, Scott Gray a écrit :
>> +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" <[hidden email]> 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
>>
>> <deprecate replace-by-service="theNewServiceName"> Explain the
>> reason</deprecated>
>>
>> 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" <[hidden email]>
>>> 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
>>>> <[hidden email]>
>>>> 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 :
>>>>>
>>>>> -    <service name="addPromoToMarketingCampaign" ...
>>>>> +    <service name="createMarketingCampaignPromo" ...
>>>>>
>>>>> 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 :
>>>>>
>>>>>       <service name="addPromoToMarketingCampaign"
>>>>> default-entity-name="MarketingCampaignPromo" engine="deprecated"
>>>>> invoke="create" auth="true">
>>>>>            <description>Deprecated please replace by
>>>>> createMarketingCampaignPromo</description>
>>>>>            <auto-attributes include="pk" mode="IN" optional="false"/>
>>>>>            <auto-attributes include="nonpk" mode="IN"
>>>>> optional="true"/>
>>>>>        </service>
>>>>>
>>>>> 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 <https://nereide.fr/>
>>>>>           Nicolas Malin
>>>>> The apache way <http://theapacheway.com/> : *Openness* Technical
>>>>> decisions are made publicly
>>>>> [hidden email]
>>>>> 8 rue des Déportés 37000 TOURS, 02 47 50 30 54
>>>>>
>>>>> Apache OFBiz <http://ofbiz.apache.org/>|The Apache Way <
>>>>> http://theapacheway.com/>|ofbiz-fr
>>>>> <http://www.ofbiz-fr.org/>|réseau LE
>>>>>
>>>> <
>>>>
>>>>> http://www.libre-entreprise.org/>
>>>>>
>>>>>
>
>

[Nicolas Malin-2]

Hello,

I implemented a first solution on the issue OFBIZ-9558 [1]. If you have
a reviewer heart, It would be great :)

Nicolas

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


Le 07/08/2017 à 09:24, Nicolas Malin a écrit :

> Thanks Scott, your suggestions complete like a charm this theme :)
>
> I will implement the deprecated service process and complete the
> documentation for the future
>
> Nicolas
>
>
> Le 07/08/2017 à 09:05, Jacques Le Roux a écrit :
>> Nice suggestions
>>
>> Thanks Scott
>>
>> Jacques
>>
>>
>> Le 07/08/2017 à 00:02, Scott Gray a écrit :
>>> +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" <[hidden email]> 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
>>>
>>> <deprecate replace-by-service="theNewServiceName"> Explain the
>>> reason</deprecated>
>>>
>>> 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"
>>>> <[hidden email]>
>>>> 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
>>>>> <[hidden email]>
>>>>> 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 :
>>>>>>
>>>>>> -    <service name="addPromoToMarketingCampaign" ...
>>>>>> +    <service name="createMarketingCampaignPromo" ...
>>>>>>
>>>>>> 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 :
>>>>>>
>>>>>>       <service name="addPromoToMarketingCampaign"
>>>>>> default-entity-name="MarketingCampaignPromo" engine="deprecated"
>>>>>> invoke="create" auth="true">
>>>>>>            <description>Deprecated please replace by
>>>>>> createMarketingCampaignPromo</description>
>>>>>>            <auto-attributes include="pk" mode="IN"
>>>>>> optional="false"/>
>>>>>>            <auto-attributes include="nonpk" mode="IN"
>>>>>> optional="true"/>
>>>>>>        </service>
>>>>>>
>>>>>> 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 <https://nereide.fr/>
>>>>>>           Nicolas Malin
>>>>>> The apache way <http://theapacheway.com/> : *Openness* Technical
>>>>>> decisions are made publicly
>>>>>> [hidden email]
>>>>>> 8 rue des Déportés 37000 TOURS, 02 47 50 30 54
>>>>>>
>>>>>> Apache OFBiz <http://ofbiz.apache.org/>|The Apache Way <
>>>>>> http://theapacheway.com/>|ofbiz-fr
>>>>>> <http://www.ofbiz-fr.org/>|réseau LE
>>>>>>
>>>>> <
>>>>>
>>>>>> http://www.libre-entreprise.org/>
>>>>>>
>>>>>>
>>
>>
>
>

[Deepak Dixit-3]

+1

Thanks Nicolas,

This is inline with what I proposed.

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

On Sun, Aug 6, 2017 at 10:34 PM, Nicolas Malin <[hidden email]>
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
>
> <deprecate replace-by-service="theNewServiceName"> Explain the
> reason</deprecated>
>
> 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" <[hidden email]>
>> 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 <[hidden email]>
>>> 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 :
>>>>
>>>> -    <service name="addPromoToMarketingCampaign" ...
>>>> +    <service name="createMarketingCampaignPromo" ...
>>>>
>>>> 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 :
>>>>
>>>>      <service name="addPromoToMarketingCampaign"
>>>> default-entity-name="MarketingCampaignPromo" engine="deprecated"
>>>> invoke="create" auth="true">
>>>>           <description>Deprecated please replace by
>>>> createMarketingCampaignPromo</description>
>>>>           <auto-attributes include="pk" mode="IN" optional="false"/>
>>>>           <auto-attributes include="nonpk" mode="IN" optional="true"/>
>>>>       </service>
>>>>
>>>> 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 <https://nereide.fr/>
>>>>          Nicolas Malin
>>>> The apache way <http://theapacheway.com/> : *Openness* Technical
>>>> decisions are made publicly
>>>> [hidden email]
>>>> 8 rue des Déportés 37000 TOURS, 02 47 50 30 54
>>>>
>>>> Apache OFBiz <http://ofbiz.apache.org/>|The Apache Way <
>>>> http://theapacheway.com/>|ofbiz-fr <http://www.ofbiz-fr.org/>|réseau LE
>>>>
>>> <
>>>
>>>> http://www.libre-entreprise.org/>
>>>>
>>>>
>

[Suraj Khurana]

+1 Nicolas.

--
Thanks and Regards,
*Suraj Khurana* | Sr. Enterprise Software Engineer
HotWax Commerce <http://www.hotwax.co/>  by  HotWax Systems
<http://www.hotwaxsystems.com/>
Plot no. 80, Scheme no. 78, Vijay Nagar, Indore, M.P. India 452010


On Sat, Aug 5, 2017 at 1:34 AM, Nicolas Malin <[hidden email]>
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 :
>
> -    <service name="addPromoToMarketingCampaign" ...
> +    <service name="createMarketingCampaignPromo" ...
>
> 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 :
>
>     <service name="addPromoToMarketingCampaign"
> default-entity-name="MarketingCampaignPromo" engine="deprecated"
> invoke="create" auth="true">
>          <description>Deprecated please replace by
> createMarketingCampaignPromo</description>
>          <auto-attributes include="pk" mode="IN" optional="false"/>
>          <auto-attributes include="nonpk" mode="IN" optional="true"/>
>      </service>
>
> 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 <https://nereide.fr/>
>         Nicolas Malin
> The apache way <http://theapacheway.com/> : *Openness* Technical
> decisions are made publicly
> [hidden email]
> 8 rue des Déportés 37000 TOURS, 02 47 50 30 54
>
> Apache OFBiz <http://ofbiz.apache.org/>|The Apache Way <
> http://theapacheway.com/>|ofbiz-fr <http://www.ofbiz-fr.org/>|réseau LE <
> http://www.libre-entreprise.org/>
>

[Jacques Le Roux]

Hi All,

After Nicolas's work at OFBIZ-9558 I want to create a "Code deprecation rules" wiki page.

Before doing so I think we need to get a consensus about when to remove deprecated code (Java, Groovy, XML, etc.) and services definitions.

Then we could plan to remove all deprecated code in trunk when for instance creating a new release.

I suggest that we don't wait too long and deprecate code when we create the first release of the last freezed branch

Opinions?

Jacques


Le 07/08/2017 à 00:02, Scott Gray a écrit :

> 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" <[hidden email]> wrote:
>
>
> On Aug 6, 2017 8:47 AM, "Deepak Dixit" <[hidden email]>
> wrote:
>
> Hi Nicolas,
>>> And ideally we have to mark services deprecate instead of removing, with
>>> expected release on which we will remove this deprecated code.
>>>
>>>
>>>
>>> On Sat, Aug 5, 2017 at 1:34 AM, Nicolas Malin <[hidden email]>
>>> wrote:
>>> After a new ofbiz stable branche creation, we remove all deprecated
>>> service ?
>>>
>>> Any suggests, othet ideas, comments ?
>>>

[Vaibhav Jain]

+1 Nicolas

Thanks & Regards
Vaibhav Jain
Hotwax Systems,
[hidden email]

On Wed, Aug 9, 2017 at 5:04 PM, Suraj Khurana <
[hidden email]> wrote:

> +1 Nicolas.
>
> --
> Thanks and Regards,
> *Suraj Khurana* | Sr. Enterprise Software Engineer
> HotWax Commerce <http://www.hotwax.co/>  by  HotWax Systems
> <http://www.hotwaxsystems.com/>
> Plot no. 80, Scheme no. 78, Vijay Nagar, Indore, M.P. India 452010
>
>
> On Sat, Aug 5, 2017 at 1:34 AM, Nicolas Malin <[hidden email]>
> 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 :
> >
> > -    <service name="addPromoToMarketingCampaign" ...
> > +    <service name="createMarketingCampaignPromo" ...
> >
> > 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 :
> >
> >     <service name="addPromoToMarketingCampaign"
> > default-entity-name="MarketingCampaignPromo" engine="deprecated"
> > invoke="create" auth="true">
> >          <description>Deprecated please replace by
> > createMarketingCampaignPromo</description>
> >          <auto-attributes include="pk" mode="IN" optional="false"/>
> >          <auto-attributes include="nonpk" mode="IN" optional="true"/>
> >      </service>
> >
> > 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 <https://nereide.fr/>
> >         Nicolas Malin
> > The apache way <http://theapacheway.com/> : *Openness* Technical
> > decisions are made publicly
> > [hidden email]
> > 8 rue des Déportés 37000 TOURS, 02 47 50 30 54
> >
> > Apache OFBiz <http://ofbiz.apache.org/>|The Apache Way <
> > http://theapacheway.com/>|ofbiz-fr <http://www.ofbiz-fr.org/>|réseau LE
> <
> > http://www.libre-entreprise.org/>
> >
>

[Scott Gray-3]

I think we've had these discussions before Jacques, I'd search the mailing
lists and then perhaps only continue the conversation if you have concerns
about what was agreed previously.

I'm pretty sure the policy was "remove after the next release is out", and
actually released, not just when a branch is cut.

Regards
Scott

On 9 August 2017 at 23:59, Jacques Le Roux <[hidden email]>
wrote:

> Hi All,
>
> After Nicolas's work at OFBIZ-9558 I want to create a "Code deprecation
> rules" wiki page.
>
> Before doing so I think we need to get a consensus about when to remove
> deprecated code (Java, Groovy, XML, etc.) and services definitions.
>
> Then we could plan to remove all deprecated code in trunk when for
> instance creating a new release.
>
> I suggest that we don't wait too long and deprecate code when we create
> the first release of the last freezed branch
>
> Opinions?
>
> Jacques
>
>
> Le 07/08/2017 à 00:02, Scott Gray a écrit :
>
>> 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" <[hidden email]> wrote:
>>
>>
>> On Aug 6, 2017 8:47 AM, "Deepak Dixit" <[hidden email]>
>> wrote:
>>
>> Hi Nicolas,
>>
>>> And ideally we have to mark services deprecate instead of removing, with
>>>> expected release on which we will remove this deprecated code.
>>>>
>>>>
>>>>
>>>> On Sat, Aug 5, 2017 at 1:34 AM, Nicolas Malin <[hidden email]
>>>> >
>>>> wrote:
>>>> After a new ofbiz stable branche creation, we remove all deprecated
>>>> service ?
>>>>
>>>> Any suggests, othet ideas, comments ?
>>>>
>>>>
>

[Jacques Le Roux]

Le 10/08/2017 à 13:25, Scott Gray a écrit :
> I think we've had these discussions before Jacques, I'd search the mailing
> lists and then perhaps only continue the conversation if you have concerns
> about what was agreed previously.
>
> I'm pretty sure the policy was "remove after the next release is out", and
> actually released, not just when a branch is cut.
Oops, that's what I meant too with "deprecate code when we create the first release of the last freezed branch".
I tried to be more precise there than in my previous sentence "remove all deprecated code in trunk when for instance creating a new release."
But I did not notice I misused "deprecate code" for "remove deprecated code".

I think we are on the same page and don't want to wait loo long keeping deprecated code, first occasion is best ;)

Jacques

>
> Regards
> Scott
>
> On 9 August 2017 at 23:59, Jacques Le Roux <[hidden email]>
> wrote:
>
>> Hi All,
>>
>> After Nicolas's work at OFBIZ-9558 I want to create a "Code deprecation
>> rules" wiki page.
>>
>> Before doing so I think we need to get a consensus about when to remove
>> deprecated code (Java, Groovy, XML, etc.) and services definitions.
>>
>> Then we could plan to remove all deprecated code in trunk when for
>> instance creating a new release.
>>
>> I suggest that we don't wait too long and deprecate when we create
>> the first release of the last freezed branch
>>
>> Opinions?
>>
>> Jacques
>>
>>
>> Le 07/08/2017 à 00:02, Scott Gray a écrit :
>>
>>> 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" <[hidden email]> wrote:
>>>
>>>
>>> On Aug 6, 2017 8:47 AM, "Deepak Dixit" <[hidden email]>
>>> wrote:
>>>
>>> Hi Nicolas,
>>>
>>>> And ideally we have to mark services deprecate instead of removing, with
>>>>> expected release on which we will remove this deprecated code.
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Aug 5, 2017 at 1:34 AM, Nicolas Malin <[hidden email]
>>>>> wrote:
>>>>> After a new ofbiz stable branche creation, we remove all deprecated
>>>>> service ?
>>>>>
>>>>> Any suggests, othet ideas, comments ?
>>>>>
>>>>>

[Nicolas Malin-2]

Hello,

I imagine the following process :
* deprecated on trunk an element and indicate since="$NextReleaseBranch"
(or somethink like that)
* When before create the new release branch like 17.11 :
** run a replaceAll $NextReleaseBranch by 17.11
** update the trunk
* Create the new stable branch
* remove all element contains with a since not on the last stable branch
on trunk
* update trunk

With this we have a new stable branch with the deprecated from the
previous stable branch (keep stability much as possible), and a trunk
cleaned of old deprecated who may introduce a potential instability but
we have the time to correct it.

Nicolas


Le 10/08/2017 à 13:46, Jacques Le Roux a écrit :

> Le 10/08/2017 à 13:25, Scott Gray a écrit :
>> I think we've had these discussions before Jacques, I'd search the
>> mailing
>> lists and then perhaps only continue the conversation if you have
>> concerns
>> about what was agreed previously.
>>
>> I'm pretty sure the policy was "remove after the next release is
>> out", and
>> actually released, not just when a branch is cut.
> Oops, that's what I meant too with "deprecate code when we create the
> first release of the last freezed branch".
> I tried to be more precise there than in my previous sentence "remove
> all deprecated code in trunk when for instance creating a new release."
> But I did not notice I misused "deprecate code" for "remove deprecated
> code".
>
> I think we are on the same page and don't want to wait loo long
> keeping deprecated code, first occasion is best ;)
>
> Jacques
>

[Jacques Le Roux]

Hi Nicolas,

I'm unsure about your point

"remove all element contains with a since not on the last stable branch on trunk"

I guess you mean

"to remove on trunk all elements which contains a 'since=releaseBranchNumber' with releaseBranchNumber being different from the last stable branch
just created"

For instance in your example we would remove all elements deprecated but not those marked with deprecated with 'since=17.11'

Right?

Please confirm and others please raise a hand if you disagree.

IMO we could remove all deprecated code from trunk at this moment. I mean, we would not even keep services with 'since=17.11'

So to be totally clear, my take is to remove all deprecated code (not only services) when we release a branch. In other words just after the 1st
release of a branch the trunk should no longer contain any deprecated code.
Is that too much and early ?
Another possibility would be to remove all the deprecated code from the trunk when releasing the last release of the last branch (ie when a branch get
to its End Of Life/Support)

Would be the rule Nicolas proposes better ? ie, if I have well understood, we keep in trunk the deprecated code deprecated between the creation of the
"old" (previous stable) and the (new) stable branch

I guess whether rule we pick we all agree that it must apply to all code not only services, or Java code, etc.

Some suggest to keep the deprecated code during 2-3 versions (OFBiz code can be considered an API):
https://softwareengineering.stackexchange.com/questions/67837/when-to-deprecate-and-when-to-delete-in-java

So what are your opinions :) ?

Jacques


Le 11/08/2017 à 12:08, Nicolas Malin a écrit :

> Hello,
>
> I imagine the following process :
> * deprecated on trunk an element and indicate since="$NextReleaseBranch" (or somethink like that)
> * When before create the new release branch like 17.11 :
> ** run a replaceAll $NextReleaseBranch by 17.11
> ** update the trunk
> * Create the new stable branch
> * remove all element contains with a since not on the last stable branch on trunk
> * update trunk
>
> With this we have a new stable branch with the deprecated from the previous stable branch (keep stability much as possible), and a trunk cleaned of
> old deprecated who may introduce a potential instability but we have the time to correct it.
>
> Nicolas
>
>
> Le 10/08/2017 à 13:46, Jacques Le Roux a écrit :
>> Le 10/08/2017 à 13:25, Scott Gray a écrit :
>>> I think we've had these discussions before Jacques, I'd search the mailing
>>> lists and then perhaps only continue the conversation if you have concerns
>>> about what was agreed previously.
>>>
>>> I'm pretty sure the policy was "remove after the next release is out", and
>>> actually released, not just when a branch is cut.
>> Oops, that's what I meant too with "deprecate code when we create the first release of the last freezed branch".
>> I tried to be more precise there than in my previous sentence "remove all deprecated code in trunk when for instance creating a new release."
>> But I did not notice I misused "deprecate code" for "remove deprecated code".
>>
>> I think we are on the same page and don't want to wait loo long keeping deprecated code, first occasion is best ;)
>>
>> Jacques
>>
>
>

[Nicolas Malin-2]

Imagine we are the 30 december 2019 and we decide to create a new release.
We have on trunk :
  * addCatalogMember deprecated since="next release"
  * deleteRateAmount deprecated since="17.11"
  * deleteWorkEffortAssignment depraceted since="18.12"

We prepare the release, we have on trunk :
  * addCatalogMember deprecated since="19.12"
  * deleteRateAmount deprecated since="17.11"
  * deleteWorkEffortAssignment depraceted since="18.12"

We create the stable branche and after clean the trunk,
now on trunk we have :
  * addCatalogMember deprecated since="19.12"
  * deleteWorkEffortAssignment depraceted since="18.12"

I hope this example is less confused that the sentence :)

Nicolas

Le 11/08/2017 à 17:05, Jacques Le Roux a écrit :

> Hi Nicolas,
>
> I'm unsure about your point
>
> "remove all element contains with a since not on the last stable
> branch on trunk"
>
> I guess you mean
>
> "to remove on trunk all elements which contains a
> 'since=releaseBranchNumber' with releaseBranchNumber being different
> from the last stable branch just created"
>
> For instance in your example we would remove all elements deprecated
> but not those marked with deprecated with 'since=17.11'
>
> Right?
>
> Please confirm and others please raise a hand if you disagree.
>
> IMO we could remove all deprecated code from trunk at this moment. I
> mean, we would not even keep services with 'since=17.11'
>
> So to be totally clear, my take is to remove all deprecated code (not
> only services) when we release a branch. In other words just after the
> 1st release of a branch the trunk should no longer contain any
> deprecated code.
> Is that too much and early ?
> Another possibility would be to remove all the deprecated code from
> the trunk when releasing the last release of the last branch (ie when
> a branch get to its End Of Life/Support)
>
> Would be the rule Nicolas proposes better ? ie, if I have well
> understood, we keep in trunk the deprecated code deprecated between
> the creation of the "old" (previous stable) and the (new) stable branch
>
> I guess whether rule we pick we all agree that it must apply to all
> code not only services, or Java code, etc.
>
> Some suggest to keep the deprecated code during 2-3 versions (OFBiz
> code can be considered an API):
> https://softwareengineering.stackexchange.com/questions/67837/when-to-deprecate-and-when-to-delete-in-java
>
> So what are your opinions :) ?
>
> Jacques
>
>
> Le 11/08/2017 à 12:08, Nicolas Malin a écrit :
>> Hello,
>>
>> I imagine the following process :
>> * deprecated on trunk an element and indicate
>> since="$NextReleaseBranch" (or somethink like that)
>> * When before create the new release branch like 17.11 :
>> ** run a replaceAll $NextReleaseBranch by 17.11
>> ** update the trunk
>> * Create the new stable branch
>> * remove all element contains with a since not on the last stable
>> branch on trunk
>> * update trunk
>>
>> With this we have a new stable branch with the deprecated from the
>> previous stable branch (keep stability much as possible), and a trunk
>> cleaned of old deprecated who may introduce a potential instability
>> but we have the time to correct it.
>>
>> Nicolas
>>
>>
>> Le 10/08/2017 à 13:46, Jacques Le Roux a écrit :
>>> Le 10/08/2017 à 13:25, Scott Gray a écrit :
>>>> I think we've had these discussions before Jacques, I'd search the
>>>> mailing
>>>> lists and then perhaps only continue the conversation if you have
>>>> concerns
>>>> about what was agreed previously.
>>>>
>>>> I'm pretty sure the policy was "remove after the next release is
>>>> out", and
>>>> actually released, not just when a branch is cut.
>>> Oops, that's what I meant too with "deprecate code when we create
>>> the first release of the last freezed branch".
>>> I tried to be more precise there than in my previous sentence
>>> "remove all deprecated code in trunk when for instance creating a
>>> new release."
>>> But I did not notice I misused "deprecate code" for "remove
>>> deprecated code".
>>>
>>> I think we are on the same page and don't want to wait loo long
>>> keeping deprecated code, first occasion is best ;)
>>>
>>> Jacques
>>>
>>
>>
>
>

[Jacques Le Roux]

This is interesting too https://issues.apache.org/jira/browse/OFBIZ-6273 (thanks Deepak at OFBIZ-9569)

Jacques


Le 11/08/2017 à 17:05, Jacques Le Roux a écrit :

> Hi Nicolas,
>
> I'm unsure about your point
>
> "remove all element contains with a since not on the last stable branch on trunk"
>
> I guess you mean
>
> "to remove on trunk all elements which contains a 'since=releaseBranchNumber' with releaseBranchNumber being different from the last stable branch
> just created"
>
> For instance in your example we would remove all elements deprecated but not those marked with deprecated with 'since=17.11'
>
> Right?
>
> Please confirm and others please raise a hand if you disagree.
>
> IMO we could remove all deprecated code from trunk at this moment. I mean, we would not even keep services with 'since=17.11'
>
> So to be totally clear, my take is to remove all deprecated code (not only services) when we release a branch. In other words just after the 1st
> release of a branch the trunk should no longer contain any deprecated code.
> Is that too much and early ?
> Another possibility would be to remove all the deprecated code from the trunk when releasing the last release of the last branch (ie when a branch
> get to its End Of Life/Support)
>
> Would be the rule Nicolas proposes better ? ie, if I have well understood, we keep in trunk the deprecated code deprecated between the creation of
> the "old" (previous stable) and the (new) stable branch
>
> I guess whether rule we pick we all agree that it must apply to all code not only services, or Java code, etc.
>
> Some suggest to keep the deprecated code during 2-3 versions (OFBiz code can be considered an API):
> https://softwareengineering.stackexchange.com/questions/67837/when-to-deprecate-and-when-to-delete-in-java
>
> So what are your opinions :) ?
>
> Jacques
>
>
> Le 11/08/2017 à 12:08, Nicolas Malin a écrit :
>> Hello,
>>
>> I imagine the following process :
>> * deprecated on trunk an element and indicate since="$NextReleaseBranch" (or somethink like that)
>> * When before create the new release branch like 17.11 :
>> ** run a replaceAll $NextReleaseBranch by 17.11
>> ** update the trunk
>> * Create the new stable branch
>> * remove all element contains with a since not on the last stable branch on trunk
>> * update trunk
>>
>> With this we have a new stable branch with the deprecated from the previous stable branch (keep stability much as possible), and a trunk cleaned of
>> old deprecated who may introduce a potential instability but we have the time to correct it.
>>
>> Nicolas
>>
>>
>> Le 10/08/2017 à 13:46, Jacques Le Roux a écrit :
>>> Le 10/08/2017 à 13:25, Scott Gray a écrit :
>>>> I think we've had these discussions before Jacques, I'd search the mailing
>>>> lists and then perhaps only continue the conversation if you have concerns
>>>> about what was agreed previously.
>>>>
>>>> I'm pretty sure the policy was "remove after the next release is out", and
>>>> actually released, not just when a branch is cut.
>>> Oops, that's what I meant too with "deprecate code when we create the first release of the last freezed branch".
>>> I tried to be more precise there than in my previous sentence "remove all deprecated code in trunk when for instance creating a new release."
>>> But I did not notice I misused "deprecate code" for "remove deprecated code".
>>>
>>> I think we are on the same page and don't want to wait loo long keeping deprecated code, first occasion is best ;)
>>>
>>> Jacques
>>>
>>
>>
>
>