Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.
Hi Michael, Actually, as you may have seen with recent Daniel's work, lazy consensus is de facto if nobody oppose :) Cheers Jacques Le 27/04/2023 à 18:49, Michael Brohl a écrit : Hi everyone, what do you think about this refactoring suggestion? We would organize to do this work but won't start until the community decides to do so. It will be some amount of work so it should definetely be backed by the community. Can we apply lazy consensus here or do we need some kind of voting? Best regards, Michael Brohl ecomify GmbH - www.ecomify.de Am 26.04.23 um 13:21 schrieb Michael Brohl: Hi, I suggest to start with a new ticket to coordinate the refactoring work (will you take this into your hands, Wiebke?). OFBIZ-10226 has another intention which will not solve the overall problem Wiebke described. Does the community agree that we'll have to do this work? Even more, do we agree that it has to be done before we can ship a first 22.01 release based on JDK 17? Best regards, Michael Brohl ecomify GmbH - www.ecomify.de Am 25.04.23 um 18:30 schrieb Jacques Le Roux: 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
Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.
Hi everyone, what do you think about this refactoring suggestion? We would organize to do this work but won't start until the community decides to do so. It will be some amount of work so it should definetely be backed by the community. Can we apply lazy consensus here or do we need some kind of voting? Best regards, Michael Brohl ecomify GmbH - www.ecomify.de Am 26.04.23 um 13:21 schrieb Michael Brohl: Hi, I suggest to start with a new ticket to coordinate the refactoring work (will you take this into your hands, Wiebke?). OFBIZ-10226 has another intention which will not solve the overall problem Wiebke described. Does the community agree that we'll have to do this work? Even more, do we agree that it has to be done before we can ship a first 22.01 release based on JDK 17? Best regards, Michael Brohl ecomify GmbH - www.ecomify.de Am 25.04.23 um 18:30 schrieb Jacques Le Roux: 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
Re: [jira] [Commented] (OFBIZ-12808) Eclipse build problems and proper dependency setup
Thanks Daniel! Best regards, Michael Am 27.04.23 um 09:14 schrieb Daniel Watford: 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
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
