Re: Add CHANGELOG.md file
+1 - Best regards, Swapnil M Mane, ofbiz.apache.org On Wed, Jun 17, 2020 at 11:23 AM Deepak Dixit wrote: > Hi Dev, > > As we have already moved to git for the version control system, I propose > to add a changelog file to maintain the changelogs[1]. > What is a changelog? > > A changelog is a file which contains a curated, chronologically ordered > list of notable changes for each version of a project. > Why keep a changelog? > > To make it easier for users and contributors to see precisely what notable > changes have been made between each release (or version) of the project. > Who needs a changelog? > > People do. Whether consumers or developers, the end users of software are > human beings who care about what's in the software. When the software > changes, people want to know why and how. > > We can have our own process to generate changelog, It may be either manual > entries, or some tool or using git log. We can discuss this independently. > > https://keepachangelog.com/en/1.0.0/ > > Thanks & Regards > -- > Deepak Dixit > ofbiz.apache.org >
Re: Question re master branch rename support
Le 16/06/2020 à 06:51, Daniel Gruno a écrit : We have support built-in for adopting an approach of "master, trunk or $default". We just need to decide on that and apply to all features of .asf.yaml. I'd quite appreciate that because of INFRA-20424 TIA Jacques
Re: Add CHANGELOG.md file
+1 -- Best Regards, Suraj Khurana Senior Technical Consultant On Wed, Jun 17, 2020 at 5:08 PM Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > +1 > > I believe it would be better done manually with a community consensus. > > Could someone probes me wrong? > > Jacques > > Le 17/06/2020 à 07:52, Deepak Dixit a écrit : > > Hi Dev, > > > > As we have already moved to git for the version control system, I propose > > to add a changelog file to maintain the changelogs[1]. > > What is a changelog? > > > > A changelog is a file which contains a curated, chronologically ordered > > list of notable changes for each version of a project. > > Why keep a changelog? > > > > To make it easier for users and contributors to see precisely what > notable > > changes have been made between each release (or version) of the project. > > Who needs a changelog? > > > > People do. Whether consumers or developers, the end users of software are > > human beings who care about what's in the software. When the software > > changes, people want to know why and how. > > > > We can have our own process to generate changelog, It may be either > manual > > entries, or some tool or using git log. We can discuss this > independently. > > > > https://keepachangelog.com/en/1.0.0/ > > > > Thanks & Regards > > -- > > Deepak Dixit > > ofbiz.apache.org > >
Re: Use Compound Widget on rest of the project
Hi Nicolas, Removed the additional namespace as I agree they are a distraction. Agreed that plugin may be a better place to apply compound widgets, as they are less likely being overriden by existing implementation. Just find it to be troublesome moving between related elements while making changes. So I will leave it for custom implementation then. Regards, James On 2020/06/15 13:05:44, Nicolas Malin wrote: > Hi, > > Compound widget is interesting from my view in final component, where > your code is closer than business cover so limited to reuse. > > For the "middle-ware" component, I have a doubt about the must valuable > to convert it or how to convert it. To organize by compound widget maybe > introduce to globalize by process and not by functional entities. > > After review your first commit [1] my feeling were decreased code > visibility with the namespace representation, swaying with regroup all > element that simplify the code navigation. Finally is that the problem > to improve the code navigation throw ide plugin and keep each xml as low > as possible (for the middle-ware component) and exploit compound widget > on plugin to indicate another way to concentrate business code ? > > Nicolas > > [1] > https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;a=blob;f=applications/order/widget/ordermgr/FindRequestCompound.xml;h=114e9c6d071a192d80e6278ba3e2c713f9ca1b17;hb=28809d7 > > On 14/06/2020 08:47, Jacques Le Roux wrote: > > Hi James, > > > > I see you pushed changes for FindRequest. Maybe we should wait a bit > > feedback from others? > > > > Jacques > > > > Le 14/06/2020 à 05:18, James Yong a écrit : > >> Hi Jacques, > >> > >> Ok, I created OFBIZ-11821 for this. > >> > >> Regards, > >> James > >> > >> On 2020/06/13 18:03:21, Jacques Le Roux > >> wrote: > >>> Hi James, > >>> > >>> As a 1st thought I'd see no problem with that. > >>> > >>> Jacques > >>> > >>> Le 13/06/2020 à 14:32, James Yong a écrit : > Hi all, > > Currently, compound widget tag is only used in Examples application. > Propose to convert rest of the project to use compound widget, so > that dependencies are grouped together. > > Regards, > James > >>> >
Re: Use Compound Widget on rest of the project
Hi Oliver, I would suggest grouping elements that are specific to the main screen being called by a particular requesturi. The example for compound widget is for showcasing the use of compound widgets using very simple forms. Regards, James On 2020/06/15 09:01:53, Olivier Heintz wrote: > Hi James, > > It's a good idea, but question is, how to group ? > I have tested compound Widget for the POC VueJs, and I use it with one > compound widget file by resouceName (on a REST uri format point of view). In > example, 4 files: Example, ExampleItem, ExampleFeature, ExampleFeatureAppl > I'm waiting for more time using them to say if it's the correct group size or > not. > > So I suggest to use compound Widget, but not convert all xml files > immediately, we need more developer experience to find the correct group size. > > Regards, > Olivier > > Le 13/06/2020 à 14:32, James Yong a écrit : > > Hi all, > > > > Currently, compound widget tag is only used in Examples application. > > Propose to convert rest of the project to use compound widget, so that > > dependencies are grouped together. > > > > Regards, > > James > > >
Re: Add CHANGELOG.md file
+1 I believe it would be better done manually with a community consensus. Could someone probes me wrong? Jacques Le 17/06/2020 à 07:52, Deepak Dixit a écrit : Hi Dev, As we have already moved to git for the version control system, I propose to add a changelog file to maintain the changelogs[1]. What is a changelog? A changelog is a file which contains a curated, chronologically ordered list of notable changes for each version of a project. Why keep a changelog? To make it easier for users and contributors to see precisely what notable changes have been made between each release (or version) of the project. Who needs a changelog? People do. Whether consumers or developers, the end users of software are human beings who care about what's in the software. When the software changes, people want to know why and how. We can have our own process to generate changelog, It may be either manual entries, or some tool or using git log. We can discuss this independently. https://keepachangelog.com/en/1.0.0/ Thanks & Regards -- Deepak Dixit ofbiz.apache.org
Re: Add CHANGELOG.md file
+1 Thanks and Regards, Aditya Sharma On Wed, Jun 17, 2020 at 12:57 PM Carsten Schinzer < cars...@dcs-verkaufssysteme.de> wrote: > +1 for a CHANGELOG.md > > Would this be maintained for all official release branches + trunk, right? > Or official release branches only. > Regards > > Carsten > >
Re: REST implementation
Hi Girish, Thanks to clarify :) What caught me on the OpenAPI integration is the snippet quoted below and I realize I should have read it in context. Actually then it is aligned with my view. Warm regards Carsten > Initial implementation does not contain OpenApi integration yet. And
Re: REST implementation
Hi Carsten
OpenAPI integration and the implementation go hand in hand so no reason
separating them. I think what this draft does is just trying to see how
this might work. I am also parallelly working on OpenAPI spec but I wanted
the developers to review this work to get a better understanding of how to
proceed further.
As for the PATCH example that I quoted, that was just for
demonstration purposes to show the two approaches.
Best Regards,
Girish
On Wed, Jun 17, 2020 at 2:42 PM Carsten Schinzer <
cars...@dcs-verkaufssysteme.de> wrote:
> Hello Giresh,
>
>
> Thanks for the example, it makes clearer what you want to achieve.
>
> General considerations on RESTful or not:
> If you want to stop a productionRun, why do you use PATCH and not DELETE?
> Well, I know the connotation of Delete is „dismantle“ rather than „stop“,
> but PATCH also considers and exposes config/data changes, not only status
> changes
>
> PATCH /rest/productionruns/{productionRunId}?action=cancel
> … would probably be the best
>
> Here is how an Annotation based implementation would achieve this:
>
> @Route /productionrun/{productionRunId}, requirement={productionRunid, \d+}
> @ApiDoc(title=„A service to patch MRP Production Runs“, description="It
> allows to change the run configuration and status“)
> public patchProductionRunAction(int productionRunId, string[]
> urlParameters)
> {
> ...
> if urlParameters[‚action‘] == ‚cancel‘:
> call service cancelProductionRun(productionRunId)
> ...
> }
>
> Forgive this pseudo-code, but I think you get what I mean.
>
> It would not avoid that some matching layer of code is reuqired in-between
> the exposed REST API methods like patchProductionRunAction and the actual
> service call, but this layer would remain code instead of being in XML or
> somewhere else that requires a context switch.
>
> In my other application (the PHP) the classes are clearly separated by
> responsibility, i.e. Repository classes interact wit the persistence layer,
> Service classes are manipulating things and RestController classes are
> wrapping up the REST API methods and properly annotated with the Routes and
> validation constraints. The important point is that it is all coded in the
> same language and therefore the context is exposed to the IDE I am working
> with. No lookups to be made into an XML file to understand parameters and
> return types of services etc. That is quite an advantage IMO.
>
> IMO that is the complexity in the current way of dealing with this in
> OFBiz and that’s why I believe the OpenAPI integration should be going
> along with REST implementation.
>
> Warm regards
>
>
> Carsten
>
>
> > Am 17.06.2020 um 08:38 schrieb Girish Vasmatkar <
> girish.vasmat...@hotwaxsystems.com>:
> >
> > Hi Carsten -
> >
> > Your points make a lot of sense and that's the general consensus of the
> > community as well. However, I believe we want to have the option of
> > exposing the services via "REST". The existing frameworks services
> > obviously are not named, thinking them as Resources and in the REST work
> > resources are perceived as nouns.
> >
> > This is obviously not a complete implementation and we would obviously
> like
> > to tie up entities and services with resources. For example - consider
> the
> > service cancelProductionRun.
> >
> > If we expose it under services resource (considering services as
> > resources), we could do it like this -
> > PATCH /rest/services/cancelProductionRun
> > {
> >"productionRunId": 1234
> > }
> >
> > While this may not sound RESTFul, but this in a way adds capability for
> > OFBiz to expose the services via a "REST" interface. A truly RESTFul
> > approach that I am working on might do something like this -
> >
> > PATCH /rest/productionruns/{productionRunId}
> >
> > Internally it will hook up the service cancelProductionRun with this
> > resource URL. This obviously has to be configured somewhere in XML and
> such
> > details can be chalked out.
> >
> > Best,
> > Girish
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Tue, Jun 16, 2020 at 12:45 PM Jacques Le Roux <
> > jacques.le.r...@les7arts.com> wrote:
> >
> >> Thanks Girish,
> >>
> >> I did not have time to look into details yet but your README is very
> >> promising :)
> >>
> >> Jacques
> >>
> >> Le 15/06/2020 à 17:59, Girish Vasmatkar a écrit :
> >>> Hi All
> >>>
> >>> I have tried to implement a draft proposal here -
> >>> https://github.com/girishvasmatkar/ofbiz-rest-impl.git
> >>> The readme contains details.
> >>>
> >>> In order to support the changes, I have made a corresponding change in
> >> the
> >>> service definition to include a new attribute named "verb". This can
> also
> >>> be named "method". These changes are in my forked ofbiz repo (it is
> very
> >>> much in sync with ofbiz trunk):
> >>>
> >>
> https://github.com/girishvasmatkar/ofbiz-framework/tree/feature/add-service-verb
> >>>
> >>> Initial implementation does not contain OpenApi integration
Re: REST implementation
Hello Giresh,
Thanks for the example, it makes clearer what you want to achieve.
General considerations on RESTful or not:
If you want to stop a productionRun, why do you use PATCH and not DELETE? Well,
I know the connotation of Delete is „dismantle“ rather than „stop“, but PATCH
also considers and exposes config/data changes, not only status changes
PATCH /rest/productionruns/{productionRunId}?action=cancel
… would probably be the best
Here is how an Annotation based implementation would achieve this:
@Route /productionrun/{productionRunId}, requirement={productionRunid, \d+}
@ApiDoc(title=„A service to patch MRP Production Runs“, description="It allows
to change the run configuration and status“)
public patchProductionRunAction(int productionRunId, string[] urlParameters)
{
...
if urlParameters[‚action‘] == ‚cancel‘:
call service cancelProductionRun(productionRunId)
...
}
Forgive this pseudo-code, but I think you get what I mean.
It would not avoid that some matching layer of code is reuqired in-between the
exposed REST API methods like patchProductionRunAction and the actual service
call, but this layer would remain code instead of being in XML or somewhere
else that requires a context switch.
In my other application (the PHP) the classes are clearly separated by
responsibility, i.e. Repository classes interact wit the persistence layer,
Service classes are manipulating things and RestController classes are wrapping
up the REST API methods and properly annotated with the Routes and validation
constraints. The important point is that it is all coded in the same language
and therefore the context is exposed to the IDE I am working with. No lookups
to be made into an XML file to understand parameters and return types of
services etc. That is quite an advantage IMO.
IMO that is the complexity in the current way of dealing with this in OFBiz and
that’s why I believe the OpenAPI integration should be going along with REST
implementation.
Warm regards
Carsten
> Am 17.06.2020 um 08:38 schrieb Girish Vasmatkar
> :
>
> Hi Carsten -
>
> Your points make a lot of sense and that's the general consensus of the
> community as well. However, I believe we want to have the option of
> exposing the services via "REST". The existing frameworks services
> obviously are not named, thinking them as Resources and in the REST work
> resources are perceived as nouns.
>
> This is obviously not a complete implementation and we would obviously like
> to tie up entities and services with resources. For example - consider the
> service cancelProductionRun.
>
> If we expose it under services resource (considering services as
> resources), we could do it like this -
> PATCH /rest/services/cancelProductionRun
> {
>"productionRunId": 1234
> }
>
> While this may not sound RESTFul, but this in a way adds capability for
> OFBiz to expose the services via a "REST" interface. A truly RESTFul
> approach that I am working on might do something like this -
>
> PATCH /rest/productionruns/{productionRunId}
>
> Internally it will hook up the service cancelProductionRun with this
> resource URL. This obviously has to be configured somewhere in XML and such
> details can be chalked out.
>
> Best,
> Girish
>
>
>
>
>
>
>
>
>
>
> On Tue, Jun 16, 2020 at 12:45 PM Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
>> Thanks Girish,
>>
>> I did not have time to look into details yet but your README is very
>> promising :)
>>
>> Jacques
>>
>> Le 15/06/2020 à 17:59, Girish Vasmatkar a écrit :
>>> Hi All
>>>
>>> I have tried to implement a draft proposal here -
>>> https://github.com/girishvasmatkar/ofbiz-rest-impl.git
>>> The readme contains details.
>>>
>>> In order to support the changes, I have made a corresponding change in
>> the
>>> service definition to include a new attribute named "verb". This can also
>>> be named "method". These changes are in my forked ofbiz repo (it is very
>>> much in sync with ofbiz trunk):
>>>
>> https://github.com/girishvasmatkar/ofbiz-framework/tree/feature/add-service-verb
>>>
>>> Initial implementation does not contain OpenApi integration yet. And yes,
>>> we should be fine doing both JSON and YAML.
>>>
>>> Please take a look at it and let me know what you think of this. I am
>> open
>>> to suggestions, improvements, discussions.
>>>
>>> Best Regards,
>>> Girish
>>>
>>>
>>> On Mon, Jun 15, 2020 at 7:02 PM Pritam Kute <
>> pritam.k...@hotwaxsystems.com>
>>> wrote:
>>>
Hello Girish,
+1 for having REST implementation using Jersey as a separate plugin and
>> not
to disturb the OFBiz default Control servlets and filters.
IMO we should also think about the end-point security implementations
alongside as it is one of the crucial things that users look into while
adopting any framework.
Kind Regards,
--
Pritam Kute
On Fri, Jun 12, 2020
Check Style on release branches?
Hi, While discussing with Aditya at OFBIZ-11304 I asked <> He suggested, and I tend to agree: <> What are your opinions? There are more information if needed at OFBIZ-11304 Thanks Jacques
Re: Add CHANGELOG.md file
+1 for a CHANGELOG.md Would this be maintained for all official release branches + trunk, right? Or official release branches only. Regards Carsten
Re: REST implementation
Hi Carsten -
Your points make a lot of sense and that's the general consensus of the
community as well. However, I believe we want to have the option of
exposing the services via "REST". The existing frameworks services
obviously are not named, thinking them as Resources and in the REST work
resources are perceived as nouns.
This is obviously not a complete implementation and we would obviously like
to tie up entities and services with resources. For example - consider the
service cancelProductionRun.
If we expose it under services resource (considering services as
resources), we could do it like this -
PATCH /rest/services/cancelProductionRun
{
"productionRunId": 1234
}
While this may not sound RESTFul, but this in a way adds capability for
OFBiz to expose the services via a "REST" interface. A truly RESTFul
approach that I am working on might do something like this -
PATCH /rest/productionruns/{productionRunId}
Internally it will hook up the service cancelProductionRun with this
resource URL. This obviously has to be configured somewhere in XML and such
details can be chalked out.
Best,
Girish
On Tue, Jun 16, 2020 at 12:45 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
> Thanks Girish,
>
> I did not have time to look into details yet but your README is very
> promising :)
>
> Jacques
>
> Le 15/06/2020 à 17:59, Girish Vasmatkar a écrit :
> > Hi All
> >
> > I have tried to implement a draft proposal here -
> > https://github.com/girishvasmatkar/ofbiz-rest-impl.git
> > The readme contains details.
> >
> > In order to support the changes, I have made a corresponding change in
> the
> > service definition to include a new attribute named "verb". This can also
> > be named "method". These changes are in my forked ofbiz repo (it is very
> > much in sync with ofbiz trunk):
> >
> https://github.com/girishvasmatkar/ofbiz-framework/tree/feature/add-service-verb
> >
> > Initial implementation does not contain OpenApi integration yet. And yes,
> > we should be fine doing both JSON and YAML.
> >
> > Please take a look at it and let me know what you think of this. I am
> open
> > to suggestions, improvements, discussions.
> >
> > Best Regards,
> > Girish
> >
> >
> > On Mon, Jun 15, 2020 at 7:02 PM Pritam Kute <
> pritam.k...@hotwaxsystems.com>
> > wrote:
> >
> >> Hello Girish,
> >>
> >> +1 for having REST implementation using Jersey as a separate plugin and
> not
> >> to disturb the OFBiz default Control servlets and filters.
> >>
> >> IMO we should also think about the end-point security implementations
> >> alongside as it is one of the crucial things that users look into while
> >> adopting any framework.
> >>
> >> Kind Regards,
> >> --
> >> Pritam Kute
> >>
> >>
> >> On Fri, Jun 12, 2020 at 2:58 PM Jacques Le Roux <
> >> jacques.le.r...@les7arts.com> wrote:
> >>
> >>> Hi Girish,
> >>>
> >>> Inline...
> >>>
> >>> Le 10/06/2020 à 17:42, Girish Vasmatkar a écrit :
> Hi All
>
> I am again bringing up this discussion on having a REST implementation
> >>> for
> OFBiz. I know we have had discussions before and I was looking at some
> >> of
> the past discussions about this topic and seems we are not there quite
> >>> yet
> (correct me if I am wrong).
>
> I had developed a POC plug-in based on Jersey (that I am currently
> enhancing) and recently started evaluating Apache Juneau as well. I
> >>> wanted
> to bring everybody on the same page as far as REST implementation is
> concerned so I had initiated a discussion on slack today. I am listing
> >>> down
> a few points below that can be perceived as
> >>> comment/question/understanding
> based on my general understanding of the matter and today's slack
> discussion.
>
> - Anything we start on can be part of a plug-in for the start and
> >>> later
> can become part of the framework (as separate plug-in) once it is
> developed. A dedicated API application will allow it to be
> >>> lightweight in
> terms of request processing. Should have separate auth mechanism
> >>> bypassing
> ControlerServlet/ContextFiler/ControlFilter. I opine we do not
> need
> >>> the API
> request to go through these three. Please correct me.
> >>> Though I did not look at the code (is it already somewhere?) I tend to
> >>> agree on that.
> >>> REST is something else and should not be hampered by those, if it's the
> >>> case.
> >>>
> >>>
> - We want to have mechanism to expose services (export=true) to
> be
> available as a REST resources. Possibly extending existing
> service
> definition by a new attribute verb="get|post".
> >>> +1
> >>>
> >>>
> Also, if we also want to
> expose out REST interface as an OpenApi specification, then it
> will
> possibly help if we show in the spec an example of request for a
> >>> specific
> service. In that case, the service
Re: Add CHANGELOG.md file
+1 for CHANGELOG.adoc ;-) Le 17/06/2020 à 07:52, Deepak Dixit a écrit : > Hi Dev, > > As we have already moved to git for the version control system, I propose > to add a changelog file to maintain the changelogs[1]. > What is a changelog? > > A changelog is a file which contains a curated, chronologically ordered > list of notable changes for each version of a project. > Why keep a changelog? > > To make it easier for users and contributors to see precisely what notable > changes have been made between each release (or version) of the project. > Who needs a changelog? > > People do. Whether consumers or developers, the end users of software are > human beings who care about what's in the software. When the software > changes, people want to know why and how. > > We can have our own process to generate changelog, It may be either manual > entries, or some tool or using git log. We can discuss this independently. > > https://keepachangelog.com/en/1.0.0/ > > Thanks & Regards > -- > Deepak Dixit > ofbiz.apache.org >
