Fixing logs in demo-stable
Hello, I noticed today that there have been no writes to log files on the demo-stable instance since the 11th August. The following is some notes on what went wrong and how log file permissions are implemented in our docker containers. Hopefully these will be useful if someone is investigating log issues with the demo sites in future. Notes: Looking at the git log of the release18.12 branch, I couldn't see any commits related to logging on or prior to the 11th August. I opened a terminal to the ofbiz VM, changed to the /home/ofbizdocker/demo-stable directory and then ran the following command to output the console log, piping to the less command: ``` docker compose logs | less ``` Logging is configured in the framework/base/config/log4j.xml file. In this file I can see that all the log appenders refer to files with the path runtime/logs. These paths are relative to the current working directory, which is /ofbiz inside the demo containers. I searched for 'runtime/logs' in the console log and found errors similar to the following: demo-stable-ofbiz-1 | 2024-10-04 02:35:08,031 main ERROR RollingFileManager (runtime/logs/ofbiz.log) java.io.FileNotFoundException: runtime/logs/ofbiz.log (Permission denied) java.io.FileNotFoundException: runtime/logs/ofbiz.log (Permission denied) I knew that the /ofbiz/runtime/logs/ofbiz.log file existed. From the host system I could check the permissions of the file with ``` ls -l /home/ofbizdocker/demo-stable/logs/ofbiz.log ``` -rw-r--r-- 1 166536 166536 8970237 Aug 11 02:35 /home/ofbizdocker/demo-stable/logs/ofbiz.log The owning user is uid 166536 and the owning group is gid 166536. These values might seem a bit strange, but they relate to a feature we use in docker called User Namespaces[1] where a uid or gid of a process running in a container is mapped to a different and non-privileged uid or gid on the host. That way, if a process somehow 'breaks out' of its container, it will not have any useful privileges on the host. We configure user namespaces such that uids and gids within running containers are mapped to values 165536 higher on the host system. Therefore if the ofbiz.log file is owned by uid 166536, this maps to user 1000 inside the demo-stable docker container. To quickly see which uid the various java processes on the host are running as, we can use: ``` root@ofbiz-vm1:/home/ofbizdocker/demo-stable# ps auxf | grep java | cut -c1-80 166537 1829545 3.3 3.5 6349340 1176440 ? Ssl 02:35 25:59 \_ /opt/java 166536 1830554 4.2 5.9 7056352 1964308 ? Ssl 02:35 33:09 \_ /opt/java 166536 1831670 1.9 6.0 7052264 1974948 ? Ssl 02:36 15:02 \_ /opt/java 166536 1832608 0.4 1.9 6868992 654896 ? Ssl 02:36 3:37 \_ /opt/java 166536 1833105 0.4 1.5 6878208 524976 ? Ssl 02:36 3:15 \_ /opt/java 166536 1833609 0.4 2.2 6872852 739020 ? Ssl 02:36 3:33 \_ /opt/java ``` The first column is the uid for each process. Notice that one of the processes has a different uid 166537 to the rest. Next, we run a bash process inside the demo-stable ofbiz container and check the uid of the current user: ``` root@ofbiz-vm1:/home/ofbizdocker/demo-stable# docker compose exec ofbiz /bin/bash ofbiz@47c06d728af8:/ofbiz$ id uid=1001(ofbiz) gid=1001(ofbiz) groups=1001(ofbiz) ``` Notice that the uid and gid is 1001, rather than the expected 1000. It seems that the uid of the ofbiz user changed from 1000 to 1001 in our demo-stable container images around August 11th. To fix the permissions issue, change the owning uid and gid of the demo-stable's log directory on the host to match the user running in the container, and then restart the container: ``` root@ofbiz-vm1:/home/ofbizdocker/demo-stable# chown -R 166537:166537 logs/ root@ofbiz-vm1:/home/ofbizdocker/demo-stable# docker compose restart ``` The demo-trunk and demo-next containers do not appear to have the uid/gid mismatch issue since they are built from a different base container image that the demo-stable container. Although the above changes to permissions in the demo-stable log directory solved our issue, it perhaps shows a weakness in how the ofbiz user is added to our container images. Perhaps the container image build process needed to hard-code a uid/gid for the ofbiz user during container build to try and ensure consistency. [1] - https://docs.docker.com/engine/security/userns-remap -- Daniel Watford
Re: (ofbiz-tools) branch master updated: Replaces 22.01 branch by 24.09 as stable
Hi Jacques, I have just checked on the ofbiz-vm1 host and can see that you have already updated the demo-next container to use container images from the 24.09 branch - thank you. Everything looks correct to me. I've removed the old demo-next log files. Thanks, Dan. On Wed, 11 Sept 2024 at 17:42, Jacques Le Roux wrote: > Thanks to check Nicolas, > > With Docker, Dan has much simplified things. The BB script is also now > easy to change*. > If we did not miss anything, things happens as we know, as long as the fan > is not on that should OK :) > > Jacques > > * > https://svn.apache.org/repos/infra/infrastructure/buildbot2/projects/ofbiz.py > > Le 11/09/2024 à 18:03, Nicolas Malin a écrit : > > Thanks Jacques ! > > > > I currently check the different change to do on CI , because I follow > your and Dan works so far :( > > > > Nicolas > > > > Le 11/09/2024 à 17:07, jler...@apache.org a écrit : > >> This is an automated email from the ASF dual-hosted git repository. > >> > >> jleroux pushed a commit to branch master > >> in repositoryhttps://gitbox.apache.org/repos/asf/ofbiz-tools.git > >> > >> > >> The following commit(s) were added to refs/heads/master by this push: > >> new 2d66d54 Replaces 22.01 branch by 24.09 as stable > >> 2d66d54 is described below > >> > >> commit 2d66d54ebb3f0b4eb922e9278b2c91422bdc81ce > >> Author: Jacques Le Roux > >> AuthorDate: Wed Sep 11 17:07:51 2024 +0200 > >> > >> Replaces 22.01 branch by 24.09 as stable > >> --- > >> demo-backup/ofbizdocker/home/ofbizdocker/demo-next/docker-compose.yml | > 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git > a/demo-backup/ofbizdocker/home/ofbizdocker/demo-next/docker-compose.yml > >> b/demo-backup/ofbizdocker/home/ofbizdocker/demo-next/docker-compose.yml > >> index b5f2240..7cf5651 100644 > >> --- > a/demo-backup/ofbizdocker/home/ofbizdocker/demo-next/docker-compose.yml > >> +++ > b/demo-backup/ofbizdocker/home/ofbizdocker/demo-next/docker-compose.yml > >> @@ -14,7 +14,7 @@ services: > >> - ofbiz-postgres.env > >> ofbiz: > >> -image: ghcr.io/apache/ofbiz:release22.01-plugins-snapshot > >> +image: ghcr.io/apache/ofbiz:release24.09-plugins-snapshot > >> mem_limit: 2400M > >> memswap_limit: 2400M > >> cpu_shares: 200 > >> > -- Daniel Watford
Re: [VOTE] [BRANCH] Create next stable Apache OFBiz branch : release24.09
+1 On Fri, 6 Sept 2024 at 13:29, Nicolas Malin wrote: > This is the vote thread to create the next stable branch "release24.09" > from the current trunk > > If you need more information, please refer to this thread [1] > > Vote: > [ +1] create the next stable branch "release24.09" > [ -+0] feel free > [ -1] do not create the branch > > This vote is open for at least 5 days. > > For more details about this process please refer to > http://www.apache.org/foundation/voting.html > > -- > > [1] https://lists.apache.org/thread/k903dobd1z0hm9qxo3prn8gzc71jrnx1 > > -- Daniel Watford
Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap
+1 Sounds good to me. On Tue, 3 Sept 2024 at 14:21, Nicolas Malin wrote: > Hello, > > After going through this thread [1], I propose to go ahead with the > creation of the `release24` branch in a few weeks, and the release of > the next official version 2 or 3 weeks later. > > Why: > * We've decided to leave release22.01 unpublished. > * The trunk has been stable for a long time (integration tests are > working well). > * The current version is over 6 years old > * If we wait another year for stabilization, there's a chance that a > lot of work-in-progress will be added, and as with release 22, we'll > probably miss the release stage. > * We have a lot of work to do on the trunk :D > > If there are no major objection, I'll put the release24 branch creation > to the vote in a few days. > > Nicolas > > [1] https://lists.apache.org/thread/k903dobd1z0hm9qxo3prn8gzc71jrnx1 > -- Daniel Watford
Re: 回复：URL Issue
[Only sending to dev mailing list as is an application architecture related comment] I don't have a solution to offer yet around the URL issue raised by Johan, but have a feeling it it will relate to the issue below. This is a message to highlight a deep unease I have around the OFBiz use of query arguments in URLs to carry authentication/session information between client and server. In particular, clickable links between applications in the client are rendered with the externalLoginKey query argument since each application maintains its own login mechanism and session cookie. One immediate problem I see is if a user right-clicks a link to copy the URL target, and then shares that URL, they have unwittingly also shared a credential that will allow recipients of the URL to masquerade as the original user. I assume the reason for tying session cookies to applications, rather than to the root of the OFBiz website, is to ensure a separation between back-end office applications and front-end ecommerce applications. As mentioned, I don't have a solution to offer at the moment, but perhaps we should looks at configuring the applications with the names of their session cookies. All the back-end applications could then use a single 'backend' cookie, and any front-end consumer facing application could have their own distinct session cookie. Thanks, Dan. On Thu, 29 Aug 2024 at 09:17, Jacques Le Roux wrote: > Hi, > > Finally it's not that clear. > > As can be found in trunk demo access_logs, such URLs exist at least since > June 17 2024. > > access_log.2024-06-17:28:66.249.75.98 - - [17/Jun/2024:00:11:51 +] > "GET > > /partymgr/control/main%3FexternalLoginKey=ELf5183769-2759-476b-946c-2a70afe3c42d&sortField=partyId;jsessionid=EBB57C6C3C345E70501827509E05744C.jvm1 > HTTP/1.1" 500 1165 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X > Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.6422.175 > Mobile Safari/537.36 (compatible; Googlebot/2.1; + > http://www.google.com/bot.html)" > > As you can see they are rejected (HTTP 500) since then too. Actually I > guess they exist for a very long time. Have yet no idea why and how these > URLs > are generated. > > The rejection is "new" and due to a security fix done in May 20 2024 with > (OFBIZ-13092) "Prevent special encoded characters sequences in URLs" > > So we need to clearly define steps to manually generate these URLs. Then, > if it's OK, we could allow URLs containing ";jsessionid=" to bypass the > security filter. > > I copy this email to the dev ML because of its importance > > Jacques > > > Le 28/08/2024 à 15:27, Jacques Le Roux a écrit : > > Thanks Guys, > > > > I could not reproduce yet, but I think we have already enough clues to > fix that. > > Also I can find a lot of in trunk demo log. That will be helpful too. > > > > Jacques > > > > Le 27/08/2024 à 16:20, 雷咩咩 a écrit : > >> i can reproduce by login with admin, randomly click severl places, then > when click logout, see such error: > >> > >> > >> HTTP Status 500 – Internal Server Error > >> Type Exception Report > >> > >> > >> Message For security reason this URL is not accepted > >> > >> > >> Description The server encountered an unexpected condition that > prevented it from fulfilling the request. > >> > >> > >> Exception > >> > >> > >> java.lang.RuntimeException: For security reason this URL is not accepted > >> > > org.apache.ofbiz.webapp.control.ControlFilter.doFilter(ControlFilter.java:144) > >> > > org.apache.logging.log4j.web.Log4jServletFilter.doFilter(Log4jServletFilter.java:71) > >> Note The full stack trace of the root cause is available in the server > logs. > >> > >> > >> Apache Tomcat/9.0.91 > >> > >> > >> > >> > >> Regards, > >> Yang > >> > >> > >> -- 原始邮件 -- > >> 发件人: "user" >> 发送时间: 2024年8月27日(星期二) 晚上9:12 > >> 收件人: "user" >> > >> 主题: URL Issue > >> > >> > >> > >> Hi, > >> > >> Not sure if anyone would be able to assist me, I have found an issue > which > >> can also be replicated within the demo. > >> This issue normally occurs as you navigate to a module after login. It > is > >> not easily replicable, once you refresh it works and does not occur > again. > >> Replicated the issue in multiple modules. > >> It usually adds ;jsessionid=##.jvm1 to all the URLs > and > >> this causes a navigation issue. > >> Once you submit a form or try to click the logout link, an Internal 500 > >> Internal Server Error is being returned > >> As an example: > >> https://demo-stable.ofbiz.apache.org/partymgr/control/main > >> > >> I have screenshots available, however I am not able to attach to this > mail. > >> Please let me know if you need me to upload it somewhere. > >> > >> Kind Regards, > >> Johan Cronjé -- Daniel Watford
Re: Welcome to Sebastian Tschikin as new committer
Great news! Welcome aboard, Sebastian. Dan. On Thu, 20 Jun 2024 at 15:21, Jacopo Cappellato wrote: > The OFBiz PMC has invited Sebastian Tschikin to become a committer and > we are pleased to announce that Sebastian has accepted. > > On behalf of the OFBiz PMC, welcome on board! > -- Daniel Watford
Re: Docker and new release branch
Hi Jacques, No documentation on how to handle the creation of a new release branch (and nether the retirement of an old stable branch). When the new branch is created, I'll take care of updating the docker related build processes and deployments to the demo server. I'll also write up some documentation about the process at the same time (including updating the WIKI page you linked to) On Sat, 25 May 2024 at 10:37, Jacques Le Roux wrote: > Le 25/05/2024 à 11:32, Jacques Le Roux a écrit : > > Hi Daniel, > > > > I don't remember if we talk about that already, sorry if it's the case. > > > > Have we a documentation on how to update Docker for demos in case of > the creation of a new release branch? > > > > TIA > > > > Jacques > And please add a link at > > https://cwiki.apache.org/confluence/display/OFBIZ/Release+Management+Guide+for+OFBiz#ReleaseManagementGuideforOFBiz-Creatinganewreleasebranch > -- Daniel Watford
Proposal: Merge (bundle) selected plugins into ofbiz-framework
Hello all, Following on from discussions around a previous proposal regarding merging _all_ plugins into ofbiz-framework [1], I would like to instead propose that we consider 'bundling' _some_ selected plugins into ofbiz-framework. The bundled plugins would be those deemed important enough by the development community that we want to ensure they continue to build and are updated alongside the core OFBiz code. These would be the plugins that the development community is prepared to expend effort maintaining. Those selected (bundled) plugins would then be regularly built as part of the CI process and their code processed by the various analysis tools we utilise. The bundled plugins should be disabled by default. We may then need to create guidance or some technical solution to help users enable only those bundled plugins that they need. (We have example code to enable/disable plugins in the Docker startup scripts). With those important plugins bundled as part of ofbiz-framework, we could then consider excluding the ofbiz-plugins repository from the release process. System integrators would be responsible for retrieving any non-bundled plugins that they use as part of their deployment process. If bundling key plugins into ofbiz-framework is considered worthwhile, which plugins should we bundle? Some suggestions might be: - REST-API - ecommerce - birt (assuming it is brought up to date and is secure) - passport / ldap - solr Please refer to [1] for some of the possible benefits and negatives to the above as I think they are mostly still relevant even if only bundling a subset of plugins into ofbiz-framework. Thanks, Dan. [1] https://lists.apache.org/thread/jhjohny4ovb2tnpo6qpcwmz5m6513f57 -- Daniel Watford
Re: [VOTE] Apache OFBiz 18.12.09
Hi Jacques, I raised the topic of merging the plugins into ofbiz-framework a while ago, mostly due to the difficulty I found matching branches between the ofbiz-framework and ofbiz-plugins repositories and keeping the two in sync. I don't think we went in depth on the topic, but I think the general preference of the dev mailing list was to keep the two repositories separate. However, given your points about 'fragile' plugins, perhaps we could consider moving those plugins we feel are robust and well used into ofbiz-framework and leave those fragile plugins in the ofbiz-plugins repository? I know that I am banging the same old drum again with the above suggestion(!) but I really do feel we will be able to better maintain those favoured plugins more easily if they are kept alongside the core ofbiz-framework code. The additional benefit is that it will be easier to release those plugins we are more confident of if they are already in the ofbiz-framework repository. Perhaps we would then mark those plugins as disabled by default. As far as 'framework only' distributions, I think this should be the default approach we point users of ofbiz to. Interested users can then seek out the plugins that meet their needs and install them by either retrieving the relevant plugin files or running the appropriate gradle task. We already have framework-only versions of the docker images that we publish. Thanks, Dan. On Mon, 20 May 2024 at 08:08, Jacques Le Roux wrote: > Hi, > > This thread is already a 7 month "discussion", actually a vote. But I > don't remember another about this point (not releasing the plugins). So I > reuse > it, with a security perspective. > > The last CVEs we had are possible because of ecommerce. A bunch of others > were related to Solr, etc. > > I believe we would have much secure OFBiz releases if indeed we did not > include the more fragile plugins. > > On the other hand when we fix these plugins vulnerabilities we also secure > their usage by our users. > > But for ecommerce the problem is you can create an user without being > signed on. Because it's about open ecommerce. We can't seriously change > that, > can we? > > Also I wonder how much people are using all the plugins. For some of them > I guess not much. > > So what do you thing about Jacopo's proposition? > > Jacques > > Le 02/11/2023 à 11:18, Jacopo Cappellato a écrit : > > Yes, the plugins are included in all the releases of 18.12; for newer > > release branches we can definitely revisit this decision (in fact I > > think it would be nice to have framework only distributions). -- Daniel Watford
Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap
Hi Jacques, I'm sorry, but I can't quite parse your question, 'What is the difference...'. Could you restate it another way? Are you asking what the difference is between enforcing a feature-freeze on trunk versus continuing to allow all changes to trunk whilst having a feature-freeze on a release branch (e.g. release-24.x)? I think it will be very difficult to define a prescriptive policy on what sort of fixes might be permitted on a release branch (e.g. release-24.x), but the availability of committers to do the work of applying patches to the branch might help us reach a de facto policy. I personally would want to avoid backporting changes from trunk to a release branch without good reason since I view this as duplicate work. Therefore I would only want to backport fixes from trunk to release where we have a defect that impacts users or if we felt that some new feature was very very very important to OFBiz that it couldn't wait for the future release branch. If it helps, the project has used the phrase 'This series has been stabilized with bug fixes since' on the Release History page: https://downloads.apache.org/ofbiz/. I would interpret this as the release branch was used to *stabilise* the features that were in trunk at the time the release branch was created. I fear that we all might be roughly in agreement but getting lost in the weeds of discussion. Should we go ahead and create a release-24.05 branch from trunk soon for the purpose of stabilising a future release? Or are there any important features that OFBiz developers want to see in trunk first? As far as which commits are later applied to the release-24.05 branch, shall we leave that up to the committers at the time, but with a reminder that adding new features on the release-24.05 branch will increase the test burden before a public release can be made? Thanks, Dan. On Tue, 7 May 2024 at 15:20, Jacques Le Roux wrote: > What is the difference between freezing the trunk in a release-24.xx where > the rule is no improvements but if a consensus agrees with? In other words, > apart exceptions only bugs and not only blockers,as we did so far and the > "new" proposition? Do we really wants to backport only blockerbugs? And > then > what is a blocker bug, only security? > > Somehow related, I also remember we freezed the trunk in few branches that > we never released. 14.12 and 15.12 come to mind: > https://ofbiz.apache.org/download.html > > HTH > > Jacques > > Le 07/05/2024 à 15:11, Pranay Pandey a écrit : > > Dear Daniel, > > > > Thank you for outlining the proposed release strategy for OFBiz. I liked > > the idea of creating a new branch from trunk named 'release-24.05' to > > address blockers for the upcoming release. > > > > I agree with Michael's proposal that targeting a release while working on > > the trunk is worth considering. Maintaining a consistent flow of new > > releases is crucial for project success. New releases with smaller > changes > > are not only easier to adopt but also facilitate a smoother migration for > > existing ERP implementations, especially if users find value in the new > > features introduced. > > > > I believe this approach aligns well with the project's goals and will > help > > in ensuring a structured and efficient release process. Let's continue > the > > discussion on how we can further enhance this strategy to benefit the > OFBiz > > development community. > > > > Thank you for your efforts in driving this conversation forward. > > > > Best regards, > > > > Pranay Pandey > > > > > > On Tue, 7 May 2024 at 13:36, Daniel Watford wrote: > > > >> Hello all, > >> > >> I'm a little confused by what the differences in opinions actually are > in > >> this thread. I think this is because the differences are minor and we > are > >> probably close to an agreement on how to proceed. > >> > >> Although there are not many of us involved in this conversation, it > seems > >> there is a desire to NOT impose any sort of feature freeze on the trunk > >> branch. > >> > >> Instead we take the approach of creating a new branch from trunk, named > >> something like 'release-24.05'. The purpose of this new branch is to > >> address any issues that might be considered blockers for an upcoming > OFBiz > >> release. New features would not normally be applied to the release-24.05 > >> branch, but exceptions to this rule would be considered on a > case-by-case > >> basis. > >> > >> Issues blocking an OFBiz 24.05.xx release would be tracked
Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap
Hello all, I'm a little confused by what the differences in opinions actually are in this thread. I think this is because the differences are minor and we are probably close to an agreement on how to proceed. Although there are not many of us involved in this conversation, it seems there is a desire to NOT impose any sort of feature freeze on the trunk branch. Instead we take the approach of creating a new branch from trunk, named something like 'release-24.05'. The purpose of this new branch is to address any issues that might be considered blockers for an upcoming OFBiz release. New features would not normally be applied to the release-24.05 branch, but exceptions to this rule would be considered on a case-by-case basis. Issues blocking an OFBiz 24.05.xx release would be tracked in Jira, and once addressed the release would be made public. A suitable tag - e.g. release-24.05.01 - would be applied to the release-24.05 branch to denote the commit that was publicly released. I believe the above describes how the OFBiz project has managed releases in the past. The discussions around a road map are orthogonal to the above release process, but would definitely help the OFBiz development community/PMC decide when would be an appropriate time to create a new release branch. It seems like the major project undertakings - such as the movement of Groovy Scripts within the source tree - have been completed, so now might be a good time to go ahead and create the release-24.05 branch from trunk. Thanks, Dan. On Mon, 6 May 2024 at 18:01, Jacques Le Roux wrote: > Le 06/05/2024 à 18:35, Jacques Le Roux a écrit : > > BTW, to avoid to speak in the void. Again, what are those tasks > precisely? And that are their situations? > > BTW, to avoid to speak in the void. Again, what are those tasks precisely? > And WHAT are their situations? > > Sorry, typo > > -- Daniel Watford
Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap
Hi Michael, I'm broadly in favour of your proposal, but perhaps with a slightly different 'shape' to the approach. I too was hoping that we could freeze trunk before creating a 24.x release branch as I was concerned about the about of duplicate work (backporting) that might need to be done if we took a 24.x release branch earlier in the year, but alas trunk marches on and I think it will be difficult to mandate a period of release-related-only changes in trunk. Instead I think, as Deepak mentioned, we should take a new 24.x branch to use for stabilisation - with tags denoting the actual releases along that branch. It feels that the large projects - such as groovy-scripts migration - have completed which should reduce the amount of rework that would have to take place simultaneously on trunk and the 24.x release branch. >From your comments I infer that you may be suggesting yearly releases. I think this is a good idea as it will allow the introduction of major new functionalities in trunk without needing to wait years for them to become generally accessible. Without more frequent releases we will have the temptation to port major functionality into already existing release branches which might take a large amount of effort and could introduce instability between minor releases. I hope my inference reflects your intended proposal! :) Yes to a roadmap. Thanks, Dan. On Sun, 21 Apr 2024 at 14:50, Michael Brohl wrote: > Hi everyone, > > we agreed to work towards a stabilizing trunk to be able to create a > 24.x release branch, which means we have to thoroughly decide which > changes should go into trunk. There are currently lots of changes going > into trunk with PR's created and rapidly be merged into the codebase. > This causes potential for errors being introduced in trunk, potentially > leading to delay the creation of the next release branch even more. > > In my opinion, this is contraproductive to the goal of creating a stable > release branch 24.x in due time. > > I propose to make a decision to have a code freeze for new features and > improvements and focus on bug fixes until we have created a 24.x branch. > > I also propose that we start organizing a roadmap to give the community > some guidelines where to focus and which main features can be expected > in the next release branches. It might also give developers some goals > to provide the features according to planned releases and maybe work > together to reach those project goals. > > For example, there are some initiatives for Tomcat migration, > introducing REST functionality in the framework and others which we can > assign to future release branches. Maybe we can have a plan for a 25.x > release branch which introduces those features. > > I do not intend to make this an unflexible roadmap, means there can > always be more planned/unplanned features be added to the roadmap and be > discussed. We should have some deadlines for new features though, just > to be able to create the next feature branch in the planned time periods. > > What do you think? > > Best regards, > > Michael Brohl > > ecomify GmbH - www.ecomify.de > > > -- Daniel Watford
Re: Discussion on OFBiz Tomcat upgrade
Hello, Checking the End-of-life announcements linked from https://tomcat.apache.org/whichversion.html it looks like we should have plenty of time before Tomcat 9 goes end-of-life. We have quite a few changes/fixes we are trying to complete that are blocking us from making a new release, so I am reluctant to pursue an upgrade to Tomcat 10 until after 24.x is released. My preference is to delay the Tomcat 10 upgrade until after OFBiz 24 is released. Thanks, Dan. On Thu, 11 Apr 2024 at 07:35, Nicolas Malin wrote: > Hi, > > Thanks Gaetan to push this subject. > > If we want keep OFBiz up to date, hence we need to realize this big step. > > My preference go to freeze this migration, focus to release the next > stable branch (24.xx) and restart it after. > > Nicolas > > Le 10/04/2024 à 14:27, Gaetan a écrit : > > Hi all. I'm opening a new thread to discuss the upgrade of the Tomcat > > version used by OFBiz. > > > > First, i pushed the task a bit hard without consulting the community > > first, and i apologize for it. I got carried away. > > The initial task came from a Prometheus plugin idea. [1] > > > > There is a documentation provided by tomcat on how to do the basic > > migration operations. [2] > > > > My opinion is that it will have to be done at some point. > > I don't have enough experience on OFBiz to know the full implications > > of a Tomcat migration. > > This one would be bigger even, because it would imply migrating from > > javax package to jakarta package. > > > > javax to jakarta change breaks some other things, such as JUEL > > dependency. > > Migration would be a lot of work and testing. > > > > The advantages i see in migrating as soon as possible would be that we > > could put it behind us. > > > > Any thougts ? The ticket has been created some days ago [3] > > > > [1] https://lists.apache.org/thread/jy7y96nmdr0rl43bss3sjm0jkcf2s2gz > > [2] https://tomcat.apache.org/migration-10.html > > [3] https://issues.apache.org/jira/browse/OFBIZ-12989 > > > -- Daniel Watford
Re: [jira] [Commented] (OFBIZ-12961) Upgrade Apache Shiro from 1.13.0 to 2.0.0
gt; > ../webapp/example/vite-react-app/index.html 1.29 kB ¦
> gzip: 0.74 kB
> > ../webapp/example/vite-react-app/assets/react-35ef61ed.svg4.13 kB ¦
> gzip: 2.05 kB
> > ../webapp/example/vite-react-app/assets/index-c98b5613.css2.22 kB ¦
> gzip: 0.79 kB
> > ../webapp/example/vite-react-app/assets/index-ebf59e67.js 362.20 kB ¦
> gzip: 76.94 kB
> > ? built in 5.33s
> >
> >> Task :plugins:projectmgr:nodeSetup UP-TO-DATE
> >> Task :plugins:projectmgr:npmSetup SKIPPED
> >> Task :plugins:projectmgr:npmInstall UP-TO-DATE
> >> Task :themes:common-theme:nodeSetup UP-TO-DATE
> >> Task :themes:common-theme:npmSetup SKIPPED
> >> Task :themes:common-theme:npmInstall UP-TO-DATE
> >> Task :classes
> >> Task :jar
> >> Task :startScripts
> >> Task :distTar
> >> Task :distZip
> >> Task :assemble
> >> Task :checkstyleMain
> >> Task :compileTestJava
> >> Task :compileTestGroovy
> >> Task :processTestResources
> >> Task :testClasses
> >> Task :checkstyleTest
> > The Cobertura XML file [null] is not accessible; skipping this rule
> >> Task :codenarcMain
> > The Cobertura XML file [null] is not accessible; skipping this rule
> >> Task :codenarcTest
> >> Task :test
> > OpenJDK 64-Bit Server VM warning: Sharing is only supported for boot
> loader classes because bootstrap classpath has been appended
> >
> >
> >> Task :check
> >> Task :build
> >> Task :plugins:example:assemble UP-TO-DATE
> >> Task :plugins:example:check UP-TO-DATE
> >> Task :plugins:example:build UP-TO-DATE
> >> Task :plugins:projectmgr:assemble UP-TO-DATE
> >> Task :plugins:projectmgr:check UP-TO-DATE
> >> Task :plugins:projectmgr:build UP-TO-DATE
> >> Task :themes:common-theme:assemble UP-TO-DATE
> >> Task :themes:common-theme:check UP-TO-DATE
> >> Task :themes:common-theme:build UP-TO-DATE
> > BUILD SUCCESSFUL in 14m 40s
> > 36 actionable tasks: 17 executed, 19 up-to-date
> > jacques@jacques-VirtualBox:~/ofbiz-framework$
> >
> > {noformat}
> >
> > It also works at
> https://github.com/apache/ofbiz-framework/actions/runs/8399944524/job/23006661250
> > bq. Java CI with Gradle #2887: Commit aa459fd pushed by asfgit
> >
> > But not at
> https://github.com/apache/ofbiz-framework/actions/runs/8399944523
> > bq. Analyze (java)
> > bq. We were unable to automatically build your code. Please replace the
> call to the autobuild action with your custom build steps. Encountered a
> fatal error while running
> "/opt/hostedtoolcache/CodeQL/2.16.5/x64/codeql/java/tools/autobuild.sh".
> Exit code was 1 and last log line was: Picked up JAVA_TOOL_OPTIONS:
> -Dhttp.keepAlive=false -Dmaven.wagon.http.pool=false. See the logs for more
> details.
> >
> > nor https://github.com/apache/ofbiz-framework/actions/runs/8399944544
> > bq. Build and push OFBiz docker container images
> > bq. buildx failed with: ERROR: failed to solve: process "./gradlew
> --console plain distTar" did not complete successfully: exit code: 1
> >
> > And last bu not least in BB:
> > https://ci2.apache.org/#/builders/49/builds/824
> >
> > Very weird ans sad situation :/
> >
> >
> >> Upgrade Apache Shiro from 1.13.0 to 2.0.0
> >> -
> >>
> >> Key: OFBIZ-12961
> >> URL: https://issues.apache.org/jira/browse/OFBIZ-12961
> >> Project: OFBiz
> >> Issue Type: Improvement
> >> Components: framework
> >> Affects Versions: Upcoming Branch
> >> Reporter: Jacques Le Roux
> >> Assignee: Jacques Le Roux
> >> Priority: Minor
> >> Fix For: Upcoming Branch
> >>
> >>
> >> At first glance there is no security vulnerability implied.
> >
> >
> > --
> > This message was sent by Atlassian Jira
> > (v8.20.10#820010)
>
--
Daniel Watford
OFBiz REST API
Hi Michael, I'm very keen to see how the REST API component has been progressing. Do you think it could be added to ofbiz-framework soon so that we could get a version incorporated in the 24.x release? One feature that I think would be useful would be to produce an access token within OFBiz's decorator screens such that the token is available for use by javascript running on a page. We might then be able to build an HTTP client delivered through ofbizutils.js (or other) which helps with making authenticated calls to the REST API. The approach of adding an access token to a rendered page was implemented in the example plugin's example-react-decorator screen using ApiTokenGenerator.groovy and ApiKey.ftl. ApiContext.tsx would then retrieve the key from the page and add it to an authorization header in a fetch call. Another feature I'm hoping for is for components to register themselves with the API at various paths, rather than the rest-api component attempting to derive api endpoints from the various services xml file. I think this would allow for a leaner api without the need to work around any legacy stuff from the service api. That being said, I imagine a lot of components would end up registering thin adapter layers to their standard services. Looking forward to seeing the new component and contributing where possible. Thanks, Dan. -- Daniel Watford
Re: Proposal: Merge ofbiz-plugins trunk HEAD into ofbiz-framework
Hi Michael, By symlink, are you referring to a filesystem symlink? If so, this unfortunately won't solve the problem of identifying which branch/tag of the ofbiz-plugins repository should be checked out for a continuous integration build - a problem we are seeing for tagged releases. Also, I think (but may be wrong) that checkstyle runs against plugin code as part of the CI process. This means we have to set checkstyle error count thresholds in ofbiz-framework in such a way that takes ofbiz-plugins into account. This complicates the decision around what is an acceptable threshold at any given time. Happily the threshold in trunk is currently 0 (see tasks.checkstyleMain.maxErrors in build.gradle), but when we introduce a new checkstyle rule we will need to track checkstyle errors in both ofbiz-framework and ofbiz-pluginsand we work towards being the error count back to zero. If the plugins are not really the focus of the ofbiz-framework developers, should we even include them in the ofbiz-framework CI process at all? Perhaps we should instead document and provide examples on how an integrator would retrieve and build a plugin, but remove platform-specific code - such as pull*PluginSources* - from ofbiz-framework completely. Interested parties could then augment ofbiz-plugins with a solution to insert plugin sources into the ofbiz-framework source and trigger a build accordingly. If a particular plugin is deemed important enough to the ofbiz-framework developers - such as the rest-api plugin - then we could port that plugin to become a component of ofbiz-framework. We would therefore think of ofbiz-plugins as a contributed code area when components are incubated before being integrated. I suppose the broader problem I'm trying to address is that I'm uneasy with the idea that we ofbiz-framework developers need to ensure the content of a seperate ofbiz-plugins repository remains compatible with our build checks, particularly since contributors may not event be aware ofbiz-plugins exists. (This position of course does not affect the need to maintain our API for use by plugins/integrations). Bringing a subset of plugins that need to be supported into the ofbiz-framework repository should address this problem. Thanks, Dan. On Tue, 5 Mar 2024 at 10:32, Michael Brohl wrote: > Hi Dan, > > just a short reply for now: you can easily integrate the plugins using a > symlink to the plugins repository to check if changes in the framework > are compatible with the plugins. > > The plugins do not get as much support as the core framework and > applications, I even would call some of them experimental. Some were > also be switched off because of problems/security issues. They are > optional enhancements and I think it is the right way to leave them in > their own repository with one exception. > > IMO, the rest-api Plugin should be merged into the framework as a core > functionality after we have provided the enhancements we have developed > over the last 2 years (still waiting for me to find time to provide a PR). > > For the historical view, I would need more time to dig into the past > discussions... > > Best regards, > > Michael Brohl > > ecomify GmbH - www.ecomify.de > > Am 05.03.24 um 09:42 schrieb Daniel Watford: > > Hello OFBiz developers, > > > > I imagine this topic might be revisiting discussions that pre-date my > > involvement with OFBiz so I would appreciate it if anyone can offer any > > historical perspective on the separation of the ofbiz-framework and > > ofbiz-plugins repository. > > > > This is a proposal to merge the HEAD of the trunk branch of the > > ofbiz-plugins repository into a directory within the ofbiz-framework > > repository. We would then use build-time configuration to include or > > exclude plugins from the build. > > > > Currently the ofbiz-plugins repository is maintained by the main OFBiz > > framework project's developers. As we make changes to a branch in > > ofbiz-framework, we need to check that plugins continue to build in the > > corresponding branch of the ofbiz-plugins repository. Having plugins in a > > separate repository complicates this process and I'm sure it is often > > overlooked by contributors to the project. > > > > Further, our continuous integration processes need to checkout the > relevant > > branch from ofbiz-plugins when building ofbiz-framework. We have some > > platform-specific scripts that carry out this process for us, but they > are > > not able to handle CI builds triggered by applying tags to > ofbiz-framework. > > > > Lastly, should an integrator wish to use one or more plugins from the > > ofbiz-plugins repository in addition to their own plugins, there is some > > con
Re: Any ideas on how to make demo-site logs accessible and whether it is safe to do so?
Thanks, Jacques, I'll try out some changes in the Apache HTTP Server configuration to make demo-site logs accessible without using OFBiz to retrieve them. On Sat, 2 Mar 2024 at 08:09, Jacques Le Roux wrote: > Hi Dan, > > About the logs in Webtools it's also limited to "OFBiz logs". > I mean you can't see the access_logs. They are sometime very useful too. > > So yes I agree this would be something we could do. > > Jacques > > Le 29/02/2024 à 16:15, Daniel Watford a écrit : > > Hello, > > > > I was just checking the demo-stable logs - accessible on ofbiz-vm1 at > > /home/ofbizdocker/demo-stable/logs - and found plenty of interesting > stack > > traces that would be good candidates for investigation. > > > > Given that the demo sites use well known administrator passwords and > should > > not contain any sensitive information, how would the project's members > feel > > about making these logs automatically accessible to any interested > parties? > > > > If it is deemed appropriate to make the logs publicly accessible, we then > > need to figure out how we could technically do so. > > > > One approach I can think of is to add some Alias directives ( > > https://httpd.apache.org/docs/current/mod/mod_alias.html#alias) to the > > Apache HTTP Server configuration to map relevant paths to the logs > > directory of each demo site. For example, to the demo-trunk > > configuration, we could add: > > > > Alias "/logs" "/home/ofbizdocker/demo-trunk/logs" > > > > Similarly, to the demo-stable configuration we would add: > > > > Alias "/logs" "/home/ofbizdocker/demo-stable/logs" > > > > We would then configure directory listings in Apache HTTP Server for > those > > log directory locations allowing access via a web browser. > > > > There is some pre-existing functionality in Web Tools to access logs, but > > it does require interaction through the OFBiz UI. The ability to retrieve > > demo-site logs via an unauthenticated HTTP(S) get request might offer > some > > opportunities to automatically scan for a particular class of error and > > might make it easier for ofbiz developers to check on the demo logs from > > time to time. > > > > Thanks, > > > > Dan. > > > -- Daniel Watford
Proposal: Merge ofbiz-plugins trunk HEAD into ofbiz-framework
Hello OFBiz developers, I imagine this topic might be revisiting discussions that pre-date my involvement with OFBiz so I would appreciate it if anyone can offer any historical perspective on the separation of the ofbiz-framework and ofbiz-plugins repository. This is a proposal to merge the HEAD of the trunk branch of the ofbiz-plugins repository into a directory within the ofbiz-framework repository. We would then use build-time configuration to include or exclude plugins from the build. Currently the ofbiz-plugins repository is maintained by the main OFBiz framework project's developers. As we make changes to a branch in ofbiz-framework, we need to check that plugins continue to build in the corresponding branch of the ofbiz-plugins repository. Having plugins in a separate repository complicates this process and I'm sure it is often overlooked by contributors to the project. Further, our continuous integration processes need to checkout the relevant branch from ofbiz-plugins when building ofbiz-framework. We have some platform-specific scripts that carry out this process for us, but they are not able to handle CI builds triggered by applying tags to ofbiz-framework. Lastly, should an integrator wish to use one or more plugins from the ofbiz-plugins repository in addition to their own plugins, there is some confusion about how they arrange their own code alongside the ofbiz-plugins repository. Proposed changes: - Copy repository content from the HEAD of the trunk branch from ofbiz-plugins to a suitable directory in ofbiz-framework. Perhaps this directory should be named ofbiz-plugins to help identify the contents as being maintained by the project. - Modify the build process to exclude the ofbiz-plugins directory from the build by default. The ofbiz-plugins directory can be added to the build through a gradle command line argument or setting. - Set code checking thresholds (e.g. checkstyle) to levels that allow inclusion of the new code. Expected benefits: - Contributors can more easily check their changes do not impact on the building of ofbiz-plugins. - The continuous integration builds do not need to run platform-specific scripts to fetch plugin sources since the sources are already part of the default checkout. - Determining which branch/tag from the ofbiz-plugins repository corresponds to the ofbiz-framework branch/tag being built by CI is no longer an issue. - We have one less repository to manage access/issues/PRs for. - The set of ofbiz-plugins will have more visibility among OFBiz developers - perhaps helping us decide which plugins the project no longer wishes to be responsible for and should be removed from ofbiz-framework. These plugins can be spun off into their own repository by any interested maintainers. Possible negatives: - The ofbiz-framework repository size will increase due to additional code. I'm not sure this is a major issue, particularly since the number of contributions to ofbiz-plugins is low these days. - The build process is more complicated for users wishing to include plugins. We can mitigate this by documenting the (hopefully) single modification needed to include ofbiz-plugins into the build. - We undo whatever benefit was achieved by having a separate ofbiz-plugins repository in the first place. I'm sure there will be other benefits and negatives to consider. Please let me know what you think. Thanks, Dan. -- Daniel Watford
Any ideas on how to make demo-site logs accessible and whether it is safe to do so?
Hello, I was just checking the demo-stable logs - accessible on ofbiz-vm1 at /home/ofbizdocker/demo-stable/logs - and found plenty of interesting stack traces that would be good candidates for investigation. Given that the demo sites use well known administrator passwords and should not contain any sensitive information, how would the project's members feel about making these logs automatically accessible to any interested parties? If it is deemed appropriate to make the logs publicly accessible, we then need to figure out how we could technically do so. One approach I can think of is to add some Alias directives ( https://httpd.apache.org/docs/current/mod/mod_alias.html#alias) to the Apache HTTP Server configuration to map relevant paths to the logs directory of each demo site. For example, to the demo-trunk configuration, we could add: Alias "/logs" "/home/ofbizdocker/demo-trunk/logs" Similarly, to the demo-stable configuration we would add: Alias "/logs" "/home/ofbizdocker/demo-stable/logs" We would then configure directory listings in Apache HTTP Server for those log directory locations allowing access via a web browser. There is some pre-existing functionality in Web Tools to access logs, but it does require interaction through the OFBiz UI. The ability to retrieve demo-site logs via an unauthenticated HTTP(S) get request might offer some opportunities to automatically scan for a particular class of error and might make it easier for ofbiz developers to check on the demo logs from time to time. Thanks, Dan. -- Daniel Watford
Re: breaking ofbiz piece by piece - expose parts to outside
o pay IMO. > >> I have partial integration tests running. > >> I have added some comments related to the blockers (EntityEca, Tennant) > >> They should be doable, but I need more info / help. > >> > >> To reiterate, please let me know of any issue you find and I will work > >> to fix it. > >> > >> Regards, > >> Eugen > >> > >> La 07.12.2023 20:55, Eugen Stan a scris: > >>> Hi Michael, > >>> > >>> Thank you for taking a look. > >>> I will reply inline. > >>> > >>> I did a demo project to support my case > >>> https://github.com/ieugen/ofbiz-tooling-demo . > >>> > >>> La 07.12.2023 12:53, Michael Brohl a scris: > >>>> Hi Eugen, > >>>> > >>>> can you give us some explanations/examples why this is a useful > change? > >>>> > >>>> What are the downsides? > >>> > >>> I don't see any downsides. > >>> There might be some breaking changes on upgrades. > >>> We could work to mitigate them - will explain bellow. > >>> > >>>> > >>>> I see a lot of changes in the base API like UtilValidate, > >>>> UtilProperties etc. which will brake almost every custom project out > >>>> there. > >>> > >>> Have you tried it in your projects? > >>> Do you know how many fail? > >>> > >>> All the integrations tests pass. > >>> Also we could do some work to mitigate those braking changes: > >>> - copy those methods back to the classes they came from > >>> - implement delegation: add a method with same signature that calls > >>> on the class from base/util (UtilValidate calls UtilValidateEmpty). > >>> > >>> IMO this should be a transition period until the code is cleaned up. > >>> I did not do the mitigations because this is intendend as a POC to be > >>> prepared once we decide it's a good direction. > >>> Also - I don't have access to 'all the projects out there' to test. > >>> > >>>> The changes also need explanation. For example: why the split of > >>>> UtilValidate to UtilValidateEmpty etc. > >>> > >>> Because of the cyclic dependency between classes. > >>> There is a LOT of cyclic dependencies which IMO is a code smell. > >>> UtilValidate depens on UtilProperties which depens on UtilValidate. > >>> There are numerous cases for this. > >>> If you run Intellij IDEA Analyze -> Analyze Cyclic dependencies you > >>> will see them. > >>> ( I posted an image on gh issue) > >>> > https://github.com/apache/ofbiz-framework/pull/678#issuecomment-1845903198 > >>> > >>>> > >>>> I think we need to have very strong advantages to make those changes > >>>> and currently I do not see them. > >>> > >>> We open OFBiz to be used as libraries. > >>> Then developers can use things like entity-engine, datafile, bits to > >>> build tooling as CLI or services that integrate with OFBiz. > >>> > >>> - It opens a path forward to inovation > >>> - It will make life of integrators MUCH more easy as it will provide > >>> java API's for them to do integrations > >>> - It exposes the dependencies by making them explicit (as gradle deps) > >>> - Developers can focus on a smaller part of the code base: component > >>> loading, XML parsing, entity engine without worrying about the rest > >>> of the code. > >>> - It will allow users to build tools and ofbiz components and package > >>> them as jar files (component/datafile is a component as a jar file - > >>> it depends on base/util and base/crypto - but nothing else from OFBiz). > >>> - It will facilitate the developement of proper java API's - now > >>> OFBiz is an implementation only - the API is the implementation. > >>> > >>> I would like to build some import tooling that uses the OFBiz code > >>> (so I don't reinvent the weel). > >>> Currently I don't see a way on how to do that. > >>> > >>> See the https://github.com/ieugen/ofbiz-tooling-demo I just did for > >>> Crypto. It can help people migrate data from/to OFBiz by using the > >>> same crypto code and the same xml data processing code. > >>> I do not need to bring whole OFBiz if all I want is to push / pull > >>> data from DB or to some files. > >>> To my knowledge that is not possible with OFBiz right now (unlesss > >>> you reimplement the code). It will be possible once we publish > >>> libraries. > >>> > >>> There is much more that this can help with but we will see if OFBiz > >>> to accepts some changes. > >>> And again, my changes don't break ANY integration test from the 780?! > >>> tests. > >>> > >>> I am very excited of finding this way of breaking OFBiz into smaller > >>> parts without breaking OFBiz runtime. > >>> There will be work to be done to streamline the code as libs but I am > >>> optimistic. > >>> > >>> Regards, > >> > > > > -- > Eugen Stan > > +40770 941 271 / https://www.netdava.com > > -- Daniel Watford
Re: [VOTE] [RELEASE] Apache OFBiz 18.12.12 - third attempt
Hi Jacopo, The tag on the ofbiz-framework repository triggered a non-snapshot build of the docker container image as I had hoped for, so I'm pleased with that. The build doesn't currently take tags on the ofbiz-plugins directory into account when pulling plugins sources, so there is no need to set tags there for the moment. Unfortunately the builds triggered by tags are not able to download plugins. This appears to be due to pullAllPluginsSource.sh assuming that a branch has been checked out, which is not the case when building from a tag. We'll need a bit more thinking on how to handle this situation. Thanks, Dan. On Fri, 16 Feb 2024 at 08:07, Jacopo Cappellato wrote: > Hi Daniel, > > I have created the two tags (one for the ofbiz-framework and one for > the ofbiz-plugins). Please have a look when you can and let me know if > you want me to modify them. > As a side note, if you want, I can also create the ones missing for > the previous releases. > > Thanks, > > Jacopo > > PS: did anyone else experience the same issues that Jacques is > reporting about the hash and signature? > > On Thu, Feb 15, 2024 at 8:09 PM Daniel Watford wrote: > > > > +1 > > > > Jacopo, please could you try tagging the commit you used for > > the release sources as 'release18.12.12'. That should then trigger the > > building of a non-snapshot docker container image. > > > > Building of docker container images is not an official release channel > for > > OFBiz, so no need to publicise that any such images exist. But it would > be > > good to test that images are getting built by GitHub actions in response > to > > tagging releases in case we want to highlight the availability of docker > > images in future. > > > > If this vote fails, we should be able to 'move' the release tag for the > > next release attempt, prompting the build of the next non-snapshot docker > > image. > > > > Thanks, > > > > Dan. > > > > On Tue, 13 Feb 2024 at 08:35, Jacopo Cappellato < > jacopo.cappell...@gmail.com> > > wrote: > > > > > This is the vote thread, third attempt, to publish "Apache OFBiz > > > 18.12.12", twelfth > > > release from the release18.12 branch. > > > > > > The release files can be downloaded from here: > > > https://dist.apache.org/repos/dist/dev/ofbiz/ > > > and are: > > > * apache-ofbiz-18.12.12.zip > > > * KEYS: text file with keys > > > * apache-ofbiz-18.12.12.zip.asc: the detached signature file > > > * apache-ofbiz-18.12.12.zip.sha512: checksum file > > > > > > Please download and test the zip file and its signatures (for > > > instructions on testing the signatures see > > > http://www.apache.org/info/verification.html). > > > > > > Vote: > > > [ +1] release as Apache OFBiz 18.12.12 > > > [ -1] do not release > > > > > > This vote is open for at least 5 days. > > > > > > For more details about this process please refer to > > > http://www.apache.org/foundation/voting.html > > > > > > > > > -- > > Daniel Watford > -- Daniel Watford
Re: [VOTE] [RELEASE] Apache OFBiz 18.12.12 - third attempt
+1 Jacopo, please could you try tagging the commit you used for the release sources as 'release18.12.12'. That should then trigger the building of a non-snapshot docker container image. Building of docker container images is not an official release channel for OFBiz, so no need to publicise that any such images exist. But it would be good to test that images are getting built by GitHub actions in response to tagging releases in case we want to highlight the availability of docker images in future. If this vote fails, we should be able to 'move' the release tag for the next release attempt, prompting the build of the next non-snapshot docker image. Thanks, Dan. On Tue, 13 Feb 2024 at 08:35, Jacopo Cappellato wrote: > This is the vote thread, third attempt, to publish "Apache OFBiz > 18.12.12", twelfth > release from the release18.12 branch. > > The release files can be downloaded from here: > https://dist.apache.org/repos/dist/dev/ofbiz/ > and are: > * apache-ofbiz-18.12.12.zip > * KEYS: text file with keys > * apache-ofbiz-18.12.12.zip.asc: the detached signature file > * apache-ofbiz-18.12.12.zip.sha512: checksum file > > Please download and test the zip file and its signatures (for > instructions on testing the signatures see > http://www.apache.org/info/verification.html). > > Vote: > [ +1] release as Apache OFBiz 18.12.12 > [ -1] do not release > > This vote is open for at least 5 days. > > For more details about this process please refer to > http://www.apache.org/foundation/voting.html > -- Daniel Watford
Re: Do we want to upgrade node.js ?
OFBIZ-12901 created to address the Node.js upgrade: https://issues.apache.org/jira/browse/OFBIZ-12901 On Thu, 15 Feb 2024 at 17:50, Daniel Watford wrote: > Hi Jacques, > > Upgrading sounds a good idea to me. > > We only use Node.js as part of our build process, so we should catch any > problems/incompatibilities quite easily. > > On Thu, 15 Feb 2024 at 11:42, Jacques Le Roux < > jacques.le.r...@les7arts.com> wrote: > >> Le 15/02/2024 à 10:08, Jacques Le Roux a écrit : >> > Hi, >> > >> > After installing Scorecard as a GH actions (OFBIZ-12899), we got a >> suggestion to upgrade node.js from 16 to 20 version. >> > >> > Do we want to do that? >> > >> > TIA >> > >> > Jacques >> >> node.js 16 is EOL: >> https://github.com/nodejs/Release/#end-of-life-releases >> >> > > -- > Daniel Watford > -- Daniel Watford
Re: Do we want to upgrade node.js ?
Hi Jacques, Upgrading sounds a good idea to me. We only use Node.js as part of our build process, so we should catch any problems/incompatibilities quite easily. On Thu, 15 Feb 2024 at 11:42, Jacques Le Roux wrote: > Le 15/02/2024 à 10:08, Jacques Le Roux a écrit : > > Hi, > > > > After installing Scorecard as a GH actions (OFBIZ-12899), we got a > suggestion to upgrade node.js from 16 to 20 version. > > > > Do we want to do that? > > > > TIA > > > > Jacques > > node.js 16 is EOL: https://github.com/nodejs/Release/#end-of-life-releases > > -- Daniel Watford
Re: Demos log in Docker
Hi Jacques - https://issues.apache.org/jira/browse/OFBIZ-12889 created for this On Fri, 2 Feb 2024 at 10:51, Jacques Le Roux wrote: > Hi Daniel, > > I know how to use docker compose logs --tail="1000" on demos > > But how to see logs contents like > access_log > ofbiz.log > error.log > etc. > > in Docker ? > > TIA > > Jacques > > -- Daniel Watford
Re: SvnCheckout Gradle plugin soon no longer usable with GitHub
Hi Jacques, I note your point about avoiding reply-all when replying to mailing lists. Gmail seems to have reply-all as the default option - I'll try to avoid it in future. When you tried the "--depth=1" option to git clone, did you also include the "--branch $branch" command line option? The "--branch $branch" option will retrieve the branch that you are interested in, avoiding the need for the subsequent. Presumably git clone will default to the trunk branch if not other branch is specified, and depth=1 will cause git clone to only retrieve enough data to provide a single commit of that branch. Please give the following a try to see if it will download the desired branch, using the minimum possible data retrieval, in one step: git clone --depth 1 --branch $branch https://github.com/apache/ofbiz-plugins.git plugins On Fri, 5 Jan 2024 at 07:21, Jacques Le Roux wrote: > Hi Daniel, > > I understand that it easier to be alerted when you receive an email > directly to your email address (inbox). > For Thunderbird msg filtering convenience, and in general for other > reasons*, I prefer to answer only to the ML. > This is true also for @Eugen, please don't send email directly to me, > TIA to both of you :) > > * If you are interested about a previous (long and argumented) discussion > here you go: https://s.apache.org/556a0 > > This said, I tried with depth=1, and there is an issue. It does not switch > to the current branch. You get, eg "fatal: invalid reference: release22.01" > It works well when using --filter=tree:0 and you download only 6Mb vs 7Mb > with depth=1. > > BTW "weirdly" (I have no idea about that) we don't get the depth=1 issue > when using sparse-checkout as in pullPluginSource. > Still I'll rather use --filter=tree:0 since it download a bit less of > data. So I'll push that for both scripts. > > I must say that I did not completely read nor watched the article**, only > the the "Quick Summary" > I also only considered the download aspect. I think it's OK. If you have > more indications please tell us, TIA > > ** > https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/ > > Thanks for initiating this thread (to Eugen in Jira too) > > Jacques > > Le 04/01/2024 à 19:19, Jacques Le Roux a écrit : > > Yes you are right Daniel, I remember having seen 7.62 Mb for trunk. I'll > change that tmrw :) > > > > Le 04/01/2024 à 18:57, Daniel Watford a écrit : > >> Hi Jacques, > >> > >> Using depth=1 means you only download the data you actually need, > rather than retrieving lots of data that is then immediately deleted. > >> > >> I can't check right now, but from memory I think with depth=1, around > 7MB of data was retrieved, compared to around 160MB without depth=1. > >> > >> We should try and only retrieve needed data if doing so does not > introduce too much complexity. > >> > >> Thanks, > >> > >> Dan. > >> > >> On Thu, 4 Jan 2024 at 09:43, Jacques Le Roux < > jacques.le.r...@les7arts.com> wrote: > >> > >> Hi Daniel, > >> > >> Reviews are always appreciated :) > >> > >> Inline... > >> > >> Le 04/01/2024 à 09:23, Daniel Watford a écrit : > >>> Hi Jacques, > >>> > >>> Sorry for not reviewing earlier, but for the > pullAllPluginsSource.sh you might consider simplifying a little with: > >>> > >>> # Whatever, create anew if [ -d"plugins" ] > >>> then rm -rf plugins > >>> fi # Get the branch used by the framework branch=$(git branch > --show-current) git clone --depth1 --branch$branch > >>> https://github.com/apache/ofbiz-plugins.git plugins > >>> > >>> # remove .git, in this case it's big useless information rm -rf > plugins/.git > >>> > >>> The above avoids creating the temp.txt file to detect the current > branch, and avoids changing directories. > >> > >> I'll commit that after your answer below about depth=1 > >> > >> > >>> > >>> FYI, pushd and popd are useful alternatives to cd in scripts - > https://en.wikipedia.org/wiki/Pushd_and_popd > >> > >> Thanks for the info, did not know it existed in cmd.exe. > >> > >> > >>> > >>> The git clone command has been altered to select the branch to > clone, and the depth=1 command line argument reduces the size of the clone > to >
Re: SvnCheckout Gradle plugin soon no longer usable with GitHub
Hi Jacques,
Using depth=1 means you only download the data you actually need, rather
than retrieving lots of data that is then immediately deleted.
I can't check right now, but from memory I think with depth=1, around 7MB
of data was retrieved, compared to around 160MB without depth=1.
We should try and only retrieve needed data if doing so does not introduce
too much complexity.
Thanks,
Dan.
On Thu, 4 Jan 2024 at 09:43, Jacques Le Roux
wrote:
> Hi Daniel,
>
> Reviews are always appreciated :)
>
> Inline...
> Le 04/01/2024 à 09:23, Daniel Watford a écrit :
>
> Hi Jacques,
>
> Sorry for not reviewing earlier, but for the pullAllPluginsSource.sh you
> might consider simplifying a little with:
>
> # Whatever, create anewif [ -d "plugins" ]
> thenrm -rf pluginsfi# Get the branch used by the
> frameworkbranch=$(git branch --show-current)git clone --depth 1 --branch
> $branch https://github.com/apache/ofbiz-plugins.git plugins
> # remove .git, in this case it's big useless informationrm -rf plugins/.git
>
>
> The above avoids creating the temp.txt file to detect the current branch,
> and avoids changing directories.
>
> I'll commit that after your answer below about depth=1
>
>
>
> FYI, pushd and popd are useful alternatives to cd in scripts -
> https://en.wikipedia.org/wiki/Pushd_and_popd
>
> Thanks for the info, did not know it existed in cmd.exe.
>
>
>
> The git clone command has been altered to select the branch to clone, and
> the depth=1 command line argument reduces the size of the clone to the
> minimum needed for that single branch.
>
> I'm not sure it's useful because anyway I remove .git, don't you think so?
>
> TIA
>
> Jacques
>
>
> Dan.
>
> On Wed, 3 Jan 2024 at 18:11, Eugen Stan wrote:
>
>> Hi Jacques,
>>
>> I missed this thread for some reason (was collapsed in TB) and only saw
>> it now.
>>
>> I read the thread.
>> Glad to see progress on fixing the SVN issue.
>>
>> Also inline:
>>
>> La 24.12.2023 13:05, Jacques Le Roux a scris:
>> > Hi Eugen,
>> >
>> > I tend to agree with your vision that sounds quite promising. I'm sorry
>> > I got no time to review your PR yet. I hope to do so during next year...
>>
>> It's good that it gets some attention.
>> Even if the PR does not get merged as is but is used as example for the
>> idea the PR is meant for.
>>
>> > Of course, this architecture will need to be discussed more and
>> > especially will not be part of the next release branch (24.01 ? 18.12
>> > becoming really old).
>>
>> That is ok with me since I plan to use trunk anyway.
>> So I guess the sooner we have OFBiz 24.01 the better :D .
>> Are there otehr blockers for 24.01 besides the SVN issue?
>>
>> >
>> > This said I was reading
>> >
>> https://cwiki.apache.org/confluence/display/OFBIZ/Release+Management+Guide+for+OFBiz
>> > and stumbled upon
>> > https://github.com/apache/ofbiz-tools/blob/master/demo-backup/README.md
>> >
>> > Obviously some parts are obsolete since we rely now on Docker for
>> demos.
>> > Could you please review and possibly amend?
>>
>> Is this for me or for Daniel?
>> I assume it's for Daniel (as I read in your next emails).
>>
>> > Last but not least, I guess we will need very soon to change something
>> > in Docker config for demos ; since pullAllPluginsSource relies on soon
>> > not usable SvnCheckout plugin?
>> >
>> > TIA
>> >
>> > Jacques
>> >
>> > Le 23/12/2023 à 20:43, eugen.s...@netdava.com a écrit :
>> >> Hi Jacques,
>> >>
>> >> Regarding the plugin workflow, the PR that I posted can offer
>> >> alternative ways to develop and consume plugins / components.
>> >> This would make plugin development by pulling sources in ofbiz
>> >> optional / obsolete even (a choice).
>> >>
>> >> If we move to have libraries that are published as jar files, then it
>> >> would be possible to develop plugins by depending on the specific
>> >> OFBiz bits.
>> >> It would also be possible to publish plugins / components as regular
>> >> java jars and consume them the same way.
>> >> So, in the future a custom OFBiz build could look something like this:
>> >>
>> >> build.gradle
>> >>
>> >> dependencies {
>> >> implementation 'org.apache.ofbiz:entity-engine:24.0'
>&
Re: SvnCheckout Gradle plugin soon no longer usable with GitHub
Hi Jacques,
Sorry for not reviewing earlier, but for the pullAllPluginsSource.sh you
might consider simplifying a little with:
# Whatever, create anew
if [ -d "plugins" ]
then
rm -rf plugins
fi
# Get the branch used by the framework
branch=$(git branch --show-current)
git clone --depth 1 --branch $branch
https://github.com/apache/ofbiz-plugins.git plugins
# remove .git, in this case it's big useless information
rm -rf plugins/.git
The above avoids creating the temp.txt file to detect the current branch,
and avoids changing directories.
FYI, pushd and popd are useful alternatives to cd in scripts -
https://en.wikipedia.org/wiki/Pushd_and_popd
The git clone command has been altered to select the branch to clone, and
the depth=1 command line argument reduces the size of the clone to the
minimum needed for that single branch.
Dan.
On Wed, 3 Jan 2024 at 18:11, Eugen Stan wrote:
> Hi Jacques,
>
> I missed this thread for some reason (was collapsed in TB) and only saw
> it now.
>
> I read the thread.
> Glad to see progress on fixing the SVN issue.
>
> Also inline:
>
> La 24.12.2023 13:05, Jacques Le Roux a scris:
> > Hi Eugen,
> >
> > I tend to agree with your vision that sounds quite promising. I'm sorry
> > I got no time to review your PR yet. I hope to do so during next year...
>
> It's good that it gets some attention.
> Even if the PR does not get merged as is but is used as example for the
> idea the PR is meant for.
>
> > Of course, this architecture will need to be discussed more and
> > especially will not be part of the next release branch (24.01 ? 18.12
> > becoming really old).
>
> That is ok with me since I plan to use trunk anyway.
> So I guess the sooner we have OFBiz 24.01 the better :D .
> Are there otehr blockers for 24.01 besides the SVN issue?
>
> >
> > This said I was reading
> >
> https://cwiki.apache.org/confluence/display/OFBIZ/Release+Management+Guide+for+OFBiz
> > and stumbled upon
> > https://github.com/apache/ofbiz-tools/blob/master/demo-backup/README.md
> >
> > Obviously some parts are obsolete since we rely now on Docker for demos.
> > Could you please review and possibly amend?
>
> Is this for me or for Daniel?
> I assume it's for Daniel (as I read in your next emails).
>
> > Last but not least, I guess we will need very soon to change something
> > in Docker config for demos ; since pullAllPluginsSource relies on soon
> > not usable SvnCheckout plugin?
> >
> > TIA
> >
> > Jacques
> >
> > Le 23/12/2023 à 20:43, eugen.s...@netdava.com a écrit :
> >> Hi Jacques,
> >>
> >> Regarding the plugin workflow, the PR that I posted can offer
> >> alternative ways to develop and consume plugins / components.
> >> This would make plugin development by pulling sources in ofbiz
> >> optional / obsolete even (a choice).
> >>
> >> If we move to have libraries that are published as jar files, then it
> >> would be possible to develop plugins by depending on the specific
> >> OFBiz bits.
> >> It would also be possible to publish plugins / components as regular
> >> java jars and consume them the same way.
> >> So, in the future a custom OFBiz build could look something like this:
> >>
> >> build.gradle
> >>
> >> dependencies {
> >> implementation 'org.apache.ofbiz:entity-engine:24.0'
> >> implementation 'org.apache.ofbiz:service:24.0'
> >> implementation 'org.apache.ofbiz:accounting:24.0'
> >> implementation 'com.example:my-plugin:1.2.3'
> >> }
> >>
> >>
> >>
> >>
> >> On 23.12.2023 17:06, Jacques Le Roux
> >> wrote:
> >>> It's ready for review before pushing and testing with GH and BB
> >>>
> >>> TIA
> >>>
> >>> Jacques
> >>>
> >>> Le 01/12/2023 à 11:18, Jacques Le Roux a écrit :
> >>> > Hi,
> >>> >
> >>> > I have created https://issues.apache.org/jira/browse/OFBIZ-12868
> >>> for > that... WIP...
> >>> >
> >>> > HTH
> >>> >
> >>> > Jacques
> >>> >
> >>> > Le 27/11/2023 à 13:41, Jacques Le Roux a écrit :
> >>> >> Hi,
> >>> >>
> >>> >> As you may have noticed*, the SvnCheckout Gradle plugin will not
> >>> be >> usable after January 8, 2024.
> >>> >>
> >>> >> So we need a replacement and it's clearly suggested by GitHub in
> >>> the >> link below
> >>> >>
> >>> >> Jacques
> >>> >>
> >>> >> * https://lists.apache.org/thread/08kwg2ovjt4qyfybhf1qzsvq42jsy2wz
> >>>
> >>
>
> --
> Eugen Stan
>
> +40770 941 271 / https://www.netdava.com
>
>
--
Daniel Watford
Re: SvnCheckout Gradle plugin soon no longer usable with GitHub
Hi Jacques, Please could you confirm that the project's intention is to remove the pullAllPluginsSource gradle task, rather than replace the components of that task that fetch the source via SVN with something similar that fetches via Git? The reason for asking is that you mentioned in a comment on https://issues.apache.org/jira/browse/OFBIZ-12868 that we might still use the gradle tasks: > "To minimise the change, we could decide to still use the scripts but > called from Gradle... I have not yes tested the performance differences..." If the intention is to keep the gradle tasks related to retrieving plugin sources, but have those tasks call external scripts, then we should close https://issues.apache.org/jira/browse/OFBIZ-12876 and have the docker image builds continue to leverage gradle. Thanks, Dan. On Tue, 26 Dec 2023 at 09:49, Jacques Le Roux wrote: > Hi, > > Though I believe we should get rid of the Gradle pullPluginSource and > pullAllPluginsSource tasks, this morning I tried to implement them using > the OS > scripts for pullPluginSource and pullAllPluginsSource w/o success. > > If someone is interested I can put the diff at OFBIZ-12868 > > Juste let me know... > > Jacques > > Le 23/12/2023 à 12:13, Jacques Le Roux a écrit : > > Hi, > > > > OK, we need more effort here because GH and BB will break at January 8, > 2024 and we need to test the changes before... In other words we have at > > most 2 weeks available... > > > > I have one question. It seems to me that the Gradle "installPlugin" > task, called by the pullPluginSource and pullAllPluginsSource tasks, is not > > implement in any OOTB plugin. > > > > I ask this question because, if it eventually unused, it's quite easier > and especially efficient/faster to use simple OS scripts than Gradle tasks > > for pullPluginSource and pullAllPluginsSource > > > > Jacques > > > > Le 01/12/2023 à 11:18, Jacques Le Roux a écrit : > >> Hi, > >> > >> I have created https://issues.apache.org/jira/browse/OFBIZ-12868 for > that... WIP... > >> > >> HTH > >> > >> Jacques > >> > >> Le 27/11/2023 à 13:41, Jacques Le Roux a écrit : > >>> Hi, > >>> > >>> As you may have noticed*, the SvnCheckout Gradle plugin will not be > usable after January 8, 2024. > >>> > >>> So we need a replacement and it's clearly suggested by GitHub in the > link below > >>> > >>> Jacques > >>> > >>> * https://lists.apache.org/thread/08kwg2ovjt4qyfybhf1qzsvq42jsy2wz > -- Daniel Watford
Re: SvnCheckout Gradle plugin soon no longer usable with GitHub
Hi Jacques, Dropping the pullAllPluginsSource gradle task will have the benefit of simplifying the building of docker images. Please see the comment on the topic here: https://github.com/apache/ofbiz-framework/blob/0530a58d3a912520b7f9e46c5ccde98fd3737bf5/.github/workflows/docker-image.yaml#L126 I'll create and work a ticket over the next few days to amend the docker image build process to use a git clone/checkout of the ofbiz-plugins repository rather than use the pullAllPluginsSoruce gradle task. The ticket will apply to the trunk, release18.12 and release22.01 branches. Thanks, Dan. On Mon, 25 Dec 2023 at 08:34, Jacques Le Roux wrote: > Hi Eugen, Daniel, > > Le 24/12/2023 à 12:05, Jacques Le Roux a écrit : > > Last but not least, I guess we will need very soon to change something > in Docker config for demos ; since pullAllPluginsSource relies on soon not > > usable SvnCheckout plugin? > Actually this last sentence was more directed to Daniel > -- Daniel Watford
Re: Time for the OFBiz 22.01.01 ?
Hi Nicolas, Although we didn't make a decision, mixed in with this thread - https://lists.apache.org/thread/8pyhnjs65ss6btsl8r93w6z21pyksclt - is a discussion about abandoning the 22.01 branch in favour of creating a new branch from trunk. The justification for creating a new branch was to capture a lot of the Groovy refactoring work that had gone into trunk without duplicating a similar level of effort to port those same changes to the 22.01 branch. I believe we left the conversation - but once again, we did not make an official statement or carry out any sort of vote - broadly in favour of creating a new branch some time after the completion of the Groovy refactoring work. I would now expect this to be a 24.01 branch created early in the new year. Thanks, Dan. On Tue, 12 Dec 2023 at 15:51, Nicolas Malin wrote: > Hello Michael, > > If I understood well, you propose to rename the 22.01 on 24.0.1.01 to > be more synchronize with it releasing time ? If is no worries with this > but what the name for the branch to stabilization ? > > Cheers, > Nicolas > > Le 08/12/2023 à 17:53, Michael Brohl a écrit : > > Hi Nicolas, > > > > given the time gone by I am thinking about if we should do an early > > 24.x release instead of 22.01. 22.01 sounds quite old with the year > > 2024 just a few days ahead. > > > > But yes, it would be great to have a new stable release out soon. > > > > Best regards, > > > > Michael Brohl > > > > ecomify GmbH - www.ecomify.de > > > > > > Am 08.12.23 um 16:10 schrieb Nicolas Malin: > >> Hello all, > >> > >> I know that I go out from my cave :D, there was a lot of work on the > >> OFBiz improvement quality this year on groovy and deployment process. > >> > >> I saw two issues [1][2] to solve before run a release process. Do you > >> saw other element before try to release the 22.01.01 ? > >> > >> Cheers, > >> > >> Nicolas > >> > >> [1] https://issues.apache.org/jira/browse/OFBIZ-12726 > >> [2] https://issues.apache.org/jira/browse/OFBIZ-12868 > -- Daniel Watford
Re: Lazy consensus: Host demo-trunk in a container.
This work is now complete (OFBIZ-12862). The demo-stable site is now hosted from a docker container and so should restart automatically following a restart of the host. On Mon, 16 Oct 2023 at 13:02, Eugen Stan wrote: > +1 > > -- > Eugen Stan > > +40770 941 271 / https://www.netdava.com > -- Daniel Watford
Re: HTTP/2 disabled on demo-trunk
Hi Deepak, Not yet, but I've now assigned the task to myself so that it appears more readily in my todo list. On Fri, 27 Oct 2023 at 06:38, Deepak Dixit wrote: > Hi Daniel!! > > Did you get a chance to look at this? > > Thanks & Regards > -- > Deepak Dixit > ofbiz.apache.org > > > On Tue, Aug 22, 2023 at 2:29 PM Deepak Dixit wrote: > > > Here is the task for the same > > https://issues.apache.org/jira/browse/OFBIZ-12846 > > > > HTTP/2 should be enabled by default. Need to check if we are disabling > > this while container build. > > > > > > Thanks & Regards > > -- > > Deepak Dixit > > ofbiz.apache.org > > > > > > On Tue, Aug 22, 2023 at 2:22 PM Deepak Dixit wrote: > > > >> Sure Daniel!! > >> > >> > >> Thanks & Regards > >> -- > >> Deepak Dixit > >> ofbiz.apache.org > >> > >> > >> On Tue, Aug 22, 2023 at 1:25 PM Daniel Watford > wrote: > >> > >>> Hi Deepak, > >>> > >>> Please could you raise a ticket to get it added to the container > builds. > >>> > >>> Thanks, > >>> > >>> Dan. > >>> > >>> On Tue, 22 Aug 2023 at 07:57, Deepak Dixit wrote: > >>> > >>> > Hi, > >>> > > >>> > demo-trunk not using http/2 protocol, http/2 support was added long > >>> ago. > >>> > It's working fine on localhost. > >>> > > >>> > Is there any specific reason to disable http/2 on demo-trunk? > >>> > > >>> > > >>> > Thanks & Regards > >>> > -- > >>> > Deepak Dixit > >>> > ofbiz.apache.org > >>> > > >>> > >>> > >>> -- > >>> Daniel Watford > >>> > >> > -- Daniel Watford
Re: Lazy consensus: Host demo-stable in a container.
I just realised I gave this thread the wrong subject. It should have been 'Lazy consensus: Host demo-stable in a container.' On Mon, 16 Oct 2023 at 07:45, Daniel Watford wrote: > Hello, > > Over the last few months we have been experiencing more frequent restarts > of the VM used to host our demo sites. This triggers an alert email to a > few of us and someone has to access the VM to manually restart the demo > sites. > > Since the demo-next and demo-trunk sites are hosted in docker containers, > we recently applied some configuration changes to restart those containers > at VM start up. > > LAZY CONSENSUS > > Following a recent commit to the release18.12 branch to build release and > snapshot container images of OFBiz 18.12.x, this email thread is to > establish if we have a lazy consensus to use those snapshot container > images to host the demo-stable site. > > Using a container to host the demo-stable site means we can employ the > same configuration used on the demo-next and demo-trunk stites to restart > the demo-stable site following a restart of the VM. > > If we have a lazy consensus, I will look to amend the demo-trunk site to > be hosted by a container in about 7 day's time. > > Thanks, > > Dan. > > -- > Daniel Watford > -- Daniel Watford
Lazy consensus: Host demo-trunk in a container.
Hello, Over the last few months we have been experiencing more frequent restarts of the VM used to host our demo sites. This triggers an alert email to a few of us and someone has to access the VM to manually restart the demo sites. Since the demo-next and demo-trunk sites are hosted in docker containers, we recently applied some configuration changes to restart those containers at VM start up. LAZY CONSENSUS Following a recent commit to the release18.12 branch to build release and snapshot container images of OFBiz 18.12.x, this email thread is to establish if we have a lazy consensus to use those snapshot container images to host the demo-stable site. Using a container to host the demo-stable site means we can employ the same configuration used on the demo-next and demo-trunk stites to restart the demo-stable site following a restart of the VM. If we have a lazy consensus, I will look to amend the demo-trunk site to be hosted by a container in about 7 day's time. Thanks, Dan. -- Daniel Watford
Stable demo down due to exception
6.0]
at
org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:436)
~[commons-pool2-2.6.0.jar:2.6.0]
at
org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:365)
~[commons-pool2-2.6.0.jar:2.6.0]
at
org.apache.commons.dbcp2.managed.ManagedConnection.updateTransactionStatus(ManagedConnection.java:142)
~[commons-dbcp2-2.5.0.jar:2.5.0]
at
org.apache.commons.dbcp2.managed.ManagedConnection.(ManagedConnection.java:75)
~[commons-dbcp2-2.5.0.jar:2.5.0]
at
org.apache.commons.dbcp2.managed.ManagedDataSource.getConnection(ManagedDataSource.java:80)
~[commons-dbcp2-2.5.0.jar:2.5.0]
at
org.apache.ofbiz.entity.connection.DebugManagedDataSource.getConnection(DebugManagedDataSource.java:51)
~[ofbiz.jar:?]
at
org.apache.ofbiz.entity.connection.DBCPConnectionFactory.getConnection(DBCPConnectionFactory.java:66)
~[ofbiz.jar:?]
at
org.apache.ofbiz.entity.transaction.GeronimoTransactionFactory.getConnection(GeronimoTransactionFactory.java:79)
~[ofbiz.jar:?]
at
org.apache.ofbiz.entity.jdbc.SQLProcessor.getConnection(SQLProcessor.java:261)
~[ofbiz.jar:?]
... 8 more
Caused by: org.apache.derby.iapi.error.StandardException: Java exception:
': java.lang.NullPointerException'.
at
org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
~[derby-10.14.2.0.jar:?]
at
org.apache.derby.impl.jdbc.SQLExceptionFactory.wrapArgsForTransportAcrossDRDA(Unknown
Source) ~[derby-10.14.2.0.jar:?]
at
org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown
Source) ~[derby-10.14.2.0.jar:?]
at
org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown
Source) ~[derby-10.14.2.0.jar:?]
at org.apache.derby.impl.jdbc.Util.seeNextException(Unknown Source)
~[derby-10.14.2.0.jar:?]
at org.apache.derby.impl.jdbc.Util.javaException(Unknown Source)
~[derby-10.14.2.0.jar:?]
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown
Source) ~[derby-10.14.2.0.jar:?]
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown
Source) ~[derby-10.14.2.0.jar:?]
at
org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
~[derby-10.14.2.0.jar:?]
at org.apache.derby.impl.jdbc.EmbedConnection.(Unknown
Source) ~[derby-10.14.2.0.jar:?]
at org.apache.derby.jdbc.InternalDriver$1.run(Unknown Source)
~[derby-10.14.2.0.jar:?]
at org.apache.derby.jdbc.InternalDriver$1.run(Unknown Source)
~[derby-10.14.2.0.jar:?]
at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
at
org.apache.derby.jdbc.InternalDriver.getNewEmbedConnection(Unknown Source)
~[derby-10.14.2.0.jar:?]
at org.apache.derby.jdbc.InternalDriver.connect(Unknown Source)
~[derby-10.14.2.0.jar:?]
at org.apache.derby.jdbc.InternalDriver.connect(Unknown Source)
~[derby-10.14.2.0.jar:?]
at org.apache.derby.jdbc.EmbeddedDriver.connect(Unknown Source)
~[derby-10.14.2.0.jar:?]
at
org.apache.commons.dbcp2.DriverConnectionFactory.createConnection(DriverConnectionFactory.java:53)
~[commons-dbcp2-2.5.0.jar:2.5.0]
at
org.apache.commons.dbcp2.managed.LocalXAConnectionFactory.createConnection(LocalXAConnectionFactory.java:66)
~[commons-dbcp2-2.5.0.jar:2.5.0]
at
org.apache.commons.dbcp2.managed.PoolableManagedConnectionFactory.makeObject(PoolableManagedConnectionFactory.java:67)
~[commons-dbcp2-2.5.0.jar:2.5.0]
at
org.apache.commons.pool2.impl.GenericObjectPool.create(GenericObjectPool.java:883)
~[commons-pool2-2.6.0.jar:2.6.0]
at
org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:436)
~[commons-pool2-2.6.0.jar:2.6.0]
at
org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:365)
~[commons-pool2-2.6.0.jar:2.6.0]
at
org.apache.commons.dbcp2.managed.ManagedConnection.updateTransactionStatus(ManagedConnection.java:142)
~[commons-dbcp2-2.5.0.jar:2.5.0]
at
org.apache.commons.dbcp2.managed.ManagedConnection.(ManagedConnection.java:75)
~[commons-dbcp2-2.5.0.jar:2.5.0]
at
org.apache.commons.dbcp2.managed.ManagedDataSource.getConnection(ManagedDataSource.java:80)
~[commons-dbcp2-2.5.0.jar:2.5.0]
at
org.apache.ofbiz.entity.connection.DebugManagedDataSource.getConnection(DebugManagedDataSource.java:51)
~[ofbiz.jar:?]
at
org.apache.ofbiz.entity.connection.DBCPConnectionFactory.getConnection(DBCPConnectionFactory.java:66)
~[ofbiz.jar:?]
at
org.apache.ofbiz.entity.transaction.GeronimoTransactionFactory.getConnection(GeronimoTransactionFactory.java:79)
~[ofbiz.jar:?]
at
org.apache.ofbiz.entity.jdbc.SQLProcessor.getConnection(SQLProcessor.java:261)
~[ofbiz.jar:?]
... 8 more
--
Daniel Watford
Stable demo down - restarting
-- Daniel Watford
Re: HTTP/2 disabled on demo-trunk
Hi Deepak, Please could you raise a ticket to get it added to the container builds. Thanks, Dan. On Tue, 22 Aug 2023 at 07:57, Deepak Dixit wrote: > Hi, > > demo-trunk not using http/2 protocol, http/2 support was added long ago. > It's working fine on localhost. > > Is there any specific reason to disable http/2 on demo-trunk? > > > Thanks & Regards > -- > Deepak Dixit > ofbiz.apache.org > -- Daniel Watford
Re: Backporting OFBIZ-12836 to 22.01?
Hi Paul, I would hold off backporting anything to 22.01 for the time being as we may abandon that branch in favour of creating a new release branch once the groovy refactoring effort is complete and has had a chance to stabilise. Although the idea was proposed to abandon 22.01, we didn't get round to voting on the topic. Please see https://lists.apache.org/thread/8pyhnjs65ss6btsl8r93w6z21pyksclt Thanks, Dan. On Wed, 2 Aug 2023 at 07:48, Paul Foxworthy wrote: > Hi, > > I have committed fixes for OFBIZ-12836 to trunk. > > I tried backporting to 22.01, but if I'm reading the gradle config > correctly, the version of Groovy seems to be 2.5.18 and that appears to not > support try-with-resources syntax. Is that expected? > > Thanks > > Paul Foxworthy > -- Daniel Watford
Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.
I'm not familiar with that bug, but I am of the opinion that branch 22.01 is abandoned, therefore there is no target branch to backport a bug to. We also are not accepting bug fixes into the 18 branch - Perhaps this is a decision we should reconsidered since it means we have no path to migrate users towards a fix in case of a serious bug. But once again, I am mindful that we have limited time to do additional work - perhaps this is a subject for a different thread. On Fri, 28 Jul 2023 at 16:46, Jacques Le Roux wrote: > Also please consider these comments: https://s.apache.org/fcpi3 > > Le 28/07/2023 à 17:32, Jacques Le Roux a écrit : > > Hi Daniel, > > > > Ho many time do you think we need? > > > > Maybe a month is indeed short. Though actually the changes are pretty > simple and we should not cross much issues > > > > Le 28/07/2023 à 17:17, Daniel Watford a écrit : > >> Hi Jacques, > >> > >> Apologies if I've misunderstood your meaning, but I don't think we > should > >> rush to create a 23.xx branch. > >> > >> Following such a large refactor, we are likely to find issues in our > use of > >> groovy scripts over the coming weeks. If we go ahead and create a new > 23.xx > >> branch from trunk too soon we will have to fix those groovy script > issues > >> in trunk and the new branch - increasing the amount of work needed. > >> > >> I agree that we want to get a 23.xx branch in place once we are happy > that > >> the groovy script refactor work has completed and had a chance to have a > >> few fixes applied. > >> > >> Thanks, > >> > >> Dan. > >> > >> On Fri, 28 Jul 2023 at 16:08, Jacques Le Roux < > jacques.le.r...@les7arts.com> > >> wrote: > >> > >>> Le 03/05/2023 à 09:45, Jacopo Cappellato a écrit : > >>>> On Tue, May 2, 2023 at 9:17 AM Daniel Watford > wrote: > >>>> [...] > >>>>> I'll ask one more question (and then run for cover!): Rather than > carry > >>> out > >>>>> this work twice. What if we abandon the 22.01 release and instead > make > >>> a > >>>>> new release branch (23.xx) soon after moving the Groovy sources? > >>>>> > >>>> Yes, we could do this. Abandon 22.01, perform the refactoring, create > >>>> a new release branch, stabilize (we could consider a shorter > >>>> stabilization period). > >>>> We could also extend our support (mostly for security vulnerability > >>>> fixes) to 18.12, at least until 1 or 2 releases have been published > >>>> out of the new branch. > >>>> > >>>> Jacopo > >>> Hi, > >>> > >>> In relation with [OFBIZ-12813] Refactor groovy folder structure and add > >>> package declaration > >>> > >>> As soon as a groovy file is modified, and especially moved, in trunk > >>> (framework is done, plugins is waiting), it will be more hand work to > >>> backport. > >>> So I think we should indeed quickly think about creating a 23.xx > (23.09?) > >>> release branch. Else if will be soon a nightmare to backport fixes. > >>> > >>> Jacques > >>> > >>> > >>> > -- Daniel Watford
Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.
Hi Jacques, I would like to see a delay of at least 4 weeks to give interested parties a chance to exercise the parts of OFBiz they are most familiar with. I'm happy to be challenged on this, though. Choosing a reasonable amount of time is a balance between duplicating work when resources are limited, and moving the project forward. I don't think there is an obvious answer to this one, so the maintainers will need to propose the branch when they feel the time is right. Although not expected to be the case, if we were to find lots of issues, then we could delay creating the 23.xx branch accordingly. On Fri, 28 Jul 2023 at 16:32, Jacques Le Roux wrote: > Hi Daniel, > > Ho many time do you think we need? > > Maybe a month is indeed short. Though actually the changes are pretty > simple and we should not cross much issues > > Le 28/07/2023 à 17:17, Daniel Watford a écrit : > > Hi Jacques, > > > > Apologies if I've misunderstood your meaning, but I don't think we should > > rush to create a 23.xx branch. > > > > Following such a large refactor, we are likely to find issues in our use > of > > groovy scripts over the coming weeks. If we go ahead and create a new > 23.xx > > branch from trunk too soon we will have to fix those groovy script issues > > in trunk and the new branch - increasing the amount of work needed. > > > > I agree that we want to get a 23.xx branch in place once we are happy > that > > the groovy script refactor work has completed and had a chance to have a > > few fixes applied. > > > > Thanks, > > > > Dan. > > > > On Fri, 28 Jul 2023 at 16:08, Jacques Le Roux < > jacques.le.r...@les7arts.com> > > wrote: > > > >> Le 03/05/2023 à 09:45, Jacopo Cappellato a écrit : > >>> On Tue, May 2, 2023 at 9:17 AM Daniel Watford > wrote: > >>> [...] > >>>> I'll ask one more question (and then run for cover!): Rather than > carry > >> out > >>>> this work twice. What if we abandon the 22.01 release and instead > make > >> a > >>>> new release branch (23.xx) soon after moving the Groovy sources? > >>>> > >>> Yes, we could do this. Abandon 22.01, perform the refactoring, create > >>> a new release branch, stabilize (we could consider a shorter > >>> stabilization period). > >>> We could also extend our support (mostly for security vulnerability > >>> fixes) to 18.12, at least until 1 or 2 releases have been published > >>> out of the new branch. > >>> > >>> Jacopo > >> Hi, > >> > >> In relation with [OFBIZ-12813] Refactor groovy folder structure and add > >> package declaration > >> > >> As soon as a groovy file is modified, and especially moved, in trunk > >> (framework is done, plugins is waiting), it will be more hand work to > >> backport. > >> So I think we should indeed quickly think about creating a 23.xx > (23.09?) > >> release branch. Else if will be soon a nightmare to backport fixes. > >> > >> Jacques > >> > >> > >> > -- Daniel Watford
Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.
Hi Jacques, Apologies if I've misunderstood your meaning, but I don't think we should rush to create a 23.xx branch. Following such a large refactor, we are likely to find issues in our use of groovy scripts over the coming weeks. If we go ahead and create a new 23.xx branch from trunk too soon we will have to fix those groovy script issues in trunk and the new branch - increasing the amount of work needed. I agree that we want to get a 23.xx branch in place once we are happy that the groovy script refactor work has completed and had a chance to have a few fixes applied. Thanks, Dan. On Fri, 28 Jul 2023 at 16:08, Jacques Le Roux wrote: > Le 03/05/2023 à 09:45, Jacopo Cappellato a écrit : > > On Tue, May 2, 2023 at 9:17 AM Daniel Watford wrote: > > [...] > >> I'll ask one more question (and then run for cover!): Rather than carry > out > >> this work twice. What if we abandon the 22.01 release and instead make > a > >> new release branch (23.xx) soon after moving the Groovy sources? > >> > > Yes, we could do this. Abandon 22.01, perform the refactoring, create > > a new release branch, stabilize (we could consider a shorter > > stabilization period). > > We could also extend our support (mostly for security vulnerability > > fixes) to 18.12, at least until 1 or 2 releases have been published > > out of the new branch. > > > > Jacopo > > Hi, > > In relation with [OFBIZ-12813] Refactor groovy folder structure and add > package declaration > > As soon as a groovy file is modified, and especially moved, in trunk > (framework is done, plugins is waiting), it will be more hand work to > backport. > So I think we should indeed quickly think about creating a 23.xx (23.09?) > release branch. Else if will be soon a nightmare to backport fixes. > > Jacques > > > -- Daniel Watford
Cleaning up docker file on ofbiz-vm1
Hi Jacques and all, Following a request by Jacques to check on disk space used by Docker on our demo sites server (ofbiz-vm1) I thought I would post the steps followed in case they were of interest to others. I opened a root terminal on ofbiz-vm1: > ssh danwatf...@ofbiz-vm1.apache.org danwatford@ofbiz-vm1:~$ sudo bash I then open a byobu session so I can resume working in case of disconnection: root@ofbiz-vm1:/home/danwatford# byobu To check on disk space usage for the VM: root@ofbiz-vm1:/home/danwatford# df -h Filesystem Size Used Avail Use% Mounted on /dev/root97G 77G 21G 79% / devtmpfs 16G 0 16G 0% /dev tmpfs16G 88K 16G 1% /dev/shm tmpfs 3.2G 1.6M 3.2G 1% /run tmpfs 5.0M 0 5.0M 0% /run/lock To check on disk space used by Docker: root@ofbiz-vm1:/home/danwatford# docker system df TYPETOTAL ACTIVESIZE RECLAIMABLE Images 106 6 49.22GB 47.17GB (95%) Containers 9 8 252.7kB 0B (0%) Local Volumes 2323705.7MB 0B (0%) Build Cache 0 0 0B0B To clean up unused images and containers: root@ofbiz-vm1:/home/danwatford# docker system prune WARNING! This will remove: - all stopped containers - all networks not used by at least one container - all dangling images - all dangling build cache Are you sure you want to continue? [y/N] y Deleted Containers: aef9a0a458fa7ef3b7cb768def27a62396fd63b12471f30288e56c6cce473078 Deleted Images: untagged: ghcr.io/apache/ofbiz@sha256:50c7888fadfec413d34a85cf327c5843b63002d4fc27b78f25b515650dfe750c deleted: sha256:34fbbf005c3d52d7320018de3031b5b1fdb8b32aa1a380457f3e0703987cd04b deleted: sha256:b2a89e9375e86a94295e15aa531a4f49261d8ea993d402474b8d49f2463858d6 deleted: sha256:e6955d763fa7998204538aab84191f6540e3b5d00dfd674f42a3ae45235bff6a deleted: sha256:681f455f3bbb6d3076958b3696f0334c3121d35be69c350ebb3447c3af638761 Total reclaimed space: 46.36GB The above command cleaned up 46 GB, mostly from unused cached container images. We can confirm that disk space has been reclaimed by checking df again: root@ofbiz-vm1:/home/danwatford# df -h Filesystem Size Used Avail Use% Mounted on /dev/root97G 30G 68G 31% / So available disk space increased from 21 GB to 68 GB due to the docker clean up process. We should install a cron job to run the clean up automatically. Dan. -- Daniel Watford
Re: Assertion failed: While applying custom patch
Hi Sahana, It looks like your patch failed: [ant:patch] Assertion failed: hunk, file ../patch-2.5.9-src/patch.c, line 354 Are you sure the patch is intended to be applied to the latest (trunk) OFBiz sources? On Tue, 6 Jun 2023 at 07:38, Sahana Somanna wrote: > Greetings, > > I have downloaded ofbiz project from .git repository. And trying to apply > patch using GIT BASH > I used below command to the path hot-deploy/crest-common path. > > ./gradlew applyCustomPatch -Penv=dev > > I endup with the error > > [ant:patch] patching file > E:\eclipse-workspace\Misterlight_branch_2.1\framework\images\webapp\images\OfbizUtil.js > [ant:patch] patching file > E:\eclipse-workspace\Misterlight_branch_2.1\specialpurpose\component-load.xml > [ant:patch] patching file > E:\eclipse-workspace\Misterlight_branch_2.1\framework\widget\templates\HtmlFormMacroLibrary.ftl > [ant:patch] patching file > E:\eclipse-workspace\Misterlight_branch_2.1\framework\widget\templates\HtmlScreenMacroLibrary.ftl > [ant:patch] patching file > E:\eclipse-workspace\Misterlight_branch_2.1\framework\widget\templates\HtmlMenuMacroLibrary.ftl > [ant:patch] patching file > E:\eclipse-workspace\Misterlight_branch_2.1\framework\common\widget\CommonScreens.xml > [ant:patch] Assertion failed: hunk, file ../patch-2.5.9-src/patch.c, line > 354 > :hot-deploy:crest-common:applyCustomPatch FAILED > :hot-deploy:crest-common:applyCustomPatch (Thread[main,5,main]) completed. > Took 0.402 secs. > > FAILURE: Build failed with an exception. > > * Where: > Build file > 'E:\eclipse-workspace\Misterlight_branch_2.1\hot-deploy\crest-common\build.gradle' > line: 44 > > * What went wrong: > Execution failed for task ':hot-deploy:crest-common:applyCustomPatch'. > > 'patch' failed with exit code 3 > > Configuration having: > > E:\eclipse-workspace\Misterlight_branch_2.1>where java > C:\Program Files (x86)\Common Files\Oracle\Java\javapath\java.exe > C:\Program Files\Java\jdk1.8.0_333\bin\java.exe > > E:\eclipse-workspace\Misterlight_branch_2.1>gradlew -version > > > Gradle 2.13 > > > Build time: 2016-04-25 04:10:10 UTC > Build number: none > Revision: 3b427b1481e46232107303c90be7b05079b05b1c > > Groovy: 2.4.4 > Ant: Apache Ant(TM) version 1.9.6 compiled on June 29 2015 > JVM: 1.8.0_333 (Oracle Corporation 25.333-b02) > OS: Windows 11 10.0 amd64 > > Can anyone please help me, why gradlew applyCuystomPatch -Penv=dev is > failing. > > Best Regards, > Sahana S > -- Daniel Watford
Re: Demos are down since this morning around nine UTC
Hi Jacques, What was the cause of the outage? Thanks, Dan On Thu, 1 Jun 2023, 12:47 Jacques Le Roux, wrote: > All is OK now > > Le 01/06/2023 à 12:40, Jacques Le Roux a écrit : > > The stable demo is back but not the trunk and next yet. > > > > Le 01/06/2023 à 12:07, Jacques Le Roux a écrit : > >> I'm looking at it... > >> > >> Jacques > >> >
Re: [OFBIZ-12801] "Error at CommunicationEventServices.groovy:489"
Hi Nicholas,
I can see value in the approach I think you are proposing (please correct
me if I am wrong) which I would summarise as:
- All scripts are considered service implementations and will handle
parameters and return types accordingly, and
- GroovyEventHandler should invoke an event handler as if it was a service
implementation and convert the result (i.e. a Map) in a way
similar to that in the GroovyEventHandler code that you quoted.
GroovyEventHandler effectively becomes an adapter between service calling
conventions and event-handler calling conventions.
The problem I see with the above approach is that an event handler may need
to access the Request object, something that service implementations cannot
do. If we force all groovy event handlers to be implemented as service
implementations which are later 'adapted' to the event handler calling
conventions, then we are making it difficult for the developer to
understand what interface (calling conventions) they are working with.
Taking my previous suggestion further, we could implement logic around the
following test in GroovyEventHandler and GroovyEngine respectively:
script
.getClass().getDeclaredMethod(event.getInvoke()).getReturnType().isAssignableFrom(EventResponse.
class)
script
.getClass().getDeclaredMethod(modelService.getInvoke()).getReturnType().isAssignableFrom(ServiceResponse.
class)
If the methods to be called by GroovyEventHandler and GroovyEngine do not
declare the expected return type, then a warning can be logged.
For the simple 'adapter' cases, we could implement helper methods in
GroovyBaseScript to convert between EventResponse and ServiceResponse
objects, but for more complicated cases, the method author is free to
implement an adapter appropriate to their business rules.
A principle that drives the above, in my opinion at least, is that a method
author MUST know whether they are implementing a service or an event
handler since there may be differences in context that they depend on. By
incorporating the EventReponse and ServiceReponse types the author can make
it clear to the reader (and to OFBiz) which context the code was written
for.
Thanks,
Dan.
On Fri, 28 Apr 2023 at 16:53, Nicolas Malin
wrote:
> Hi,
>
> My preference would be to the simplest for developer and keep the three
> word (error, failure and success). For that, we can force the return of
> each function as Map.
>
> After delegate the problematic to each handler. By the way, the
> GroovyEventHandler that call GroovyBaseScript already support an output
> as Map or as String :
>
> // GroovyEventHandler.java:117 [1]
>
> // check the result
> if (result instanceof Map) {
> Map resultMap = UtilGenerics.cast(result);
> String successMessage = (String)
> resultMap.get("_event_message_");
> if (successMessage != null) {
> request.setAttribute("_EVENT_MESSAGE_",
> successMessage);
> }
> String errorMessage = (String)
> resultMap.get("_error_message_");
> if (errorMessage != null) {
> request.setAttribute("_ERROR_MESSAGE_", errorMessage);
> }
> return (String) resultMap.get("_response_code_");
> }
> if (result != null && !(result instanceof String)) {
> throw new EventHandlerException("Event did not return a
> String result, it returned a " + result.getClass().getName());
> }
> return (String) result;
>
>
> If I understand well the problematic, move the return to Map, and
> improve GroovyEventHandler to support the groovy script return (better
> than what it did currently) would be cover all case ?
>
> Cheers,
> Nicolas
>
> [1]
>
> https://github.com/apache/ofbiz-framework/blob/64d012d2c20d76200cedd3e1861b720d55a61398/framework/webapp/src/main/java/org/apache/ofbiz/webapp/event/GroovyEventHandler.java#L117
>
> On 28/04/2023 16:07, Daniel Watford wrote:
> > Hi Gil,
> >
> > I don't think we need to go as far as creating a new GroovyBaseClass.
> >
> > Deprecating GroovyBaseScript:success is still preferred in my opinion,
> > replacing it with serviceSuccess and scriptSuccess. These two methods
> could
> > return separate types which extend from Map and help make it clear
> whether
> > the method in the groovyScript is intended by the author to implement a
> > service or an event handler.
> >
> > In the rare cases of a current groovy method being used to implement
> both a
> > service and an event handler, I think we could do something similar to
> this
> > contrived e
Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.
;>> line 304 Java Problem > >>>>>>>>>> Document cannot be resolved to a type CCPaymentServices.java > >>>>>>>>>> > /ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/clearcommerce > > >>>>>>>>>> > >>>>>>>>>> line 381 Java Problem > >>>>>>>>>> Document cannot be resolved to a type CCPaymentServices.java > >>>>>>>>>> > /ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/clearcommerce > > >>>>>>>>>> > >>>>>>>>>> line 427 Java Problem > >>>>>>>>>> Document cannot be resolved to a type CCPaymentServices.java > >>>>>>>>>> > /ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/clearcommerce > > >>>>>>>>>> > >>>>>>>>>> line 461 Java Problem > >>>>>>>>>> Document cannot be resolved to a type CCPaymentServices.java > >>>>>>>>>> > /ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/clearcommerce > > >>>>>>>>>> > >>>>>>>>>> line 495 Java Problem > >>>>>>>>>> Document cannot be resolved to a type CCPaymentServices.java > >>>>>>>>>> > /ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/clearcommerce > > >>>>>>>>>> > >>>>>>>>>> line 529 Java Problem > >>>>>>>>>> Document cannot be resolved to a type CCPaymentServices.java > >>>>>>>>>> > /ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/clearcommerce > > >>>>>>>>>> > >>>>>>>>>> line 563 Java Problem > >>>>>>>>>> Document cannot be resolved to a type CCPaymentServices.java > >>>>>>>>>> > /ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/clearcommerce > > >>>>>>>>>> > >>>>>>>>>> line 597 Java Problem > >>>>>>>>>> Document cannot be resolved to a type CCPaymentServices.java > >>>>>>>>>> > /ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/clearcommerce > > >>>>>>>>>> > >>>>>>>>>> line 622 Java Problem > >>>>>>>>>> Document cannot be resolved to a type CCPaymentServices.java > >>>>>>>>>> > /ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/clearcommerce > > >>>>>>>>>> > >>>>>>>>>> line 640 Java Problem > >>>>>>>>>> Document cannot be resolved to a
Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.
Hi Jacques, Sorry for the late reply - it has been a busy May-day bank holiday weekend here in the UK. I think you have already checked this, but yes, you can indeed modify Groovy script code while OFBiz is running. The script will be re-loaded (and internally recompiled) by GroovyUtil#getScriptClassFromLocation. Although at first glance it appears that GroovyUtil has a PARSED_SCRIPTS cache, so I'm not sure why the updated script is loaded. Perhaps some other process is running to invalidate the cache on file update. I have not delved into the details of how IntelliJ maps loaded classes to source files. I assume there is a mechanism that detects the loading of new classes and figures out a mapping of class back to source file, meaning that once a groovy script is loaded, all breakpoints in that script's source file become live while debugging and will move appropriately following source code changes. Dan. On Sat, 29 Apr 2023 at 13:12, Jacques Le Roux wrote: > Hi Daniel, > > Do you know how are reacting dynamically changed Groovy scripts while you > are Debugging them, at least in Eclipse (I don't use Intellij). > The big advantage of minilang was its faculty to allow dynamic changes, > like Freemarker does. We have the same advantage with Groovy. > But I wonder for dynamically changed Groovy scripts while you are > Debugging in Eclipse. > For instance for Java it's sometimes allowed, but sometimes you need to > reload all :/ > > Jacques > > Le 28/04/2023 à 12:30, Daniel Watford a écrit : > > The reason for checking is that groovyScripts are loaded as independent > > scripts and compiled at runtime by OFBiz (See > > GroovyUtil#getScriptClassFromLocation), rather than being loaded from a > > pre-compiled JAR. > -- Daniel Watford
Re: [OFBIZ-12801] "Error at CommunicationEventServices.groovy:489"
Hi Gil,
I don't think we need to go as far as creating a new GroovyBaseClass.
Deprecating GroovyBaseScript:success is still preferred in my opinion,
replacing it with serviceSuccess and scriptSuccess. These two methods could
return separate types which extend from Map and help make it clear whether
the method in the groovyScript is intended by the author to implement a
service or an event handler.
In the rare cases of a current groovy method being used to implement both a
service and an event handler, I think we could do something similar to this
contrived example:
/
// GroovyBaseScript.groovy
interface ServiceResponse extends Map
interface EventResponse extends Map
ServiceResponse serviceSuccess() { ... }
ServiceResponse serviceFail(...) {...}
ServiceResponse serviceError(...) {...}
EventResponse eventSuccess(...) {...}
EventResponse eventFail(...) {...}
EventResponse eventError(...) {...}
//
// ExampleServiceAndEventImpl.groovy
// Here is the main implementation, initially implemented as a service
handler
ServiceResponse countProducts () {
...
...
return serviceSuccess([stock: 42])
// Here is the event handler implementation, leveraging the service
implementation as an adapter.
EventResponse countProductsEventHandler () {
ServiceResponse sr = countProducts();
return eventSuccess("Found ${sr.stock} products");
}
The return type of the above methods help identify whether we are dealing
with a service or event handler. If conversion is needed from one type to
the other, an adapter specific to the business logic can decide how to map
between EventResponses and ServiceResponses.
Thanks,
Dan.
On Fri, 28 Apr 2023 at 14:27, Gil Portenseigne
wrote:
> Hello I got a quick look about it, having two separate class means
> having two distinct groovy DSL and need lot of modification that IMO are
> not worth the complexity for this subject.
>
> I now only wonder, is it that bad too keep that one exception (about
> untyped return) for GroovyBaseScript::success ?
>
> Gil
>
> Le 26/04/2023 à 09:49, Gil Portenseigne a écrit :
> > Hello,
> >
> > I like the idea that the developer do not have to sync about which
> > method to use.
> >
> > If I understand well what Michael envision, i.e. to use for event a
> > new GroovyBaseEvent class, and for services/scripts a GroovyBaseScript
> > class, that both extends a common class for the common code, should be
> > one way to allow this usage.
> >
> > But I don't know about IDE integration behavior of such a solution...
> >
> > Do you think that is worth a look ?
> >
> > I will just add that there is a chance that project implementation are
> > using groovy script as the event target (I know some ;) )
> >
> > Thanks,
> >
> > Gil
> >
> > Le 20/04/2023 à 17:13, Michael Brohl a écrit :
> >> To have it even more clear, I would separate logic for events and
> >> services.
> >>
> >> The GroovyBaseScript in the service engine package should only be
> >> used for services and there should be another one for events, if
> >> really needed. Mixing both together is bad practice IMO. There seem
> >> to be only 7 controller entries using a groovy script as the event
> >> target.
> >>
> >> Best regards,
> >>
> >> Michael Brohl
> >>
> >> ecomify GmbH - www.ecomify.de
> >>
> >>
> >> Am 20.04.23 um 16:49 schrieb Jacques Le Roux:
> >>> Hi Daniel,
> >>>
> >>> I dont think there is a knowledge about methods being both services
> >>> and events. I think there are not (much?) such cases.
> >>> Being acquainted to OFBiz logs I did not check the trunk demo log
> >>> content (now in Docker);
> >>> so I wonder if there are such other cases than
> >>> CommunicationEventServices::sendEmail (colon notation is available
> >>> in Groovy 3)
> >>> that bots and demo uses could have generated.
> >>>
> >>> I tend to agree about having GroovyBaseScript::success deprecated
> >>> and replaced with methods GroovyBaseScript::scriptSuccess
> >>> GroovyBaseScript::serviceSuccess and GroovyCaseScript::eventSuccess
> >>>
> >>> I'm not yet acquainted with Codernarc rules, but the changes in
> >>> GroovyBaseScript seem straightforward.
> >>> And (hopefully) this should not be a big deal to change accordingly
> >>> in scripts methods with the help of Codenarc, right ?
> >>>
> >>> My 2 cts
> >>>
> >>> Jacques
> >>>
> >>> Le 19/04/202
Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.
line 261 Java Problem > >>>>>>>>>>>>> Document cannot be resolved to a type CCPaymentServices.java > >>>>>>>>>>>>> > /ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/clearcommerce > > >>>>>>>>>>>>> > >>>>>>>>>>>>> line 264 Java Problem > >>>>>>>>>>>>> Document cannot be resolved to a type CCPaymentServices.java > >>>>>>>>>>>>> > /ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/clearcommerce > > >>>>>>>>>>>>> > >>>>>>>>>>>>> line 304 Java Problem > >>>>>>>>>>>>> Document cannot be resolved to a type CC
Re: [jira] [Commented] (OFBIZ-12808) Eclipse build problems and proper dependency setup
Hi Michael, Demo-trunk and demo-next have now been refreshed with builds containing OFBIZ-12808. On Thu, 27 Apr 2023 at 07:40, Daniel Watford wrote: > Hi Michael, > > The demo instances do get updated overnight - around 02:35 from memory. > > Just in case there was a race condition between the commits on > ofbiz-plugins vs ofbiz-framework, I've triggered a rebuild of the release > branch and trunk container images. > > Once the re-build is complete I'll run the script to update the demo > instances with the new container images. > > On Thu, 27 Apr 2023 at 07:28, Michael Brohl > wrote: > >> Thanks all, >> >> the fixes are implemented and merged for framework/plugins in the trunk >> and release22.01 branches now. >> >> When will those changes be deployed to the demo instances? Over night? >> >> It would be helpful if someone can test framework and plugins on the >> trunk and release22.01 demo instances to detect any runtime problems >> caused by the dependency changes. >> >> For plugins, changes were being made in the BIRT and LDAP components. >> >> Best regards, >> >> Michael Brohl >> >> ecomify GmbH - www.ecomify.de >> >> >> Am 26.04.23 um 17:24 schrieb Gil Portenseigne: >> > +1 >> > >> > Gil >> > >> > Le 26/04/2023 à 16:36, Jacques Le Roux a écrit : >> >> +1 >> >> >> >> Jacques >> >> >> >> Le 26/04/2023 à 16:01, Jacopo Cappellato a écrit : >> >>> +1 >> >>> >> >>> Jacopo >> >>> >> >>> On Wed, Apr 26, 2023 at 3:11 PM Michael Brohl >> >>> wrote: >> >>>> Hi everyone, >> >>>> >> >>>> any objections against merging those pr's for framework/plugins in >> >>>> trunk/release22.01? >> >>>> >> >>>> I think it would be good to test the changes on the demo servers as >> >>>> well >> >>>> to detect possible runtime problems caused by the changed >> >>>> dependencies. >> >>>> >> >>>> If there are no objections, I would like to merge the changes >> >>>> tomorrow. >> >>>> >> >>>> Thanks, >> >>>> >> >>>> Michael Brohl >> >>>> >> >>>> ecomify GmbH - www.ecomify.de >> >>>> >> >>>> >> >>>> Am 21.04.23 um 14:54 schrieb Michael Brohl (Jira): >> >>>>> [ >> >>>>> >> https://issues.apache.org/jira/browse/OFBIZ-12808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17714986#comment-17714986 >> >>>>> ] >> >>>>> >> >>>>> Michael Brohl commented on OFBIZ-12808: >> >>>>> --- >> >>>>> >> >>>>> Fixes for framework / plugins for trunk and release22.01 are now >> >>>>> in the pull requests. >> >>>>> >> >>>>> To test, the corresponding pr's for framework and plugins have to >> >>>>> be checked out respectively. >> >>>>> >> >>>>>> Eclipse build problems and proper dependency setup >> >>>>>> -- >> >>>>>> >> >>>>>> Key: OFBIZ-12808 >> >>>>>> URL: >> >>>>>> https://issues.apache.org/jira/browse/OFBIZ-12808 >> >>>>>> Project: OFBiz >> >>>>>>Issue Type: Bug >> >>>>>>Components: ALL APPLICATIONS, ALL COMPONENTS, ALL >> PLUGINS >> >>>>>> Affects Versions: 22.01.01, Upcoming Branch >> >>>>>> Reporter: Michael Brohl >> >>>>>> Assignee: Michael Brohl >> >>>>>> Priority: Major >> >>>>>> Fix For: 22.01.01, Upcoming Branch >> >>>>>> >> >>>>>> >> >>>>>> Due to improper dependency configurations and the JPMS (Java >> >>>>>> Plattform Module System) which was introduced to Java since >> >>>>>> version 9, the Eclipse build and running/debugging is not working >> >>>>>> with JDK 17 (trunk and release22.01). >> >>>>>> The reason is that there are dependencies to libraries which are >> >>>>>> also shipped with the JDK which causes a conflict leading to >> >>>>>> ignore those packages/classes in the build. >> >>>>>> We have a working solution for this. >> >>>>> >> >>>>> -- >> >>>>> This message was sent by Atlassian Jira >> >>>>> (v8.20.10#820010) >> > > > -- > Daniel Watford > -- Daniel Watford
Re: [jira] [Commented] (OFBIZ-12808) Eclipse build problems and proper dependency setup
Hi Michael, The demo instances do get updated overnight - around 02:35 from memory. Just in case there was a race condition between the commits on ofbiz-plugins vs ofbiz-framework, I've triggered a rebuild of the release branch and trunk container images. Once the re-build is complete I'll run the script to update the demo instances with the new container images. On Thu, 27 Apr 2023 at 07:28, Michael Brohl wrote: > Thanks all, > > the fixes are implemented and merged for framework/plugins in the trunk > and release22.01 branches now. > > When will those changes be deployed to the demo instances? Over night? > > It would be helpful if someone can test framework and plugins on the > trunk and release22.01 demo instances to detect any runtime problems > caused by the dependency changes. > > For plugins, changes were being made in the BIRT and LDAP components. > > Best regards, > > Michael Brohl > > ecomify GmbH - www.ecomify.de > > > Am 26.04.23 um 17:24 schrieb Gil Portenseigne: > > +1 > > > > Gil > > > > Le 26/04/2023 à 16:36, Jacques Le Roux a écrit : > >> +1 > >> > >> Jacques > >> > >> Le 26/04/2023 à 16:01, Jacopo Cappellato a écrit : > >>> +1 > >>> > >>> Jacopo > >>> > >>> On Wed, Apr 26, 2023 at 3:11 PM Michael Brohl > >>> wrote: > >>>> Hi everyone, > >>>> > >>>> any objections against merging those pr's for framework/plugins in > >>>> trunk/release22.01? > >>>> > >>>> I think it would be good to test the changes on the demo servers as > >>>> well > >>>> to detect possible runtime problems caused by the changed > >>>> dependencies. > >>>> > >>>> If there are no objections, I would like to merge the changes > >>>> tomorrow. > >>>> > >>>> Thanks, > >>>> > >>>> Michael Brohl > >>>> > >>>> ecomify GmbH - www.ecomify.de > >>>> > >>>> > >>>> Am 21.04.23 um 14:54 schrieb Michael Brohl (Jira): > >>>>> [ > >>>>> > https://issues.apache.org/jira/browse/OFBIZ-12808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17714986#comment-17714986 > >>>>> ] > >>>>> > >>>>> Michael Brohl commented on OFBIZ-12808: > >>>>> --- > >>>>> > >>>>> Fixes for framework / plugins for trunk and release22.01 are now > >>>>> in the pull requests. > >>>>> > >>>>> To test, the corresponding pr's for framework and plugins have to > >>>>> be checked out respectively. > >>>>> > >>>>>> Eclipse build problems and proper dependency setup > >>>>>> -- > >>>>>> > >>>>>> Key: OFBIZ-12808 > >>>>>> URL: > >>>>>> https://issues.apache.org/jira/browse/OFBIZ-12808 > >>>>>> Project: OFBiz > >>>>>>Issue Type: Bug > >>>>>>Components: ALL APPLICATIONS, ALL COMPONENTS, ALL PLUGINS > >>>>>> Affects Versions: 22.01.01, Upcoming Branch > >>>>>> Reporter: Michael Brohl > >>>>>> Assignee: Michael Brohl > >>>>>> Priority: Major > >>>>>> Fix For: 22.01.01, Upcoming Branch > >>>>>> > >>>>>> > >>>>>> Due to improper dependency configurations and the JPMS (Java > >>>>>> Plattform Module System) which was introduced to Java since > >>>>>> version 9, the Eclipse build and running/debugging is not working > >>>>>> with JDK 17 (trunk and release22.01). > >>>>>> The reason is that there are dependencies to libraries which are > >>>>>> also shipped with the JDK which causes a conflict leading to > >>>>>> ignore those packages/classes in the build. > >>>>>> We have a working solution for this. > >>>>> > >>>>> -- > >>>>> This message was sent by Atlassian Jira > >>>>> (v8.20.10#820010) > -- Daniel Watford
Re: Buildbot failure in on ofbizTrunkFrameworkPlugins
Hi Jacques, We'll need some text in the README adjacent to the badge image to explain which build each badge relates to. On Thu, 20 Apr 2023 at 19:32, Jacques Le Roux wrote: > Le 19/04/2023 à 11:24, Jacques Le Roux a écrit : > > Good idea about the badge. I'll have a look. > > Hi Daniel, > > It's OK for trunk build but how to cleanly differentiate ? > > https://ci2.apache.org/badges/ofbizTrunkFramework.svg > from > https://ci2.apache.org/badges/ofbizTrunkFrameworkRat.svg > > https://ci2.apache.org/badges/ gives nothing :/ > > Jacques > > -- Daniel Watford
Re: Lazy consensus: Build docker container images for the release22.01 branch and demo-next site
Hi Michael, Those changes have been applied to trunk and release22.01. You should be able to sync your repository fork and avoid the build failures related to pushing docker images. On Thu, 20 Apr 2023 at 11:42, Michael Brohl wrote: > Hi Dan, > > sound good! > > I would propose to name the environment variable more explicitely, e.g. > DO_DOCKER_PUSH. DO_PUSH sounds too broad to me. > > Thanks, > > Michael Brohl > > ecomify GmbH - www.ecomify.de > > > Am 20.04.23 um 12:25 schrieb Daniel Watford: > > Hi Michael, > > > > I have just reproduced the issue you raised at > > https://github.com/danwatford/ofbiz-framework by resyncing trunk. > > > > Yes, we can (and should) make the problematic steps skippable/optional. > > > > If you drill into the GitHub Action you will probably find the failure > > occurred at step, 'Build and push runtime docker image'. > > > > If you look at the GitHub Actions definition file, > > $ofbiz-framework/.github/workflows/docker-image.yml, for the 'Build and > > push runtime docker image' step (lines 89-96) we use an environment > > variable to control whether the image is pushed to ghcr.io/apache/ofbiz. > > > > Currently we check to see if env.ACT is unset, but perhaps we should > change > > this to see if an environment variable similar to 'DO_PUSH' exists. We > > would then set that environment variable of apache/ofbiz-framework, but > it > > would be unset on all forks. > > > > I'll raise a ticket. > > > > Dan. > > > > > > On Thu, 20 Apr 2023 at 11:02, Michael Brohl > > wrote: > > > >> Hi Dan, > >> > >> the build integration to build docker images seems to break forks and > >> therefore external repositories. > >> > >> When synching our fork, a git actions seems to chime in: > >> > >> === > >> > >> Build and push docker images: All jobs have failed > >> Build and push OFBiz docker container images > >> > >> Build and push docker images / Build and push OFBiz docker container > images > >> Failed in 4 minutes and 2 seconds > >> > >> docker-image.yaml > >> on: push > >> > >> Annotations > >> 1 error > >> Build and push OFBiz docker container images > >> buildx failed with: ERROR: denied: permission_denied: The requested > >> installation does not exist. > >> > >> === > >> > >> Is it possible to configure this in a way that this is optional or must > >> be triggered explicitely? > >> > >> Thanks, > >> > >> Michael Brohl > >> > >> ecomify GmbH - www.ecomify.de > >> > >> > >> Am 06.04.23 um 21:25 schrieb Daniel Watford: > >>> Hello, > >>> > >>> We recently configured the demo-trunk site ( > >>> https://demo-trunk.ofbiz.apache.org/partymgr) to use docker containers > >>> based on images built following commits to the ofbiz-framework trunk > >> branch > >>> (https://issues.apache.org/jira/browse/OFBIZ-12786) > >>> > >>> This work brought about some improvements in how containers are > deployed, > >>> particularly regarding the disabling of specified plugins when a > >> container > >>> is started up. > >>> > >>> The deployment also highlighted that memory constraints applied to the > >>> ofbiz container were too low and that there was a bug in the logic used > >> to > >>> set the password for the tenant database. Both of these issues were > >> quickly > >>> resolved. > >>> > >>> Through deployment of the demo-trunk site as a container, we also > >>> demonstrated how we can alter the configuration of an OFBiz instance at > >>> runtime through the use of scripts which 'hook' into various stages of > >> the > >>> initialisation process. See the scripts used for demo-trunk here - > >>> > >> > https://github.com/apache/ofbiz-tools/tree/master/demo-backup/ofbizdocker/home/ofbizdocker/demo-trunk/after-config-applied.d > >>> > >>> LAZY CONSENSUS > >>> > >>> This email thread is to establish if we have a lazy consensus to > >>> automatically build and publish container images for commits to the > >>> ofbiz-framework release22.01 branch similar to what is currently > >> configured > >>> for the trunk bran
Re: Lazy consensus: Build docker container images for the release22.01 branch and demo-next site
Hi Michael, I have just reproduced the issue you raised at https://github.com/danwatford/ofbiz-framework by resyncing trunk. Yes, we can (and should) make the problematic steps skippable/optional. If you drill into the GitHub Action you will probably find the failure occurred at step, 'Build and push runtime docker image'. If you look at the GitHub Actions definition file, $ofbiz-framework/.github/workflows/docker-image.yml, for the 'Build and push runtime docker image' step (lines 89-96) we use an environment variable to control whether the image is pushed to ghcr.io/apache/ofbiz. Currently we check to see if env.ACT is unset, but perhaps we should change this to see if an environment variable similar to 'DO_PUSH' exists. We would then set that environment variable of apache/ofbiz-framework, but it would be unset on all forks. I'll raise a ticket. Dan. On Thu, 20 Apr 2023 at 11:02, Michael Brohl wrote: > Hi Dan, > > the build integration to build docker images seems to break forks and > therefore external repositories. > > When synching our fork, a git actions seems to chime in: > > === > > Build and push docker images: All jobs have failed > Build and push OFBiz docker container images > > Build and push docker images / Build and push OFBiz docker container images > Failed in 4 minutes and 2 seconds > > docker-image.yaml > on: push > > Annotations > 1 error > Build and push OFBiz docker container images > buildx failed with: ERROR: denied: permission_denied: The requested > installation does not exist. > > === > > Is it possible to configure this in a way that this is optional or must > be triggered explicitely? > > Thanks, > > Michael Brohl > > ecomify GmbH - www.ecomify.de > > > Am 06.04.23 um 21:25 schrieb Daniel Watford: > > Hello, > > > > We recently configured the demo-trunk site ( > > https://demo-trunk.ofbiz.apache.org/partymgr) to use docker containers > > based on images built following commits to the ofbiz-framework trunk > branch > > (https://issues.apache.org/jira/browse/OFBIZ-12786) > > > > This work brought about some improvements in how containers are deployed, > > particularly regarding the disabling of specified plugins when a > container > > is started up. > > > > The deployment also highlighted that memory constraints applied to the > > ofbiz container were too low and that there was a bug in the logic used > to > > set the password for the tenant database. Both of these issues were > quickly > > resolved. > > > > Through deployment of the demo-trunk site as a container, we also > > demonstrated how we can alter the configuration of an OFBiz instance at > > runtime through the use of scripts which 'hook' into various stages of > the > > initialisation process. See the scripts used for demo-trunk here - > > > https://github.com/apache/ofbiz-tools/tree/master/demo-backup/ofbizdocker/home/ofbizdocker/demo-trunk/after-config-applied.d > > > > > > LAZY CONSENSUS > > > > This email thread is to establish if we have a lazy consensus to > > automatically build and publish container images for commits to the > > ofbiz-framework release22.01 branch similar to what is currently > configured > > for the trunk branch. These container images will have container tags > such > > as release22.01-snapshot. > > > > Further, GitHub actions will also build container images in response to > > tags, prefixed with 'release', being pushed to the release22.01 branch. > > These containers will have container tags derived from the git tag. For > > example, git tag 'release22.01.02' would result in a container tag of > > '22.01.02'. > > > > This email thread is also to establish if we have lazy consensus to then > > use the release22.01-snapshot container images for deployment of the > > demo-next site (https://demo-next.ofbiz.apache.org/partymgr) similar to > > what is currently in place for trunk. The container tags current used can > > be seen here - > > https://github.com/apache/ofbiz-framework/pkgs/container/ofbiz > > > > Using a container for deployment removes the need to have any > dependencies > > in place on the host OS used for the demo-next site. Dependencies are not > > an issue at the moment, but may become difficult to manage if and when we > > want to vary the JDK used to build and run release22.01. > > > > Container images produced by the GitHub Actions workflow will be > published > > to the GitHub Container Registry (ghcr.io). They should only be > considered > > as a convenience to users who wish to use containers. Container images > are > > not an official release of the Apache OFBiz project. I am not proposing > to > > alter any README files to refer to the container images at this time. > > > > Thanks, > > > > Dan. > > > -- Daniel Watford
Re: [OFBIZ-12801] "Error at CommunicationEventServices.groovy:489"
Hello, In my opinion, the semantics of calling an event handler vs a service implementation are different, albeit similar enough that most handler/implementation authors wouldn't necessarily care how the code was called. The untyped nature of Groovy had allowed a certain degree of flexibility in code that GroovyBaseScript#success could be relied upon to prepare a response appropriate to the calling conventions of an event handler or service implementation. However over the last decade, possibly driven by increased use of linters/static analysers, we have seen a push back towards explicit typing, particularly on public methods. If we continue to adopt the guidance from static analysers and apply explicit typing to public methods in our groovy code, then we need to avoid the black box approach of GroovyBaseScript#success figuring out what calling conventions (i.e. event or service) are in play and, instead, a groovy method should be intentionally written as either a service or event handler. If we have cases where a groovy method is used to provide implementations for both a service and an event handler, then we can employ a thin adapter layer to convert the result type between the two calling conventions. Do we know if many such cases currently exist in OFBiz? My preference would be to see GroovyBaseScript#success deprecated and replaced with methods along the lines of GroovyBaseScript#scriptSuccess and GroovyCaseScript#eventSuccess that return a Map and String respectively. Thanks, Dan. On Wed, 19 Apr 2023 at 16:44, Jacques Le Roux wrote: > Hi All, > > At OFBIZ-12801, we had a discussion with Daniel and Gil about the > described issue (last comments there) > We are unsure of the best solution, so this thread to discuss and decide. > > As Gil reported, Jacopo's comment of the related commit* contains > > < groovy method executed as services or events in a transparent way.>> > > What would be your opinion about a best solution? > > TIA > > Jacques > > * http://svn.apache.org/viewvc?view=revision&revision=1298908 > -- Daniel Watford
Re: Need help finding where JCrop is used
Hi Michael, I couldn't find anything in the UI for product content that would allow manipulation (cropping, rotating, resizing) of images. It's not a well known area for me, hence wanting to check in with the community. I imagine the functionality was withdrawn from the UI at some point, but backend source files were left behind. Thanks, Dan. On Wed, 19 Apr 2023 at 08:20, Michael Brohl wrote: > I think there is some functionality in the field of (product) content > management to automatically resize images. > > Has this anyting to do with it? > > Regards, > > Michael Brohl > > ecomify GmbH - www.ecomify.de > > > Am 19.04.23 um 08:17 schrieb Daniel Watford: > > Thanks Jacques and Jacopo for your responses. > > > > Jacques, like you I found the path to the functionality through > > controller.xml, but was not able to find any path through the UI that a > > user would take to make use of the functionality. > > > > This leads me to believe the Jcrop (and other associated) functionality > is > > no longer in use and, like Jacopo said, it is acceptable to remove it > from > > the OFBiz sources. I'll raise a ticket separate to the other npm work to > do > > this. > > > > Thanks, > > > > Dan. > > > > On Tue, 18 Apr 2023 at 11:00, Jacopo Cappellato < > jacopo.cappell...@gmail.com> > > wrote: > > > >> Hello, > >> > >> For cases like this one, i.e. an external dependency from old code > >> that is only partially functional for a long time, I think it is > >> acceptable to remove it (if its presence is making it more difficult > >> to do some new work or refactoring). > >> > >> Jacopo > >> > >> On Mon, Apr 17, 2023 at 7:25 PM Jacques Le Roux > >> wrote: > >>> Hi Daniel, > >>> > >>> It's used in ImageCrop.ftl. Itself used in name="ImageCropping"> > >> inside ImageManagementScreens.xml > >>> There is a and a >> name="ImageCropping" inside ImageManagementForms.xml related to > >>> uri="CropImage">, etc. > >>> > >>> I guess it's used to resize images but it does not seems to work well > >> (at least a jpg file was blurred) > >>> This was initially put in in 2010 : https://s.apache.org/ak8s6 (can be > >> seen in https://markmail.org/message/udi25j4wyqyrowcu) > >>> Not sure of the current quality > >>> > >>> HTH > >>> > >>> Jacques > >>> > >>> Le 17/04/2023 à 13:43, Daniel Watford a écrit : > >>>> Hello, > >>>> > >>>> As part of https://issues.apache.org/jira/browse/OFBIZ-12789 I wanted > >> to > >>>> understand how the javascript library jcrop was being used by OFBiz. > >> This > >>>> is so I can ensure any replacement library sourced from npm would > >> continue > >>>> to work correctly. > >>>> > >>>> I have found the various screen and form definitions > >>>> (ImageManagementScreens and ImageManagementForms) in > >>>> applications/product/widget/catalog, but cannot find any path through > >> the > >>>> UI that would take a user to these screens. > >>>> > >>>> I have found the Image Management sub-application under > >>>> https://localhost:8443/catalog/control/Imagemanagement, but this > >> screen > >>>> does not appear to make use of image cropping or resizing. > >>>> > >>>> Please could someone guide me to the correct part of the UI where > >>>> jquery.jcrop.js is used? Or perhaps this functionality was removed at > >> some > >>>> point and we just have some old library files let in the OFBiz sources > >> that > >>>> can be cleaned up? > >>>> > >>>> Thanks, > >>>> > >>>> Dan. > >>>> > > > -- Daniel Watford
Re: Need help finding where JCrop is used
Thanks Jacques and Jacopo for your responses. Jacques, like you I found the path to the functionality through controller.xml, but was not able to find any path through the UI that a user would take to make use of the functionality. This leads me to believe the Jcrop (and other associated) functionality is no longer in use and, like Jacopo said, it is acceptable to remove it from the OFBiz sources. I'll raise a ticket separate to the other npm work to do this. Thanks, Dan. On Tue, 18 Apr 2023 at 11:00, Jacopo Cappellato wrote: > Hello, > > For cases like this one, i.e. an external dependency from old code > that is only partially functional for a long time, I think it is > acceptable to remove it (if its presence is making it more difficult > to do some new work or refactoring). > > Jacopo > > On Mon, Apr 17, 2023 at 7:25 PM Jacques Le Roux > wrote: > > > > Hi Daniel, > > > > It's used in ImageCrop.ftl. Itself used in > inside ImageManagementScreens.xml > > There is a and a name="ImageCropping" inside ImageManagementForms.xml related to > uri="CropImage">, etc. > > > > I guess it's used to resize images but it does not seems to work well > (at least a jpg file was blurred) > > > > This was initially put in in 2010 : https://s.apache.org/ak8s6 (can be > seen in https://markmail.org/message/udi25j4wyqyrowcu) > > Not sure of the current quality > > > > HTH > > > > Jacques > > > > Le 17/04/2023 à 13:43, Daniel Watford a écrit : > > > Hello, > > > > > > As part of https://issues.apache.org/jira/browse/OFBIZ-12789 I wanted > to > > > understand how the javascript library jcrop was being used by OFBiz. > This > > > is so I can ensure any replacement library sourced from npm would > continue > > > to work correctly. > > > > > > I have found the various screen and form definitions > > > (ImageManagementScreens and ImageManagementForms) in > > > applications/product/widget/catalog, but cannot find any path through > the > > > UI that would take a user to these screens. > > > > > > I have found the Image Management sub-application under > > > https://localhost:8443/catalog/control/Imagemanagement, but this > screen > > > does not appear to make use of image cropping or resizing. > > > > > > Please could someone guide me to the correct part of the UI where > > > jquery.jcrop.js is used? Or perhaps this functionality was removed at > some > > > point and we just have some old library files let in the OFBiz sources > that > > > can be cleaned up? > > > > > > Thanks, > > > > > > Dan. > > > > -- Daniel Watford
Re: Buildbot failure in on ofbizTrunkFrameworkPlugins
Hi Jacques, I haven't found a way to selectively inhibit the failure state of a gradle task. However, I'm not sure we should take that approach otherwise we may find ourselves in a situation where issues related to checkstyle and codenarc are not addressed. [ Side note: In this particular case, the codenarc failure was caused by changes in ofbiz-plugins which are not built as part of the checking of a pull request. Codenarc issues will not be found in ofbiz-plugins until a new commit is pushed to ofbiz-framework trunk. Perhaps this is something we could think about. ] I have to confess to not checking Build Bot regularly. Instead I rely on the GitHub Actions builds since they are more visible to me. I imagine others are also failing to notice the status of the Build Bot builds and this is why these build failures are not getting addressed. To improve BuildBot visibility we could update the build status badges included in Readme.adoc. We currently include the badge for the framework build as: image:https://ci2.apache.org/badges/ofbizTrunkFramework.svg[link= https://ci2.apache.org/badges/ofbizTrunkFramework.svg] This should be change to link to BuildBot: image:https://ci2.apache.org/badges/ofbizTrunkFramework.svg[link= https://ci2.apache.org/#/builders/49] We could then add badges for the frameworkPlugins and RAT builds. Presumably the README.adoc would look something like: image:https://ci2.apache.org/badges/ofbizTrunkFrameworkPlugins.svg[link= https://ci2.apache.org/#/builders/46] image:https://ci2.apache.org/badges/ofbizTrunkFrameworkRat.svg[link= https://ci2.apache.org/#/builders/51] Perhaps there is a way to send an email notification to those who have pushed commits since the last successful build in the event of a new BuildBot build failure? Thanks, Dan. On Tue, 18 Apr 2023 at 13:29, Jacques Le Roux wrote: > Hi Team, > > Now that we have Codenarc used, we need to generate a report on our site > with BuildBot like we have: > https://nightlies.apache.org/ofbiz/trunk/checkstyle.html (also available > for next and stable). > This report allows everyone to see what the checkstyle problems are and to > fix them. > > In theory (much code violations) having a similar Codenarc report on site > would help us to fix the issue that we currently have at > https://ci2.apache.org/#/builders/46 reported below > > I launched the codenarcGroovyScripts Gradle task locally and got this > information at top of the report: > > Package Total Files Files with Violations Priority 1 > Priority 2 Priority 3 > All Packages547 134 - 448 4396 > 62 46 - 269 2416 > > Fortunately the BB issue does not prevent the rest of the BB script to > complete (the BB "check" step is marked as "haltOnFailure=False") > So it's not a blocker and does not hide other possible issue happening > "below" but it sticks the build status to BUILD FAILED. > So if another issue happens "below"we will not be alerted (no status > change ever). > > Here is the part that fails on BB (note: as you can see Cobertura is not a > problem): > > > Task :checkstyleTest > The Cobertura XML file [null] is not accessible; skipping this rule > > Task :checkstyleMain > > Task :codenarcGroovyScripts > CodeNarc completed: (p1=0; p2=448; p3=4409) 66597ms > > > Task :codenarcGroovyScripts FAILED > FAILURE: Build failed with an exception. > > * What went wrong: > Execution failed for task ':codenarcGroovyScripts'. > > CodeNarc rule violations were found. See the report at: > > file:///home/buildslave/slave/ofbizTrunkFrameworkPlugins/build/build/reports/codenarc/groovyScripts.html > > I'll create a Jira in order to generate a groovyScripts.html with BB > accessible on site. > But I'd like to know if it's possible to bypass the failed status. Either > by unlocking the rules or another mean? > > TIA > > Jacques > > Le 17/04/2023 à 11:26, build...@apache.org a écrit : > > Build status: BUILD FAILED: failed './gradlew --no-daemon ...' (failure) > './gradlew --no-daemon ...' (failure) > > Worker used: bb_worker4_ubuntu > > URL:https://ci2.apache.org/#builders/46/builds/507 > > Blamelist: Aditya Sharma, Benjamin Jugl< > benjamin.j...@ecomify.de>, Daniel Watford, Jacques Le > Roux, Michael Brohl, > Nicolas Malin, Pierre Smits< > pierre.sm...@gmail.com>, Pierre Smits, > cshan-ecomify<117295991+cshan-ecom...@users.noreply.github.com> > > Build Text: failed './gradlew --no-daemon ...' (failure) './gradlew > --no-daemon ...' (failure) > > Status Detected: new failure > > Build Source Stamp: [branch trunk] > 14
Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.
Hi Michael, Thank you for the heads up. I was aware that JetBrains provided licenses for open source committers, but thought I was ineligible on account of my consultancy work. However, your message prompted me to go and re-read the terms and conditions and I now realise that I am eligible to take one of the offered licenses for my OFBiz contributions. I am now happily running the latest IntelliJ Ultimate, although memory usage appears to have jumped by around 1GB since the previous version I had around 2 years ago. If/when I take on some OFBiz consultancy work I'll be sure to purchase an appropriate commercial license to provide appropriate cover. Thanks, Dan. On Fri, 14 Apr 2023 at 20:47, Michael Brohl wrote: > Hi Daniel, > > thanks for your reply! > > Are you aware that you can get a free license being an Open Source > Commiter at the ASF? See > https://www.jetbrains.com/community/opensource/#support . > > I have OFBiz up and running with IntelliJ Idea which works flawlessly > but we are mainly using Eclipse for the whole team and trying to get it > running there also. > > Best regards, > > Michael > > Am 14.04.23 um 17:33 schrieb Daniel Watford: > > Hi Michael, > > > > I did try getting Eclipse up and running a few weeks ago for OFBiz but > > failed, unfortunately. > > > > Following up from Jacques, I think Groovy debugging is going to be a > really > > important feature for an OFBiz Developers' IDE since so much of our > > minilang is getting converted to Groovy scripts. Using IntelliJ 'just > > works'. > > > > I let my IntelliJ Ultimate license lapse a while ago so recently updated > to > > the latest Community edition. The only thing missing from the IntelliJ > > Community edition for my work was Freemarker Template support. > > > > Every now and then I try using VS Code for OFBiz development but have not > > been successful so far. Groovy/Gradle support is not there in vscode at > the > > moment and, as mentioned for Eclipse, I think we really need good Groovy > > support in our IDE to develop OFBiz effectively. > > > > It's a shame about vscode as the ability to run your development > > environment inside a container or in WSL2 is really useful. > > > > So, apologies that I haven't really answered the original question and > have > > gone slightly off topic, but my recommendation is to give IntelliJ a try. > > > > Dan. > > > > > > On Fri, 14 Apr 2023 at 15:50, Jacques Le Roux < > jacques.le.r...@les7arts.com> > > wrote: > > > >> Hi Michael, > >> > >> Yes I did some. I have still this issue* pending but it does not prevent > >> to debug. > >> > >> It's also a long time I'm not able to make breakpoints to work for > groovy. > >> I must say I did not dig much because most of the time (so far all > cases) > >> a printl is enough. > >> > >> * https://github.com/eclipse-jdt/eclipse.jdt/issues/57 > >> > >> HTH > >> > >> Jacques > >> > >> Le 14/04/2023 à 15:31, Michael Brohl a écrit : > >>> Hi devs, > >>> > >>> just to pull up this topic to get more attention: > >>> > >>> is there anyone out there who has successfully imported a JDK 17 based > >> Apache OFBiz project into Eclipse and debugged from there? > >>> Thanks and regards, > >>> > >>> Michael > >>> > >>> > >>> Am 16.02.23 um 17:59 schrieb Jacques Le Roux: > >>>> Hi, > >>>> > >>>> It's a complicated matter due to indecision in an OpenJDK. > >>>> > >>>> I'm curious to know if people using Intellij are crossing the same > >> issue? That could explain why it has not been reported. Most OFBiz > >> committers > >>>> are using Intellij, I guess. > >>>> > >>>> I looked at this issue some time ago and found that Eclipse compiler > >> (used by UI to build the project) is not using the same way than javac. > >>>> That's why, as Cheng Hu Shan said: " OFBiz actually starts and is > >> operating properly thanks to the backwards compatibility of Java" > >>>> It's a "philosophy" difference. I found it well explained in this > >> stackoverflow answer (and links from there): https://s.apache.org/8n6op > >>>> You may also read > >> > https://stackoverflow.com/questions/55571046/eclipse-is-confused-by-imports-accessible-f
Need help finding where JCrop is used
Hello, As part of https://issues.apache.org/jira/browse/OFBIZ-12789 I wanted to understand how the javascript library jcrop was being used by OFBiz. This is so I can ensure any replacement library sourced from npm would continue to work correctly. I have found the various screen and form definitions (ImageManagementScreens and ImageManagementForms) in applications/product/widget/catalog, but cannot find any path through the UI that would take a user to these screens. I have found the Image Management sub-application under https://localhost:8443/catalog/control/Imagemanagement, but this screen does not appear to make use of image cropping or resizing. Please could someone guide me to the correct part of the UI where jquery.jcrop.js is used? Or perhaps this functionality was removed at some point and we just have some old library files let in the OFBiz sources that can be cleaned up? Thanks, Dan. -- Daniel Watford
Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.
g/apache/ofbiz/content/data > >>>> line 783 Java Problem > >>>> Document cannot be resolved to a type DataResourceWorker.java > >>>> > /ofbiz/applications/content/src/main/java/org/apache/ofbiz/content/data > >>>> line 813 Java Problem > >>>> Document cannot be resolved to a type Delegator.java > >>>> /ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity line > 702 Java > >>>> Problem > >>>> Document cannot be resolved to a type DhlServices.java > >>>> > /ofbiz/applications/product/src/main/java/org/apache/ofbiz/shipment/thirdparty/dhl > >>>> line 293 Java Problem > >>>> Document cannot be resolved to a type DhlServices.java > >>>> > /ofbiz/applications/product/src/main/java/org/apache/ofbiz/shipment/thirdparty/dhl > >>>> line 309 Java Problem > >>>> Document cannot be resolved to a type DhlServices.java > >>>> > /ofbiz/applications/product/src/main/java/org/apache/ofbiz/shipment/thirdparty/dhl > >>>> line 395 Java Problem > >>>> Document cannot be resolved to a type DhlServices.java > >>>> > /ofbiz/applications/product/src/main/java/org/apache/ofbiz/shipment/thirdparty/dhl > >>>> line 428 Java Problem > >>>> Document cannot be resolved to a type DhlServices.java > >>>> > /ofbiz/applications/product/src/main/java/org/apache/ofbiz/shipment/thirdparty/dhl > >>>> line 447 Java Problem > >>>> Document cannot be resolved to a type DhlServices.java > >>>> > /ofbiz/applications/product/src/main/java/org/apache/ofbiz/shipment/thirdparty/dhl > >>>> line 796 Java Problem > >>>> Document cannot be resolved to a type DhlServices.java > >>>> > /ofbiz/applications/product/src/main/java/org/apache/ofbiz/shipment/thirdparty/dhl > >>>> line 854 Java Problem > >>>> Document cannot be resolved to a type DhlServices.java > >>>> > /ofbiz/applications/product/src/main/java/org/apache/ofbiz/shipment/thirdparty/dhl > >>>> line 855 Java Problem > >>>> Document cannot be resolved to a type DispatchContext.java > >>>> /ofbiz/framework/service/src/main/java/org/apache/ofbiz/service line > 241 > >>>> Java Problem > >>>> Document cannot be resolved to a type DynamicViewEntity.java > >>>> /ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity/model > line 98 > >>>> Java Problem > >>>> Document cannot be resolved to a type DynamicViewEntity.java > >>>> /ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity/model > line > >>>> 109 Java Problem > >>>> Document cannot be resolved to a type EbayHelper.java > >>>> /ofbiz/plugins/ebay/src/main/java/org/apache/ofbiz/ebay line 103 Java > >>>> Problem > >>>> Document cannot be resolved to a type EbayOrderServices.java > >>>> /ofbiz/plugins/ebay/src/main/java/org/apache/ofbiz/ebay line 180 Java > >>>> Problem > >>>> Document cannot be resolved to a type EbayOrderServices.java > >>>> /ofbiz/plugins/ebay/src/main/java/org/apache/ofbiz/ebay line 230 Java > >>>> Problem > >>>> Document cannot be resolved to a type EbayOrderServices.java > >>>> /ofbiz/plugins/ebay/src/main/java/org/apache/ofbiz/ebay line 267 Java > >>>> Problem > >>>> Document cannot be resolved to a type EbayOrderServices.java > >>>> /ofbiz/plugins/ebay/src/main/java/org/apache/ofbiz/ebay line 454 Java > >>>> Problem > >>>> Document cannot be resolved to a type EbayOrderServices.java > >>>> /ofbiz/plugins/ebay/src/main/java/org/apache/ofbiz/ebay line 681 Java > >>>> Problem > >>>> Document cannot be resolved to a type EbayOrderServices.java > >>>> /ofbiz/plugins/ebay/src/main/java/org/apache/ofbiz/ebay line 993 Java > >>>> Problem > >>>> Document cannot be resolved to a type EntitySaxReader.java > >>>> /ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity/util > line 112 > >>>> Java Problem > >>>> Document cannot be resolved to a type EntitySaxReader.java > >>>> /ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity/util > line 339 > >>>> Java Problem > >>>> Document cannot be resolved to a type EntitySaxReader.java > >>>> /ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity/util > line 556 > >>>> Java Problem > >>>> Document cannot be resolved to a type EntitySaxReader.java > >>>> /ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity/util > line 561 > >>>> Java Problem > >>>> Document cannot be resolved to a type EntitySyncServices.java > >>>> > /ofbiz/framework/entityext/src/main/java/org/apache/ofbiz/entityext/synchronization > >>>> line 483 Java Problem > >>>> Document cannot be resolved to a type EntitySyncServices.java > >>>> > /ofbiz/framework/entityext/src/main/java/org/apache/ofbiz/entityext/synchronization > >>>> line 561 Java Problem > >>>> Document cannot be resolved to a type FedexServices.java > >>>> > /ofbiz/applications/product/src/main/java/org/apache/ofbiz/shipment/thirdparty/fedex > >>>> line 381 Java Problem > >>>> Document cannot be resolved to a type FedexServices.java > >>>> > /ofbiz/applications/product/src/main/java/org/apache/ofbiz/shipment/thirdparty/fedex > >>>> line 1020 Java Problem > >>>> Document cannot be resolved to a type FormFactory.java > >>>> /ofbiz/framework/widget/src/main/java/org/apache/ofbiz/widget/model > line 58 > >>>> Java Problem > >>>> Document cannot be resolved to a type FormFactory.java > >>>> /ofbiz/framework/widget/src/main/java/org/apache/ofbiz/widget/model > line 71 > >>>> Java Problem > >>>> Document cannot be resolved to a type FormFactory.java > >>>> /ofbiz/framework/widget/src/main/java/org/apache/ofbiz/widget/model > line > >>>> 101 Java Problem > >>>> Document cannot be resolved to a type FormFactory.java > >>>> /ofbiz/framework/widget/src/main/java/org/apache/ofbiz/widget/model > line > >>>> 114 Java Problem > >>>> Document cannot be resolved to a type FormFactory.java > >>>> /ofbiz/framework/widget/src/main/java/org/apache/ofbiz/widget/model > line > >>>> 142 Java Problem > >>>> Document cannot be resolved to a type GatewayResponse.java > >>>> > /ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/eway > >>>> line 170 Java Problem > >>>> Document cannot be resolved to a type GenericDelegator.java > >>>> /ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity line > 2182 > >>>> Java Problem > >>>> Document cannot be resolved to a type GenericEntity.java > >>>> /ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity line > 1230 > >>>> Java Problem > >>>> Document cannot be resolved to a type GenericEntity.java > >>>> /ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity line > 1231 > >>>> Java Problem > >>>> Document cannot be resolved to a type GenericEntity.java > >>>> /ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity line > 1241 > >>>> Java Problem > >>>> Document cannot be resolved to a type GenericEntity.java > >>>> /ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity line > 1245 > >>>> Java Problem > >>>> Document cannot be resolved to a type GenericEntity.java > >>>> /ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity line > 1268 > >>>> Java Problem > >>>> Document cannot be resolved to a type GenericEntity.java > >>>> /ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity line > 1277 > >>>> Java Problem > >>>> Document cannot be resolved to a type GridFactory.java > >>>> /ofbiz/framework/widget/src/main/java/org/apache/ofbiz/widget/model > line 60 > >>>> Java Problem > >>>> > >>>> Any clue on how to fix these issues? > >>>> > >>>> Thanks. > >>>> > >>>> Carlos Navarro > >>>> > -- Daniel Watford
Moving node/npm to sub-projects. Should we apply to release22.01
Hello, As part of working on OFBIZ-12789 to see if we could further utilise NPM as a repository of various javascript modules rather than keep those modules' sources in the OFBiz source repository, I went down a bit of a rabbit hole changing the OFBiz build to allow node/npm use in multiple OFBiz components (gradle sub-projects). My aim was to allow a plugin to be able to use npm modules without having to modify the ofbiz-framework parent build.gradle file. The current use of npm for common-theme involves configuration applied in the root build.gradle file. The result was a 'convention' plugin, created in ofbiz-framework/buildSrc which describes how the Gradle Node Plugin should be applied to a gradle project. OFBiz components wishing to use node when building can 'apply' the ofbiz-node-conventions plugin to their gradle sub-project which will: - apply and configure the com.github.node-gradle plugin - configure the plugin to use 'npm install' or 'npm ci' depending on if the CI environment variable is defined. - run 'npm install/ci' as part of the 'classes' parent gradle task, ensuring npm modules have been retrieved regardless of whether gradle is being used to build, run or create a distribution of OFBiz. - clean up retrieved node_modules as part of the parent project's 'cleanAll' task. These changes can be viewed in PR ( https://github.com/apache/ofbiz-framework/pull/621). [ Note: Gradle documents relating to 'convention' plugins: - https://docs.gradle.org/current/samples/sample_convention_plugins.html - https://docs.gradle.org/current/userguide/organizing_gradle_projects.html#sec:build_sources ] A corresponding PR has been created for ofbiz-plugins ( https://github.com/apache/ofbiz-plugins/pull/77). This PR introduces a change to the example plugin to demonstrate use of the Gradle Node Plugin in an OFBiz plugin component. In the case of the example plugin, a small Typescript React web application, created using Vite, has been integrated to show an OFBiz screen can be rendered to include CSS and javascript created by an npm build step. If there is an appetite to keep this functionality in the example plugin, perhaps we can extend the react app to call the REST api to retrieve and display live OFBiz data. I think these changes will be very useful for plugins which need to incorporate a web front-end, such as eCommerce, rest-api (swagger), solr and webpos. These plugins all use some externally sourced javascript modules which should hopefully be available from NPM. In my opinion it would be great to get these modules out of the OFBiz sources and retrieve them at build time. QUESTIONS Any concerns about this approach to retrieving javascript code at build time? We already decided to take this approach with common-theme, but applying the pattern more widely will increase the time it takes to perform an initial build. Subsequent builds should be faster since node_modules would have already been downloaded by all components using the build pattern. Should we apply these changes to Release 22.01? I would like to do so as I think it will make it easier for system integrators to deploy more feature rich plugins with OFBiz. However I do appreciate that we need to stop making changes to 22.01 at some point otherwise we'll keep delaying its eventual release. However again, if these changes are useful for system integrators, then it could be years before they can use them in a future 23.xx/24.xx release. Please give the PRs a try and let me know what you think. Thanks, Dan. -- Daniel Watford
Re: [jira] [Commented] (OFBIZ-12796) Handle licence issues reported by RAT in trunk
No problem, Jacques - I'll take care of it On Tue, 11 Apr 2023 at 12:32, Jacques Le Roux wrote: > Hi Daniel, > > After fixing this one, I suggest that you handle the Docker ones. More for > you to familiarize with the licence aspect. > When an ASL2 header does not fit you can put the file in the list at > https://github.com/apache/ofbiz-tools/blob/master/rat-excludes.txt > > TIA > > Jacques > > Le 11/04/2023 à 13:25, ASF subversion and git services (Jira) a écrit : > > [ > https://issues.apache.org/jira/browse/OFBIZ-12796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17710908#comment-17710908 > ] > > > > ASF subversion and git services commented on OFBIZ-12796: > > - > > > > Commit eec8a6e69c62f1650a327056b47f29338f2d8f70 in ofbiz-plugins's > branch refs/heads/trunk from Jacques Le Roux > > [ https://gitbox.apache.org/repos/asf?p=ofbiz-plugins.git;h=eec8a6e69 ] > > > > Improved: Handle licence issues reported by RAT in trunk (OFBIZ-12796) > > > > Fixes a missing ASL2 header in ForumEvents.java > > > > There are a bunch of others related to Docker. I'll ask Daniel to handle > them. > > > > > >> Handle licence issues reported by RAT in trunk > >> -- > >> > >> Key: OFBIZ-12796 > >> URL: https://issues.apache.org/jira/browse/OFBIZ-12796 > >> Project: OFBiz > >> Issue Type: Improvement > >> Components: Docker > >> Affects Versions: Upcoming Branch > >> Reporter: Jacques Le Roux > >> Priority: Major > >> > >> See https://nightlies.apache.org/ofbiz/trunk/rat-output.html > > > > > > -- > > This message was sent by Atlassian Jira > > (v8.20.10#820010) > -- Daniel Watford
Re: Lazy consensus: Build docker container images for the release22.01 branch and demo-next site
Hi Jacques, INFRA have confirmed (https://issues.apache.org/jira/browse/INFRA-24446) that they have not put constraints on how we securely run processes in the VM, but have also provided some advice to help with ( https://issues.apache.org/jira/browse/OFBIZ-12795). I'll double check script file permissions on ofbiz-vm1, but those permissions you mentioned seem reasonable to me. Thanks, Dan. On Sat, 8 Apr 2023 at 10:09, Jacques Le Roux wrote: > Hi Daniel, > > I think that reading > https://github.com/apache/ofbiz-tools/tree/master/demo-backup/ofbizdocker#readme > answered my question. > There ofbizdocker user is taking the same role than ofbizDemo user. > > I though noticed that ofbizdocker has permissions 0755 on > pull-rebuild-restart.sh, not 0775 has mentioned in > > https://github.com/apache/ofbiz-tools/tree/master/demo-backup/ofbizdocker#readme > > ofbizDemo has permissions 0764 on batch files. > > I guess all is OK, right? > > TIA > > Jacques > > Le 07/04/2023 à 19:41, Jacques Le Roux a écrit : > > Hi Daniel, > > > > I have no problems with that. BTW what about my question concerning > "RUN-DEMOS-AS-ofbizDemo-USER-ONLY-NOT-ROOT"? > > > > cf. https://lists.apache.org/thread/92ylovhsh9jl9r37448s487blvzq3vfy > > > > TIA > > > > Jacques > > > > Le 06/04/2023 à 21:25, Daniel Watford a écrit : > >> Hello, > >> > >> We recently configured the demo-trunk site ( > >> https://demo-trunk.ofbiz.apache.org/partymgr) to use docker containers > >> based on images built following commits to the ofbiz-framework trunk > branch > >> (https://issues.apache.org/jira/browse/OFBIZ-12786) > >> > >> This work brought about some improvements in how containers are > deployed, > >> particularly regarding the disabling of specified plugins when a > container > >> is started up. > >> > >> The deployment also highlighted that memory constraints applied to the > >> ofbiz container were too low and that there was a bug in the logic used > to > >> set the password for the tenant database. Both of these issues were > quickly > >> resolved. > >> > >> Through deployment of the demo-trunk site as a container, we also > >> demonstrated how we can alter the configuration of an OFBiz instance at > >> runtime through the use of scripts which 'hook' into various stages of > the > >> initialisation process. See the scripts used for demo-trunk here - > >> > https://github.com/apache/ofbiz-tools/tree/master/demo-backup/ofbizdocker/home/ofbizdocker/demo-trunk/after-config-applied.d > >> > >> > >> LAZY CONSENSUS > >> > >> This email thread is to establish if we have a lazy consensus to > >> automatically build and publish container images for commits to the > >> ofbiz-framework release22.01 branch similar to what is currently > configured > >> for the trunk branch. These container images will have container tags > such > >> as release22.01-snapshot. > >> > >> Further, GitHub actions will also build container images in response to > >> tags, prefixed with 'release', being pushed to the release22.01 branch. > >> These containers will have container tags derived from the git tag. For > >> example, git tag 'release22.01.02' would result in a container tag of > >> '22.01.02'. > >> > >> This email thread is also to establish if we have lazy consensus to then > >> use the release22.01-snapshot container images for deployment of the > >> demo-next site (https://demo-next.ofbiz.apache.org/partymgr) similar to > >> what is currently in place for trunk. The container tags current used > can > >> be seen here - > >> https://github.com/apache/ofbiz-framework/pkgs/container/ofbiz > >> > >> Using a container for deployment removes the need to have any > dependencies > >> in place on the host OS used for the demo-next site. Dependencies are > not > >> an issue at the moment, but may become difficult to manage if and when > we > >> want to vary the JDK used to build and run release22.01. > >> > >> Container images produced by the GitHub Actions workflow will be > published > >> to the GitHub Container Registry (ghcr.io). They should only be > considered > >> as a convenience to users who wish to use containers. Container images > are > >> not an official release of the Apache OFBiz project. I am not proposing > to > >> alter any README files to refer to the container images at this time. > >> > >> Thanks, > >> > >> Dan. > >> > -- Daniel Watford
Lazy consensus: Build docker container images for the release22.01 branch and demo-next site
Hello, We recently configured the demo-trunk site ( https://demo-trunk.ofbiz.apache.org/partymgr) to use docker containers based on images built following commits to the ofbiz-framework trunk branch (https://issues.apache.org/jira/browse/OFBIZ-12786) This work brought about some improvements in how containers are deployed, particularly regarding the disabling of specified plugins when a container is started up. The deployment also highlighted that memory constraints applied to the ofbiz container were too low and that there was a bug in the logic used to set the password for the tenant database. Both of these issues were quickly resolved. Through deployment of the demo-trunk site as a container, we also demonstrated how we can alter the configuration of an OFBiz instance at runtime through the use of scripts which 'hook' into various stages of the initialisation process. See the scripts used for demo-trunk here - https://github.com/apache/ofbiz-tools/tree/master/demo-backup/ofbizdocker/home/ofbizdocker/demo-trunk/after-config-applied.d LAZY CONSENSUS This email thread is to establish if we have a lazy consensus to automatically build and publish container images for commits to the ofbiz-framework release22.01 branch similar to what is currently configured for the trunk branch. These container images will have container tags such as release22.01-snapshot. Further, GitHub actions will also build container images in response to tags, prefixed with 'release', being pushed to the release22.01 branch. These containers will have container tags derived from the git tag. For example, git tag 'release22.01.02' would result in a container tag of '22.01.02'. This email thread is also to establish if we have lazy consensus to then use the release22.01-snapshot container images for deployment of the demo-next site (https://demo-next.ofbiz.apache.org/partymgr) similar to what is currently in place for trunk. The container tags current used can be seen here - https://github.com/apache/ofbiz-framework/pkgs/container/ofbiz Using a container for deployment removes the need to have any dependencies in place on the host OS used for the demo-next site. Dependencies are not an issue at the moment, but may become difficult to manage if and when we want to vary the JDK used to build and run release22.01. Container images produced by the GitHub Actions workflow will be published to the GitHub Container Registry (ghcr.io). They should only be considered as a convenience to users who wish to use containers. Container images are not an official release of the Apache OFBiz project. I am not proposing to alter any README files to refer to the container images at this time. Thanks, Dan. -- Daniel Watford
Re: [VOTE] Apache OFBiz 18.12.07
+1 Checked hashes. Built and run with demo data in OpenJdk 8 container. Thanks, Dan Watford On Mon, 3 Apr 2023 at 08:48, Jacopo Cappellato wrote: > This is the vote thread to publish "Apache OFBiz 18.12.07", seventh > and probably final release from the release18.12 branch. > > The release files can be downloaded from here: > https://dist.apache.org/repos/dist/dev/ofbiz/ > and are: > * apache-ofbiz-18.12.07.zip > * KEYS: text file with keys > * apache-ofbiz-18.12.07.zip.asc: the detached signature file > * apache-ofbiz-18.12.07.zip.sha512: checksum file > > Please download and test the zip file and its signatures (for > instructions on testing the signatures see > http://www.apache.org/info/verification.html). > > Vote: > [ +1] release as Apache OFBiz 18.12.07 > [ -1] do not release > > This vote is open for at least 5 days. > > For more details about this process please refer to > http://www.apache.org/foundation/voting.html > -- Daniel Watford
Re: [ofbiz-framework] branch ofbiz-12723 created (now 5267532fde)
Hi Jacques, Yes - I thought I had already taken care of cleaning up that branch a week or two ago. I must have missed something. Now deleted On Tue, 4 Apr 2023 at 10:59, Jacques Le Roux wrote: > Hi Daniel, > > Seems that the "branch ofbiz-12723" has been already merged in trunk, so > we can delete it, right? > > https://github.com/apache/ofbiz-framework/compare/trunk...ofbiz-12723 > > TIA > > Jacques > > Le 04/04/2023 à 10:39, Jacques Le Roux a écrit : > > I have no ideas what happened there :D > > > > Anyway since OFBIZ-12723 is closed I guess we should merge and then > delete the "branch ofbiz-12723" > > > > Le 04/04/2023 à 10:10, jler...@apache.org a écrit : > >> This is an automated email from the ASF dual-hosted git repository. > >> > >> jleroux pushed a change to branch ofbiz-12723 > >> in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git > >> > >> > >>at 5267532fde Improved: Removed unused oldQOH and oldATP fields > from InventoryItem (OFBIZ-12723) > >> > >> No new revisions were added by this update. > >> > -- Daniel Watford
Re: OpenHub page out of date for OFBiz
Hi Jacques, Yes, please add me as a manager on the OFBiz page on OpenHub. I have signed up using my github username, danwatford. Thanks, Dan. On Wed, 29 Mar 2023 at 12:57, Jacques Le Roux wrote: > Daniel, > > I created the link between OFBiz and OpenHub (then OHLOH) back in the > days of 2009* > > I then said** > << I'm not sure if they really cope with what they pretend (OFBIz has not > been > updated since september).>> > > When migrated to OpenHub it worked well for few years and then it was > again quite a pain to update the information. > It's possible that it's now better again. I did not try after several > attempts. > > Do you want that add you as a "managers"? to allow you to handle things > there? > > Jacques > > * > https://ofbiz.markmail.org/search/?q=OHLOH+#query:OHLOH%20order%3Adate-forward+page:1+state:facets > ** https://markmail.org/message/fj7tpwdbcv6e3isa > > Le 29/03/2023 à 12:38, Daniel Watford a écrit : > > Hello, > > > > Does anyone on the dev mailing list 'own' the OFBiz page at OpenHub? ( > > https://www.openhub.net/p/Apache-OFBiz) > > > > The OFBiz page there is quite out of date since it seems to reference the > > SVN repositories and doesn't account for the last 3 years of activity in > > the Git repositories. > > > > If anyone has access to the page, could they update the source code > > repositories to point at the GitHub versions: > > https://www.openhub.net/p/Apache-OFBiz/enlistments > > > > I think this should get more up to date information displayed and better > > report the activity on the project. > > > > Thanks, > > > > Dan. > > > -- Daniel Watford
Re: Help needed to check demo-trunk solr functionality following switch to docker
minServer |ServiceContainer > |I| Removing from cache dispatcher: default > 2023-03-28 15:41:40,138 |OFBiz-AdminServer |ServiceDispatcher > |I| De-Registering dispatcher: default > 2023-03-28 15:41:40,138 |OFBiz-AdminServer |ServiceContainer > |I| Removing from cache dispatcher: rest-api > 2023-03-28 15:41:40,138 |OFBiz-AdminServer |ServiceDispatcher > |I| De-Registering dispatcher: rest-api > 2023-03-28 15:41:40,138 |OFBiz-AdminServer |ServiceContainer > |I| Removing from cache dispatcher: entity-default > 2023-03-28 15:41:40,138 |OFBiz-AdminServer |ServiceDispatcher > |I| De-Registering dispatcher: entity-default > 2023-03-28 15:41:40,139 |OFBiz-AdminServer |ServiceDispatcher > |I| Shutting down the service engine... > 2023-03-28 15:41:40,139 |OFBiz-JobPoller |JobPoller > |I| JobPoller thread stopped. > 2023-03-28 15:41:40,139 |OFBiz-AdminServer |ContainerLoader > |I| Stopped container service-container > 2023-03-28 15:41:40,139 |OFBiz-AdminServer |ContainerLoader > |I| Stopping container delegator-container > 2023-03-28 15:41:40,139 |OFBiz-AdminServer |ContainerLoader > |I| Stopped container delegator-container > 2023-03-28 15:41:40,139 |OFBiz-AdminServer |ContainerLoader > |I| Stopping container admin-container > 2023-03-28 15:41:40,139 |OFBiz-AdminServer |ContainerLoader > |I| Stopped container admin-container > 2023-03-28 15:41:40,139 |OFBiz-AdminServer |ContainerLoader > |I| Stopping container component-container > 2023-03-28 15:41:40,139 |OFBiz-AdminServer |ContainerLoader > |I| Stopped container component-container > > Sorry, I have no time yet to check further. > > Jacques > > Le 28/03/2023 à 18:09, Daniel Watford a écrit : > > Hello, > > > > Per https://issues.apache.org/jira/browse/OFBIZ-12786, the demo-trunk > site > > is now hosted by a docker container running on VM ofbiz-vm1.apache.org. > > > > The changes to the host are captured in PR, > > https://github.com/apache/ofbiz-tools/pull/5. > > > > The previous approach to demo-trunk deployment patched the solr plugin to > > set the solr URL to https://demo-trunk.ofbiz.apache.org/solr. You can > view > > the patch here - > > > https://github.com/apache/ofbiz-tools/blob/master/demo-backup/patch/trunk/solr.config.patch > > . > > > > I believe I have configured the new demo-trunk container to produce the > > same solr url, but by using configuration rather than source code > changes. > > > > I don't know much about the use of Solr in OFBiz so don't know how to > check > > that the original demo-trunk behaviour has been maintained. > > > > Please could someone familiar with Solr in OFBiz take a look > > https://demo-trunk.ofbiz.apache.org/partymgr/control/main and see if > Solr > > is operating as expected. > > > > Thanks, > > > > Dan. > > > -- Daniel Watford
OpenHub page out of date for OFBiz
Hello, Does anyone on the dev mailing list 'own' the OFBiz page at OpenHub? ( https://www.openhub.net/p/Apache-OFBiz) The OFBiz page there is quite out of date since it seems to reference the SVN repositories and doesn't account for the last 3 years of activity in the Git repositories. If anyone has access to the page, could they update the source code repositories to point at the GitHub versions: https://www.openhub.net/p/Apache-OFBiz/enlistments I think this should get more up to date information displayed and better report the activity on the project. Thanks, Dan. -- Daniel Watford
Re: Help needed to check demo-trunk solr functionality following switch to docker
Hi Jacques, On the page, https://github.com/apache/ofbiz-framework, at the right-hand side, under Releases and above Contributors, you will see the Packages section. This lists the packages associated with the ofbiz-framework github repository. Clicking on the OFBiz package above will take you to https://github.com/apache/ofbiz-framework/pkgs/container/ofbiz. Container systems, such as Docker and Podman, pull container images from registries. Examples of some well known registries are: - registry-1.docker.io (Docker Hub) - ghcr.io (GitHub Container Registry) - mcr.microsoft.com (Microsoft Container Registry) Organisations can also operate their own private container registries. Within a container registry, we find repositories. Some examples: - ghcr.io/apache/ofbiz (OFBiz container repository) - mcr.microsoft.com/azure-cli (Azure command line interface) - hub.docker.com/_/httpd/ (Apache HTTPd) Repositories store multiple versions of container images, some of which are tagged. We can see all container images in the ofbiz repository at these links: - https://github.com/apache/ofbiz-framework/pkgs/container/ofbiz/versions?filters%5Bversion_type%5D=tagged - https://github.com/apache/ofbiz-framework/pkgs/container/ofbiz/versions?filters%5Bversion_type%5D=untagged The tags help users find a particular version of a container image. Tags can be 'moved' to different container image versions as newer versions are published. A common tag, although not used in the images published for OFBiz, is the 'latest' tag. Note: Although the above discusses 'container images', really we are just talking about files arranged in a well known manner and/or accessible behind the well known REST APIs of the registries. Container registries are often implemented using artifact management systems, such as Artifactory and Nexus. We can think of a container registry as analogous to a Maven repository in that artifacts are laid out in a common format. GitHub Packages is a product offering from GitHub to provide storage and publication of various artifacts (packages). The GitHub Container Registry is a component of that product offering. When choosing a place to publish OFBiz container images to, I considered Docker Hub, the Apache Foundation's Artifactory instance and GitHub Packages. There was sufficient friction to getting up and running publishing to Docker Hub. I would have needed assistance from INFRA, and documentation wasn't clear on precisely what information/support I would have needed to request. Plus, the recent policy changes from Docker Inc meant I didn't want to expend too much effort there. GitHub packages seemed a nice low-friction direction to go in as it integrated well with GitHub Actions. It also appeared to be growing in recognition as a location to publish container image. During the GitHub Actions build of the OFBiz container images (see .github/workflows/docker-image.yml), we use the docker/login-action to log in to ghcr.io (GitHub Packages Container Registry). The login makes use of the GITHUB_TOKEN secret which is included by default in the workflow. No additional configuration or permissions were required to access the registry. Later in the workflow, we use the docker/build-push-action to create the docker image and push to ghcr.io. We do not publish the OFBiz container images to DockerHub. However we do build our container images based on the eclipse-temurin:17 image. Since the image 'eclipse-temurin:17' identifier does not include a hostname, the default hostname of registry-1.docker.io (i.e. Docker Hub) is used. We do therefore depend on an image from Docker Hub, although we could explore whether eclipse-temurin is available from any other public container registries and use that instead. Hope that helps, Dan. On Wed, 29 Mar 2023 at 10:01, Jacques Le Roux wrote: > Daniel, > > I have another minor question: how works and special is > https://github.com/apache/ofbiz-framework/pkgs/container/ofbiz ? I can't > see it locally nor > from https://github.com/apache/ofbiz-framework > I guess it's not related to Docker Hub, right ? > > TIA > > Le 29/03/2023 à 09:33, Daniel Watford a écrit : > > Hi Jacques, > > > > Answers to your questions below. > > > > 1 - Yes, we should wait to be sure that nothing has been broken by the > move to a container deployment to trunk. If/when we are happy then we can > > merge ofbiz-tools PR5 into master, bringing in and squashing the commits > currently in the docker-experimental branch. > > > > If we discover an issue with docker-trunk we can revert. I decided to > use a PR to capture the changes to make it a bit easier for folks without > > access to ofbiz-vm1 to review. > > > > I have seen some errors in the logs related to lack of database > connections, probably due to my use of a
Re: Help needed to check demo-trunk solr functionality following switch to docker
Hi Jacques, Answers to your questions below. 1 - Yes, we should wait to be sure that nothing has been broken by the move to a container deployment to trunk. If/when we are happy then we can merge ofbiz-tools PR5 into master, bringing in and squashing the commits currently in the docker-experimental branch. If we discover an issue with docker-trunk we can revert. I decided to use a PR to capture the changes to make it a bit easier for folks without access to ofbiz-vm1 to review. I have seen some errors in the logs related to lack of database connections, probably due to my use of a Postgres database for the demo-trunk deployment. As I write this I realise that by using a postgres rather than the embedded Derby I have already failed in delivering a like-for-like version of demo-trunk. If wanted by the dev community, I can switch demo-trunk to use Derby, but I think it is valuable to have an external database deployment publicly visible. I will look into the errors in the logs soon. 2 - I don't have a problem with using AsciiDoc instead of Markdown, I just haven't dealt with it myself yet. Perhaps someone else could convert that file for us. :) I agree that the content in DOCKER.md is not intended to form part of the official OFBiz documentation, but I imagine in the future we might want to point potential users towards the container images as an unsupported convenience. In that case we would probably need to rework DOCKER.[md|adoc] to give appropriate deployment guidance, perhaps with separate documents to explain the container build process. 3 - Creating the ofbiz-12723 branch in apache/ofbiz-framework rather than danwatford/ofbiz-framework was an oversight on my part. I'll get it cleaned up. Thanks, Dan. On Wed, 29 Mar 2023 at 08:09, Jacques Le Roux wrote: > Hi Daniel, > > First, thanks for all your work! > > I had a quick look and Solr demo is working as expected. We are not up to > date with Solr (now 9.2.0), but that's another issue: OFBIZ-12645. > > Now, I have few questions/notes for you and the community. You mentioned > in a previous email: > Le 22/03/2023 à 17:49, Daniel Watford a écrit : > > If consensus is established, then changes shall be initially made in a way > allowing them to be quickly reversed if needed. Once the demo-trunk site is > observed as running correctly, and with refreshes applied daily, then more > permanent changes can be applied to the demo VM and changes committed > tohttps://github.com/apache/ofbiz-tools/tree/master/demo-backup accordingly. > > >1. I guess we should now wait for at least another day before merging >the docker-experimental branch into ofbiz-tools, right? >2. We switched from using Markdown to AsciiDoc. I just want to say >that you created >https://github.com/apache/ofbiz-framework/blob/trunk/DOCKER.md. I >don't think it's an issue because we don't want to expose that in the site, >it's rather for Docker users, right? >3. (unrelated to docker effort) I guess we should remove the >https://github.com/apache/ofbiz-framework/tree/ofbiz-12723 branch, >right? (there are more docker unrelated branches to clean, I'll send >another email for that) > > Again, thanks! > > Jacques > Le 28/03/2023 à 18:09, Daniel Watford a écrit : > > Hello, > > Per https://issues.apache.org/jira/browse/OFBIZ-12786, the demo-trunk site > is now hosted by a docker container running on VM ofbiz-vm1.apache.org. > > The changes to the host are captured in > PR,https://github.com/apache/ofbiz-tools/pull/5. > > The previous approach to demo-trunk deployment patched the solr plugin to > set the solr URL to https://demo-trunk.ofbiz.apache.org/solr. You can view > the patch here > -https://github.com/apache/ofbiz-tools/blob/master/demo-backup/patch/trunk/solr.config.patch > . > > I believe I have configured the new demo-trunk container to produce the > same solr url, but by using configuration rather than source code changes. > > I don't know much about the use of Solr in OFBiz so don't know how to check > that the original demo-trunk behaviour has been maintained. > > Please could someone familiar with Solr in OFBiz take a > lookhttps://demo-trunk.ofbiz.apache.org/partymgr/control/main and see if Solr > is operating as expected. > > Thanks, > > Dan. > > > -- Daniel Watford
Help needed to check demo-trunk solr functionality following switch to docker
Hello, Per https://issues.apache.org/jira/browse/OFBIZ-12786, the demo-trunk site is now hosted by a docker container running on VM ofbiz-vm1.apache.org. The changes to the host are captured in PR, https://github.com/apache/ofbiz-tools/pull/5. The previous approach to demo-trunk deployment patched the solr plugin to set the solr URL to https://demo-trunk.ofbiz.apache.org/solr. You can view the patch here - https://github.com/apache/ofbiz-tools/blob/master/demo-backup/patch/trunk/solr.config.patch . I believe I have configured the new demo-trunk container to produce the same solr url, but by using configuration rather than source code changes. I don't know much about the use of Solr in OFBiz so don't know how to check that the original demo-trunk behaviour has been maintained. Please could someone familiar with Solr in OFBiz take a look https://demo-trunk.ofbiz.apache.org/partymgr/control/main and see if Solr is operating as expected. Thanks, Dan. -- Daniel Watford
Lazy consensus: Using docker builds for demo-trunk site
Hello, Following on from recent trunk changes to build and publish OFBiz as a container image (https://issues.apache.org/jira/browse/OFBIZ-12781), this email is to establish if we have a lazy consensus to use the built container images to serve the https://demo-trunk.ofbiz.apache.org/partymgr demo site. Using a container to serve the trunk demo site was originally listed as one of the 'proposed next steps' in my email updating the community on the experimental docker work ( https://lists.apache.org/thread/njg7fgwxjxt1vsfs6df8rrwvyp5pwv9p)(https://issues.apache.org/jira/browse/OFBIZ-12757 ) If consensus is established, then changes shall be initially made in a way allowing them to be quickly reversed if needed. Once the demo-trunk site is observed as running correctly, and with refreshes applied daily, then more permanent changes can be applied to the demo VM and changes committed to https://github.com/apache/ofbiz-tools/tree/master/demo-backup accordingly. Overview of changes: - Manually stop the trunk instance of OFBiz on the demo VM ( ofbiz-vm1.apache.org) - Modify script https://github.com/apache/ofbiz-tools/blob/master/demo-backup/all-manual.sh to prevent the instance being started again during the 03:00 refresh. - Create a docker compose application, similar to those under https://github.com/apache/ofbiz-tools/tree/docker-experimental/demo-backup/ofbizdocker/home/ofbizdocker, which uses the trunk-plugins-snapshot container image and loads demo data. This container shall be configured to listen on the same AJP port as the original demo-trunk OFBiz instance. Some items to check: Currently, various patches are applied to the trunk sources prior to rebuild at 03:00 daily. We need to check the intention behind those changes and, if needed, ensure they can be applied to a container instance of OFBiz. This may require changes to the docker entrypoint script. Why do this? There are numerous reasons to explore container usage, but this effort began in response to some difficulties in upgrading the JDK version installed on the demo VM while running different OFBiz versions concurrently. That particular issue has been resolved by use of sdkman, but it will still require someone to alter deployment scripts on the VM when we change JDK version in future. Running OFBiz in a container means the JDK, along with all other dependencies, is packaged in the container. There is no dependency on the JDK installed globally on the host. Thanks, Dan. -- Daniel Watford
Re: Lazy consensus: Merging docker-experimental to trunk
Hello,
This work has now been completed under
https://issues.apache.org/jira/browse/OFBIZ-12781
Built container images can be viewed here -
https://github.com/apache/ofbiz-framework/pkgs/container/ofbiz
I'll raise a ticket with INFRA to ask them to remove the experimental
images published to the container registry since they might confuse
visitors.
Thanks,
Dan.
On Thu, 16 Mar 2023 at 20:31, Jacques Le Roux
wrote:
> Hi Daniel,
>
> As long as Docker Hub is not concerned it's OK with me:
> https://blog.alexellis.io/docker-is-deleting-open-source-images/
>
> https://devclass.com/2023/03/15/docker-to-users-of-free-team-orgs-one-month-to-pay-up-or-we-freeze-account-and-images-go/
>
> This looks like things that happened in the past with other "free"
> "organisations" (if it's free your are the product, don't do evil, etc.)
>
> Jacques
>
> Le 15/03/2023 à 12:31, Daniel Watford a écrit :
> > Hi Michael,
> >
> > Users will not experience any changes except for the presence of some new
> > files in the ofbiz-framework repository.
> >
> > These new files will not affect the regular build process.
> >
> > The README is not being changed to mention docker in any way, so the
> > standard entry point for new users will still refer users to the regular
> > build process.
> >
> > A new DOCKER.md file, present in the root of the ofbiz-framework
> repository
> > will describe building and deployment of OFBiz using Docker for
> interested
> > users. Further, a docker directory will be added, containing resources to
> > support the build of container images along with examples of how to
> deploy
> > them.
> >
> > In summary, no change to the build and deployment approach currently
> > experienced by users.
> >
> > Thanks,
> >
> > Dan.
> >
> > On Tue, 14 Mar 2023 at 20:52, michael.br...@ecomify.de <
> > michael.br...@ecomify.de> wrote:
> >
> >> Hi Dan,
> >>
> >> I am on vacation so I am not able to work through the extensive
> >> informations you provided.
> >>
> >> What impact has the merge for the functionality, build system or other
> >> parts of OFBiz?
> >>
> >> Or, asked differently: what is changing for users who don‘t use docker
> to
> >> run OFBiz?
> >>
> >> Thanks for all your work,
> >>
> >> Michael
> >>
> >>
> >>
> >>
> >>> Am 14.03.2023 um 14:47 schrieb Daniel Watford :
> >>>
> >>> Hello,
> >>>
> >>> In my recent email regarding Docker and OFBiz [1] I included some
> >> proposed
> >>> next steps.
> >>>
> >>> This email is to establish a lazy consensus [2] around the first
> >> proposed
> >>> step, merging the experimental-docker branch into trunk and adapting
> >> those
> >>> changes to build and push 'snapshot' images to ghcr.io/apache/ofbiz in
> >>> response to trunk commits.
> >>>
> >>> The proposal listed the 3 image variants that would be produced from
> >> trunk,
> >>> and how each variant would be assigned 2 tags, snapshot and {{sha}}.
> >>>
> >>> I now propose dropping the {{sha}} image tag to reduce noise in the
> list
> >> of
> >>> container images. The {{sha}} tags can be re-implemented later if a
> need
> >>> arises.
> >>>
> >>> No work on this proposal will begin for at least 72 hours from the time
> >> of
> >>> sending this email.
> >>>
> >>> Other steps proposed in my previous email [1] are excluded from this
> lazy
> >>> consensus and shall be addressed in their own email threads.
> >>>
> >>> Thanks,
> >>>
> >>> Dan.
> >>>
> >>> [1] https://lists.apache.org/thread/njg7fgwxjxt1vsfs6df8rrwvyp5pwv9p
> >>> [2] https://community.apache.org/committers/lazyConsensus.html
> >>>
> >>> --
> >>> Daniel Watford
> >
>
--
Daniel Watford
Re: Lazy consensus: Merging docker-experimental to trunk
Hi Michael,
Users will not experience any changes except for the presence of some new
files in the ofbiz-framework repository.
These new files will not affect the regular build process.
The README is not being changed to mention docker in any way, so the
standard entry point for new users will still refer users to the regular
build process.
A new DOCKER.md file, present in the root of the ofbiz-framework repository
will describe building and deployment of OFBiz using Docker for interested
users. Further, a docker directory will be added, containing resources to
support the build of container images along with examples of how to deploy
them.
In summary, no change to the build and deployment approach currently
experienced by users.
Thanks,
Dan.
On Tue, 14 Mar 2023 at 20:52, michael.br...@ecomify.de <
michael.br...@ecomify.de> wrote:
> Hi Dan,
>
> I am on vacation so I am not able to work through the extensive
> informations you provided.
>
> What impact has the merge for the functionality, build system or other
> parts of OFBiz?
>
> Or, asked differently: what is changing for users who don‘t use docker to
> run OFBiz?
>
> Thanks for all your work,
>
> Michael
>
>
>
>
> > Am 14.03.2023 um 14:47 schrieb Daniel Watford :
> >
> > Hello,
> >
> > In my recent email regarding Docker and OFBiz [1] I included some
> proposed
> > next steps.
> >
> > This email is to establish a lazy consensus [2] around the first
> proposed
> > step, merging the experimental-docker branch into trunk and adapting
> those
> > changes to build and push 'snapshot' images to ghcr.io/apache/ofbiz in
> > response to trunk commits.
> >
> > The proposal listed the 3 image variants that would be produced from
> trunk,
> > and how each variant would be assigned 2 tags, snapshot and {{sha}}.
> >
> > I now propose dropping the {{sha}} image tag to reduce noise in the list
> of
> > container images. The {{sha}} tags can be re-implemented later if a need
> > arises.
> >
> > No work on this proposal will begin for at least 72 hours from the time
> of
> > sending this email.
> >
> > Other steps proposed in my previous email [1] are excluded from this lazy
> > consensus and shall be addressed in their own email threads.
> >
> > Thanks,
> >
> > Dan.
> >
> > [1] https://lists.apache.org/thread/njg7fgwxjxt1vsfs6df8rrwvyp5pwv9p
> > [2] https://community.apache.org/committers/lazyConsensus.html
> >
> > --
> > Daniel Watford
>
--
Daniel Watford
Lazy consensus: Merging docker-experimental to trunk
Hello,
In my recent email regarding Docker and OFBiz [1] I included some proposed
next steps.
This email is to establish a lazy consensus [2] around the first proposed
step, merging the experimental-docker branch into trunk and adapting those
changes to build and push 'snapshot' images to ghcr.io/apache/ofbiz in
response to trunk commits.
The proposal listed the 3 image variants that would be produced from trunk,
and how each variant would be assigned 2 tags, snapshot and {{sha}}.
I now propose dropping the {{sha}} image tag to reduce noise in the list of
container images. The {{sha}} tags can be re-implemented later if a need
arises.
No work on this proposal will begin for at least 72 hours from the time of
sending this email.
Other steps proposed in my previous email [1] are excluded from this lazy
consensus and shall be addressed in their own email threads.
Thanks,
Dan.
[1] https://lists.apache.org/thread/njg7fgwxjxt1vsfs6df8rrwvyp5pwv9p
[2] https://community.apache.org/committers/lazyConsensus.html
--
Daniel Watford
Re: Update on experimenting with docker deployments of OFBiz
Hi Jacques, The issue about the apparent process ownership by brianb is due to UID (user id) 1000 getting resolved to a name. Since brianb doesn't exist in /etc/passwd it looks like a component of the OS or a system library is resolving the name using LDAP. It hasn't been confirmed, but #asfinfra mentioned that Brian was the original foundation sysadmin so likely had UID 1000. No change is needed, but to prevent confusion we can map uid 1000 from within the OFBiz containers to an appropriate user present on the VM. If we go ahead I will request creation of a new user with minimal permissions to be mapped to. Thanks, Dan. On Thu, 9 Mar 2023 at 14:22, Jacques Le Roux wrote: > Le 09/03/2023 à 12:34, Daniel Watford a écrit : > > Difficulties experienced along the way: > > > > The biggest problem we hit was a capacity issue on the OFBiz project's > VM, > > ofbiz-vm1.apache.org. > > > > A good rule of thumb seemed to be that an OFBiz demo instance consumed > > around 2GB of RAM. Judicious use of memory and cpu limits on the > containers > > to be deployed on ofbiz-vm1 mean we could squeeze a container instance of > > OFBiz alongside the existing 3 demo sites and still fit into the total > 8GB > > of RAM available on the host. > > > > Everything seemed to be going well… until! An OFBiz demo instance would > > consume around 2GB of RAM, but to build that instance would take much > more > > - perhaps another 2GB. OFBiz demo instances are rebuilt daily at 03:00 > UTC > > and suddenly these rebuild processes - which would normally complete in a > > few minutes - were taking hours to run. The system was under such heavy > > load, presumably from all the garbage collecting and swapping, that it > was > > unresponsive to web requests and SSH connections. > > > > On Friday 10th February INFRA-24185 was raised, requesting an additional > > 4GB of RAM for ofbiz-vm1. INFRA approved the request and plans were made > to > > shut down the VM to perform the upgrade the following Monday. However the > > 03:00 UTC scheduled rebuild didn't agree with the plan! > > > > The next day (Saturday 11th February), due to the 03:00 rebuild, the VM > was > > unresponsive again ( > > https://lists.apache.org/thread/dh0dp8f3n8jyy8n3jbho7vsghy42f41f). INFRA > > shut down the VM for us in response and performed the upgrade ahead of > > schedule. They upgraded us from a 2vCPU 8GB VM to 8vCPU 32GB VM. A > 4-times > > increase in compute and memory - an unexpected and very much appreciated > > upgrade! > > Thanks Daniel, > > I just want to add that we crossed another quite weird issue reported at > https://issues.apache.org/jira/browse/INFRA-24303 > "brianb user (Brian Behlendorf) is weirdly running the trunk demo on > ofbiz-vm1.apache.org VM." > It's a random issue. We have no solution for now. > > Jacques > > -- Daniel Watford
Update on experimenting with docker deployments of OFBiz
ques, Eugen and
Michael dealt with the various issues with ofbiz-vm1.apache.org.
Proposed next steps:
I would like to merge the experimental-docker branch into trunk and modify
the GitHub Actions workflow to build
snapshot docker container images in response to pushes on the branch.
Container images would be published to ghcr.io/apache/ofbiz
Variants of the container images built in response to git commits are:
- the ofbiz-framework without any data loaded. Tags: trunk-branch-snapshot
/ trunk-branch-{{sha}}
- the ofbiz-framework, preloaded with demo data using the embedded Derby
database. Tags: trunk-branch-preloaddemo-snapshot /
trunk-branch-preloaddemo-{{sha}}
- the ofbiz-framework plus plugins, without any data loaded. Tags:
trunk-branch-plugins-snapshot / trunk-branch-plugins-{{sha}}
The above container image tag names are subject to change based on feedback
received.
I would then like to replace the current approach to deploying demo-trunk
with a docker container, using the image variant
ofbiz-framework-plugins-snapshot. Using docker for this demo will work
around the issue of 'ofbiz --shutdown' not consistently working for
demo-trunk (OFBIZ-10287).
With the above in place I would propose waiting a week or two to address
any issues that might occur and to hopefully confirm that trunk snapshot
container images are consistently built and pushed in response to trunk
commits. If the container images and demo-trunk site work successfully then
I propose we apply similar changes to the release22.01 branch so that we
can offer users a quick-start based on docker deployments. We must
highlight, though, that container images are provided only as a
convenience, and that the official project release is the sources.
(GitHub Packages do provide counts of downloads so we might see some
interesting numbers:
https://github.com/apache/ofbiz-framework/pkgs/container/ofbiz)
If building container images for commits on the release22.01 branch,
proposed variants would follow the same pattern as for trunk commits, using
tags:
- release22.01-branch-snapshot / release22.01-branch-{{sha}}
- release22.01-branch-preloaddemo-snapshot /
release22.01-branch-preloaddemo-{{sha}}
- release22.01-branch-plugins-snapshot / release22.01-branch-plugins-{{sha}}
Further, we would also build container images in response to git tags being
pushed to the release22.01 branch. The container image tags for these would
be based on the git tag. For example, if pushing tag 'release22.01.03', the
container image tags would be:
- 22.01.03
- 22.01.03-preloaddemo
22.01.03-plugins
Please could the community respond to the proposed next steps as a possible
way forward to using docker deployments on our demo site AND as a
convenience for users to try out OFBiz.
Thanks,
Dan.
--
Daniel Watford
Re: Confused with screen different elements
Hello, I'm not sure it is the answer you are looking for, but really the ultimate description of how OFBiz components work is the OFBiz source code itself. There are various documents you can refer to in Confluence ( https://cwiki.apache.org/confluence/display/OFBIZ/Technical+Documentation), but I imagine you have already looked there and found gaps that you are looking to plug. In that case the source code - along with focussed questions to this mailing list - are your next step. Once you have found an answer, a pull request to improve the XSD file, or updates to pages in Confluence are appreciated and will help others who find themselves in the same position as you. Dan. On Fri, 3 Mar 2023 at 01:52, honestch...@163.com wrote: > Hi, guys > These days I am learning to use OFBiz . > I want know where can I get detail description about each element in the > > The widget-screen.xsd file does not give detailed annotation. > For example,, > > > thanks > > > > > honestch...@163.com > -- Daniel Watford
All Committers, can you give 20 minutes to help with the OFBiz Codenarc code review?
Hello Committers, We need your help! We have a very large, but hopefully simple, PR that we need to review - https://github.com/apache/ofbiz-framework/pull/517 This PR alters OFBIz groovy code to satisfy the guidance from the Codenarc static analysis tool.It is not intended to change OFBiz behaviour in any way. All committers, please could you help review this PR by following the process outlined here: https://cwiki.apache.org/confluence/display/OFBIZ/Codenarc+integration+review+tracker If every committer could give 20 minutes to this effort we should be able to make significant progress. Of course we would be happy for any time you can offer. If while working on this review you find any bugs in existing behaviour, please raise those bugs as a separate ticket. The aim of this review is to provide assurance that PR 517 does NOT change OFBiz behaviour in any way, even if that means keeping existing bugs in place! Progress on this review is being tracked through the above linked Confluence document. To avoid clashes between review participants, I suggest you choose a file to review at random from the table in the document, review the file and then update the confluence document with your results. Please do not open long running confluence edit sessions as this could cause difficulties for other committers who want to update the document. If you find an issue in the PR, please open a PR review on GitHub, add your comments, and then close the PR review. This will allow others to see your comments. Please also update the confluence document to show there is an issue to be addressed. Many thanks, Dan. -- Daniel Watford
Re: Demo sites not response - suspect low RAM following docker container deployment
Hi Michael, On Sat, 11 Feb 2023 at 09:43, Michael Brohl wrote: > Hi Dan, all, > > maybe we can find a way to experiment on this outside the productive > VM's for our demos? > > The alternative to working on ofbiz-vm1.apache.org would have been to work on our own hosts, or get a second host from Apache. I favoured an Apache host as it meant others could collaborate more easily, but I believe justifying a second host would have taken time and may not have been approved. I think our current approach was reasonably balanced given the risk to the demo sites vs benefit of experimenting with new approaches, (perceived) impact on users and how rapidly we addressed issues as they were discovered. We hit this RAM issue twice. The first time it occured we recovered quickly and implemented some mitigations to constrain resource usage by the containers. What we didn't think of was that RAM usage would increase again during the nightly build, making the VM unresponsive again. However in response to the first occurrence we already had a request out to INFRA for a RAM uplift which was already approved and was just waiting for a suitable time for application. (Note: I am still assuming the issue was lack of memory. We don't have any metrics yet to confirm this) I don't have any figures on how much traffic our demo sites get, but I have a feeling it is low. Given how quickly we addressed the problems I don't think there was much impact to users. It would be good to have some metrics on demo site usage though. It could be something we include in the PMC report/blog post as an indicator on user engagement with the project. Dan
Re: Demo sites not response - suspect low RAM following docker container deployment
32 GB - Nice! :) And we have 8 vcpus too - rather than the 2 we started with . A 4 times the previous CPU and memory capacity On Sat, 11 Feb 2023 at 10:14, Jacques Le Roux wrote: > Hi Michael, > > I guess it should be OK now. We got 32GB! > > The demos are back and should be faster > > Jacques > > Le 11/02/2023 à 10:42, Michael Brohl a écrit : > > Hi Dan, all, > > > > maybe we can find a way to experiment on this outside the productive > VM's for our demos? > > > > Best regards, > > > > Michael > > > > > > Am 11.02.23 um 09:34 schrieb Daniel Watford: > >> Hello, > >> > >> After checking Saturday morning, it looks like the demo sites are not > >> responding to browser requests and I cannot SSH to ofbiz-vm1.apache.org > , > >> the demo sites host. > >> > >> This follows some experiments on Friday to deploy a docker container > >> version of OFBiz. (Progress is reported here -[OFBIZ-12757] Experiment > with > >> deploying OFBiz containers to the demo sites server - ASF JIRA ( > apache.org) > >> <https://issues.apache.org/jira/browse/OFBIZ-12757>) > >> > >> On Friday we had a similar lock-up on the host which was thought to be > due > >> to running out of memory on the VM. > >> > >> I suspect that, with the nightly rebuild of trunk, stable and next, > these > >> processes may cause a higher memory load on the server compared to > normal > >> running, and this may have caused us to exhaust available RAM on the > server > >> again. > >> > >> If this suspicion is correct, then there is not enough RAM on the host > to > >> support docker experimentation in addition to normal operation of the > sites. > >> > >> A request has been made to INFRA for a RAM increase which has been > accepted > >> ([INFRA-24185] Request to increase RAM on ofbiz-vm1.apache.org - ASF > JIRA > >> <https://issues.apache.org/jira/browse/INFRA-24185>). Depending on > INFRA > >> availability, hopefully this will be completed early next week. > >> > >> What can we do now? > >> When we had the previous lock-up on Friday, the demo host did eventually > >> recover and start accepting browser requests and SSH connections. I > imagine > >> the OFBiz build process is still ongoing - and would have been running > for > >> 5.5 hours at time of writing this message. > >> > >> If the host recovers and I am available, I will SSH to the host and > disable > >> the docker containers, hopefully avoiding this issue over the next few > days > >> until the RAM uplift is applied. > >> > >> Alternatively, if we ask INFRA to reboot the VM, perhaps they can apply > the > >> RAM lift at the same time. > >> > >> Dan. > >> > -- Daniel Watford
Demo sites not response - suspect low RAM following docker container deployment
Hello, After checking Saturday morning, it looks like the demo sites are not responding to browser requests and I cannot SSH to ofbiz-vm1.apache.org, the demo sites host. This follows some experiments on Friday to deploy a docker container version of OFBiz. (Progress is reported here -[OFBIZ-12757] Experiment with deploying OFBiz containers to the demo sites server - ASF JIRA (apache.org) <https://issues.apache.org/jira/browse/OFBIZ-12757>) On Friday we had a similar lock-up on the host which was thought to be due to running out of memory on the VM. I suspect that, with the nightly rebuild of trunk, stable and next, these processes may cause a higher memory load on the server compared to normal running, and this may have caused us to exhaust available RAM on the server again. If this suspicion is correct, then there is not enough RAM on the host to support docker experimentation in addition to normal operation of the sites. A request has been made to INFRA for a RAM increase which has been accepted ([INFRA-24185] Request to increase RAM on ofbiz-vm1.apache.org - ASF JIRA <https://issues.apache.org/jira/browse/INFRA-24185>). Depending on INFRA availability, hopefully this will be completed early next week. What can we do now? When we had the previous lock-up on Friday, the demo host did eventually recover and start accepting browser requests and SSH connections. I imagine the OFBiz build process is still ongoing - and would have been running for 5.5 hours at time of writing this message. If the host recovers and I am available, I will SSH to the host and disable the docker containers, hopefully avoiding this issue over the next few days until the RAM uplift is applied. Alternatively, if we ask INFRA to reboot the VM, perhaps they can apply the RAM lift at the same time. Dan. -- Daniel Watford
Re: [PROPOSAL] Migration of the Apache OFBiz website to Hugo
Hi Michael, This sounds very interesting. I have gone back and forth over the years between CMS driven (WordPress) and statically generated sites (Jekyll) depending on the users that would be responsible for authoring content. Mixing the two with tools like Next.js was also interesting. WordPress suited non-technical better, whereas technical users benefited from being able to generate the exact site they wanted. Plus the static sites have the benefit of fast load times without having to implement caches (although caching at CDNs is still useful) Since we are a techy bunch I would support building the website using a static generation tool. I've heard good things about Hugo, and since there is existing experience on this tool within our community it would seem a reasonable direction to take. I'm also interested to see if adding more data-driven pages to the site would be easier with Hugo. I quite like the idea of a few utility pages to help generate seed data for users, such as: - Custom time period generator - Chart of accounts generator My only concern with changing the site is the amount of work involved since we have limited resources, but since we are being forced to take action in order to get the blog operational, perhaps widening the scope to the site is reasonable. I expect we can keep the existing HTML pages, and replace them with Hugo generated pages as and when needed. +1 from me. Dan. On Tue, 7 Feb 2023 at 18:07, Michael Brohl wrote: > Dear community, > > In the course of getting Wiebke to be able to help with our blog, it > turned out that Apache Roller will be discontinued as the platform for > blogs by infra [1]. > > There is an offer and already a pull request [2] to export the existing > blog posts for a migration to Hugo [3]. > Hugo is a static site generator which will generate individual pages > from every markdown blog posts file which is provided in the PR. > > That means we need to (at least) > > - setup a Hugo project > - build up templates for the blog posts which also include header and > footer for full page rendering >(hence, we have to take over some of the templates/html > code/javascrip/CSS to Hugo as well) > - generate the post pages and include them in the website under /blog. > > These are quite some steps we have to take anyway and I ask myself if we > should not switch over to Hugo for the whole website as well. > That should be not too difficult because we already have some kind of > templates (in php) and there is already some sectioning with header, > content, footer etc. > > The advantages would be > > - to truly separate content from the templates (it is now mixed > php/content) > - blog posts can be generated from OFBiz commits and, together with page > content, be send in by pull requests > - content automation (no need to change the copyright year manually, > automated taxonimies for the blog etc.) > - easy process for a git supported writing process for pages and blog > posts and a fast and automatable publishing process (git hooks or GitHub > integration). > > Coincidence: I am on a journey to migrate the ecomify websites to Hugo > we have at least some knowledge there (maybe others as well?). > > To sum up, I propose to migrate our blog and also the Apache OFBiz > website to be an integrated, Hugo based website. > > Opinions? > > Best regards, > > Michael Brohl > > ecomify GmbH - www.ecomify.de > > [1] https://issues.apache.org/jira/browse/INFRA-22461 > [2] https://github.com/apache/ofbiz-site/pull/8/files > [3] https://gohugo.io/ > > -- Daniel Watford
Should balance sheet fixes be added to 22.01 release branch?
Hello, While reading through BalanceSheet.groovy - the script used to prepare data used during the rendering of the Accounting Balance Sheet report - I found that some refactoring would make the script easier to read and therefore created OFBIZ-12753. While testing the refactored implementation I found OFBIZ-12754, a previously existing bug, that in some circumstances caused contra account values to be added to the asset total rather than subtracted. Since this was causing incorrect results in reporting I thought it would be considered important enough to fix in release 22.01 and created a patch (PR586) for review. This patch is not built on top of the refactoring of OFBIZ-12753 since I wasn't sure a bug fix would justify bringing in refactored code while we are in a feature freeze for 22.01. However, another pre-existing bug in the balance sheet has since been found - OFBIZ-12755 - which also causes misreporting of account values in some circumstances. I have created a fix for trunk (PR 588), built on top of the refactoring from OFBIZ-12753, but have not yet created a separate patch for release 22.01 since it will be a completely different implementation. My questions:- - Should we fix balance sheet bugs in release 22.01 as it seems these bugs may have existed for quite some time and were previously unnoticed? I haven't tested older releases yet, but the code has not changed for a long time. There is also the possibility that I have just interpreted something incorrectly and that the bugs I have reported are invalid. - If we decide to fix the bugs in release 22.01, is it acceptable to bring in the refactored code to do so? In my opinion the refactoring has made it easier to reason about the correctness of the resultant balance sheet so I think bringing the refactoring into 22.01 will result in quicker bug fixes. Side question: If the bug reports are valid, why haven't we heard about them already from the users? I didn't find anything similar in Jira. Could it be the case that the Accounting Balance Sheet Report is not really used? If so, how are users preparing their financial statements? Perhaps users export accounting entries to another accounting tool? Thanks, Dan. -- Daniel Watford
Re: Codenarc integration process
No, we should be able to create multiple reviews within a single PR - or perhaps add a comment to an existing review. On Tue, 7 Feb 2023 at 17:44, Jacques Le Roux wrote: > Le 07/02/2023 à 16:53, gil.portenseigne a écrit : > > yes ongoing review are private, you need to finish it to let other see > > your comments and suggestions. > > Does it mean that you need to review ALL before others see what you > commented 😮 ? > > Thanks > > Jacques > > -- Daniel Watford
Re: Codenarc integration process
Hi Gil, There is a comment 'Can requestIdMap be removed?' against the StatsSinceStart.groovy file in the PR. This comment is part of a review. JobDetails.groovy was marked as UNSURE as it concerned a possible feature of Groovy that I wasn't aware of and couldn't find appropriate documentation for. The comment against JobDetails.groovy would hopefully get another reviewer to take a look and provide a bit more info. This gives me a chance to learn something! :) The comments in the PR are part of my ongoing review. Since the review has not been submitted yet, perhaps it's not visible to you? If that's the case then we'll need to submit multiple reviews as we go. Please could you let me know if my review within PR 517 is visible to you. Thanks, Dan. On Mon, 6 Feb 2023 at 12:35, gil.portenseigne wrote: > Indeed, i agree it is better in PR (sorry again for missing it), but i > did not find comments about the StatsSinceStart.groovy and other files > you noted as unpassed. > > Did I miss something ? > > Gil > On 06/02/23 09:10, Daniel Watford wrote: > > Hi Gil, > > > > The Review Approach section of the tracking document says that comments > > should be added to the PR when marking a file as WORK_NEEDED. In my case > I > > added review comments to the PR. > > > > However I didn't specify how a reviewer should communicate why they were > > UNSURE about any particular file. I had added a comment to the PR, but > > depending on what the issue is, adding a note to the table might be > > appropriate. > > > > I think comments in PRs are a reasonable approach since they will keep > the > > comment alongside the code that needs to be worked on or discussed. I > would > > rather not duplicate comments from the PR in the tracking document. > > > > Thanks, > > > > Dan. > > > > On Mon, 6 Feb 2023 at 08:18, gil.portenseigne < > gil.portensei...@nereide.fr> > > wrote: > > > > > Hello Daniel, > > > > > > Thanks again for the review you did, could we add a small description > > > when UNSURE or WORK_NEEDED is set in the review table ? > > > > > > Or will it be best to use github comments in pull request ? > > > > > > I'm curious about the reason, and would like to help solve them. > > > > > > I will try to advance this week in the review process. > > > > > > Regards, > > > > > > Gil > > > > > > On 28/01/23 08:46, Daniel Watford wrote: > > > > Turns out I was able to import the list of files into Excel and copy > and > > > > paste the table from Excel to Confluence. > > > > > > > > On Sat, 28 Jan 2023 at 08:37, Daniel Watford > wrote: > > > > > > > > > Hi Gil, > > > > > > > > > > I don't think a checklist is quite enough, assuming we want to > track > > > the > > > > > status of each file reviewed. > > > > > > > > > > From the review approach section: > > > > > > > > > > > > > > >- If in the reviewers opinion a file change will not change > OFBiz > > > > >behaviour in any way they should mark the corresponding entry in > > > the table > > > > >below as PASSED. > > > > >- If the reviewer identifies an issue with a changed file, then > they > > > > >should add a comment in the PR on GitHub AND mark the > corresponding > > > entry > > > > >in the table below as WORK NEEDED. > > > > >- If the reviewer is unsure how to classify a changed file they > > > should > > > > >mark the corresponding entry in the table below as UNSURE. > > > > >- In each of the above cases, the reviewer should add their name > > > > >against the entry in the table below. > > > > > > > > > > The checklist doesn't give us the opportunity to see what files > need > > > some > > > > > additional help. > > > > > > > > > > I'm sure there must be some way of getting Confluence to produce a > > > table > > > > > from a list - I just don't seem to have found it yet! I'll play > around > > > with > > > > > Confluence a bit more. > > > > > > > > > > But as mentioned before, perhaps I am making too much out of > tracking > > > this > > > >
Re: Codenarc integration process
Hi Gil, The Review Approach section of the tracking document says that comments should be added to the PR when marking a file as WORK_NEEDED. In my case I added review comments to the PR. However I didn't specify how a reviewer should communicate why they were UNSURE about any particular file. I had added a comment to the PR, but depending on what the issue is, adding a note to the table might be appropriate. I think comments in PRs are a reasonable approach since they will keep the comment alongside the code that needs to be worked on or discussed. I would rather not duplicate comments from the PR in the tracking document. Thanks, Dan. On Mon, 6 Feb 2023 at 08:18, gil.portenseigne wrote: > Hello Daniel, > > Thanks again for the review you did, could we add a small description > when UNSURE or WORK_NEEDED is set in the review table ? > > Or will it be best to use github comments in pull request ? > > I'm curious about the reason, and would like to help solve them. > > I will try to advance this week in the review process. > > Regards, > > Gil > > On 28/01/23 08:46, Daniel Watford wrote: > > Turns out I was able to import the list of files into Excel and copy and > > paste the table from Excel to Confluence. > > > > On Sat, 28 Jan 2023 at 08:37, Daniel Watford wrote: > > > > > Hi Gil, > > > > > > I don't think a checklist is quite enough, assuming we want to track > the > > > status of each file reviewed. > > > > > > From the review approach section: > > > > > > > > >- If in the reviewers opinion a file change will not change OFBiz > > >behaviour in any way they should mark the corresponding entry in > the table > > >below as PASSED. > > >- If the reviewer identifies an issue with a changed file, then they > > >should add a comment in the PR on GitHub AND mark the corresponding > entry > > >in the table below as WORK NEEDED. > > >- If the reviewer is unsure how to classify a changed file they > should > > >mark the corresponding entry in the table below as UNSURE. > > >- In each of the above cases, the reviewer should add their name > > >against the entry in the table below. > > > > > > The checklist doesn't give us the opportunity to see what files need > some > > > additional help. > > > > > > I'm sure there must be some way of getting Confluence to produce a > table > > > from a list - I just don't seem to have found it yet! I'll play around > with > > > Confluence a bit more. > > > > > > But as mentioned before, perhaps I am making too much out of tracking > this > > > review. > > > > > > Thanks, > > > > > > Dan. > > > > > > > > > On Fri, 27 Jan 2023 at 17:05, gil.portenseigne < > > > gil.portensei...@nereide.fr> wrote: > > > > > >> I got to leave, but i generated in confluence a list of check, is that > > >> good enough ? > > >> > > >> Gil > > >> On 27/01/23 05:41, gil.portenseigne wrote: > > >> > Hello, indeed, that will generate much spam, i did some before > reading > > >> > your answer. > > >> > > > >> > I'll have a look for conluence. > > >> > > > >> > Gil > > >> > > > >> > > > >> > On 27/01/23 04:14, Daniel Watford wrote: > > >> > > Hi Gill and Jacques, > > >> > > > > >> > > I don't think we should add comments to the PR to track the files > > >> that we > > >> > > have reviewed as I think each comment will appear separately in > the > > >> PR's > > >> > > conversation view. > > >> > > > > >> > > However, with such a large PR where we hope to get several > reviewers > > >> > > involved I think we do need a mechanism to track reviewed files. > > >> > > > > >> > > I created a page here - Codenarc integration review tracker - > OFBiz > > >> Project > > >> > > Open Wiki - Apache Software Foundation > > >> > > < > > >> > https://cwiki.apache.org/confluence/display/OFBIZ/Codenarc+integration+review+tracker > > >> > > > >> > > - > > >> > > suggesting an approach. > > >> > > > > >> > > If the approach is acceptable th
Are thruDates inclusive or exclusive?
Hello, Although it may seem a minor topic, I would like to see if we can make a statement about date ranges defined using fromDate and thruDate in OFBiz entities. In The Data Resource Model Revised Edition volume 1 - Table 1.2 Conventions Used In Attribute Naming, thru date is described as specifying the end date of a date range and is inclusive of that date. The book draws a distinction between thruDate and toDate, stating that thruDate is clearer for specifying the inclusive end of a date range. However I'm not sure if OFBiz is always using thruDate as an inclusive value. Personally I'm not keen on using inclusive ranges for continuous measurements - such as date times - since it bakes in an assumption on the maximum precision of our unit of measure, as illustrated by this (very contrived) example: *** BEGIN Dan's contrived example A self-service checkout allows customers to buy flour with the customer pouring the flour onto the integrated weighing scales themselves. The pricing table for flour used by the self-checkout uses inclusive ranges: 0 to 5kg priced at $1.30 per kg. 6kg to 10kg priced at $1.25 per kg. 11kg or more priced at $1.20 per kg. Confusion occurs when figuring out what price we should use for 5.5kg of the product. So we adjust the pricing table to: 0 to 5.999kg priced at $1.30 per kg. 6kg to 10.999kg priced at $1.25 per kg. 11kg or more priced at $1.20 per kg. ... and can then answer that 5.5kg should be sold at $1.25 per kg. But then the weighing scales are upgraded to provide readings with more significant digits and a customer (against the odds) pours 5.9995kg of flour. We either need to get some rounding rules agreed or further enhance the pricing table to allow for these new significant digits in our measurements. Alternatively we could use exclusive 'to' values in our pricing table For weight W of flour: 0kg <= W < 6kg: $1.30 per kg. 6kg <= W < 11kg: $1.25 per kg. 11kg <= W: $1.20 per kg. *** END Dan's contrived example So why am I asking about this? In service computeGlAccountBalanceForTimePeriod we select all transactions that occurred BEFORE the time period we are interested in using the condition: transactionDate < customTimePeriod.fromDate The service then selects all transactions that occurred DURING the time period we are interested in by using the condition: transactionDate < customTimePeriod.thruDate The above condition suggests that computeGlAccountBalanceForTimePeriod has been implemented with an assumption that the date range for a CustomTimePeriod is EXCLUSIVE. If the date range for a custom time period is INCLUSIVE, the condition be: transactionDate <= customTimePeriod.thruDate ? If we look at the Fiscal Year time period in the Demo Data ( https://demo-next.ofbiz.apache.org/accounting/control/TimePeriods?organizationPartyId=Company) we see date: fromDate: 2010-01-01 08:00:00.000 thruDate: 2011-01-02 07:59:59.000 Ignoring the fact that the dates don't line up, the use of 07:59:59 suggests the custom time periods have been defined using inclusive date ranges. But given my contrived example above, shouldn't we be using 07:59:59.999. I appreciate this all might be splitting hairs and that I am essentially pointing at a 1 second gap for each financial period where some database queries might miss out a transaction. And even if the transaction was missed, it would be included in the query results the following time period. But these gaps are where confusion can occur and subtle and difficult to reproduce bugs can appear, so it's nice to get things fully specified if possible. Therefore, do we have a general rule on whether thruDates in OFBiz are inclusive or exclusive of the thruDate value itself? Or does the inclusivity of the thruDate depend on context? Thanks for reading :) Dan. -- Daniel Watford
Re: Welcome to Daniel Watford as new PMC member
Thanks all - I appreciate the invitation and am happy to be here :) On Mon, 30 Jan 2023 at 16:33, gil.portenseigne wrote: > Welcome Daniel, and Congrats ! > > Gil > On 28/01/23 11:57, Jacopo Cappellato wrote: > > The OFBiz PMC has invited Daniel Watford as a new PMC member and we > > are glad to announce that Daniel has accepted the nomination. > > > > On behalf of the OFBiz PMC, welcome on board! > -- Daniel Watford
Re: Apache OfBiz HTML Customization
You might also find this page useful: ofbiz-framework/themes.adoc at trunk · apache/ofbiz-framework (github.com) <https://github.com/apache/ofbiz-framework/blob/trunk/themes/docs/themes.adoc> On Mon, 30 Jan 2023 at 19:19, Daniel Watford wrote: > Hi Douglas, > > I think you probably want to take a look at TopAppBar.ftl template here - > ofbiz-framework/themes/rainbowstone/template/includes > at dfc05edbab3ced075480b264c1356195a957db1d · apache/ofbiz-framework > (github.com) > <https://github.com/apache/ofbiz-framework/tree/dfc05edbab3ced075480b264c1356195a957db1d/themes/rainbowstone/template/includes> > > If you use your browser's development tools and search the elements for > "app-bar-list" you should be able to match up the rendered HTML with line > 49 of the TopAppBar.ftl template. > > I imagine this will just be the starting point, but you should be able to > search the OFBiz code for TopAppBar.ftl to see how the various components > are stitched together to render a screen. > > Dan. > > On Fri, 27 Jan 2023 at 04:32, Douglas Melo > wrote: > >> More precisely, I would like to edit HTML content of NAVbar menu or main >> menu, in rainbowstone theme. >> >> Douglas Melo >> douglas.mel...@hotmail.com ( >> https://link.getmailspring.com/link/64b47262-b830-4118-982c-5274f3629...@getmailspring.com/0?redirect=mailto%3Adouglas.melo98%40hotmail.com&recipient=ZGV2QG9mYml6LmFwYWNoZS5vcmc%3D >> ) >> +55 28 99955-2528 (tel:+55%2028%2099955-2528) >> >> On Jan 26 2023, at 4:04 am, Daniel Watford wrote: >> > Hi Douglas, >> > >> > There isn't normally a single HTML file. Instead, OFBiz pages are >> rendered >> > by combining a number of elements. >> > >> > If you let us know which page you want to alter we can point you at the >> > relevant components. >> > >> > Dan. >> > On Thu, 26 Jan 2023 at 04:58, Douglas Melo >> > wrote: >> > >> > > Good morning, people!! >> > > >> > > I know it's a very simple question, but I'm really having trouble >> finding >> > > the Apache OfBiz HTML file. I need to find the HTML file to perform a >> > > customization, how do I find it? >> > > Douglas Melo >> > > douglas.mel...@hotmail.com ( >> > > >> https://link.getmailspring.com/link/54c39963-3980-4ba9-be6e-0c016cdb3...@getmailspring.com/0?redirect=mailto%3Adouglas.melo98%40hotmail.com&recipient=ZGV2QG9mYml6LmFwYWNoZS5vcmc%3D >> > > ) >> > > +55 28 99955-2528 (tel:+55%2028%2099955-2528) >> > > >> > > >> > >> > -- >> > Daniel Watford >> > >> >> > > -- > Daniel Watford > -- Daniel Watford
Re: Apache OfBiz HTML Customization
Hi Douglas, I think you probably want to take a look at TopAppBar.ftl template here - ofbiz-framework/themes/rainbowstone/template/includes at dfc05edbab3ced075480b264c1356195a957db1d · apache/ofbiz-framework (github.com) <https://github.com/apache/ofbiz-framework/tree/dfc05edbab3ced075480b264c1356195a957db1d/themes/rainbowstone/template/includes> If you use your browser's development tools and search the elements for "app-bar-list" you should be able to match up the rendered HTML with line 49 of the TopAppBar.ftl template. I imagine this will just be the starting point, but you should be able to search the OFBiz code for TopAppBar.ftl to see how the various components are stitched together to render a screen. Dan. On Fri, 27 Jan 2023 at 04:32, Douglas Melo wrote: > More precisely, I would like to edit HTML content of NAVbar menu or main > menu, in rainbowstone theme. > > Douglas Melo > douglas.mel...@hotmail.com ( > https://link.getmailspring.com/link/64b47262-b830-4118-982c-5274f3629...@getmailspring.com/0?redirect=mailto%3Adouglas.melo98%40hotmail.com&recipient=ZGV2QG9mYml6LmFwYWNoZS5vcmc%3D > ) > +55 28 99955-2528 (tel:+55%2028%2099955-2528) > > On Jan 26 2023, at 4:04 am, Daniel Watford wrote: > > Hi Douglas, > > > > There isn't normally a single HTML file. Instead, OFBiz pages are > rendered > > by combining a number of elements. > > > > If you let us know which page you want to alter we can point you at the > > relevant components. > > > > Dan. > > On Thu, 26 Jan 2023 at 04:58, Douglas Melo > > wrote: > > > > > Good morning, people!! > > > > > > I know it's a very simple question, but I'm really having trouble > finding > > > the Apache OfBiz HTML file. I need to find the HTML file to perform a > > > customization, how do I find it? > > > Douglas Melo > > > douglas.mel...@hotmail.com ( > > > > https://link.getmailspring.com/link/54c39963-3980-4ba9-be6e-0c016cdb3...@getmailspring.com/0?redirect=mailto%3Adouglas.melo98%40hotmail.com&recipient=ZGV2QG9mYml6LmFwYWNoZS5vcmc%3D > > > ) > > > +55 28 99955-2528 (tel:+55%2028%2099955-2528) > > > > > > > > > > -- > > Daniel Watford > > > > -- Daniel Watford
Re: Codenarc integration process
Turns out I was able to import the list of files into Excel and copy and paste the table from Excel to Confluence. On Sat, 28 Jan 2023 at 08:37, Daniel Watford wrote: > Hi Gil, > > I don't think a checklist is quite enough, assuming we want to track the > status of each file reviewed. > > From the review approach section: > > >- If in the reviewers opinion a file change will not change OFBiz >behaviour in any way they should mark the corresponding entry in the table >below as PASSED. >- If the reviewer identifies an issue with a changed file, then they >should add a comment in the PR on GitHub AND mark the corresponding entry >in the table below as WORK NEEDED. >- If the reviewer is unsure how to classify a changed file they should >mark the corresponding entry in the table below as UNSURE. >- In each of the above cases, the reviewer should add their name >against the entry in the table below. > > The checklist doesn't give us the opportunity to see what files need some > additional help. > > I'm sure there must be some way of getting Confluence to produce a table > from a list - I just don't seem to have found it yet! I'll play around with > Confluence a bit more. > > But as mentioned before, perhaps I am making too much out of tracking this > review. > > Thanks, > > Dan. > > > On Fri, 27 Jan 2023 at 17:05, gil.portenseigne < > gil.portensei...@nereide.fr> wrote: > >> I got to leave, but i generated in confluence a list of check, is that >> good enough ? >> >> Gil >> On 27/01/23 05:41, gil.portenseigne wrote: >> > Hello, indeed, that will generate much spam, i did some before reading >> > your answer. >> > >> > I'll have a look for conluence. >> > >> > Gil >> > >> > >> > On 27/01/23 04:14, Daniel Watford wrote: >> > > Hi Gill and Jacques, >> > > >> > > I don't think we should add comments to the PR to track the files >> that we >> > > have reviewed as I think each comment will appear separately in the >> PR's >> > > conversation view. >> > > >> > > However, with such a large PR where we hope to get several reviewers >> > > involved I think we do need a mechanism to track reviewed files. >> > > >> > > I created a page here - Codenarc integration review tracker - OFBiz >> Project >> > > Open Wiki - Apache Software Foundation >> > > < >> https://cwiki.apache.org/confluence/display/OFBIZ/Codenarc+integration+review+tracker >> > >> > > - >> > > suggesting an approach. >> > > >> > > If the approach is acceptable then all reviewers should be able to >> update >> > > the page as we go. >> > > >> > > I'm stuck with finding a nice way to generate a table listing all the >> > > changed files and the review status of each file. I have included the >> > > commands to produce the list of files and shown some examples of how >> to add >> > > a header, but my attempts to turn that into something useful on a >> > > confluence page have not been fruitful. >> > > >> > > So two questions. >> > > - Is it worth coming up with a page/table to track this PR or am I >> just >> > > creating unnecessary admin work when we could use comments in the PR? >> > > - Can anyone create a table in Confluence that we could use to track >> the >> > > review effort? >> > > >> > > Thanks, >> > > >> > > Dan. >> > > >> > > >> > > On Fri, 27 Jan 2023 at 15:27, gil.portenseigne < >> gil.portensei...@nereide.fr> >> > > wrote: >> > > >> > > > Oops, i did a fixup commit with push force that remove all comments >> in >> > > > the pull request... Will not do that again. >> > > > >> > > > I fixed the detected typo. >> > > > >> > > > gil >> > > > On 27/01/23 02:56, Jacques Le Roux wrote: >> > > > > Ah OK, sounds better indeed >> > > > > >> > > > > Le 27/01/2023 à 14:06, gil.portenseigne a écrit : >> > > > > > The idea is not to modify the files, but to add a comment into >> the pull >> > > > > > request. Those allowing each reviewer to check the viewed >> checkbox if a >> > > > > > commen
Re: Codenarc integration process
Hi Gil, I don't think a checklist is quite enough, assuming we want to track the status of each file reviewed. >From the review approach section: - If in the reviewers opinion a file change will not change OFBiz behaviour in any way they should mark the corresponding entry in the table below as PASSED. - If the reviewer identifies an issue with a changed file, then they should add a comment in the PR on GitHub AND mark the corresponding entry in the table below as WORK NEEDED. - If the reviewer is unsure how to classify a changed file they should mark the corresponding entry in the table below as UNSURE. - In each of the above cases, the reviewer should add their name against the entry in the table below. The checklist doesn't give us the opportunity to see what files need some additional help. I'm sure there must be some way of getting Confluence to produce a table from a list - I just don't seem to have found it yet! I'll play around with Confluence a bit more. But as mentioned before, perhaps I am making too much out of tracking this review. Thanks, Dan. On Fri, 27 Jan 2023 at 17:05, gil.portenseigne wrote: > I got to leave, but i generated in confluence a list of check, is that > good enough ? > > Gil > On 27/01/23 05:41, gil.portenseigne wrote: > > Hello, indeed, that will generate much spam, i did some before reading > > your answer. > > > > I'll have a look for conluence. > > > > Gil > > > > > > On 27/01/23 04:14, Daniel Watford wrote: > > > Hi Gill and Jacques, > > > > > > I don't think we should add comments to the PR to track the files that > we > > > have reviewed as I think each comment will appear separately in the > PR's > > > conversation view. > > > > > > However, with such a large PR where we hope to get several reviewers > > > involved I think we do need a mechanism to track reviewed files. > > > > > > I created a page here - Codenarc integration review tracker - OFBiz > Project > > > Open Wiki - Apache Software Foundation > > > < > https://cwiki.apache.org/confluence/display/OFBIZ/Codenarc+integration+review+tracker > > > > > - > > > suggesting an approach. > > > > > > If the approach is acceptable then all reviewers should be able to > update > > > the page as we go. > > > > > > I'm stuck with finding a nice way to generate a table listing all the > > > changed files and the review status of each file. I have included the > > > commands to produce the list of files and shown some examples of how > to add > > > a header, but my attempts to turn that into something useful on a > > > confluence page have not been fruitful. > > > > > > So two questions. > > > - Is it worth coming up with a page/table to track this PR or am I just > > > creating unnecessary admin work when we could use comments in the PR? > > > - Can anyone create a table in Confluence that we could use to track > the > > > review effort? > > > > > > Thanks, > > > > > > Dan. > > > > > > > > > On Fri, 27 Jan 2023 at 15:27, gil.portenseigne < > gil.portensei...@nereide.fr> > > > wrote: > > > > > > > Oops, i did a fixup commit with push force that remove all comments > in > > > > the pull request... Will not do that again. > > > > > > > > I fixed the detected typo. > > > > > > > > gil > > > > On 27/01/23 02:56, Jacques Le Roux wrote: > > > > > Ah OK, sounds better indeed > > > > > > > > > > Le 27/01/2023 à 14:06, gil.portenseigne a écrit : > > > > > > The idea is not to modify the files, but to add a comment into > the pull > > > > > > request. Those allowing each reviewer to check the viewed > checkbox if a > > > > > > comment is present, to collapse already reviewed files. > > > > > > > > > > > > So no need further action, apart the real code modification > request, > > > > > > when commiting the code. > > > > > > > > > > > > On 27/01/23 12:00, Jacques Le Roux wrote: > > > > > > > Hi Gil, Daniel, > > > > > > > > > > > > > > I agree Gil, I just tried before seeing your message and came > to the > > > > same conclusion. > > > > > > > > > > > > > > With a comment at top we would need to
Re: Codenarc integration process
Hi Gill and Jacques, I don't think we should add comments to the PR to track the files that we have reviewed as I think each comment will appear separately in the PR's conversation view. However, with such a large PR where we hope to get several reviewers involved I think we do need a mechanism to track reviewed files. I created a page here - Codenarc integration review tracker - OFBiz Project Open Wiki - Apache Software Foundation <https://cwiki.apache.org/confluence/display/OFBIZ/Codenarc+integration+review+tracker> - suggesting an approach. If the approach is acceptable then all reviewers should be able to update the page as we go. I'm stuck with finding a nice way to generate a table listing all the changed files and the review status of each file. I have included the commands to produce the list of files and shown some examples of how to add a header, but my attempts to turn that into something useful on a confluence page have not been fruitful. So two questions. - Is it worth coming up with a page/table to track this PR or am I just creating unnecessary admin work when we could use comments in the PR? - Can anyone create a table in Confluence that we could use to track the review effort? Thanks, Dan. On Fri, 27 Jan 2023 at 15:27, gil.portenseigne wrote: > Oops, i did a fixup commit with push force that remove all comments in > the pull request... Will not do that again. > > I fixed the detected typo. > > gil > On 27/01/23 02:56, Jacques Le Roux wrote: > > Ah OK, sounds better indeed > > > > Le 27/01/2023 à 14:06, gil.portenseigne a écrit : > > > The idea is not to modify the files, but to add a comment into the pull > > > request. Those allowing each reviewer to check the viewed checkbox if a > > > comment is present, to collapse already reviewed files. > > > > > > So no need further action, apart the real code modification request, > > > when commiting the code. > > > > > > On 27/01/23 12:00, Jacques Le Roux wrote: > > > > Hi Gil, Daniel, > > > > > > > > I agree Gil, I just tried before seeing your message and came to the > same conclusion. > > > > > > > > With a comment at top we would need to remove it later, right? Could > be easy if it's the same unique words in every file. > > > > > > > > Jacques > > > > > > > > Le 27/01/2023 à 10:41, gil.portenseigne a écrit : > > > > > Hi Daniel, Jacques, > > > > > > > > > > I wonders the same, the "Review changes" do not seems to concern > one > > > > > file but the whole pull request, there is a review checkbox, but it > > > > > seems to be personal, i checked the first one > > > > > (AcctgAdminServices.groovy) for testing purpose. > > > > > > > > > > What we could do is to add a comment at the start of each file, to > let > > > > > others know that review job has been done. > > > > > > > > > > WDYT ? > > > > > > > > > > Gil > > > > > > > > > > > > > > > On 26/01/23 07:48, Jacques Le Roux wrote: > > > > > > Hi Daniel, > > > > > > > > > > > > In "Files changed" tab*, when you select a file, the "Review > changes" button allows you to comment, approve or request changes on this > file. > > > > > > I guess "approve" is what you are looking for? > > > > > > > > > > > > * https://github.com/apache/ofbiz-framework/pull/517/files > > > > > > > > > > > > Le 26/01/2023 à 17:26, Daniel Watford a écrit : > > > > > > > Does anyone know of a way in a GitHub PR that a reviewer can > mark an > > > > > > > individual file as reviewed-and-passed so that other reviewers > can skip > > > > > > > that file? > -- Daniel Watford
Re: Codenarc integration process
This was a massive effort - well done, Gil. My initial thought regarding the discussion about whether to commit all changes at once was initially - 'no way! we should break the changes up into multiple PRs'. However after reviewing the first few files I see the intention behind the changes do not have any effect, and that the effort to now break the changes into multiple PRs feels like it would outweigh the benefit and we would risk demotivating anyone working on this task. I am happy to work through some of the files for review. I would suggest we have a process similar to: - Changes which do not affect behaviour are accepted. - Any changes which appear to be typos, might change the system's behaviour, or the reviewer is unsure about can have a review/comment raised against them. This will boost their visibility among other reviewers so they can be examined in a bit more depth. Does anyone know of a way in a GitHub PR that a reviewer can mark an individual file as reviewed-and-passed so that other reviewers can skip that file? On Sun, 22 Jan 2023 at 08:49, Jacques Le Roux wrote: > Hi, > > Before I answered you I had an idea: we could split the effort. If we are > 10 to review it'd be reasonable. > > Jacques > > Le 21/01/2023 à 11:51, Gil Portenseigne a écrit : > > Haha, i understand, I will continue reviewing and testing while others > can review also, > > > > Thanks Jacques > > > > 21 janv. 2023 10:43:08 Jacques Le Roux : > > > >> Thanks Gil, > >> > >> OK, seems good to me to avoid gstring indeed. > >> > >> I had a glance, I was too optimistic. I'll not review the 455(!) files > and will rather call our CTR mode as I'm much confident in your (big) work > :) > >> > >> +1 from my side > >> > >> Jacques > >> > >> > >> Le 21/01/2023 à 09:57, Gil Portenseigne a écrit : > >>> Yes, it is considered best practice to avoid gstring usage when not > needed. > >>> > >>> Like for others, we can decide to not apply this rule. > >>> > >>> The detailed rule from codenarc documentation : > >>> > >>> > >>> *UnnecessaryGString** Rule* > >>> > >>> /Since //CodeNarc// 0.13/ > >>> > >>> String objects should be created with single quotes, and GString > objects created with double quotes. Creating normal String objects with > double quotes is confusing to readers. > >>> > >>> Gil > >>> > >>> 21 janv. 2023 09:41:39 Jacques Le Roux : > >>> > >>>> Hi Gil, > >>>> > >>>> So we need to use single quotes instead of double quotes now in > Groovy? > >>>> > >>>> Thanks > >>>> > >>>> Jacques > >>>> > >>>> Le 20/01/2023 à 17:01, Jacques Le Roux a écrit : > >>>>> Thank you very much Gil, > >>>>> > >>>>> +1 for a big squash... after some reviews... > >>>>> > >>>>> Jacques > >>>>> > >>>>> Le 20/01/2023 à 15:53, gil.portenseigne a écrit : > >>>>>> Hello Devs, > >>>>>> > >>>>>> That is with pleasure, that I managed to integrate into OFBiz > framework > >>>>>> (no plugins yet) Codenarc, and that the build is successful under > java > >>>>>> 17. > >>>>>> > >>>>>> > https://github.com/apache/ofbiz-framework/pull/517#issuecomment-1398487745 > >>>>>> > >>>>>> I tried to isolate rule fixes in separated commits, there are a lot > (133 > >>>>>> commits), with some redundancy. But rebasing is not easy since > files are > >>>>>> modified by several rule fixing. > >>>>>> > >>>>>> Integration and unit test are ok. I did some manual testing when I > got > >>>>>> some doubt, but it could be nice to have some more eyes on the > subject. > >>>>>> > >>>>>> After reviewing process, and if everything is fine, should we commit > >>>>>> that as a big squash ? > >>>>>> > >>>>>> WDYT > >>>>>> > >>>>>> Regards, > >>>>>> > >>>>>> Gil > -- Daniel Watford
Re: Apache OfBiz HTML Customization
Hi Douglas, There isn't normally a single HTML file. Instead, OFBiz pages are rendered by combining a number of elements. If you let us know which page you want to alter we can point you at the relevant components. Dan. On Thu, 26 Jan 2023 at 04:58, Douglas Melo wrote: > Good morning, people!! > > I know it's a very simple question, but I'm really having trouble finding > the Apache OfBiz HTML file. I need to find the HTML file to perform a > customization, how do I find it? > Douglas Melo > douglas.mel...@hotmail.com ( > https://link.getmailspring.com/link/54c39963-3980-4ba9-be6e-0c016cdb3...@getmailspring.com/0?redirect=mailto%3Adouglas.melo98%40hotmail.com&recipient=ZGV2QG9mYml6LmFwYWNoZS5vcmc%3D > ) > +55 28 99955-2528 (tel:+55%2028%2099955-2528) > > -- Daniel Watford
Re: Calling groovy from a form field
Hi Ernest, I'm not aware of any examples in OFBiz that exactly fit your use case. You may implement a solution using javascript to send your request to the testCalc service and then apply the results to the current form. An example of executing javascript from clicking a hyperlink can be seen in the Example plugin: https://demo-next.ofbiz.apache.org/example/control/FormWidgetExamples and is defined by the following element in FormWidgetExampleForms.xml: Another approach, albeit not one I have experimented with, is the on-event-update-area element. See example https://demo-next.ofbiz.apache.org/example/control/authview/findExampleAjax. In this example, screen ExampleAjaxScreens.xml#AjaxExample is rendered containing screens ListExampleFormOnly and CreateExampleFormOnly. Screen CreateExampleFormOnly includes form ExampleForms.xml#EditExampleBackgroundSubmit. Form EditExampleBackgroundSubmit has an on-event-update-area element directing OFBiz to update the ListExamplesAjax area (i.e. the form on the ListExampleFormOnly screen) when the EditExampleBackgroundSubmit form is submitted. If you trace the network calls in your web browser's development tools, you will see that submitting the EditExampleBackgroundSubmit form does not reload the page. Instead a post request is made to endpoint createExampleAjax to create the new Example record. A post is then made to the ListFormExampleOnly endpoint, retrieving the new contents of the list and displaying on the page. There might be a solution for your use case where your Calculate C button is on a small form adjacent to your Product Measures form. The form containing the button would have on-event-update-area configured to update the Product Measures form following a submit event. Please let us know how you get on. Dan. On Sun, 22 Jan 2023 at 04:19, Ernest Hocking wrote: > Hi everyone > > I'd like to use groovy to implement some business logic and call that logic > from a button in a form. > > E.g Add a button on the product measures form to calculate the volume > given a product's dimensions.. I've tried > > > also-hidden="false"> > > > > > I can call/test the service "testCalc" from webtools etc but not use the > button. > > Can anyone point me to an example in the existing code base that I can use > as a reference model. > > thanks in advance > > Ernest > -- Daniel Watford
