[GitHub] [commons-imaging] kinow merged pull request #270: Fix unit test
kinow merged PR #270: URL: https://github.com/apache/commons-imaging/pull/270 -- 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: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-imaging] codecov-commenter commented on pull request #270: Fix unit test
codecov-commenter commented on PR #270: URL: https://github.com/apache/commons-imaging/pull/270#issuecomment-1384546615 # [Codecov](https://codecov.io/gh/apache/commons-imaging/pull/270?src=pr=h1_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) Report > Merging [#270](https://codecov.io/gh/apache/commons-imaging/pull/270?src=pr=desc_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) (4d1d64b) into [master](https://codecov.io/gh/apache/commons-imaging/commit/72a9ccf52c81e7bb34cad09dc52160c03646fb04?el=desc_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) (72a9ccf) will **not change** coverage. > The diff coverage is `n/a`. ```diff @@Coverage Diff@@ ## master #270 +/- ## = Coverage 70.76% 70.76% Complexity 3368 3368 = Files 332 332 Lines 1693616936 Branches 2652 2652 = Hits 1198511985 Misses 3904 3904 Partials 1047 1047 ``` :mega: We’re building smart automated test selection to slash your CI/CD build times. [Learn more](https://about.codecov.io/iterative-testing/?utm_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) -- 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: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-imaging] kpouer opened a new pull request, #270: Fix unit test
kpouer opened a new pull request, #270: URL: https://github.com/apache/commons-imaging/pull/270 Fix two unit tests that were broken. PixelDensityRoundtrip was now writing data in a byte array instead of a tmp file, but was trying to read the tmp file anyway. And PngWriteForceTrueColorText that was writing a png into a file named .gif, but was unable to read it because the extension was checked and refused by png parser. -- 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: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (IMAGING-343) Apache Commons Imaging 0.97 - CVE-2018-17202
[
https://issues.apache.org/jira/browse/IMAGING-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17677506#comment-17677506
]
Gary D. Gregory commented on IMAGING-343:
-
0.97-incubator users should upgrade to commons-imaging-1.0-alpha1
> Apache Commons Imaging 0.97 - CVE-2018-17202
>
>
> Key: IMAGING-343
> URL: https://issues.apache.org/jira/browse/IMAGING-343
> Project: Commons Imaging
> Issue Type: Bug
>Affects Versions: 0.97
>Reporter: Nikhil
>Priority: Major
>
> Certain input files could make the code to enter into an infinite loop when
> Apache Sanselan 0.97-incubator was used to parse them, which could be used in
> a DoS attack. Note that Apache Sanselan (incubating) was renamed to Apache
> Commons Imaging.
>
> See [https://nvd.nist.gov/vuln/detail/CVE-2018-17202] for more details.
>
> There is Apache Commons Imaging 1.0-{*}alpha3{*} version available.. but we
> are trying to understand if a new *GA* will be made available and also to see
> if this specific CVE is addressed in the latest versions ?
>
> Please help
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IMAGING-343) Apache Commons Imaging 0.97 - CVE-2018-17202
[
https://issues.apache.org/jira/browse/IMAGING-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved IMAGING-343.
-
Fix Version/s: 1.0-alpha1
Resolution: Fixed
> Apache Commons Imaging 0.97 - CVE-2018-17202
>
>
> Key: IMAGING-343
> URL: https://issues.apache.org/jira/browse/IMAGING-343
> Project: Commons Imaging
> Issue Type: Bug
>Affects Versions: 0.97
>Reporter: Nikhil
>Priority: Major
> Fix For: 1.0-alpha1
>
>
> Certain input files could make the code to enter into an infinite loop when
> Apache Sanselan 0.97-incubator was used to parse them, which could be used in
> a DoS attack. Note that Apache Sanselan (incubating) was renamed to Apache
> Commons Imaging.
>
> See [https://nvd.nist.gov/vuln/detail/CVE-2018-17202] for more details.
>
> There is Apache Commons Imaging 1.0-{*}alpha3{*} version available.. but we
> are trying to understand if a new *GA* will be made available and also to see
> if this specific CVE is addressed in the latest versions ?
>
> Please help
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IMAGING-343) Apache Commons Imaging 0.97 - CVE-2018-17202
[
https://issues.apache.org/jira/browse/IMAGING-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17677506#comment-17677506
]
Gary D. Gregory edited comment on IMAGING-343 at 1/16/23 8:33 PM:
--
0.97-incubator users should upgrade to commons-imaging-1.0-alpha1 or later.
was (Author: garydgregory):
0.97-incubator users should upgrade to commons-imaging-1.0-alpha1
> Apache Commons Imaging 0.97 - CVE-2018-17202
>
>
> Key: IMAGING-343
> URL: https://issues.apache.org/jira/browse/IMAGING-343
> Project: Commons Imaging
> Issue Type: Bug
>Affects Versions: 0.97
>Reporter: Nikhil
>Priority: Major
>
> Certain input files could make the code to enter into an infinite loop when
> Apache Sanselan 0.97-incubator was used to parse them, which could be used in
> a DoS attack. Note that Apache Sanselan (incubating) was renamed to Apache
> Commons Imaging.
>
> See [https://nvd.nist.gov/vuln/detail/CVE-2018-17202] for more details.
>
> There is Apache Commons Imaging 1.0-{*}alpha3{*} version available.. but we
> are trying to understand if a new *GA* will be made available and also to see
> if this specific CVE is addressed in the latest versions ?
>
> Please help
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (FILEUPLOAD-309) Release version 2.0.0
[ https://issues.apache.org/jira/browse/FILEUPLOAD-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17677499#comment-17677499 ] Steve Lopez edited comment on FILEUPLOAD-309 at 1/16/23 7:40 PM: - Thank you Jochen for the reply. I went ahead and just refactored our code to use Servlet 3.1 spec and remove the need for this. As a an observation it seems like there aren’t standards for how OS projected are handling this Jakarta thing. Another library we use added a jakarta tag to their existing version whereas another just bumped the major version up to 2.0 (which is what I mistakenly thought the Apache commons library did as well) was (Author: steve.rc): Thank you Jochen for the replay. I went ahead and just refactored our code to use Servlet 3.1 spec and remove the need for this. As a an observation it seems like there aren’t standards for how OS projected are handling this Jakarta thing. Another library we use added a jakarta tag to their existing version whereas another just bumped the major version up to 2.0 (which is what I mistakenly thought the Apache commons library did as well) > Release version 2.0.0 > - > > Key: FILEUPLOAD-309 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-309 > Project: Commons FileUpload > Issue Type: Wish >Reporter: Thiago Henrique Hupner >Priority: Major > > At Piranha, we've migrated to use the new Jakarta namespace. > One of our dependencies is the Commons File Upload, but the latest version > available is 1.4. > Looking around at the source code, I've found that the code is already > prepared for the new Jakarta namespace. > So, I want to know if there's a plan to release a new version soon. Or at > least a 2.0.0 milestone. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FILEUPLOAD-309) Release version 2.0.0
[ https://issues.apache.org/jira/browse/FILEUPLOAD-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17677499#comment-17677499 ] Steve Lopez commented on FILEUPLOAD-309: Thank you Jochen for the replay. I went ahead and just refactored our code to use Servlet 3.1 spec and remove the need for this. As a an observation it seems like there aren’t standards for how OS projected are handling this Jakarta thing. Another library we use added a jakarta tag to their existing version whereas another just bumped the major version up to 2.0 (which is what I mistakenly thought the Apache commons library did as well) > Release version 2.0.0 > - > > Key: FILEUPLOAD-309 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-309 > Project: Commons FileUpload > Issue Type: Wish >Reporter: Thiago Henrique Hupner >Priority: Major > > At Piranha, we've migrated to use the new Jakarta namespace. > One of our dependencies is the Commons File Upload, but the latest version > available is 1.4. > Looking around at the source code, I've found that the code is already > prepared for the new Jakarta namespace. > So, I want to know if there's a plan to release a new version soon. Or at > least a 2.0.0 milestone. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [commons-release-plugin] garydgregory merged pull request #168: Bump maven.plugin.version from 3.7.0 to 3.7.1
garydgregory merged PR #168: URL: https://github.com/apache/commons-release-plugin/pull/168 -- 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: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-release-plugin] dependabot[bot] opened a new pull request, #168: Bump maven.plugin.version from 3.7.0 to 3.7.1
dependabot[bot] opened a new pull request, #168: URL: https://github.com/apache/commons-release-plugin/pull/168 Bumps `maven.plugin.version` from 3.7.0 to 3.7.1. Updates `maven-plugin-annotations` from 3.7.0 to 3.7.1 Release notes Sourced from https://github.com/apache/maven-plugin-tools/releases;>maven-plugin-annotations's releases. 3.7.1 Commits https://github.com/apache/maven-plugin-tools/commit/52afb9ff7129912a1ff2d02c42487dc3a33f8364;>52afb9f [maven-release-plugin] prepare release maven-plugin-tools-3.7.1 https://github.com/apache/maven-plugin-tools/commit/73065a1ba216235150b832edad4b43ad3207e3ce;>73065a1 Set version to 3.7.1-SNAPSHOT https://github.com/apache/maven-plugin-tools/commit/17aabccca1590f01925db9f63f04a67bd0a4c2f1;>17aabcc [MPLUGIN-452] Maven scope and module name logs at wrong level (https://github-redirect.dependabot.com/apache/maven-plugin-tools/issues/190;>#190) See full diff in https://github.com/apache/maven-plugin-tools/compare/maven-plugin-tools-3.7.0...maven-plugin-tools-3.7.1;>compare view Updates `maven-plugin-tools-ant` from 3.7.0 to 3.7.1 Updates `maven-plugin-plugin` from 3.7.0 to 3.7.1 Release notes Sourced from https://github.com/apache/maven-plugin-tools/releases;>maven-plugin-plugin's releases. 3.7.1 Commits https://github.com/apache/maven-plugin-tools/commit/52afb9ff7129912a1ff2d02c42487dc3a33f8364;>52afb9f [maven-release-plugin] prepare release maven-plugin-tools-3.7.1 https://github.com/apache/maven-plugin-tools/commit/73065a1ba216235150b832edad4b43ad3207e3ce;>73065a1 Set version to 3.7.1-SNAPSHOT https://github.com/apache/maven-plugin-tools/commit/17aabccca1590f01925db9f63f04a67bd0a4c2f1;>17aabcc [MPLUGIN-452] Maven scope and module name logs at wrong level (https://github-redirect.dependabot.com/apache/maven-plugin-tools/issues/190;>#190) See full diff in https://github.com/apache/maven-plugin-tools/compare/maven-plugin-tools-3.7.0...maven-plugin-tools-3.7.1;>compare view Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- 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: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-validator] garydgregory commented on pull request #29: Add Getters for IBANValidator's RegexValidator its patterns
garydgregory commented on PR #29: URL: https://github.com/apache/commons-validator/pull/29#issuecomment-1384317132 @arnaudfnr Done in git master, with a defensive copy of the pattern array. -- 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: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-validator] garydgregory closed pull request #29: Add Getters for IBANValidator's RegexValidator its patterns
garydgregory closed pull request #29: Add Getters for IBANValidator's RegexValidator its patterns URL: https://github.com/apache/commons-validator/pull/29 -- 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: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-validator] garydgregory closed pull request #115: add IBAN Validator for Djibouti DJ as listed in iban-registry.pdf ...
garydgregory closed pull request #115: add IBAN Validator for Djibouti DJ as listed in iban-registry.pdf ... URL: https://github.com/apache/commons-validator/pull/115 -- 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: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-validator] garydgregory commented on pull request #115: add IBAN Validator for Djibouti DJ as listed in iban-registry.pdf ...
garydgregory commented on PR #115: URL: https://github.com/apache/commons-validator/pull/115#issuecomment-1384298175 Done in git master with another PR. -- 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: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Resolved] (VALIDATOR-486) the IBAN validator does not support all the IBAN supported countries
[ https://issues.apache.org/jira/browse/VALIDATOR-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved VALIDATOR-486. --- Fix Version/s: 1.8 Resolution: Fixed > the IBAN validator does not support all the IBAN supported countries > > > Key: VALIDATOR-486 > URL: https://issues.apache.org/jira/browse/VALIDATOR-486 > Project: Commons Validator > Issue Type: Bug >Affects Versions: 1.7 >Reporter: Nicola Gioia >Priority: Major > Fix For: 1.8 > > > the list of supported countries for iban miss the following countries: > |Burundi|BI| > |Djibouti|DJ| > |Libya|LY| > |Russia|RU| > |Sudan|SD| -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [commons-validator] garydgregory merged pull request #88: Adding new countries to IBAN list
garydgregory merged PR #88: URL: https://github.com/apache/commons-validator/pull/88 -- 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: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-validator] codecov-commenter commented on pull request #115: add IBAN Validator for Djibouti DJ as listed in iban-registry.pdf ...
codecov-commenter commented on PR #115: URL: https://github.com/apache/commons-validator/pull/115#issuecomment-1384292310 # [Codecov](https://codecov.io/gh/apache/commons-validator/pull/115?src=pr=h1_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) Report > Merging [#115](https://codecov.io/gh/apache/commons-validator/pull/115?src=pr=desc_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) (10957a9) into [master](https://codecov.io/gh/apache/commons-validator/commit/012651d8f7956238011ebaa8c955acb9bbd2280d?el=desc_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) (012651d) will **not change** coverage. > The diff coverage is `n/a`. ```diff @@Coverage Diff@@ ## master #115 +/- ## = Coverage 71.90% 71.90% Complexity 1137 1137 = Files63 63 Lines 3157 3157 Branches542 542 = Hits 2270 2270 Misses 693 693 Partials194 194 ``` | [Impacted Files](https://codecov.io/gh/apache/commons-validator/pull/115?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) | Coverage Δ | | |---|---|---| | [...ache/commons/validator/routines/IBANValidator.java](https://codecov.io/gh/apache/commons-validator/pull/115?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL21haW4vamF2YS9vcmcvYXBhY2hlL2NvbW1vbnMvdmFsaWRhdG9yL3JvdXRpbmVzL0lCQU5WYWxpZGF0b3IuamF2YQ==) | `80.48% <ø> (ø)` | | :mega: We’re building smart automated test selection to slash your CI/CD build times. [Learn more](https://about.codecov.io/iterative-testing/?utm_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) -- 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: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-validator] homebeaver opened a new pull request, #115: add IBAN Validator for Djibouti DJ as listed in iban-registry.pdf ...
homebeaver opened a new pull request, #115: URL: https://github.com/apache/commons-validator/pull/115 ... Release 92 – May 2022 see https://issues.apache.org/jira/browse/VALIDATOR-486 Hi @garydgregory this is the validator for DJ regards EUGen -- 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: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-validator] garydgregory commented on pull request #88: Adding new countries to IBAN list
garydgregory commented on PR #88: URL: https://github.com/apache/commons-validator/pull/88#issuecomment-1384288061 @tatiana-scda FYI, I resolved the conflict. -- 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: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (VALIDATOR-486) the IBAN validator does not support all the IBAN supported countries
[ https://issues.apache.org/jira/browse/VALIDATOR-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17677458#comment-17677458 ] Eugen Hanussek commented on VALIDATOR-486: -- No, I'm not confused. This is my personal decision, because I am involved. Please respect it. > the IBAN validator does not support all the IBAN supported countries > > > Key: VALIDATOR-486 > URL: https://issues.apache.org/jira/browse/VALIDATOR-486 > Project: Commons Validator > Issue Type: Bug >Affects Versions: 1.7 >Reporter: Nicola Gioia >Priority: Major > > the list of supported countries for iban miss the following countries: > |Burundi|BI| > |Djibouti|DJ| > |Libya|LY| > |Russia|RU| > |Sudan|SD| -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (VALIDATOR-486) the IBAN validator does not support all the IBAN supported countries
[ https://issues.apache.org/jira/browse/VALIDATOR-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17677451#comment-17677451 ] Gary D. Gregory commented on VALIDATOR-486: --- bq. By the way: what about the pull requests https://github.com/apache/commons-validator/pull/60 and https://github.com/apache/commons-validator/pull/61 ? This ticket is about IBAN, let's not mix up topics bq. Not for RU because of the sanctions! You must be confused. Are you referring to a law that prevents this component from implementing ISO 13616? > the IBAN validator does not support all the IBAN supported countries > > > Key: VALIDATOR-486 > URL: https://issues.apache.org/jira/browse/VALIDATOR-486 > Project: Commons Validator > Issue Type: Bug >Affects Versions: 1.7 >Reporter: Nicola Gioia >Priority: Major > > the list of supported countries for iban miss the following countries: > |Burundi|BI| > |Djibouti|DJ| > |Libya|LY| > |Russia|RU| > |Sudan|SD| -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (VALIDATOR-486) the IBAN validator does not support all the IBAN supported countries
[ https://issues.apache.org/jira/browse/VALIDATOR-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17677438#comment-17677438 ] Eugen Hanussek commented on VALIDATOR-486: -- Hi [~ggregory] - I will provide IBAN Validator for DJ. In Release 92 – May 2022 of iban-registry.pdf DJ is listed. Not for RU because of the sanctions! By the way: what about the pull requests [https://github.com/apache/commons-validator/pull/60] and [https://github.com/apache/commons-validator/pull/61] ? Regards EUGen > the IBAN validator does not support all the IBAN supported countries > > > Key: VALIDATOR-486 > URL: https://issues.apache.org/jira/browse/VALIDATOR-486 > Project: Commons Validator > Issue Type: Bug >Affects Versions: 1.7 >Reporter: Nicola Gioia >Priority: Major > > the list of supported countries for iban miss the following countries: > |Burundi|BI| > |Djibouti|DJ| > |Libya|LY| > |Russia|RU| > |Sudan|SD| -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (FILEUPLOAD-309) Release version 2.0.0
[ https://issues.apache.org/jira/browse/FILEUPLOAD-309 ] Flying Wolf deleted comment on FILEUPLOAD-309: was (Author: flyingwolf): [~joc...@apache.org] The current big problem with FileUpload, where is issue is about, is this: At 10 September 2019 the "Java Servlet" api was renamed to "Jakarta Servlet", starting from version 4.0.3. At 9 October 2020, with the release of Jakarta Servlet 5.0, the API moved from package `javax.servlet` to `jakarta.servlet`. This package change has big consequences when a project (such as Wicket) wants to update its old Servlet dependency to the new Jakarta Servlet 5.0 API package (jakarta.servlet), but the project (Wicket) also depends on a project (FileUpload) that is still using the old package (javax.servlet). This causes the project (Wicket) to be unable to update to a new Servlet version. If Wicket would stick to the old Java Servlet version that FileUpload automatically and unknowingly is enforcing to projects since 9 October 2020, then this also causes other dependency problems for Wicket. For example, Spring Framework 6 also moved from Java Servlet to Jakarta Servlet. Because FileUpload is enforcing other projects to stay with the old Java Servlet spec, other projects (such as Wicket) won't be able to update to Spring Framework 6. This will become an ever bigger issue when Spring Framework 5 gets end-of-life in 2024. Then projects are forced to use outdated insecure Spring version, or they have to fully drop the usage of FileUpload. So FileUpload is enforcing projects to use an old Servlet spec, which causes major problems for these projects to be able to update important dependencies (Jakarta Servlet and Spring Framework). Whereas the solution in FileUpload to solve this big problem, is really simple: FileUpload only needs to update it dependency (javax.servlet:servlet-api:2.4 provided dependency) to a Jakarta Servlet depedency (for example jakarta.servlet:jakarta.servlet-api:6.0.0). Which means changing some simple import statements from "javax.servlet" to "jakarta.servlet". This simple fix would help projects that depend on FileUpload, a lot. > Release version 2.0.0 > - > > Key: FILEUPLOAD-309 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-309 > Project: Commons FileUpload > Issue Type: Wish >Reporter: Thiago Henrique Hupner >Priority: Major > > At Piranha, we've migrated to use the new Jakarta namespace. > One of our dependencies is the Commons File Upload, but the latest version > available is 1.4. > Looking around at the source code, I've found that the code is already > prepared for the new Jakarta namespace. > So, I want to know if there's a plan to release a new version soon. Or at > least a 2.0.0 milestone. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (COMPRESS-638) The GzipCompressorOutputStream#writeHeader method uses the ISO_8859_1 to write the file name. If the file name contains non-ISO_8859_1 characters, some unknown chara
[
https://issues.apache.org/jira/browse/COMPRESS-638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17677398#comment-17677398
]
Gary D. Gregory commented on COMPRESS-638:
--
Note: I added
{{org.apache.commons.compress.compressors.gzip.GzipCompressorOutputStreamTest}}.
I don't think we can do anything that will be interoperable with all of the
gzip utilities out in the world.
Even if we convert non-ISO-8859-1-encodable file names to _something_ that _we_
can convert back ourselves, that will look odd elsewhere.
For example, we could encode "测试中文名称.xml"/"Test Chinese name.xml" to
"\u6D4B\u8BD5\u4E2D\u6587\u540D\u79F0.xml"
> The GzipCompressorOutputStream#writeHeader method uses the ISO_8859_1 to
> write the file name. If the file name contains non-ISO_8859_1 characters,
> some unknown characters are displayed after decompression.
> --
>
> Key: COMPRESS-638
> URL: https://issues.apache.org/jira/browse/COMPRESS-638
> Project: Commons Compress
> Issue Type: Bug
>Reporter: Radar wen
>Priority: Major
> Attachments: 0110.png
>
>
> The GzipCompressorOutputStream#writeHeader method uses the ISO_8859_1 to
> write the file name.
> If the file name contains non-ISO_8859_1 characters, some unknown characters
> are displayed after decompression. !0110.png!
> Can change the ISO_8859_1 to UTF-8?
> if (filename != null) {
> out.write(filename.getBytes(ISO_8859_1));
> out.write(0);
> }
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [commons-parent] garydgregory merged pull request #207: Bump maven-surefire-plugin from 3.0.0-M7 to 3.0.0-M8
garydgregory merged PR #207: URL: https://github.com/apache/commons-parent/pull/207 -- 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: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (VALIDATOR-486) the IBAN validator does not support all the IBAN supported countries
[ https://issues.apache.org/jira/browse/VALIDATOR-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17677349#comment-17677349 ] Gary D. Gregory commented on VALIDATOR-486: --- PR 67 has been merged. There is still no support for DJ and RU. > the IBAN validator does not support all the IBAN supported countries > > > Key: VALIDATOR-486 > URL: https://issues.apache.org/jira/browse/VALIDATOR-486 > Project: Commons Validator > Issue Type: Bug >Affects Versions: 1.7 >Reporter: Nicola Gioia >Priority: Major > > the list of supported countries for iban miss the following countries: > |Burundi|BI| > |Djibouti|DJ| > |Libya|LY| > |Russia|RU| > |Sudan|SD| -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (FILEUPLOAD-309) Release version 2.0.0
[ https://issues.apache.org/jira/browse/FILEUPLOAD-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17677337#comment-17677337 ] Flying Wolf edited comment on FILEUPLOAD-309 at 1/16/23 11:53 AM: -- [~joc...@apache.org] The current big problem with FileUpload, where is issue is about, is this: At 10 September 2019 the "Java Servlet" api was renamed to "Jakarta Servlet", starting from version 4.0.3. At 9 October 2020, with the release of Jakarta Servlet 5.0, the API moved from package `javax.servlet` to `jakarta.servlet`. This package change has big consequences when a project (such as Wicket) wants to update its old Servlet dependency to the new Jakarta Servlet 5.0 API package (jakarta.servlet), but the project (Wicket) also depends on a project (FileUpload) that is still using the old package (javax.servlet). This causes the project (Wicket) to be unable to update to a new Servlet version. If Wicket would stick to the old Java Servlet version that FileUpload automatically and unknowingly is enforcing to projects since 9 October 2020, then this also causes other dependency problems for Wicket. For example, Spring Framework 6 also moved from Java Servlet to Jakarta Servlet. Because FileUpload is enforcing other projects to stay with the old Java Servlet spec, other projects (such as Wicket) won't be able to update to Spring Framework 6. This will become an ever bigger issue when Spring Framework 5 gets end-of-life in 2024. Then projects are forced to use outdated insecure Spring version, or they have to fully drop the usage of FileUpload. So FileUpload is enforcing projects to use an old Servlet spec, which causes major problems for these projects to be able to update important dependencies (Jakarta Servlet and Spring Framework). Whereas the solution in FileUpload to solve this big problem, is really simple: FileUpload only needs to update it dependency (javax.servlet:servlet-api:2.4 provided dependency) to a Jakarta Servlet depedency (for example jakarta.servlet:jakarta.servlet-api:6.0.0). Which means changing some simple import statements from "javax.servlet" to "jakarta.servlet". This simple fix would help projects that depend on FileUpload, a lot. was (Author: flyingwolf): [~joc...@apache.org] The current big problem with FileUpload, where is issue is about, is this: At 10 September 2019 the "Java Servlet" api was renamed to "Jakarta Servlet", starting from version 4.0.3. At 9 October 2020, with the release of Jakarta Servlet 5.0, the API moved from package `javax.servlet` to `jakarta.servlet`. This package change has big consequences when a project (such as Wicket) wants to update its old Servlet dependency to the new Jakarta Servlet 5.0 API package (jakarta.servlet), but the project (Wicket) also depends on a project (FileUpload) that is still using the old package (javax.servlet). This causes the project (Wicket) to be unable to update to a new Servlet version. If Wicket would stick to the old Java Servlet version that FileUpload automatically and unknowingly is enforcing to projects since 10 September 2019, then this also causes other dependency problems for Wicket. For example, Spring Framework 6 also moved from Java Servlet to Jakarta Servlet. Because FileUpload is enforcing other projects to stay with the old Java Servlet spec, other projects (such as Wicket) won't be able to update to Spring Framework 6. This will become an ever bigger issue when Spring Framework 5 gets end-of-life in 2024. Then projects are forced to use outdated insecure Spring version, or they have to fully drop the usage of FileUpload. So FileUpload is enforcing projects to use an old Servlet spec, which causes major problems for these projects to be able to update important dependencies (Jakarta Servlet and Spring Framework). Whereas the solution in FileUpload to solve this big problem, is really simple: FileUpload only needs to update it dependency (javax.servlet:servlet-api:2.4 provided dependency) to a Jakarta Servlet depedency (for example jakarta.servlet:jakarta.servlet-api:6.0.0). Which means changing some simple import statements from "javax.servlet" to "jakarta.servlet". This simple fix would help projects that depend on FileUpload, a lot. > Release version 2.0.0 > - > > Key: FILEUPLOAD-309 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-309 > Project: Commons FileUpload > Issue Type: Wish >Reporter: Thiago Henrique Hupner >Priority: Major > > At Piranha, we've migrated to use the new Jakarta namespace. > One of our dependencies is the Commons File Upload, but the latest version > available is 1.4. > Looking around at the source code, I've found that the code is already > prepared for the new Jakarta namespace. > So, I want to know if there's a plan to release
[jira] [Comment Edited] (FILEUPLOAD-309) Release version 2.0.0
[ https://issues.apache.org/jira/browse/FILEUPLOAD-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17677337#comment-17677337 ] Flying Wolf edited comment on FILEUPLOAD-309 at 1/16/23 11:52 AM: -- [~joc...@apache.org] The current big problem with FileUpload, where is issue is about, is this: At 10 September 2019 the "Java Servlet" api was renamed to "Jakarta Servlet", starting from version 4.0.3. At 9 October 2020, with the release of Jakarta Servlet 5.0, the API moved from package `javax.servlet` to `jakarta.servlet`. This package change has big consequences when a project (such as Wicket) wants to update its old Servlet dependency to the new Jakarta Servlet 5.0 API package (jakarta.servlet), but the project (Wicket) also depends on a project (FileUpload) that is still using the old package (javax.servlet). This causes the project (Wicket) to be unable to update to a new Servlet version. If Wicket would stick to the old Java Servlet version that FileUpload automatically and unknowingly is enforcing to projects since 10 September 2019, then this also causes other dependency problems for Wicket. For example, Spring Framework 6 also moved from Java Servlet to Jakarta Servlet. Because FileUpload is enforcing other projects to stay with the old Java Servlet spec, other projects (such as Wicket) won't be able to update to Spring Framework 6. This will become an ever bigger issue when Spring Framework 5 gets end-of-life in 2024. Then projects are forced to use outdated insecure Spring version, or they have to fully drop the usage of FileUpload. So FileUpload is enforcing projects to use an old Servlet spec, which causes major problems for these projects to be able to update important dependencies (Jakarta Servlet and Spring Framework). Whereas the solution in FileUpload to solve this big problem, is really simple: FileUpload only needs to update it dependency (javax.servlet:servlet-api:2.4 provided dependency) to a Jakarta Servlet depedency (for example jakarta.servlet:jakarta.servlet-api:6.0.0). Which means changing some simple import statements from "javax.servlet" to "jakarta.servlet". This simple fix would help projects that depend on FileUpload, a lot. was (Author: flyingwolf): [~joc...@apache.org] The current big problem with FileUpload is this: At 10 September 2019 the "Java Servlet" api was renamed to "Jakarta Servlet", starting from version 4.0.3. At 9 October 2020, with the release of Jakarta Servlet 5.0, the API moved from package `javax.servlet` to `jakarta.servlet`. This package change has big consequences when a project (such as Wicket) wants to update its old Servlet dependency to the new Jakarta Servlet 5.0 API package (jakarta.servlet), but the project (Wicket) also depends on a project (FileUpload) that is still using the old package (javax.servlet). This causes the project (Wicket) to be unable to update to a new Servlet version. If Wicket would stick to the old Java Servlet version that FileUpload automatically and unknowingly is enforcing to projects since 10 September 2019, then this also causes other dependency problems for Wicket. For example, Spring Framework 6 also moved from Java Servlet to Jakarta Servlet. Because FileUpload is enforcing other projects to stay with the old Java Servlet spec, other projects (such as Wicket) won't be able to update to Spring Framework 6. This will become an ever bigger issue when Spring Framework 5 gets end-of-life in 2024. Then projects are forced to use outdated insecure Spring version, or they have to fully drop the usage of FileUpload. So FileUpload is enforcing projects to use an old Servlet spec, which causes major problems for these projects to be able to update important dependencies (Jakarta Servlet and Spring Framework). Whereas the solution in FileUpload to solve this big problem, is really simple: FileUpload only needs to update it dependency (javax.servlet:servlet-api:2.4 provided dependency) to a Jakarta Servlet depedency (for example jakarta.servlet:jakarta.servlet-api:6.0.0). Which means changing some simple import statements from "javax.servlet" to "jakarta.servlet". This simple fix would help projects that depend on FileUpload, a lot. > Release version 2.0.0 > - > > Key: FILEUPLOAD-309 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-309 > Project: Commons FileUpload > Issue Type: Wish >Reporter: Thiago Henrique Hupner >Priority: Major > > At Piranha, we've migrated to use the new Jakarta namespace. > One of our dependencies is the Commons File Upload, but the latest version > available is 1.4. > Looking around at the source code, I've found that the code is already > prepared for the new Jakarta namespace. > So, I want to know if there's a plan to release a new version soon. Or
[jira] [Commented] (FILEUPLOAD-309) Release version 2.0.0
[ https://issues.apache.org/jira/browse/FILEUPLOAD-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17677337#comment-17677337 ] Flying Wolf commented on FILEUPLOAD-309: [~joc...@apache.org] The current big problem with FileUpload is this: At 10 September 2019 the "Java Servlet" api was renamed to "Jakarta Servlet", starting from version 4.0.3. At 9 October 2020, with the release of Jakarta Servlet 5.0, the API moved from package `javax.servlet` to `jakarta.servlet`. This package change has big consequences when a project (such as Wicket) wants to update its old Servlet dependency to the new Jakarta Servlet 5.0 API package (jakarta.servlet), but the project (Wicket) also depends on a project (FileUpload) that is still using the old package (javax.servlet). This causes the project (Wicket) to be unable to update to a new Servlet version. If Wicket would stick to the old Java Servlet version that FileUpload automatically and unknowingly is enforcing to projects since 10 September 2019, then this also causes other dependency problems for Wicket. For example, Spring Framework 6 also moved from Java Servlet to Jakarta Servlet. Because FileUpload is enforcing other projects to stay with the old Java Servlet spec, other projects (such as Wicket) won't be able to update to Spring Framework 6. This will become an ever bigger issue when Spring Framework 5 gets end-of-life in 2024. Then projects are forced to use outdated insecure Spring version, or they have to fully drop the usage of FileUpload. So FileUpload is enforcing projects to use an old Servlet spec, which causes major problems for these projects to be able to update important dependencies (Jakarta Servlet and Spring Framework). Whereas the solution in FileUpload to solve this big problem, is really simple: FileUpload only needs to update it dependency (javax.servlet:servlet-api:2.4 provided dependency) to a Jakarta Servlet depedency (for example jakarta.servlet:jakarta.servlet-api:6.0.0). Which means changing some simple import statements from "javax.servlet" to "jakarta.servlet". This simple fix would help projects that depend on FileUpload, a lot. > Release version 2.0.0 > - > > Key: FILEUPLOAD-309 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-309 > Project: Commons FileUpload > Issue Type: Wish >Reporter: Thiago Henrique Hupner >Priority: Major > > At Piranha, we've migrated to use the new Jakarta namespace. > One of our dependencies is the Commons File Upload, but the latest version > available is 1.4. > Looking around at the source code, I've found that the code is already > prepared for the new Jakarta namespace. > So, I want to know if there's a plan to release a new version soon. Or at > least a 2.0.0 milestone. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FILEUPLOAD-309) Release version 2.0.0
[ https://issues.apache.org/jira/browse/FILEUPLOAD-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17677289#comment-17677289 ] Jeff Thomas commented on FILEUPLOAD-309: ..and in addition to "voting" for a release, I was agreeing with Andy's comment that the javax namespace maybe should be replaced with the jakarta namespace instead of providing alternate code. :) > Release version 2.0.0 > - > > Key: FILEUPLOAD-309 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-309 > Project: Commons FileUpload > Issue Type: Wish >Reporter: Thiago Henrique Hupner >Priority: Major > > At Piranha, we've migrated to use the new Jakarta namespace. > One of our dependencies is the Commons File Upload, but the latest version > available is 1.4. > Looking around at the source code, I've found that the code is already > prepared for the new Jakarta namespace. > So, I want to know if there's a plan to release a new version soon. Or at > least a 2.0.0 milestone. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [commons-net] mawiesne commented on a diff in pull request #141: Fixes many grammar issues and typos in JavaDoc and code comments
mawiesne commented on code in PR #141:
URL: https://github.com/apache/commons-net/pull/141#discussion_r1070935486
##
src/main/java/org/apache/commons/net/ftp/parser/UnixFTPEntryParser.java:
##
@@ -110,7 +110,7 @@ public class UnixFTPEntryParser extends
ConfigurableFTPFileEntryParserImpl {
/**
* The default constructor for a UnixFTPEntryParser object.
*
- * @throws IllegalArgumentException Thrown if the regular expression is
unparseable. Should not be seen under normal conditions. It it is seen, this is
a
+ * @throws IllegalArgumentException Thrown if the regular expression is
unparseable. Should not be seen under normal conditions. If it is seen, this is
a
Review Comment:
I replaced "it" with "this exception" and left "seen" as is.
--
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: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
