Re: [jira] [Commented] (OFBIZ-12808) Eclipse build problems and proper dependency setup
+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=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)
Re: [jira] [Commented] (OFBIZ-12808) Eclipse build problems and proper dependency setup
+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=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)
Re: [jira] [Commented] (OFBIZ-12808) Eclipse build problems and proper dependency setup
+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=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)
Re: [jira] [Commented] (OFBIZ-12808) Eclipse build problems and proper dependency setup
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=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)
Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.
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 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:
Re: [OFBIZ-12801] "Error at CommunicationEventServices.groovy:489"
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/2023 à 18:37, Daniel Watford a écrit : 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 <> What would be your opinion about a best solution? TIA Jacques *http://svn.apache.org/viewvc?view=revision=1298908
Re: Migration from ci.a.o
Here is the PR for xml rpc related code removal. Please review and let me know if it looks good. https://github.com/apache/ofbiz-framework/pull/630/files Thanks & Regards -- Deepak Dixit ofbiz.apache.org On Wed, Apr 26, 2023 at 11:01 AM Deepak Dixit wrote: > 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. >> > >> >
