Re: Rule to deprecate a service
Hi, Sorry to resurrect this thread. In relation with OFBIZ-11435, I have tried to clarify the information about deprecated services at https://s.apache.org/7pra2. I went back to the discussion in this thread to be sure to reflect the community decision. The initial reason which makes me change is that in the wiki we used "next release" when actually people are using "Upcoming branch" in code, which is consistent with Jira. I also wanted to clarify when and who should remove deprecated services. As described in the wiki, we implicitly decided it's a RM's (Release Manager) task. Because, so far, the RM creates the new branches. As I did not want to add a new wiki page only for that action, I updated the https://cwiki.apache.org/confluence/display/OFBIZ/Release+Management+Guide+for+OFBiz page, and added: /<>/ I hope I wrote things as simple as possible (here and in the wiki), please check! Jacques Le 29/09/2017 à 19:47, Nicolas Malin a écrit : Thanks for the work Jacques. Nicolas Le 29/09/2017 à 09:49, Jacques Le Roux a écrit : Done at https://s.apache.org/12Uq Jacques Le 14/08/2017 à 18:05, Jacques Le Roux a écrit : Thanks Nicolas :) It's with mine at least and I guess Jacopo's, Scott's and Deepak's, right guys? W/o answers I will soon consider the status quo a consensus ans will write the rules in wiki Jacques Le 14/08/2017 à 14:51, Nicolas Malin a écrit : Le 14/08/2017 à 07:48, Deepak Dixit a écrit : Thank Jacques, The code that has been deprecated before December 2014 will be released in the releases of the 14.12 branch: in this way users will be notified about deprecated methods/code. I am also on same page . We tag code deprecated as a part of release and these code will be removed from next release. Lets say we set Release 17.XX as deprecated for an service, this service will be part of Release17.XX and will be removed in next Release 18.XX Sometime it would be good to stop my work when I'm tired :) I restart my example because it's wrong with my brain : Imagine we are the 30 december 2019 and we decide to create a new release. We have on trunk : * addCatalogMember deprecated since="next release" * deleteWorkEffortAssignment depraceted since="18.12" We prepare the release, we have on trunk : * addCatalogMember deprecated since="19.12" * 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" It's in coherence with your remark Deepak ? Nicolas Thanks & Regards -- Deepak Dixit www.hotwaxsystems.com www.hotwax.co On Sat, Aug 12, 2017 at 2:33 PM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: Thanks Nicolas, Actually when I read OFBIZ-6273 it seems Jacopo are on the same page than me: The code that has been deprecated before December 2014 will be released in the releases of the 14.12 branch: in this way users will be notified about deprecated methods/code. For this reason we can proceed and remove all the deprecated code from trunk, deprecated before December 2014. Anyway I'd like to have more opinions about *when to remove deprecated code before writing definitive rules about it*. It seems Jacopo, Scott and I are on the same page (please confirm guys). And you Nicolas propose something which lets more time to users. This is maybe not a bad idea, our users are our most important assets! Jacques Le 11/08/2017 à 20:52, Nicolas Malin a écrit : 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
Re: Theme files loading taking longer time
Le 11/05/2020 à 16:56, Nicolas Malin a écrit : (and I don't understand why I haven't did at the beginning) Hi Nicolas, Could be because of the partialPath parameter of findXmlFiles(). It's a bit confusing at 1st glance, this method lacks of documentation :/ Jacques
Re: Rule to deprecate a service
Forgot to mention that we have so far never removed a deprecated services. Not surprising, the feature is rather new. Le 11/05/2020 à 21:22, Jacques Le Roux a écrit : Hi, Sorry to resurrect this thread. In relation with OFBIZ-11435, I have tried to clarify the information about deprecated services at https://s.apache.org/7pra2. I went back to the discussion in this thread to be sure to reflect the community decision. The initial reason which makes me change is that in the wiki we used "next release" when actually people are using "Upcoming branch" in code, which is consistent with Jira. I also wanted to clarify when and who should remove deprecated services. As described in the wiki, we implicitly decided it's a RM's (Release Manager) task. Because, so far, the RM creates the new branches. As I did not want to add a new wiki page only for that action, I updated the https://cwiki.apache.org/confluence/display/OFBIZ/Release+Management+Guide+for+OFBiz page, and added: /<>/ I hope I wrote things as simple as possible (here and in the wiki), please check! Jacques Le 29/09/2017 à 19:47, Nicolas Malin a écrit : Thanks for the work Jacques. Nicolas Le 29/09/2017 à 09:49, Jacques Le Roux a écrit : Done at https://s.apache.org/12Uq Jacques Le 14/08/2017 à 18:05, Jacques Le Roux a écrit : Thanks Nicolas :) It's with mine at least and I guess Jacopo's, Scott's and Deepak's, right guys? W/o answers I will soon consider the status quo a consensus ans will write the rules in wiki Jacques Le 14/08/2017 à 14:51, Nicolas Malin a écrit : Le 14/08/2017 à 07:48, Deepak Dixit a écrit : Thank Jacques, The code that has been deprecated before December 2014 will be released in the releases of the 14.12 branch: in this way users will be notified about deprecated methods/code. I am also on same page . We tag code deprecated as a part of release and these code will be removed from next release. Lets say we set Release 17.XX as deprecated for an service, this service will be part of Release17.XX and will be removed in next Release 18.XX Sometime it would be good to stop my work when I'm tired :) I restart my example because it's wrong with my brain : Imagine we are the 30 december 2019 and we decide to create a new release. We have on trunk : * addCatalogMember deprecated since="next release" * deleteWorkEffortAssignment depraceted since="18.12" We prepare the release, we have on trunk : * addCatalogMember deprecated since="19.12" * 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" It's in coherence with your remark Deepak ? Nicolas Thanks & Regards -- Deepak Dixit www.hotwaxsystems.com www.hotwax.co On Sat, Aug 12, 2017 at 2:33 PM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: Thanks Nicolas, Actually when I read OFBIZ-6273 it seems Jacopo are on the same page than me: The code that has been deprecated before December 2014 will be released in the releases of the 14.12 branch: in this way users will be notified about deprecated methods/code. For this reason we can proceed and remove all the deprecated code from trunk, deprecated before December 2014. Anyway I'd like to have more opinions about *when to remove deprecated code before writing definitive rules about it*. It seems Jacopo, Scott and I are on the same page (please confirm guys). And you Nicolas propose something which lets more time to users. This is maybe not a bad idea, our users are our most important assets! Jacques Le 11/08/2017 à 20:52, Nicolas Malin a écrit : 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
Re: new script-template> widget
Hi Jacques, I think having RequireJs for loading dependencies, can go in another JIRA issue. It requires us to change the way Javascript coding is done. Regards, James On 2020/05/10 12:58:49, Jacques Le Roux wrote: > Hi James, > > I know it's not all of them as you already mentioned. But could not some > these of these scripts be handled by Require.js? > > Jacques > > Le 10/05/2020 à 14:32, James Yong a écrit : > > Hi Michael, > > > > There are CSP errors being logged in the browser console, due to the use of > > inline javascripts. > > > > The proposed method allow us to: > > 1. convert the inline javascripts into external scripts for better CSP > > compliance. > > 2. use freemarker macros in the scripts. > > 3. place the extracted javascript in the same directory as the original > > freemarker template file, to save time locating and editing the 2 related > > files. > > > > Regards, > > James > > > > On 2020/05/10 09:53:47, Michael Brohl wrote: > >> Hi James, > >> > >> can you explain the purpose of this? Why not just use a JavaScript file > >> and a decorator? > >> > >> Thanks, > >> > >> Michael Brohl > >> > >> ecomify GmbH - www.ecomify.de > >> > >> > >> Am 10.05.20 um 06:53 schrieb James Yong: > >>> Hi all, > >>> > >>> I have created a JIRA issue for this, i.e. OFBIZ-11686. > >>> Decided not to have a placement attribute because script will always be > >>> placed after body tag. > >>> > >>> Regards, > >>> James > >>> > >>> On 2020/05/07 11:48:32, James Yong wrote: > Hi all, > > Propose a new widget tag that adds an external script > inside html head tag, or after body tag. The external script will > contain the rendered result of the specified template file location. > e.g. > > > location="component://order/template/quote/test.ftl” placement=“head”/> > > will render as: > > > … >
Re: new script-template> widget
Hi James, Yes, it already exists. Unfortunately for years as it's a major change. https://issues.apache.org/jira/browse/OFBIZ-9976 It will be interesting to see if after your proposed effort much work remains for require.js. It could be then done... Jacques Le 11/05/2020 à 12:21, James Yong a écrit : Hi Jacques, I think having RequireJs for loading dependencies, can go in another JIRA issue. It requires us to change the way Javascript coding is done. Regards, James On 2020/05/10 12:58:49, Jacques Le Roux wrote: Hi James, I know it's not all of them as you already mentioned. But could not some these of these scripts be handled by Require.js? Jacques Le 10/05/2020 à 14:32, James Yong a écrit : Hi Michael, There are CSP errors being logged in the browser console, due to the use of inline javascripts. The proposed method allow us to: 1. convert the inline javascripts into external scripts for better CSP compliance. 2. use freemarker macros in the scripts. 3. place the extracted javascript in the same directory as the original freemarker template file, to save time locating and editing the 2 related files. Regards, James On 2020/05/10 09:53:47, Michael Brohl wrote: Hi James, can you explain the purpose of this? Why not just use a JavaScript file and a decorator? Thanks, Michael Brohl ecomify GmbH - www.ecomify.de Am 10.05.20 um 06:53 schrieb James Yong: Hi all, I have created a JIRA issue for this, i.e. OFBIZ-11686. Decided not to have a placement attribute because script will always be placed after body tag. Regards, James On 2020/05/07 11:48:32, James Yong wrote: Hi all, Propose a new widget tag that adds an external script inside html head tag, or after body tag. The external script will contain the rendered result of the specified template file location. e.g. This will allow inline script from a freemarker file, to be rendered as external script in html. Regards, James
Re: Have a README.TXT file in release package
Thank you All for your answers, I like the idea of creating a simple INSTALL file with minimum installation information and redirection to more documentation I created https://issues.apache.org/jira/browse/OFBIZ-11691 for that Jacques Le 10/05/2020 à 18:43, Jacques Le Roux a écrit : Hi, We often get questions from people not reading the basic documentation. Like not able to run Gradle because ignoring init-gradle-wrapper scripts. I know there will always people not reading the documentation. But maybe, to prevent most obvious questions and tempting RTFM answers, we could add a small README.TXT with basic information in OFBiz root. It would ultimately refer to README.adoc. Also saying that README.adoc can be read with a text reader tool. And it's easy to follow https://asciidoctor.org/docs/convert-documents/#converting-a-document-to-html What do you think? Jacques
Re: New Online Help, need some ideas
Hi community, First step about Docbook migration to asciidoc is done, all existing files have been converted (waiting a review before PR merge) Next step is to have a new help system, I propose to do a very simple solution which would be a link to a documentation site. This solution would use 1. at ofbiz level, a default proprety for documentation website uri 2. at the screen level * it would be possible to give a other uri (for user documentation) * if the anchor in the user documentation for this screen is put, the new help is used otherwise the older link is used If this solution is validated, next step will be to update all the screens with the correct link value I propose to create the Jira (and the implmentation) with this very simple solution (using the doc generated by Buildbot as documentation site) when some other people with a good knowledge of gradle and/or ofbiz cms have time to do a internal documentation website, it will be possible to change the default uri ;-) what's your opinion about ? Le 26/02/2020 à 17:10, Olivier Heintz a écrit : > inline > > Le 26/02/2020 à 14:02, Taher Alkhateeb a écrit : >> Hello Olivier, >> >> Without digging into much detail, I can say that it's a good idea to >> switch the online help system to asciidoc. >> >> The current structure of asciidoc templates is designed to be a full >> manual document. To link up different pages to different sections, you >> need to break the documentation down to smaller files and then combine >> them. This way you can have both the "big" manual and the "per screen" >> help section. > > In my experience, as I'm working with > - current ofbiz online help > - ofbiz webhelp > - some static doc website done with Grav (build with multiple small files) > - some static doc website done with asciidoc (only one large file) > - ... > > With multiple small files it's needed to have a very good search engine and a > global index / TOC > > With the One page doc, the TOC is very large and not always very convenient, > but exist and the browser-find works > and it's easy to navigate between details and generality > > So, as a user, I prefer help base on One page documentation. >> >> Also, gradle might not be enough for online help. A more robust >> solution could involve integrating asciidoc at the framework level to >> dynamically generate help. So this is another idea to consider. > > When we have tried, in the past to dynamically generate html from standard > docbook process it was too slow > it's why it was decide to use a freemarker template to do the generation, > even if only 5% of docbook syntax > was managed. > > Documentation not change very often, static page seem enough for our need. > >> >> On Wed, Feb 26, 2020 at 2:29 PM Olivier Heintz wrote: >>> >>> Hi all, >>> >>> Currently OFBiz Online help work with docbook files with html generation >>> done by a ftl template. >>> Link between screen and file to show is done with some content associated >>> with key-word >>> >>> Decision has been done to no more used docbook format but now use asciidoc >>> format. >>> >>> User-manual.adoc should be the new reference for user help. How to use it >>> for online help ? >>> >>> I think it's important that online help is link to a internal help (which >>> can be modified) not to a Apache-OFBiz-website-Help >>> but this point of view can be discuss. >>> >>> To be able to have OFBiz internal help, three points should be solved : >>> 1) with asciidoc we have multiple documentations, it seem important to have >>> a "website" to be able to access easily all the doc. >>>how to "encapsulate" each html documentation generated in a "website" >>> 2) generation doc process put html and pdf files in build directory, how >>> it's possible to access them from ofbiz >>> 3) For online help it's necessary to be able to create link between screen >>> and html anchor. >>>In documentation generate from asciidoc, all title can be used. >>>How to to say this screen should go to this documentation at this title. >>> >>> I suppose content application, can help to solve this points. >>> I need some help from OFBiz-Content experts. >>> >>> For point (1) I'm using jBake but maybe it's possible to do something >>> similar with templating in Content >>> Who has some idea ? >>> >>> For point (2) I suppose it's a "gradle configuration" and "content >>> configuration" >>> Who has some idea ? >>> >>> For point (3) the more simple solution is to add 1 (or 2) field in context >>> which contain help_title,(help_documentation) and >>> so it will be simple to build the correct help link >>>
Hiding the irrelevant applications
Hi, I want to remove the irrelevant applications/Component . How to do this??? Also, can we extend an service and share to third party application for access .
Re: Theme files loading taking longer time
Hello Pawan, By default I use de basePath to include themes and plugins directory. With this we can load a theme by the plugins system. So two possibilities, reduce the path to only these tow directories (and I don't understand why I haven't did at the beginning) or exclude the possibility to load a theme as plugin Nicolas On 07/05/2020 16:03, Pawan Verma wrote: > Thank you all for the feedback. Here is the Jira ticket: > https://issues.apache.org/jira/browse/OFBIZ-11665 pEpkey.asc Description: application/pgp-keys
Re: Hiding the irrelevant applications
Hi, Your message has been moderated (again), else it would not have reached this Mailing List. Please subscribe to the user ML for such questions and then use your email client. See why here http://ofbiz.apache.org/mailing-lists.html. You will get a better support, people can answer you on the ML. The wider the audience the better the answers you might get. Also it's more work for moderators who have to accept your messages as long as you have not subscribed. I'll personally no longer accept them (other moderators still could). Thanks Jacques Le 11/05/2020 à 13:36, Atul Dhengre a écrit : Hi, I want to remove the irrelevant applications/Component . How to do this??? Also, can we extend an service and share to third party application for access .
