Re: Migration from ci.a.o
Hi Jacques, I agree we should remove the xml rpc related code from trunk, Here is the task for the issue, I'll create PR for the same https://issues.apache.org/jira/browse/OFBIZ-12812 Thanks & Regards -- Deepak Dixit ofbiz.apache.org On Tue, Dec 14, 2021 at 2:05 PM Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > Hi All, > > I have created https://issues.apache.org/jira/browse/OFBIZ-12456 as a > clone of INFRA-22279 "Migrate Ofbiz bb 0.8 config to 3.2" > > Long story short, the XMLRPC integration tests, that needs HTTP and 8080 > port, don't pass on the new BuildBot and getting back to the old one is > impossible (more info OFBiz side in OFBIZ-12456). > > In INFRA-22279, I have asked Gavin if we could allow the new BuildBot to > allow HTTP and 8080 port as it was on the old one. > > I also wonder if we should not get rid of Apache XMLRPC knowing that it's > no longer maintained: https://github.com/advisories/GHSA-6vwp-35w3-xph8 > > I'm not aware of an easy replacement for Apache XMLRPC. > > What do you think? > > Jacques > > Le 31/08/2021 à 14:08, Jacques Le Roux a écrit : > > Hi Gavin, > > > > Answering there > > > > Jacques > > > > Le 31/08/2021 à 11:32, Gavin McDonald a écrit : > >> I have created a Jira ticket where we can liaise on the migration which > I > >> would like to do ASAP. > > >
Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.
Thanks Wiebke, I know that for a while (https://s.apache.org/kewrn) but was desperately trying to avoid what you propose. It's indeed the right solution. So I think we can go on with OFBIZ-10226. At the bottom there is a link to a related discussion with some opinions from then. Or do you prefer to start anew for the sake of clarity? Thanks again for your work, I was not aware of this Groovy page. It definitely confirms what Mathieu said then. Jacques Le 25/04/2023 à 16:09, Wiebke Pätzold a écrit : Hi everyone, I did a bit of research regarding the groovy debugging. After some research I found this: “The Java Platform Module System requires that classes in distinct modules have distinct package names. Groovy has its own "modules" but these haven’t historically been structured according to the above requirement. For this reason, Groovy 2.x and 3.0 should be added to the classpath not module path when using JDK9+. This places Groovy’s classes into the unnamed module where the split package naming requirement is not enforced.“ http://groovy-lang.org/releasenotes/groovy-3.0.html#Groovy3.0releasenotes-Splitpackages For testing I used the service "sendEmailDated" in CommunicationEventServices.groovy. I can confirm the described behavior of Jacques, without a package declaration the service does not stop at my breakpoint. If I add the package declaration for the class, the service stops at my breakpoint. From my point of view it would make sense for the project not only to add the package declaration in all groovy classes, but also to ensure a consistent folder structure. For example, under framework -> base -> src there is a distinction between main and test. Within the test folder there is again a distinction between groovy and Java. Therefore I would suggest to introduce this structure everywhere, which means that there would be a src folder which in turn contains main, test, ... within these folders there is again a distinction between groovy and java. Example: applications -> product -> src -> main -> groovy -> org -> apache -> ofbiz ->... -> java -> org -> apache -> ofbiz ->... -> test -> groovy -> org -> apache -> ofbiz ->... -> java -> org -> apache -> ofbiz ->... What do you think about this idea? Best regards, Wiebke ecomify GmbH - www.ecomify.de Am 20.04.23 um 11:46 schrieb Michael Brohl: We have a working solution with all tests passing for release22.01 and trunk, I have created a Jira issue to track the effort. https://issues.apache.org/jira/browse/OFBIZ-12808 Best regards, Michael Brohl ecomify GmbH - www.ecomify.de Am 19.04.23 um 15:52 schrieb Michael Brohl: 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
Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.
Hi everyone, I did a bit of research regarding the groovy debugging. After some research I found this: “The Java Platform Module System requires that classes in distinct modules have distinct package names. Groovy has its own "modules" but these haven’t historically been structured according to the above requirement. For this reason, Groovy 2.x and 3.0 should be added to the classpath not module path when using JDK9+. This places Groovy’s classes into the unnamed module where the split package naming requirement is not enforced.“ http://groovy-lang.org/releasenotes/groovy-3.0.html#Groovy3.0releasenotes-Splitpackages For testing I used the service "sendEmailDated" in CommunicationEventServices.groovy. I can confirm the described behavior of Jacques, without a package declaration the service does not stop at my breakpoint. If I add the package declaration for the class, the service stops at my breakpoint. From my point of view it would make sense for the project not only to add the package declaration in all groovy classes, but also to ensure a consistent folder structure. For example, under framework -> base -> src there is a distinction between main and test. Within the test folder there is again a distinction between groovy and Java. Therefore I would suggest to introduce this structure everywhere, which means that there would be a src folder which in turn contains main, test, ... within these folders there is again a distinction between groovy and java. Example: applications -> product -> src -> main -> groovy -> org -> apache -> ofbiz ->... -> java -> org -> apache -> ofbiz ->... -> test -> groovy -> org -> apache -> ofbiz ->... -> java -> org -> apache -> ofbiz ->... What do you think about this idea? Best regards, Wiebke ecomify GmbH - www.ecomify.de Am 20.04.23 um 11:46 schrieb Michael Brohl: We have a working solution with all tests passing for release22.01 and trunk, I have created a Jira issue to track the effort. https://issues.apache.org/jira/browse/OFBIZ-12808 Best regards, Michael Brohl ecomify GmbH - www.ecomify.de Am 19.04.23 um 15:52 schrieb Michael Brohl: 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,
