Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.
Le 14/04/2023 à 21:53, Michael Brohl a écrit : 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. Yes, as I could not get it working, I did not dig into that yet. As I said it's not stopping me to debug, but Groovy, so unrelated to JDK 17. I use the last Eclipse ( 2023-03) and all last Eclipse plugins.
Re: Moving node/npm to sub-projects. Should we apply to release22.01
+1 from my side bringing this to the 22.01 branch as well. Thanks for the work and initiative, Daniel. Best regards, Michael Am 14.04.23 um 16:59 schrieb Jacques Le Roux: Hi Ingo, Your message has been moderated, else it would not have reached this Mailing List. Please subscribe to the MLs: http://ofbiz.apache.org/mailing-lists.html. Thanks Jacques Le 14/04/2023 à 13:01, Ingo Richter a écrit : Hey, Sadly I do not have the time right now to check the changes but I wanted to chime in on the proposal to apply them to release 22.01: I agree with Daniels opinion on frontend plugins that do not only profit very much from NPM but also benefit from the ability to apply different versions of the same plugin on a plugin-basis. There might be one plugin running on a frontend library of a different version than a second plugin were an update to the same version might just not be viable. The proposed changes make it possible to use NPM in both plugins simultaneously. While the integration of NPM into OFBiz 22.01 is already a huge benefit, Daniels changes make it usable for OFBiz based frontend applications as well which - in my opinion - should not be delayed to a future release. Thanks for your efforts, Daniel! Ingo Am 14.04.23 um 09:11 schrieb Daniel Watford: 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.
Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.
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 /ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity/util line 527 Java Problem Comment cannot be resolved to a type LabelManagerFactory.java /ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager line 164 Java Problem Comment cannot be resolved to a type LabelManagerFactory.java /ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager line 169 Java Problem Comment cannot be resolved to a type SaveLabelsToXmlFile.java /ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager line 128 Java Problem Comment cannot be resolved to a type SaveLabelsToXmlFile.java /ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager
Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.
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 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-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 error
Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.
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 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-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
Re: Moving node/npm to sub-projects. Should we apply to release22.01
Hi Ingo, Your message has been moderated, else it would not have reached this Mailing List. Please subscribe to the MLs: http://ofbiz.apache.org/mailing-lists.html. Thanks Jacques Le 14/04/2023 à 13:01, Ingo Richter a écrit : Hey, Sadly I do not have the time right now to check the changes but I wanted to chime in on the proposal to apply them to release 22.01: I agree with Daniels opinion on frontend plugins that do not only profit very much from NPM but also benefit from the ability to apply different versions of the same plugin on a plugin-basis. There might be one plugin running on a frontend library of a different version than a second plugin were an update to the same version might just not be viable. The proposed changes make it possible to use NPM in both plugins simultaneously. While the integration of NPM into OFBiz 22.01 is already a huge benefit, Daniels changes make it usable for OFBiz based frontend applications as well which - in my opinion - should not be delayed to a future release. Thanks for your efforts, Daniel! Ingo Am 14.04.23 um 09:11 schrieb Daniel Watford: 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.
Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.
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 /ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity/util line 527 Java Problem Comment cannot be resolved to a type LabelManagerFactory.java /ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager line 164 Java Problem Comment cannot be resolved to a type LabelManagerFactory.java /ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager line 169 Java Problem Comment cannot be resolved to a type SaveLabelsToXmlFile.java /ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager line 128 Java Problem Comment cannot be resolved to a type SaveLabelsToXmlFile.java /ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager line 143 Java Problem Comment cannot be resolved to a type WebToolsDbEvents.java /ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools line 99 Java Problem DefaultHandler cannot be resolved to a type EntitySaxReader.java /ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity/util line 75 Java Problem DefaultHandler cannot be resolved to a type WebAppUtil.java /ofbiz/framework/webapp/src/main/java/org/apache/ofbiz/webapp line 261 Java Problem DocumentBuilder cannot be resolved to a type CsrfUtilTests.java /ofbiz/framework/security/src/test/java/org/apache/ofbiz/security line 115 Java Problem DocumentBuilder cannot be resolved to a type Csrf
Re: Moving node/npm to sub-projects. Should we apply to release22.01
Hey, Sadly I do not have the time right now to check the changes but I wanted to chime in on the proposal to apply them to release 22.01: I agree with Daniels opinion on frontend plugins that do not only profit very much from NPM but also benefit from the ability to apply different versions of the same plugin on a plugin-basis. There might be one plugin running on a frontend library of a different version than a second plugin were an update to the same version might just not be viable. The proposed changes make it possible to use NPM in both plugins simultaneously. While the integration of NPM into OFBiz 22.01 is already a huge benefit, Daniels changes make it usable for OFBiz based frontend applications as well which - in my opinion - should not be delayed to a future release. Thanks for your efforts, Daniel! Ingo Am 14.04.23 um 09:11 schrieb Daniel Watford: 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. -- Ingo Richter IT Consultant Fon +49 521 448 157-96 Fax +49 521 448 157-99 Mobil+49 170 962 385 9 ecomify GmbH, Gustav-Winkler-Str. 22, 33699 Bielefeld Fon: +49 521 448157-90 | Fax: +49 521 448157-99 | www.ecomify.de Court Registration: Amtsgericht Bielefeld, HRB 41683 | CEO: Martin Becker, Michael Brohl
Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.
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 /ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity/util line 527 Java Problem Comment cannot be resolved to a type LabelManagerFactory.java /ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager line 164 Java Problem Comment cannot be resolved to a type LabelManagerFactory.java /ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager line 169 Java Problem Comment cannot be resolved to a type SaveLabelsToXmlFile.java /ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager line 128 Java Problem Comment cannot be resolved to a type SaveLabelsToXmlFile.java /ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager line 143 Java Problem Comment cannot be resolved to a type WebToolsDbEvents.java /ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools line 99 Java Problem DefaultHandler cannot be resolved to a type EntitySaxReader.java /ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity/util line 75 Java Problem DefaultHandler cannot be resolved to a type WebAppUtil.java /ofbiz/framework/webapp/src/main/java/org/apache/ofbiz/webapp line 261 Java Problem DocumentBuilder cannot be resolved to a type CsrfUtilTests.java /ofbiz/framework/security/src/test/java/org/apache/ofbiz/security line 115 Java Problem DocumentBuilder cannot be resolved to a type CsrfUtilTests.java /ofbiz/framework/security/src/test/java/org/apache/ofbiz/security line 152 Java Problem DocumentBuilder cannot be resolved to a type GatewayResponse.java /ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/eway line 169 Java Problem DocumentBuilder cannot be resolved to a type ModelService.java
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
