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=1298908 > -- Daniel Watford
[OFBIZ-12801] "Error at CommunicationEventServices.groovy:489"
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 <> What would be your opinion about a best solution? TIA Jacques * http://svn.apache.org/viewvc?view=revision=1298908
Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.
Hi Michael, That's surely the best and cleaner solution Thanks Jacques Le 19/04/2023 à 15:52, Michael Brohl a écrit : Hi everyone, it seems that we have a solution for the Eclipse Java build and runtime problems we faced with JDK 17 (not speaking of the Groovy build problems). We removed some (transitive) dependencies in the build file and updated some of them so that libraries are used from the JDK instead of external libaries. This avoids the compiler from finding duplicate classes which seem to be ignored and therefore not being found also at runtime. We are checking the changes with a project now and provide a pull request when we are sure everything works fine. Best regards, Michael Brohl ecomify GmbH - www.ecomify.de Am 14.04.23 um 21:53 schrieb Michael Brohl: Thanks Jacques! for me, org.eclipse.jdt.core.compiler.ignoreUnnamedModuleForSplitPackage only works as far as the build problems get away but there are still packages and classes not found by Eclipse at runtime so not really working for debugging here. Additionally, I realized that the settings file is (re)generated by the Gradle eclipse task and the property vanished during the process. It would be necessary to add the setting during the build. All in all, some kind of showstopper using OFBiz with JDK 17 and Eclipse which has to be solved somehow. Thanks, Michael Am 14.04.23 um 16:50 schrieb Jacques Le Roux: 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-from-more-than-one-module Anyway, I need to fix that myself and will look at the best option when I'll get a chance. I tried some w/o success so far, . It's very annoying in Eclipse UI. The best way could be to follow the point 7 at https://www.eclipse.org/community/eclipse_newsletter/2018/june/java9andbeyond.php I did not try yet, just found it :) HTH Jacques Le 16/02/2023 à 17:10, Cheng Hu Shan a écrit : Hi, I've encounterd the same problem. I cannot offer a solution. But maybe a better description of this problem may help you. The root problem seems to be how the Java Platform Modular System introduced in version 9 and foreign libraries interact: Since Java 9 one particular package may only exists once in your entire project system, but if you import foreign libraries, they may bring their own version of a that package. If you mouse over a faulty import statement in any of the java classes, you may find an error similiar to "The package [name] is accessible from more than one module: java.xml". The module refers to all foreign libraries stuffed into the classpath which counts as one huge unnamed module. I'm surprised that this issue has not been reported yet, as it seems to be a fundamental one. My guess would be that we need to somehow update the build.gradle file. On a side note: OfBiz actually starts and is operating properly thanks to the backwards compatiblity of Java, but the error messages remain. Best regards, Cheng Hu Shan Am 14.02.23 um 23:15 schrieb Carlos Navarro: Hello Community, Hope you're all doing well. I'm trying to setup OFBiz 22 and Eclipse in order to get a debugging environment following https://cwiki.apache.org/confluence/display/ofbiz/eclipse+tips OFBiz version: 22.01 JDK: 17 Eclipse: Eclipse IDE for Enterprise Java and Web Developers (includes Incubating components) Version: 2022-12 (4.26.0) OS: Windows 10 However, as far as I import an existente OFBiz 22 Eclipse project, there are a lot of errors (that I have have not experienced with OFBiz 18). Here are some of them (100 of 3967 errors): Description Resource Path Location Type Attributes cannot be
Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.
Hi everyone, it seems that we have a solution for the Eclipse Java build and runtime problems we faced with JDK 17 (not speaking of the Groovy build problems). We removed some (transitive) dependencies in the build file and updated some of them so that libraries are used from the JDK instead of external libaries. This avoids the compiler from finding duplicate classes which seem to be ignored and therefore not being found also at runtime. We are checking the changes with a project now and provide a pull request when we are sure everything works fine. Best regards, Michael Brohl ecomify GmbH - www.ecomify.de Am 14.04.23 um 21:53 schrieb Michael Brohl: Thanks Jacques! for me, org.eclipse.jdt.core.compiler.ignoreUnnamedModuleForSplitPackage only works as far as the build problems get away but there are still packages and classes not found by Eclipse at runtime so not really working for debugging here. Additionally, I realized that the settings file is (re)generated by the Gradle eclipse task and the property vanished during the process. It would be necessary to add the setting during the build. All in all, some kind of showstopper using OFBiz with JDK 17 and Eclipse which has to be solved somehow. Thanks, Michael Am 14.04.23 um 16:50 schrieb Jacques Le Roux: 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-from-more-than-one-module Anyway, I need to fix that myself and will look at the best option when I'll get a chance. I tried some w/o success so far, . It's very annoying in Eclipse UI. The best way could be to follow the point 7 at https://www.eclipse.org/community/eclipse_newsletter/2018/june/java9andbeyond.php I did not try yet, just found it :) HTH Jacques Le 16/02/2023 à 17:10, Cheng Hu Shan a écrit : Hi, I've encounterd the same problem. I cannot offer a solution. But maybe a better description of this problem may help you. The root problem seems to be how the Java Platform Modular System introduced in version 9 and foreign libraries interact: Since Java 9 one particular package may only exists once in your entire project system, but if you import foreign libraries, they may bring their own version of a that package. If you mouse over a faulty import statement in any of the java classes, you may find an error similiar to "The package [name] is accessible from more than one module: java.xml". The module refers to all foreign libraries stuffed into the classpath which counts as one huge unnamed module. I'm surprised that this issue has not been reported yet, as it seems to be a fundamental one. My guess would be that we need to somehow update the build.gradle file. On a side note: OfBiz actually starts and is operating properly thanks to the backwards compatiblity of Java, but the error messages remain. Best regards, Cheng Hu Shan Am 14.02.23 um 23:15 schrieb Carlos Navarro: Hello Community, Hope you're all doing well. I'm trying to setup OFBiz 22 and Eclipse in order to get a debugging environment following https://cwiki.apache.org/confluence/display/ofbiz/eclipse+tips OFBiz version: 22.01 JDK: 17 Eclipse: Eclipse IDE for Enterprise Java and Web Developers (includes Incubating components) Version: 2022-12 (4.26.0) OS: Windows 10 However, as far as I import an existente OFBiz 22 Eclipse project, there are a lot of errors (that I have have not experienced with OFBiz 18). Here are some of them (100 of 3967 errors): Description Resource Path Location Type Attributes cannot be resolved to a type EntitySaxReader.java
Re: [ofbiz-framework] branch ofbiz-12723 created (now 5267532fde)
Not quite sure why this happened (happens sometimes). I guess due to my use of ToirtoiseGit. Anyway not a big deal, actually just a "void" message. Le 19/04/2023 à 14:28, 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.
Re: Codenarc integration process
Everybody can now help by looking at https://nightlies.apache.org/ofbiz/trunk/groovyScripts.html (only trunk for now) Le 12/04/2023 à 17:24, Jacques Le Roux a écrit : Hi Gil, IMO better forget it, that's not a big deal and it looks good enough to me at https://issues.apache.org/jira/browse/OFBIZ-11167 Jacques Le 12/04/2023 à 16:58, Gil Portenseigne a écrit : Hello ! I just squashed and committed the pull request, I would like to thank you again for the review work and animation ! I failed the commit message due to the pull request feature i was not familiar about... I am not aware of "force push" policy in trunk that could allow me to fix that, i wanted to ask if it is allowed ? Gil Le 27/03/2023 à 16:46, Jacques Le Roux a écrit : Hi Guys, For those who have used a non "PASSED" lozenge in wiki and resolved a related conversation in GH please update the status in wiki TIA Jacques Le 28/01/2023 à 11:51, Gil Portenseigne a écrit : Oh sorry indeed i overview the review approach section. The table is nice, thanks Dan ! 28 janv. 2023 09:37:50 Daniel Watford : 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: … the pull … checkbox if a … request, … to the same conclusion. … Could be easy if it's the same unique words in every file. … concern one … but it … file, to let … "Review changes" button allows you to comment, approve or request changes on this file. … can mark an … reviewers can skip … -- Daniel Watford -- Daniel Watford
Re: Buildbot failure in on ofbizTrunkFrameworkPlugins
Hi Daniel, For now I have committed a change in BB config in order to generate a file at https://nightlies.apache.org/ofbiz/trunk/groovyScripts.html It should appear with the next trunk commit. I agree that should be enough. It's similar to what I did for checkstyle. And indeed fixing new Codenarc issues is all what is needed for the status to change to success. As long as we react sufficiently quick, as you did thanks, it's OK. About your side note: The BB config is already complicated enough for me and OK as is. But anyone can have a look :) Actually as you can see below, you are in the list of those who should receive an email from BB when a status change ie the blamelist: 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> At least I receive these emails when status change. From the top of my head I don't remember how this blamelist is set. I guess people subscribe somewhere. I don't remember where. Good idea about the badge. I'll have a look. Thanks Jacques Le 19/04/2023 à 08:12, Daniel Watford a écrit : 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
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
Hi Michaek, All, Yes that's also what I think and said in my answer to Daniel. But I did not dig, more an intuition, like you. Jacques Le 19/04/2023 à 09:19, Michael Brohl a écrit : 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 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.
Re: Need help finding where JCrop is used
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 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.
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] > 145da8136056a76d4e5c8bb9e40ebe8a93de01fb > > > > > > Steps: > > > >worker_preparation: 0 > > > >git: 0 > > > >pullAllPluginsSource: 0 > > > >build: 0 > > > >check: 2 > > > >Copy checkstyle to destination directory structure: 0 > > > >generateReadmeFiles: 0 > > > >Copy readme: 0 > > > >generateOfbizDocumentation: 0 > > > >Copy OfbizDocumentation: 0 > > > >
