Re: Rule to deprecated a service
+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
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
Re: Rule to deprecated a service
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" 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 :
-
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
optional="false"/>
optional="true"/>
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
buildbot success in on ofbiz-branch14
The Buildbot has detected a restored build on builder ofbiz-branch14 while building . Full details are available at: https://ci.apache.org/builders/ofbiz-branch14/builds/381 Buildbot URL: https://ci.apache.org/ Buildslave for this Build: lares_ubuntu Build Reason: forced: by IRC user (privmsg): forces manual build after tests wrongly failed, OK locally Build Source Stamp: HEAD Blamelist: Build succeeded! Sincerely, -The Buildbot
buildbot success in on ofbiz-trunk-framework-plugins
The Buildbot has detected a restored build on builder ofbiz-trunk-framework-plugins while building . Full details are available at: https://ci.apache.org/builders/ofbiz-trunk-framework-plugins/builds/311 Buildbot URL: https://ci.apache.org/ Buildslave for this Build: silvanus_ubuntu Build Reason: forced: by IRC user (privmsg): forces manual build after tests wrongly failed, OK locally Build Source Stamp: HEAD Blamelist: Build succeeded! Sincerely, -The Buildbot
buildbot failure in on ofbiz-trunk-framework-plugins
The Buildbot has detected a new failure on builder ofbiz-trunk-framework-plugins while building . Full details are available at: https://ci.apache.org/builders/ofbiz-trunk-framework-plugins/builds/310 Buildbot URL: https://ci.apache.org/ Buildslave for this Build: orcus_ubuntu Build Reason: The AnyBranchScheduler scheduler named 'on-ofbiz-framework-commit' triggered this build Build Source Stamp: [branch ofbiz/ofbiz-framework/trunk] 1804328 Blamelist: jleroux BUILD FAILED: failed shell_4 Sincerely, -The Buildbot
buildbot failure in on ofbiz-branch14
The Buildbot has detected a new failure on builder ofbiz-branch14 while building . Full details are available at: https://ci.apache.org/builders/ofbiz-branch14/builds/380 Buildbot URL: https://ci.apache.org/ Buildslave for this Build: lares_ubuntu Build Reason: The AnyBranchScheduler scheduler named 'on-ofbiz14-commit' triggered this build Build Source Stamp: [branch ofbiz/branches/release14.12] 1804322 Blamelist: jleroux BUILD FAILED: failed compile_1 Sincerely, -The Buildbot
Alternative UI using Vaadin as ofbiz user interface
Interest for co-operation? We are looking here using vaadin (http://vaadin.com/) as user interface for OFBIz using existing OFBiz screens and forms we have a proof of concept working here and are preparing a vadinDemo component for others to try. We implemented it creating an FTL macrolibrary generating Vaadin instead of HTML statements. Please let me know here, if there is interest helping to implement this. The license of Vaadin is in general Apache 2.0 or compatible. -- Regards, Hans Bakker CEO, http://antwebsystems.com
Re: Request for enhance entity:SystemProperty.
Hi Wai, Can you give us some examples on the reason to set a specific access to a property or have a UserProperty. Because my first react would be says when you use a property, it's always through a service or screen so the limit access is manage by them. And for the user property it seems to be an UserPreference Nicolas Le 07/08/2017 à 09:03, Jacques Le Roux a écrit : Hi Wai, This is typically the kind of questions which can go in dev ML, copying there Thanks Jacques Le 07/08/2017 à 04:44, Wai a écrit : I would like to get some comments on a request to enhance the SystemProperty entity. It would be useful to add the following fields: field: access -this field is used to indicate if the entry is readable and/or writable by the a user with admin access. -valid values: field: valueType -this field is used to indicate the format of the value. It could be used to aid validation -valid values: A second point. The SystemProperty entity contains settings for the whole system (even thought some are for specific components). Would it be useful to include user specific settings based on userLoginId. If so, would that be using SystemProperty or create a new entity (eg. UserProperty?) Thanks. -- View this message in context: http://ofbiz.135035.n4.nabble.com/Request-for-enhance-entity-SystemProperty-tp4709232.html Sent from the OFBiz - User mailing list archive at Nabble.com.
Re: Rule to deprecated a service
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" 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 :
-
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
optional="true"/>
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
Re: Rule to deprecated a service
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" 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 :
-
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
Re: Request for enhance entity:SystemProperty.
Hi Wai, This is typically the kind of questions which can go in dev ML, copying there Thanks Jacques Le 07/08/2017 à 04:44, Wai a écrit : I would like to get some comments on a request to enhance the SystemProperty entity. It would be useful to add the following fields: field: access -this field is used to indicate if the entry is readable and/or writable by the a user with admin access. -valid values: field: valueType -this field is used to indicate the format of the value. It could be used to aid validation -valid values: A second point. The SystemProperty entity contains settings for the whole system (even thought some are for specific components). Would it be useful to include user specific settings based on userLoginId. If so, would that be using SystemProperty or create a new entity (eg. UserProperty?) Thanks. -- View this message in context: http://ofbiz.135035.n4.nabble.com/Request-for-enhance-entity-SystemProperty-tp4709232.html Sent from the OFBiz - User mailing list archive at Nabble.com.
