Re: Clojure service engine proposal for inclusion
Hello Nicolas, Pierre, Thanks for your feedback, I replied to the issue. @Pierre: I would like to be able to use a "slim" OFBiz version but that is not easy to do at the moment. I would like to announce my intention to work on this issue. One way that would get us closer to a "Slim" (composable) OFBiz is to have concrete gradle projects for OFBiz components instead of dynamically created projects as we have now. Once that is done, we could build and publish each component and assemble them in a different way than Apache OFBiz currently does. I think this is doable and the project workflow will not change too much from how it is now. Regards, On 29.07.2021 20:13, Pierre Smits wrote: Hi Nicolas, I wasn't aware of that constraint. Thanks for the insight. Pierre Op do 29 jul. 2021 17:40 schreef Nicolas Malin : Hello, @Eugeu Yeah nice, I added some suggest to the PR, and create the linked jira issue and we can push it on trunk @Pierre The service engine don't support an extension by plugins, you can't load a new engine without change the framework. In this case I prefer to load the minimal quantity of code to demonstrate an engine on the OFBiz framework instead of separate it in plugin and load it by apply a path or manually change the configuration. Nicolas On 29/07/2021 10:58, Pierre Smits wrote: Hi Ioan, Would it not be better for the community to be able to implement this set of functionalities by means of a downloadable plugin? It seems to me that - in a way - this levels up to plugins like the indexing (lucene) or the REST plugins. Not every adopters would be keen to have this by default OOTB. Best regards, Pierre Smits On Wed, Jul 28, 2021 at 10:23 PM Eugen Stan wrote: Hello Nicolas, Thanks for the suggestions. I've made a PR for this: https://github.com/apache/ofbiz-framework/pull/317 * has a service test * has a service example (defn echo-service "Echo back all the parameters" [dctx ctx] (doto (new java.util.LinkedHashMap) (.putAll ctx) (.put ModelService/RESPONSE_MESSAGE ModelService/RESPOND_SUCCESS))) On 07.07.2021 09:58, Nicolas Malin wrote: Hello, Thanks for this detail email and your works. I'm not opposed to load closure in OFBiz code base for same reason that you exposed. For success the inclusion, I suggest to rename the namespace to org.apache.ofbiz, add test one framework/service/testdef and an example "hello world" service. Thanks Eugen ! Nicolas -- Eugen Stan +40720 898 747 / netdava.com -- Eugen Stan +40720 898 747 / netdava.com
Re: Clojure service engine proposal for inclusion
Hi Nicolas, I wasn't aware of that constraint. Thanks for the insight. Pierre Op do 29 jul. 2021 17:40 schreef Nicolas Malin : > Hello, > > @Eugeu > > Yeah nice, I added some suggest to the PR, and create the linked jira > issue and we can push it on trunk > > @Pierre > > The service engine don't support an extension by plugins, you can't load > a new engine without change the framework. > > In this case I prefer to load the minimal quantity of code to > demonstrate an engine on the OFBiz framework instead of > > separate it in plugin and load it by apply a path or manually change the > configuration. > > Nicolas > > On 29/07/2021 10:58, Pierre Smits wrote: > > Hi Ioan, > > > > Would it not be better for the community to be able to implement this set > > of functionalities by means of a downloadable plugin? > > > > It seems to me that - in a way - this levels up to plugins like the > > indexing (lucene) or the REST plugins. Not every adopters would be keen > to > > have this by default OOTB. > > > > Best regards, > > Pierre Smits > > > > On Wed, Jul 28, 2021 at 10:23 PM Eugen Stan > wrote: > > > >> Hello Nicolas, > >> > >> Thanks for the suggestions. > >> I've made a PR for this: > >> https://github.com/apache/ofbiz-framework/pull/317 > >> > >> * has a service test > >> * has a service example > >> > >> > >> (defn echo-service > >>"Echo back all the parameters" > >>[dctx ctx] > >>(doto (new java.util.LinkedHashMap) > >> (.putAll ctx) > >> (.put ModelService/RESPONSE_MESSAGE ModelService/RESPOND_SUCCESS))) > >> > >> > >> On 07.07.2021 09:58, Nicolas Malin wrote: > >>> Hello, > >>> > >>> Thanks for this detail email and your works. > >>> > >>> I'm not opposed to load closure in OFBiz code base for same reason that > >>> you exposed. > >>> > >>> For success the inclusion, I suggest to rename the namespace to > >>> org.apache.ofbiz, add test one framework/service/testdef and an example > >>> "hello world" service. > >>> > >>> Thanks Eugen ! > >>> > >>> Nicolas > >> -- > >> Eugen Stan > >> +40720 898 747 / netdava.com > >> >
Re: JFrog to shut down jcenter
Hi Jacques It seems, for now, it has again started working, so no need for changes. But I am keeping an eye on this because in another thread Daniel also faced the same issue. I am unsure if anything was done by the spring community. All of our docker based builds in all environments were failing. Thanks for confirming! Best, Girish On Wed, Jul 28, 2021 at 1:16 PM Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > Thanks Girish, > > Reluctant to clean all my cache (1 GB to download again for the 3 > branches), I have tried 1st to manually remove only but all the syndication > files in > cache to no avail. I mean the files where put back when building. > > I then used --refresh-dependencies, the build worked too. > > After clearing the cache, I got not problem (w/o changing syndication > path) on trunk > > HTH > > Jacques > > Le 28/07/2021 à 06:44, Girish Vasmatkar a écrit : > > Hi Jacques, > > > > Yes, I do. Apparently, the artifact " > > com.sun.syndication:com.springsource.com.sun.syndication:1.0.0" is > > available on "https://plugins.gradle.org/m2/"; too. I was able to do a > > successful build using this. > > > > Earlier, the syndication dependency was being resolved from " > > https://repo.spring.io/plugins-release"; which seems to now have blocked > > anonymous access. > > > > Best, > > Girish > > > > > > On Tue, Jul 27, 2021 at 8:50 PM Jacques Le Roux < > > jacques.le.r...@les7arts.com> wrote: > > > >> Le 27/07/2021 à 15:47, Girish Vasmatkar a écrit : > >>> Possibly, gradle cache is preventing building failure but if you do > clean > >>> up your cache you should start getting build failure. Can someone > please > >>> confirm? > >> Hi Girish, > >> > >> Before doing so, do you have a cure? > >> > >> Jacques > >> > >> >
Re: Clojure service engine proposal for inclusion
Hello, @Eugeu Yeah nice, I added some suggest to the PR, and create the linked jira issue and we can push it on trunk @Pierre The service engine don't support an extension by plugins, you can't load a new engine without change the framework. In this case I prefer to load the minimal quantity of code to demonstrate an engine on the OFBiz framework instead of separate it in plugin and load it by apply a path or manually change the configuration. Nicolas On 29/07/2021 10:58, Pierre Smits wrote: > Hi Ioan, > > Would it not be better for the community to be able to implement this set > of functionalities by means of a downloadable plugin? > > It seems to me that - in a way - this levels up to plugins like the > indexing (lucene) or the REST plugins. Not every adopters would be keen to > have this by default OOTB. > > Best regards, > Pierre Smits > > On Wed, Jul 28, 2021 at 10:23 PM Eugen Stan wrote: > >> Hello Nicolas, >> >> Thanks for the suggestions. >> I've made a PR for this: >> https://github.com/apache/ofbiz-framework/pull/317 >> >> * has a service test >> * has a service example >> >> >> (defn echo-service >>"Echo back all the parameters" >>[dctx ctx] >>(doto (new java.util.LinkedHashMap) >> (.putAll ctx) >> (.put ModelService/RESPONSE_MESSAGE ModelService/RESPOND_SUCCESS))) >> >> >> On 07.07.2021 09:58, Nicolas Malin wrote: >>> Hello, >>> >>> Thanks for this detail email and your works. >>> >>> I'm not opposed to load closure in OFBiz code base for same reason that >>> you exposed. >>> >>> For success the inclusion, I suggest to rename the namespace to >>> org.apache.ofbiz, add test one framework/service/testdef and an example >>> "hello world" service. >>> >>> Thanks Eugen ! >>> >>> Nicolas >> -- >> Eugen Stan >> +40720 898 747 / netdava.com >>
Re: Dynamism screen and compound widget
Hello,
I opened a jira issue OFBIZ-12292 [1] and a linked Pull Request 318 [2]
for give a good vision of this work.
All remarks are welcome :)
Nicolas
[1] https://issues.apache.org/jira/browse/OFBIZ-12292
[2] https://github.com/apache/ofbiz-framework/pull/318
On 12/07/2021 18:20, Nicolas Malin wrote:
> Hi all,
>
> We would like to share with you a thinking that we try at Nereide, to
> reorganize some widget screen with compound widget associated with the
> work about screen dynamism [1].
>
> After the proposal by Xin Wang to improve the FindWorkEffort screen and
> our suggestion to dynamism at the same time, it occured to us that codes
> are spread in many places. To avoid that, we refactored using compound
> widget introduced in OFBIZ-4090, that is not really used yet through
> standard Apache OFBiz applications.
>
> We wanted to share the idea since we weren't convinced at that time
> about the compound feature [2]. With that usecase as a basis, we would
> like to reconsider using it, and discuss with the community.
>
> We did experiment to convert each tab in workeffort menu (rate, party,
> note) to implement dynamism, gathering every element used by each menu
> within one compound file.
>
> The benefits of this are :
> * Everything in one sufficient and coherent file
> * Ease the integration of dynamic compound screen in application level.
> * Help detect screen complexity looking at compound file size.
>
> As shown below, we created suffixed files with Cpd to quickly identify
> the type of xml. We wonder about alternative like subfolder for compound
> or other. WDYT ?
>
> Some example on WorkEffortRate :
>
> controller.xml :
>
>
> WorkEffortScreens.xml :
> ###
>
> ...
>
> location="${parameters.mainDecoratorLocation}">
>
> location="component://workeffort/widget/WorkEffortRateCpd.xml"/>
>
>
>
>
>
> ###
>
> WorkEffortRateAssignCpd.xml :
> ###
>
> ...
> ...
> ...
>
>
>
>
> ...
> page="component://workeffort/widget/WorkEffortRateCpd.xml#ListWorkEffortRates"/>
> page="component://workeffort/widget/WorkEffortRateCpd.xml#EditWorkEffortRate"/>
>
>
>
> ...
>
> location="component://workeffort/widget/CommonScreens.xml">...
> location="component://workeffort/widget/WorkEffortRateCpd.xml"/>...
>
> ...
>
> location="component://workeffort/widget/CommonScreens.xml">...
> location="component://workeffort/widget/WorkEffortRateCpd.xml"/>...
>
>
>
> extends-resource="component://common/widget/CommonMenus.xml">
> link-type="layered-modal">...
> ...
>
> extends="CommonInlineBarMenu"
> extends-resource="component://common/widget/CommonMenus.xml">
>
> request-confirmation="true">
> service-name="expireRateAmount"/>
> ...
>
>
>
> paginate-target="WorkEffortRate/List"
> extends="CommonDynamicGrid"
> extends-resource="component://common/widget/CommonForms.xml">...
> default-map-name="workEffortRateAmount" target="WorkEffortRate/update"
> extends="CommonBasicSingle"
> extends-resource="component://common/widget/CommonForms.xml">...
>
> ###
>
> We understand that it's hard to read :) you can find the current work on
> our labs [3]
>
> Thanks for taking time to read this and any suggests are welcome
>
> Cheers,
> Gil, Leila, Nicolas
>
> [1] https://issues.apache.org/jira/browse/OFBIZ-11808
> [2]
> https://lists.apache.org/thread.html/r729c22dcba0b7c4e29979f5e65230ab140427addb3af8844f33108f5%40%3Cdev.ofbiz.apache.org%3E
> [3]
> https://labs.nereide.fr/10031/Communautaire/-/compare/trunk...DynamismWorkEffort
>
Re: Clojure service engine proposal for inclusion
Hi Ioan, Would it not be better for the community to be able to implement this set of functionalities by means of a downloadable plugin? It seems to me that - in a way - this levels up to plugins like the indexing (lucene) or the REST plugins. Not every adopters would be keen to have this by default OOTB. Best regards, Pierre Smits On Wed, Jul 28, 2021 at 10:23 PM Eugen Stan wrote: > Hello Nicolas, > > Thanks for the suggestions. > I've made a PR for this: > https://github.com/apache/ofbiz-framework/pull/317 > > * has a service test > * has a service example > > > (defn echo-service >"Echo back all the parameters" >[dctx ctx] >(doto (new java.util.LinkedHashMap) > (.putAll ctx) > (.put ModelService/RESPONSE_MESSAGE ModelService/RESPOND_SUCCESS))) > > > On 07.07.2021 09:58, Nicolas Malin wrote: > > Hello, > > > > Thanks for this detail email and your works. > > > > I'm not opposed to load closure in OFBiz code base for same reason that > > you exposed. > > > > For success the inclusion, I suggest to rename the namespace to > > org.apache.ofbiz, add test one framework/service/testdef and an example > > "hello world" service. > > > > Thanks Eugen ! > > > > Nicolas > -- > Eugen Stan > +40720 898 747 / netdava.com >
