[jira] [Commented] (OFBIZ-12836) Resource leaks in EntitySQLProcessor.groovy
[ https://issues.apache.org/jira/browse/OFBIZ-12836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17750105#comment-17750105 ] ASF subversion and git services commented on OFBIZ-12836: - Commit 1e96dd11bfa73a35dac518e74e0bf29e204ddf1f in ofbiz-framework's branch refs/heads/trunk from paul [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=1e96dd11bf ] Fixed: Make loop counters in EntitySQLProcessor.groovy into local variables (OFBIZ-12836) > Resource leaks in EntitySQLProcessor.groovy > --- > > Key: OFBIZ-12836 > URL: https://issues.apache.org/jira/browse/OFBIZ-12836 > Project: OFBiz > Issue Type: Bug > Components: webtools >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Minor > Attachments: EntitySQLProcessor-1.groovy, > EntitySQLProcessor-2.groovy, EntitySQLProcessor-3.groovy, > EntitySQLProcessor-4.groovy, EntitySQLProcessor.groovy, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-1.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-2.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-3.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-4.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-5.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy.patch > > > In framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy at line > 35 > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L35] > > it creates an SQLProcessor. SQLProcessor has a Close method and implements > AutoCloseable, but we're not using try-with-resources, nor directly calling > the Close method. > > Similarly, > > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L38] > > obtains a java.sql.Resultset, which will be closed when everything works, but > would leak if there was an exception. Again, we should be using > try-with-resources. > > Note that according to > > [https://docs.oracle.com/en/java/javase/20/docs/api/java.sql/java/sql/ResultSet.html#close()] > > "Calling the method close on a ResultSet object that is already closed is a > no-op.", if you obtain a ResultSet from the SQLProcessor and directly close > that ResultSet, it's not a problem when the SQLProcessor.close also attempts > to close the ResultSet. > > The problem is minor, most of the time. The groovy script is in the webtools, > so used for developer tinkering and not production use. > > When you're doing a SELECT, the script is closing the ResultSet, so the > important resources are cleaned up (assuming no exception occurred). > > However, if you are doing INSERT, UPDATE or DELETE, the script creates a > prepared statement that is not closed, so there's a resource leak. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12813) Refactor groovy folder structure and add package declaration
[
https://issues.apache.org/jira/browse/OFBIZ-12813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17750098#comment-17750098
]
Deepak Dixit commented on OFBIZ-12813:
--
Not able to build trunk on local, disabled the codenarc plugins to avoid the
checkstyle failure,
Getting following error
{quote}
FAILURE: Build failed with an exception.
What went wrong:
Execution failed for task ':compileGroovy'.
> java.lang.ExceptionInInitializerError (no error message)
{quote}
While running {quote}gradlew --stacktrace {quote}
{quote}Caused by: groovy.lang.GroovyRuntimeException: Conflicting module
versions. Module [groovy-datetime is loaded in version 4.0.2 and you are trying
to load version 3.0.13
{quote}
Anyone else facing the same issue?
> Refactor groovy folder structure and add package declaration
>
>
> Key: OFBIZ-12813
> URL: https://issues.apache.org/jira/browse/OFBIZ-12813
> Project: OFBiz
> Issue Type: Bug
>Affects Versions: 22.01.01, Upcoming Branch
>Reporter: Wiebke Paetzold
>Assignee: Michael Brohl
>Priority: Major
> Fix For: Upcoming Branch
>
>
> Due to the upgrade to jdk17 all groovy Classes need a package declaration.
> To get a distinct package naming a consistent folder structure is needed.
> 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.
> This scheme should be applied everywhere. So a src folder contains main,
> test, ... within these folders there is again a distinction between groovy
> and java.
>
> For more information visit:
> [http://groovy-lang.org/releasenotes/groovy-3.0.html#Groovy3.0releasenotes-Splitpackages]
> “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.“
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OFBIZ-12813) Refactor groovy folder structure and add package declaration
[ https://issues.apache.org/jira/browse/OFBIZ-12813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17750093#comment-17750093 ] ASF subversion and git services commented on OFBIZ-12813: - Commit f3784fcb44980e5a566c340ddce9ab0baa7f91b3 in ofbiz-site's branch refs/heads/master from Deepak Dixit [ https://gitbox.apache.org/repos/asf?p=ofbiz-site.git;h=f3784fc ] Updated groovyScripts references in test-suites.xsd file (OFBIZ-12813) > Refactor groovy folder structure and add package declaration > > > Key: OFBIZ-12813 > URL: https://issues.apache.org/jira/browse/OFBIZ-12813 > Project: OFBiz > Issue Type: Bug >Affects Versions: 22.01.01, Upcoming Branch >Reporter: Wiebke Paetzold >Assignee: Michael Brohl >Priority: Major > Fix For: Upcoming Branch > > > Due to the upgrade to jdk17 all groovy Classes need a package declaration. > To get a distinct package naming a consistent folder structure is needed. > 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. > This scheme should be applied everywhere. So a src folder contains main, > test, ... within these folders there is again a distinction between groovy > and java. > > For more information visit: > [http://groovy-lang.org/releasenotes/groovy-3.0.html#Groovy3.0releasenotes-Splitpackages] > “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.“ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12813) Refactor groovy folder structure and add package declaration
[ https://issues.apache.org/jira/browse/OFBIZ-12813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17750087#comment-17750087 ] Deepak Dixit commented on OFBIZ-12813: -- >>>Deepak Dixit why shoul we "remove the projectmgr groovy and form from >>>MyCommunicationEvents screen"? We should not include plugins dependencies in application code, I remembered the same thing discussed in past as well, we can keep it as is. > Refactor groovy folder structure and add package declaration > > > Key: OFBIZ-12813 > URL: https://issues.apache.org/jira/browse/OFBIZ-12813 > Project: OFBiz > Issue Type: Bug >Affects Versions: 22.01.01, Upcoming Branch >Reporter: Wiebke Paetzold >Assignee: Michael Brohl >Priority: Major > Fix For: Upcoming Branch > > > Due to the upgrade to jdk17 all groovy Classes need a package declaration. > To get a distinct package naming a consistent folder structure is needed. > 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. > This scheme should be applied everywhere. So a src folder contains main, > test, ... within these folders there is again a distinction between groovy > and java. > > For more information visit: > [http://groovy-lang.org/releasenotes/groovy-3.0.html#Groovy3.0releasenotes-Splitpackages] > “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.“ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12836) Resource leaks in EntitySQLProcessor.groovy
[ https://issues.apache.org/jira/browse/OFBIZ-12836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17750053#comment-17750053 ] ASF subversion and git services commented on OFBIZ-12836: - Commit c04d699dfc56f6b577c72469f0b18581b868d562 in ofbiz-framework's branch refs/heads/trunk from paul [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=c04d699dfc ] Fixed: Prevent resource leaks in EntitySQLProcessor.groovy (OFBIZ-12836) Use try-with-resources to ensure the SQLProcessor is always closed. > Resource leaks in EntitySQLProcessor.groovy > --- > > Key: OFBIZ-12836 > URL: https://issues.apache.org/jira/browse/OFBIZ-12836 > Project: OFBiz > Issue Type: Bug > Components: webtools >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Minor > Attachments: EntitySQLProcessor-1.groovy, > EntitySQLProcessor-2.groovy, EntitySQLProcessor-3.groovy, > EntitySQLProcessor-4.groovy, EntitySQLProcessor.groovy, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-1.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-2.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-3.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-4.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-5.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy.patch > > > In framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy at line > 35 > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L35] > > it creates an SQLProcessor. SQLProcessor has a Close method and implements > AutoCloseable, but we're not using try-with-resources, nor directly calling > the Close method. > > Similarly, > > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L38] > > obtains a java.sql.Resultset, which will be closed when everything works, but > would leak if there was an exception. Again, we should be using > try-with-resources. > > Note that according to > > [https://docs.oracle.com/en/java/javase/20/docs/api/java.sql/java/sql/ResultSet.html#close()] > > "Calling the method close on a ResultSet object that is already closed is a > no-op.", if you obtain a ResultSet from the SQLProcessor and directly close > that ResultSet, it's not a problem when the SQLProcessor.close also attempts > to close the ResultSet. > > The problem is minor, most of the time. The groovy script is in the webtools, > so used for developer tinkering and not production use. > > When you're doing a SELECT, the script is closing the ResultSet, so the > important resources are cleaned up (assuming no exception occurred). > > However, if you are doing INSERT, UPDATE or DELETE, the script creates a > prepared statement that is not closed, so there's a resource leak. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12836) Resource leaks in EntitySQLProcessor.groovy
[ https://issues.apache.org/jira/browse/OFBIZ-12836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17750052#comment-17750052 ] Paul Foxworthy commented on OFBIZ-12836: One more patch relative to Jacques' commit 663dd3d for OFBIZ-12813. > Resource leaks in EntitySQLProcessor.groovy > --- > > Key: OFBIZ-12836 > URL: https://issues.apache.org/jira/browse/OFBIZ-12836 > Project: OFBiz > Issue Type: Bug > Components: webtools >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Minor > Attachments: EntitySQLProcessor-1.groovy, > EntitySQLProcessor-2.groovy, EntitySQLProcessor-3.groovy, > EntitySQLProcessor-4.groovy, EntitySQLProcessor.groovy, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-1.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-2.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-3.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-4.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-5.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy.patch > > > In framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy at line > 35 > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L35] > > it creates an SQLProcessor. SQLProcessor has a Close method and implements > AutoCloseable, but we're not using try-with-resources, nor directly calling > the Close method. > > Similarly, > > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L38] > > obtains a java.sql.Resultset, which will be closed when everything works, but > would leak if there was an exception. Again, we should be using > try-with-resources. > > Note that according to > > [https://docs.oracle.com/en/java/javase/20/docs/api/java.sql/java/sql/ResultSet.html#close()] > > "Calling the method close on a ResultSet object that is already closed is a > no-op.", if you obtain a ResultSet from the SQLProcessor and directly close > that ResultSet, it's not a problem when the SQLProcessor.close also attempts > to close the ResultSet. > > The problem is minor, most of the time. The groovy script is in the webtools, > so used for developer tinkering and not production use. > > When you're doing a SELECT, the script is closing the ResultSet, so the > important resources are cleaned up (assuming no exception occurred). > > However, if you are doing INSERT, UPDATE or DELETE, the script creates a > prepared statement that is not closed, so there's a resource leak. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OFBIZ-12836) Resource leaks in EntitySQLProcessor.groovy
[ https://issues.apache.org/jira/browse/OFBIZ-12836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Foxworthy updated OFBIZ-12836: --- Attachment: Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-5.patch EntitySQLProcessor-4.groovy > Resource leaks in EntitySQLProcessor.groovy > --- > > Key: OFBIZ-12836 > URL: https://issues.apache.org/jira/browse/OFBIZ-12836 > Project: OFBiz > Issue Type: Bug > Components: webtools >Reporter: Paul Foxworthy >Assignee: Paul Foxworthy >Priority: Minor > Attachments: EntitySQLProcessor-1.groovy, > EntitySQLProcessor-2.groovy, EntitySQLProcessor-3.groovy, > EntitySQLProcessor-4.groovy, EntitySQLProcessor.groovy, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-1.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-2.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-3.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-4.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-5.patch, > Fixed__Resource_leaks_in_EntitySQLProcessor_groovy.patch > > > In framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy at line > 35 > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L35] > > it creates an SQLProcessor. SQLProcessor has a Close method and implements > AutoCloseable, but we're not using try-with-resources, nor directly calling > the Close method. > > Similarly, > > [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L38] > > obtains a java.sql.Resultset, which will be closed when everything works, but > would leak if there was an exception. Again, we should be using > try-with-resources. > > Note that according to > > [https://docs.oracle.com/en/java/javase/20/docs/api/java.sql/java/sql/ResultSet.html#close()] > > "Calling the method close on a ResultSet object that is already closed is a > no-op.", if you obtain a ResultSet from the SQLProcessor and directly close > that ResultSet, it's not a problem when the SQLProcessor.close also attempts > to close the ResultSet. > > The problem is minor, most of the time. The groovy script is in the webtools, > so used for developer tinkering and not production use. > > When you're doing a SELECT, the script is closing the ResultSet, so the > important resources are cleaned up (assuming no exception occurred). > > However, if you are doing INSERT, UPDATE or DELETE, the script creates a > prepared statement that is not closed, so there's a resource leak. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [ofbiz-framework]: Workflow run "Build and push docker images" is working again!
The GitHub Actions job "Build and push docker images" on ofbiz-framework.git has succeeded. Run started by GitHub user asfgit (triggered by asfgit). Head commit for run: 663dd3de82ff67cfbac02eb4cd84b39f14391b47 / Jacques Le Roux Improved: Refactor groovy folder structure and add package declaration (OFBIZ-12813) Codenarc changes, removes in *.groovy files "Blank line precedes package declaration in file FilterOutReceipts.groovy" "File *.groovy has consecutive blank lines" Updates build.gradle accordingly Report URL: https://github.com/apache/ofbiz-framework/actions/runs/5729199291 With regards, GitHub Actions via GitBox
[jira] [Commented] (OFBIZ-12813) Refactor groovy folder structure and add package declaration
[ https://issues.apache.org/jira/browse/OFBIZ-12813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749921#comment-17749921 ] ASF subversion and git services commented on OFBIZ-12813: - Commit 663dd3de82ff67cfbac02eb4cd84b39f14391b47 in ofbiz-framework's branch refs/heads/trunk from Jacques Le Roux [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=663dd3de82 ] Improved: Refactor groovy folder structure and add package declaration (OFBIZ-12813) Codenarc changes, removes in *.groovy files "Blank line precedes package declaration in file FilterOutReceipts.groovy" "File *.groovy has consecutive blank lines" Updates build.gradle accordingly > Refactor groovy folder structure and add package declaration > > > Key: OFBIZ-12813 > URL: https://issues.apache.org/jira/browse/OFBIZ-12813 > Project: OFBiz > Issue Type: Bug >Affects Versions: 22.01.01, Upcoming Branch >Reporter: Wiebke Paetzold >Assignee: Michael Brohl >Priority: Major > Fix For: Upcoming Branch > > > Due to the upgrade to jdk17 all groovy Classes need a package declaration. > To get a distinct package naming a consistent folder structure is needed. > 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. > This scheme should be applied everywhere. So a src folder contains main, > test, ... within these folders there is again a distinction between groovy > and java. > > For more information visit: > [http://groovy-lang.org/releasenotes/groovy-3.0.html#Groovy3.0releasenotes-Splitpackages] > “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.“ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12813) Refactor groovy folder structure and add package declaration
[ https://issues.apache.org/jira/browse/OFBIZ-12813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749920#comment-17749920 ] ASF subversion and git services commented on OFBIZ-12813: - Commit a1b2a08cff90d2af2f50fa898daada1ff0f0fbbb in ofbiz-plugins's branch refs/heads/trunk from Jacques Le Roux [ https://gitbox.apache.org/repos/asf?p=ofbiz-plugins.git;h=a1b2a08cf ] Improved: Refactor groovy folder structure and add package declaration (OFBIZ-12813) Codenarc changes, removes in *.groovy files "Blank line precedes package declaration in file FilterOutReceipts.groovy" "File *.groovy has consecutive blank lines" Updates build.gradle accordingly > Refactor groovy folder structure and add package declaration > > > Key: OFBIZ-12813 > URL: https://issues.apache.org/jira/browse/OFBIZ-12813 > Project: OFBiz > Issue Type: Bug >Affects Versions: 22.01.01, Upcoming Branch >Reporter: Wiebke Paetzold >Assignee: Michael Brohl >Priority: Major > Fix For: Upcoming Branch > > > Due to the upgrade to jdk17 all groovy Classes need a package declaration. > To get a distinct package naming a consistent folder structure is needed. > 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. > This scheme should be applied everywhere. So a src folder contains main, > test, ... within these folders there is again a distinction between groovy > and java. > > For more information visit: > [http://groovy-lang.org/releasenotes/groovy-3.0.html#Groovy3.0releasenotes-Splitpackages] > “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.“ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12813) Refactor groovy folder structure and add package declaration
[ https://issues.apache.org/jira/browse/OFBIZ-12813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749608#comment-17749608 ] ASF subversion and git services commented on OFBIZ-12813: - Commit 65ee57f7d5a52a62288a9be03f5baa8836d18e98 in ofbiz-plugins's branch refs/heads/trunk from Michael Brohl [ https://gitbox.apache.org/repos/asf?p=ofbiz-plugins.git;h=65ee57f7d ] Fixed: Renamed ProductsExportToEbay.groovy to ProductsExportToEbayScript.groovy (OFBIZ-12813) This was necessary after the groovy scripts refactoring to avoid duplicate classes. > Refactor groovy folder structure and add package declaration > > > Key: OFBIZ-12813 > URL: https://issues.apache.org/jira/browse/OFBIZ-12813 > Project: OFBiz > Issue Type: Bug >Affects Versions: 22.01.01, Upcoming Branch >Reporter: Wiebke Paetzold >Assignee: Michael Brohl >Priority: Major > Fix For: Upcoming Branch > > > Due to the upgrade to jdk17 all groovy Classes need a package declaration. > To get a distinct package naming a consistent folder structure is needed. > 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. > This scheme should be applied everywhere. So a src folder contains main, > test, ... within these folders there is again a distinction between groovy > and java. > > For more information visit: > [http://groovy-lang.org/releasenotes/groovy-3.0.html#Groovy3.0releasenotes-Splitpackages] > “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.“ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [ofbiz-plugins] sonarcloud[bot] commented on pull request #87: Fixed: Renamed ProductsExportToEbay.groovy to ProductsExportToEbayScript.groovy (OFBIZ-12813)
sonarcloud[bot] commented on PR #87: URL: https://github.com/apache/ofbiz-plugins/pull/87#issuecomment-1660018422 Kudos, SonarCloud Quality Gate passed! [](https://sonarcloud.io/dashboard?id=apache_ofbiz-plugins=87) [](https://sonarcloud.io/project/issues?id=apache_ofbiz-plugins=87=false=BUG) [](https://sonarcloud.io/project/issues?id=apache_ofbiz-plugins=87=false=BUG) [0 Bugs](https://sonarcloud.io/project/issues?id=apache_ofbiz-plugins=87=false=BUG) [](https://sonarcloud.io/project/issues?id=apache_ofbiz-plugins=87=false=VULNERABILITY) [](https://sonarcloud.io/project/issues?id=apache_ofbiz-plugins=87=false=VULNERABILITY) [0 Vulnerabilities](https://sonarcloud.io/project/issues?id=apache_ofbiz-plugins=87=false=VULNERABILITY) [](https://sonarcloud.io/project/security_hotspots?id=apache_ofbiz-plugins=87=false=SECURITY_HOTSPOT) [](https://sonarcloud.io/project/security_hotspots?id=apache_ofbiz-plugins=87=false=SECURITY_HOTSPOT) [0 Security Hotspots](https://sonarcloud.io/project/security_hotspots?id=apache_ofbiz-plugins=87=false=SECURITY_HOTSPOT) [](https://sonarcloud.io/project/issues?id=apache_ofbiz-plugins=87=false=CODE_SMELL) [](https://sonarcloud.io/project/issues?id=apache_ofbiz-plugins=87=false=CODE_SMELL) [0 Code Smells](https://sonarcloud.io/project/issues?id=apache_ofbiz-plugins=87=false=CODE_SMELL) [](https://sonarcloud.io/component_measures?id=apache_ofbiz-plugins=87) No Coverage information [](https://sonarcloud.io/component_measures?id=apache_ofbiz-plugins=87=new_duplicated_lines_density=list) [0.0% Duplication](https://sonarcloud.io/component_measures?id=apache_ofbiz-plugins=87=new_duplicated_lines_density=list) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@ofbiz.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [ofbiz-plugins] mbrohl merged pull request #87: Fixed: Renamed ProductsExportToEbay.groovy to ProductsExportToEbayScript.groovy (OFBIZ-12813)
mbrohl merged PR #87: URL: https://github.com/apache/ofbiz-plugins/pull/87 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@ofbiz.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [ofbiz-plugins] mbrohl opened a new pull request, #87: Fixed: Renamed ProductsExportToEbay.groovy to ProductsExportToEbayScript.groovy (OFBIZ-12813)
mbrohl opened a new pull request, #87: URL: https://github.com/apache/ofbiz-plugins/pull/87 This was necessary after the groovy scripts refactoring to avoid duplicate classes. Improved: Implemented: Documented: Completed: Reverted: Fixed: (OFBIZ-) Explanation Thanks: -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@ofbiz.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (OFBIZ-12813) Refactor groovy folder structure and add package declaration
[ https://issues.apache.org/jira/browse/OFBIZ-12813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749603#comment-17749603 ] Michael Brohl commented on OFBIZ-12813: --- There is a problem with a duplicate class now: ProductsExportToEbay exists as a Java class and Groovy class. I'll rename the Groovy File to ProductsExportToEbayScript.groovy like Wiebke did in the previous refactorings. > Refactor groovy folder structure and add package declaration > > > Key: OFBIZ-12813 > URL: https://issues.apache.org/jira/browse/OFBIZ-12813 > Project: OFBiz > Issue Type: Bug >Affects Versions: 22.01.01, Upcoming Branch >Reporter: Wiebke Paetzold >Assignee: Michael Brohl >Priority: Major > Fix For: Upcoming Branch > > > Due to the upgrade to jdk17 all groovy Classes need a package declaration. > To get a distinct package naming a consistent folder structure is needed. > 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. > This scheme should be applied everywhere. So a src folder contains main, > test, ... within these folders there is again a distinction between groovy > and java. > > For more information visit: > [http://groovy-lang.org/releasenotes/groovy-3.0.html#Groovy3.0releasenotes-Splitpackages] > “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.“ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [ofbiz-framework]: Workflow run "Build and push docker images" failed!
The GitHub Actions job "Build and push docker images" on ofbiz-framework.git has failed. Run started by GitHub user mbrohl (triggered by mbrohl). Head commit for run: 3e077e5f17b839d8cca88643e605975c2fc552c7 / Michael Brohl Fixed: Corrects groovy source folder location in build.gradle (OFBIZ-12813) Report URL: https://github.com/apache/ofbiz-framework/actions/runs/5724646734 With regards, GitHub Actions via GitBox
[jira] [Commented] (OFBIZ-12813) Refactor groovy folder structure and add package declaration
[ https://issues.apache.org/jira/browse/OFBIZ-12813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749574#comment-17749574 ] Michael Brohl commented on OFBIZ-12813: --- Everything is merged now. > Refactor groovy folder structure and add package declaration > > > Key: OFBIZ-12813 > URL: https://issues.apache.org/jira/browse/OFBIZ-12813 > Project: OFBiz > Issue Type: Bug >Affects Versions: 22.01.01, Upcoming Branch >Reporter: Wiebke Paetzold >Assignee: Michael Brohl >Priority: Major > Fix For: Upcoming Branch > > > Due to the upgrade to jdk17 all groovy Classes need a package declaration. > To get a distinct package naming a consistent folder structure is needed. > 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. > This scheme should be applied everywhere. So a src folder contains main, > test, ... within these folders there is again a distinction between groovy > and java. > > For more information visit: > [http://groovy-lang.org/releasenotes/groovy-3.0.html#Groovy3.0releasenotes-Splitpackages] > “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.“ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (OFBIZ-12813) Refactor groovy folder structure and add package declaration
[ https://issues.apache.org/jira/browse/OFBIZ-12813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749574#comment-17749574 ] Michael Brohl edited comment on OFBIZ-12813 at 8/1/23 8:51 AM: --- Everything is merged now. I think we can close this issue, right? was (Author: mbrohl): Everything is merged now. > Refactor groovy folder structure and add package declaration > > > Key: OFBIZ-12813 > URL: https://issues.apache.org/jira/browse/OFBIZ-12813 > Project: OFBiz > Issue Type: Bug >Affects Versions: 22.01.01, Upcoming Branch >Reporter: Wiebke Paetzold >Assignee: Michael Brohl >Priority: Major > Fix For: Upcoming Branch > > > Due to the upgrade to jdk17 all groovy Classes need a package declaration. > To get a distinct package naming a consistent folder structure is needed. > 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. > This scheme should be applied everywhere. So a src folder contains main, > test, ... within these folders there is again a distinction between groovy > and java. > > For more information visit: > [http://groovy-lang.org/releasenotes/groovy-3.0.html#Groovy3.0releasenotes-Splitpackages] > “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.“ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12813) Refactor groovy folder structure and add package declaration
[ https://issues.apache.org/jira/browse/OFBIZ-12813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749572#comment-17749572 ] ASF subversion and git services commented on OFBIZ-12813: - Commit 0bf579f8dd5bc5bb5fe4ee503df3279126a869db in ofbiz-plugins's branch refs/heads/trunk from Michael Brohl [ https://gitbox.apache.org/repos/asf?p=ofbiz-plugins.git;h=0bf579f8d ] Improved: Removes obsolete request entry (OFBIZ-12813) The references groovy script was not present anymore which lead to the untouched reference to groovyScripts. > Refactor groovy folder structure and add package declaration > > > Key: OFBIZ-12813 > URL: https://issues.apache.org/jira/browse/OFBIZ-12813 > Project: OFBiz > Issue Type: Bug >Affects Versions: 22.01.01, Upcoming Branch >Reporter: Wiebke Paetzold >Assignee: Michael Brohl >Priority: Major > Fix For: Upcoming Branch > > > Due to the upgrade to jdk17 all groovy Classes need a package declaration. > To get a distinct package naming a consistent folder structure is needed. > 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. > This scheme should be applied everywhere. So a src folder contains main, > test, ... within these folders there is again a distinction between groovy > and java. > > For more information visit: > [http://groovy-lang.org/releasenotes/groovy-3.0.html#Groovy3.0releasenotes-Splitpackages] > “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.“ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12813) Refactor groovy folder structure and add package declaration
[ https://issues.apache.org/jira/browse/OFBIZ-12813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749570#comment-17749570 ] ASF subversion and git services commented on OFBIZ-12813: - Commit 7a9e6aaa1e72069bfc236124e23eaa06f9cc4107 in ofbiz-plugins's branch refs/heads/trunk from Michael Brohl [ https://gitbox.apache.org/repos/asf?p=ofbiz-plugins.git;h=7a9e6aaa1 ] Improved: Refactoring groovy folder structure and package declaration (OFBIZ-12813) Moves groovy scripts to src and adds a package declaration to all of them. Work was done using automatic scripts from Wiebke Pätzold. LoadReactApp.groovy was handled manually because the license header was placed below some import statements. > Refactor groovy folder structure and add package declaration > > > Key: OFBIZ-12813 > URL: https://issues.apache.org/jira/browse/OFBIZ-12813 > Project: OFBiz > Issue Type: Bug >Affects Versions: 22.01.01, Upcoming Branch >Reporter: Wiebke Paetzold >Assignee: Michael Brohl >Priority: Major > Fix For: Upcoming Branch > > > Due to the upgrade to jdk17 all groovy Classes need a package declaration. > To get a distinct package naming a consistent folder structure is needed. > 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. > This scheme should be applied everywhere. So a src folder contains main, > test, ... within these folders there is again a distinction between groovy > and java. > > For more information visit: > [http://groovy-lang.org/releasenotes/groovy-3.0.html#Groovy3.0releasenotes-Splitpackages] > “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.“ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12813) Refactor groovy folder structure and add package declaration
[ https://issues.apache.org/jira/browse/OFBIZ-12813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749573#comment-17749573 ] ASF subversion and git services commented on OFBIZ-12813: - Commit 425b4560c2b4d19812b2d64d1721d72b5be21fc2 in ofbiz-plugins's branch refs/heads/trunk from Michael Brohl [ https://gitbox.apache.org/repos/asf?p=ofbiz-plugins.git;h=425b4560c ] Improved: Removes obsolete groovy script call (OFBIZ-12813) The referenced groovy script GetEmailOptions.groovy was not present anymore which lead to the untouched reference to groovyScripts. > Refactor groovy folder structure and add package declaration > > > Key: OFBIZ-12813 > URL: https://issues.apache.org/jira/browse/OFBIZ-12813 > Project: OFBiz > Issue Type: Bug >Affects Versions: 22.01.01, Upcoming Branch >Reporter: Wiebke Paetzold >Assignee: Michael Brohl >Priority: Major > Fix For: Upcoming Branch > > > Due to the upgrade to jdk17 all groovy Classes need a package declaration. > To get a distinct package naming a consistent folder structure is needed. > 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. > This scheme should be applied everywhere. So a src folder contains main, > test, ... within these folders there is again a distinction between groovy > and java. > > For more information visit: > [http://groovy-lang.org/releasenotes/groovy-3.0.html#Groovy3.0releasenotes-Splitpackages] > “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.“ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12813) Refactor groovy folder structure and add package declaration
[ https://issues.apache.org/jira/browse/OFBIZ-12813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749568#comment-17749568 ] ASF subversion and git services commented on OFBIZ-12813: - Commit 870f673e2c1e9a8e45ed48694a6f3f28b83bc5d6 in ofbiz-framework's branch refs/heads/trunk from Michael Brohl [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=870f673e2c ] Improved: Reword comment (OFBIZ-12813) > Refactor groovy folder structure and add package declaration > > > Key: OFBIZ-12813 > URL: https://issues.apache.org/jira/browse/OFBIZ-12813 > Project: OFBiz > Issue Type: Bug >Affects Versions: 22.01.01, Upcoming Branch >Reporter: Wiebke Paetzold >Assignee: Michael Brohl >Priority: Major > Fix For: Upcoming Branch > > > Due to the upgrade to jdk17 all groovy Classes need a package declaration. > To get a distinct package naming a consistent folder structure is needed. > 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. > This scheme should be applied everywhere. So a src folder contains main, > test, ... within these folders there is again a distinction between groovy > and java. > > For more information visit: > [http://groovy-lang.org/releasenotes/groovy-3.0.html#Groovy3.0releasenotes-Splitpackages] > “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.“ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12813) Refactor groovy folder structure and add package declaration
[ https://issues.apache.org/jira/browse/OFBIZ-12813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749571#comment-17749571 ] ASF subversion and git services commented on OFBIZ-12813: - Commit b7c7757b35a22529ca272ea690d82e755d2afa49 in ofbiz-plugins's branch refs/heads/trunk from Michael Brohl [ https://gitbox.apache.org/repos/asf?p=ofbiz-plugins.git;h=b7c7757b3 ] Improved: Changes script location for the moved CreateApplicationList.groovy (OFBIZ-12813) > Refactor groovy folder structure and add package declaration > > > Key: OFBIZ-12813 > URL: https://issues.apache.org/jira/browse/OFBIZ-12813 > Project: OFBiz > Issue Type: Bug >Affects Versions: 22.01.01, Upcoming Branch >Reporter: Wiebke Paetzold >Assignee: Michael Brohl >Priority: Major > Fix For: Upcoming Branch > > > Due to the upgrade to jdk17 all groovy Classes need a package declaration. > To get a distinct package naming a consistent folder structure is needed. > 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. > This scheme should be applied everywhere. So a src folder contains main, > test, ... within these folders there is again a distinction between groovy > and java. > > For more information visit: > [http://groovy-lang.org/releasenotes/groovy-3.0.html#Groovy3.0releasenotes-Splitpackages] > “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.“ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12813) Refactor groovy folder structure and add package declaration
[ https://issues.apache.org/jira/browse/OFBIZ-12813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749569#comment-17749569 ] ASF subversion and git services commented on OFBIZ-12813: - Commit 3e077e5f17b839d8cca88643e605975c2fc552c7 in ofbiz-framework's branch refs/heads/trunk from Michael Brohl [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=3e077e5f17 ] Fixed: Corrects groovy source folder location in build.gradle (OFBIZ-12813) > Refactor groovy folder structure and add package declaration > > > Key: OFBIZ-12813 > URL: https://issues.apache.org/jira/browse/OFBIZ-12813 > Project: OFBiz > Issue Type: Bug >Affects Versions: 22.01.01, Upcoming Branch >Reporter: Wiebke Paetzold >Assignee: Michael Brohl >Priority: Major > Fix For: Upcoming Branch > > > Due to the upgrade to jdk17 all groovy Classes need a package declaration. > To get a distinct package naming a consistent folder structure is needed. > 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. > This scheme should be applied everywhere. So a src folder contains main, > test, ... within these folders there is again a distinction between groovy > and java. > > For more information visit: > [http://groovy-lang.org/releasenotes/groovy-3.0.html#Groovy3.0releasenotes-Splitpackages] > “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.“ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12813) Refactor groovy folder structure and add package declaration
[ https://issues.apache.org/jira/browse/OFBIZ-12813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749566#comment-17749566 ] ASF subversion and git services commented on OFBIZ-12813: - Commit 12f69648418b3c63467e39c1a759ca6241e8094b in ofbiz-framework's branch refs/heads/trunk from Michael Brohl [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=12f6964841 ] Fixed: Corrects wrong groovy file reference (OFBIZ-12813) > Refactor groovy folder structure and add package declaration > > > Key: OFBIZ-12813 > URL: https://issues.apache.org/jira/browse/OFBIZ-12813 > Project: OFBiz > Issue Type: Bug >Affects Versions: 22.01.01, Upcoming Branch >Reporter: Wiebke Paetzold >Assignee: Michael Brohl >Priority: Major > Fix For: Upcoming Branch > > > Due to the upgrade to jdk17 all groovy Classes need a package declaration. > To get a distinct package naming a consistent folder structure is needed. > 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. > This scheme should be applied everywhere. So a src folder contains main, > test, ... within these folders there is again a distinction between groovy > and java. > > For more information visit: > [http://groovy-lang.org/releasenotes/groovy-3.0.html#Groovy3.0releasenotes-Splitpackages] > “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.“ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OFBIZ-12813) Refactor groovy folder structure and add package declaration
[ https://issues.apache.org/jira/browse/OFBIZ-12813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749567#comment-17749567 ] ASF subversion and git services commented on OFBIZ-12813: - Commit 88071b0eaf1d14db93c7b29d2a70bfb81d35ef38 in ofbiz-framework's branch refs/heads/trunk from Michael Brohl [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=88071b0eaf ] Fixed: Corrects path reference for groovy files (OFBIZ-12813) > Refactor groovy folder structure and add package declaration > > > Key: OFBIZ-12813 > URL: https://issues.apache.org/jira/browse/OFBIZ-12813 > Project: OFBiz > Issue Type: Bug >Affects Versions: 22.01.01, Upcoming Branch >Reporter: Wiebke Paetzold >Assignee: Michael Brohl >Priority: Major > Fix For: Upcoming Branch > > > Due to the upgrade to jdk17 all groovy Classes need a package declaration. > To get a distinct package naming a consistent folder structure is needed. > 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. > This scheme should be applied everywhere. So a src folder contains main, > test, ... within these folders there is again a distinction between groovy > and java. > > For more information visit: > [http://groovy-lang.org/releasenotes/groovy-3.0.html#Groovy3.0releasenotes-Splitpackages] > “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.“ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [ofbiz-framework] mbrohl merged pull request #665: Refactor groovy framework open issues (OFBIZ-12813)
mbrohl merged PR #665: URL: https://github.com/apache/ofbiz-framework/pull/665 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@ofbiz.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
