Re: [VOTE] Release Apache Commons Compress 1.26.1 based on RC1

2024-03-06 Thread Melloware Inc 
+1 (non-binding)

I only checked it out and tested it locally with our application.

On Tue, Mar 5, 2024 at 5:43 PM Gary Gregory  wrote:

> We have fixed a few bugs and added some enhancements since Apache
> Commons Compress 1.26.0 was released, so I would like to release
> Apache Commons Compress 1.26.1.
>
> Apache Commons Compress 1.26.1 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/compress/1.26.1-RC1
> (svn revision 67751)
>
> The Git tag commons-compress-1.26.1-RC1 commit for this RC is
> 81ac94151eedc61c2131239362a051e30c5e9e59 which you can browse here:
>
> https://gitbox.apache.org/repos/asf?p=commons-compress.git;a=commit;h=81ac94151eedc61c2131239362a051e30c5e9e59
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-compress.git
> --branch
> 
> commons-compress-1.26.1-RC1 commons-compress-1.26.1-RC1
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1700/org/apache/commons/commons-compress/1.26.1/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Tue Mar 05 22:24:25 UTC 2024
> Apache\ Commons\
>
> Compress-1.26.1.spdx.rdf.xml=7dd9d7ad576dea9611f87acd8b047f4b0f9701730a7cdcc62a3800b04f3ef7aa889e80c7df2a1636aa44f8fd58462c5bf3b19dc2c0004490009faef1ac2301b9
>
> commons-compress-1.26.1-bin.tar.gz=56325ec491bc5e6d8c37742d5f44869a9668f8359d5243cf8628dfb06f223bc3c1133239185295df4a98f8503f32f7609cecdbe24cc0f15fdd34a577bab0d7b9
>
> commons-compress-1.26.1-bin.zip=217838bad31682bb29b4f5eafad2ec5bf767a0c417fec2f16e84e2a6af7ed8fb44a34ad81c382a88155f0688988c58b85280411cf00a0f7022ccd89e83fbd3b5
>
> commons-compress-1.26.1-bom.json=9ddb2350681af3e6378e7fa5c35ae2916b07dc429adb25b96a07a72b095fa0db81e59904aaab4b6c48856ab9c77c64dadd414d652b1b0aa8e22494354f3937b7
>
> commons-compress-1.26.1-bom.xml=0fcaa44fd3393be32cfdf37e8678554a4fb9bfae90a6ab20975ef48493df6a7cab7fc79ac1c821e538daa18ecfe4d29c0f9aa27ccff63dbcfe3d588dd26e5d91
>
> commons-compress-1.26.1-javadoc.jar=5de00b4eedc3e9f9343c165b11d23e3a0d42c3681890707888af5c3257e15c1d3af35c1bb924c4b86fa8ce5398116b4eb61aeb32fec3181a339857fd305c934d
>
> commons-compress-1.26.1-sources.jar=65cbf8d1db3c150f76c5c4afec5f874253a18d89df7afff24ad93097507ddb52edaf47829863f4a0f561d547879c52c75a7bd590476e6911b6614000a0eaa58d
>
> commons-compress-1.26.1-src.tar.gz=096c94344a9bbcd021a3cce0869456cf6d22ca5136b63de017922d7c3de5d94b591961fe550201b654f9dc90b2cd8f32ef9bf1e507fddfb2e2f7c33bddc790c4
>
> commons-compress-1.26.1-src.zip=69387bd46fe25b5b046819d41804f3b9c867b598a2d408e1131f34ba33ccf3589cce07ef3f360da5c60a5b455e7084aca3a0722ab75de67279babf5fa7c65280
>
> commons-compress-1.26.1-test-sources.jar=08d2729412759a5e2c3a07619e807b67ac57dc29bdd69d24114dfc467e1ca2589837150db18195510d19accb1604b8c77987e85bb1787dfec3be441b0980c54c
>
> commons-compress-1.26.1-tests.jar=d2af16e04a0d5f8c1de0d23c1c4b035ebf20598bb6c9c1f7ea5858605804a35bb7b70b0e8f42bf735303d916f9fe1d2292b36838ca8912e2d70f89ec88261da4
>
> I have tested this with:
>
> mvn
>
> and
>
> mvn -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site deploy
>
> using:
>
> openjdk version "21.0.2" 2024-01-16
> OpenJDK Runtime Environment Homebrew (build 21.0.2)
> OpenJDK 64-Bit Server VM Homebrew (build 21.0.2, mixed mode, sharing)
>
> Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
> Maven home: /usr/local/Cellar/maven/3.9.6/libexec
> Java version: 21.0.2, vendor: Homebrew, runtime:
> /usr/local/Cellar/openjdk/21.0.2/libexec/openjdk.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "14.3.1", arch: "x86_64", family: "mac"
>
> Darwin  23.3.0 Darwin Kernel Version 23.3.0: Wed Dec 20 21:28:58
> PST 2023; root:xnu-10002.81.5~7/RELEASE_X86_64 x86_64
>
> Details of changes since 1.26.0 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/compress/1.26.1-RC1/RELEASE-NOTES.txt
>
> https://dist.apache.org/repos/dist/dev/commons/compress/1.26.1-RC1/site/changes-report.html
>
> Site:
>
> https://dist.apache.org/repos/dist/dev/commons/compress/1.26.1-RC1/site/index.html
> (note some *relative* links are broken and the 1.26.1 directories
> are not yet created - these will be OK once the site is deployed.)
>
> JApiCmp Report (compared to 1.26.0):
>
> https://dist.apache.org/repos/dist/dev/commons/compress/1.26.1-RC1/site/japicmp.html
>
> RAT Report:
>
> https://dist.apache.org/repos/dist/dev/commons/compress/1.26.1-RC1/site/rat-report.html
>
> KEYS:
>   https://downloads.apache.org/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will close no sooner than 72 hours from now.
>
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
>
> Thank you,
>
> Gary Gregory,
> Release Manager (using key 86fdc7e2a11262cb)
>
> For following is

Re: [all] SBOM Generation

2022-07-17 Thread Melloware Inc 
Matt,

I am a member of a few other open source Java libs and I am interested in what 
you come up with to follow your lead and add SBOM to them as well. The more 
pervasive we can make it the better for the whole Java ecosystem overall!

Melloware
@melloware on GitHub

> On Jul 17, 2022, at 12:16 PM, Matt Juntunen  wrote:
> 
> Sounds good. I've moved the discussion to the
> security-disc...@community.apache.org mailist list [1].
> 
> Regards,
> Matt J
> 
> [1] https://lists.apache.org/thread/l8661o0t1r8498bhy01wdwg1s2kkhogy
> 
>> On Sun, Jul 17, 2022 at 11:11 AM Gary Gregory  wrote:
>> 
>>> On Sun, Jul 17, 2022 at 11:00 AM sebb  wrote:
>>> 
>>> On Sun, 17 Jul 2022 at 15:45, Matt Juntunen  
>>> wrote:
 
 Hello all,
 
 Steve Springett recently created a PR [1] for commons-parent that
 introduces the generation of software bill of materials (SBOM)
 artifacts into the build process. First of all, thank you, Steve.
 Secondly, I believe this is an important topic that should be
 addressed by our community. SBOMs contain metadata that can be used in
 application security contexts and software supply chain analysis. They
 seem to be becoming increasingly important as the software industry
 places a greater emphasis on cybersecurity. I have a small amount of
 experience with these types of files from my day job. My team will
 soon begin generating them for all of our projects in order to allow
 automated tools to better track CVEs and report to our customers on
 the security of our applications. The questions I believe we need to
 answer as a community are:
 
 1. Do we want to include SBOMs in our Maven build artifacts?
 2. If so, what format do we want to use?
 
 In regard to the first question, I believe that we would need a good
 reason to *not* include these (or similar) artifacts. It's a simple
 service we can provide to help our users maintain good cybersecurity
 practices. As the provider of a number of hugely popular open-source
 libraries, I would love to see us take the lead on ensuring the
 security of the Java ecosystem.
 
 For question two, there are a few SBOM standards out there, notably
 SPDX [2] and CycloneDX [3] (which is what Steve included in his PR). I
 am not well versed in the exact differences between the formats, but
 CycloneDX seems to have better Java support and a large number of
 useful tools, such as the Maven plugin used in Steve's PR.
 
 If we can agree on answers to the two questions above, then we can
 move forward and start discussing details. Thank you all for your
 time.
>>> 
>>> SBOMs presumably apply to all ASF software, so it seems to me it would
>>> be sensible to address this at ASF level.
>>> It would be silly for each project to generate the data differently,
>>> even if only slightly.
>>> Once a format is settled upon, I would expect it to be implemented via
>>> the Apache POM, rather than by every Maven Java project.
>>> 
>>> I think the mailing list for this is probably
>>> security-disc...@community.apache.org:
>>> https://lists.apache.org/list.html?security-disc...@community.apache.org
>> 
>> I agree with Sebb.
>> 
>> Note that the CycloneDX plugin does not work correctly for
>> multi-module Maven projects. See the PR for my results.
>> 
>> Gary
>> 
>>> 
 Regards,
 Matt J
 
 [1] https://github.com/apache/commons-parent/pull/122
 [2] https://spdx.dev/
 [3] https://cyclonedx.org/
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org
 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [beanutils]

2022-04-20 Thread Melloware Inc 
Matt, 

I totally agree.  I asked over and over for almost a year for a release. 

 I understand the contributors are busy. I was submitting PRs that were not 
getting reviewed and merged.   I have a client that had 2 concerns…the security 
findings and the fact it still used commons collections 3 instead of 4. 

I literally tried everything to get this Jar released you can look back through 
the mailing list.  So I finally resorted to “I have no choice but to release 
this myself”.

 I absolutely did NOT want to. But what else is the community to do when an 
open source library goes 5+ years between releases???

Melloware
@melloware on GitHub

> On Apr 20, 2022, at 8:09 PM, Matt Sicker  wrote:
> 
> I don’t see why that couldn’t have been done here. There’s no need to fork 
> Commons projects when they’re fairly open to contributors.
> 
> —
> Matt Sicker
> 
>> On Apr 20, 2022, at 16:19, Melloware Inc  wrote:
>> 
>> It was supposed to be temporary until Apache released 2.0.  It’s been over 
>> 5 years since last beanutils release so it’s a good thing I did in my 
>> opinion.  
>> 
>> Melloware
>> @melloware on GitHub
>> 
>>>> On Apr 20, 2022, at 3:31 PM, Gary Gregory  wrote:
>>> 
>>> You are crearting jar hell by reusing the Apache package names under
>>> different Maven coordinates. Not a good idea IMO.
>>> 
>>> Gary
>>> 
>>>>> On Wed, Apr 20, 2022, 15:27 Melloware  wrote:
>>>> 
>>>> I did not the package names are the same I did this because I had
>>>> multiple clients complaining about Commons Beantutils 1.9.4 security
>>>> vulnerabilities and needed a public version of the code so it could be
>>>> scanned.  Whenever the REAL BeanUtils2 is ever released to Maven Central
>>>> my clients can simply change their pom.xml back to org.apache versions
>>>> and they are a drop in.
>>>> 
>>>> 
>>>>> On 4/20/2022 2:26 PM, sebb wrote:
>>>>> On Wed, 20 Apr 2022 at 18:54, Melloware  wrote:
>>>>>> And and I have forked it and deployed to Maven Central
>>>>>> 
>>>>>> 
>>>>>>  com.melloware
>>>>>>  commons-beanutils2
>>>>>>  2.0.0
>>>>>> 
>>>>>> 
>>>>> Did you change the package names?
>>>>> 
>>>>> If not, there will be problems in the future if a project depends on
>>>>> both via different dependencies.
>>>>> 
>>>>>> On 4/20/2022 10:12 AM, Xeno Amess wrote:
>>>>>>> Well I wonder should we give melloware (https://github.com/melloware)
>>>> a
>>>>>>> committer permission.
>>>>>>> 
>>>>>>> Since:
>>>>>>> 
>>>>>>> 1. he has quite some experience here, not a fresh hand.
>>>>>>> 
>>>>>>> 2. he has ability to write/review good codes.(already several thousands
>>>>>>> lines in common-beanutils).
>>>>>>> 
>>>>>>> 3. he has enough time and interest to refine beanutils. (This is the
>>>> most
>>>>>>> important, as it seems no committers want to develop beanutils...)
>>>>>>> 
>>>>>>> Any thoughts?
>>>>>>> 
>>>>>>> Gary Gregory  于2022年4月20日周三 21:00写道：
>>>>>>> 
>>>>>>>> There isn't one; we are all volunteers here ;-)
>>>>>>>> 
>>>>>>>> There is probably clean up to do, PRs, Jiras, releasing and synching
>>>> with
>>>>>>>> Commons Collections 4.5 first (probably).
>>>>>>>> 
>>>>>>>> Gary
>>>>>>>> 
>>>>>>>> On Wed, Apr 20, 2022, 07:21 Martin Aldrin
>>>>>>>>  wrote:
>>>>>>>> 
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>>>> I wonder what the time plan for release of beanutils2 is.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> /Martin
>>>>>>>>> 
>>>>>> -
>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>> 
>>>>> -
>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>> 
>>>> 
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>> 
>>>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [beanutils]

2022-04-20 Thread Melloware Inc 
It was supposed to be temporary until Apache released 2.0.  It’s been over 5 
years since last beanutils release so it’s a good thing I did in my opinion.  

Melloware
@melloware on GitHub

> On Apr 20, 2022, at 3:31 PM, Gary Gregory  wrote:
> 
> You are crearting jar hell by reusing the Apache package names under
> different Maven coordinates. Not a good idea IMO.
> 
> Gary
> 
>> On Wed, Apr 20, 2022, 15:27 Melloware  wrote:
>> 
>> I did not the package names are the same I did this because I had
>> multiple clients complaining about Commons Beantutils 1.9.4 security
>> vulnerabilities and needed a public version of the code so it could be
>> scanned.  Whenever the REAL BeanUtils2 is ever released to Maven Central
>> my clients can simply change their pom.xml back to org.apache versions
>> and they are a drop in.
>> 
>> 
>>> On 4/20/2022 2:26 PM, sebb wrote:
>>> On Wed, 20 Apr 2022 at 18:54, Melloware  wrote:
 And and I have forked it and deployed to Maven Central
 
 
com.melloware
commons-beanutils2
2.0.0
 
 
>>> Did you change the package names?
>>> 
>>> If not, there will be problems in the future if a project depends on
>>> both via different dependencies.
>>> 
 On 4/20/2022 10:12 AM, Xeno Amess wrote:
> Well I wonder should we give melloware (https://github.com/melloware)
>> a
> committer permission.
> 
> Since:
> 
> 1. he has quite some experience here, not a fresh hand.
> 
> 2. he has ability to write/review good codes.(already several thousands
> lines in common-beanutils).
> 
> 3. he has enough time and interest to refine beanutils. (This is the
>> most
> important, as it seems no committers want to develop beanutils...)
> 
> Any thoughts?
> 
> Gary Gregory  于2022年4月20日周三 21:00写道：
> 
>> There isn't one; we are all volunteers here ;-)
>> 
>> There is probably clean up to do, PRs, Jiras, releasing and synching
>> with
>> Commons Collections 4.5 first (probably).
>> 
>> Gary
>> 
>> On Wed, Apr 20, 2022, 07:21 Martin Aldrin
>>  wrote:
>> 
>>> Hi,
>>> 
>>> I wonder what the time plan for release of beanutils2 is.
>>> 
>>> 
>>> /Martin
>>> 
 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org
 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
>> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [fileupload] jakarta versus javax?

2022-03-30 Thread Melloware Inc 
With PrimeFaces we use a special plug-in for Shade that builds a second jar 
that renames javax to Jakarta everywhere and in maven central it adds the 
Jakarta classifier to the jar so we can have both javax and Jakarta versions 
built from the same code base. 

See:  https://github.com/primefaces/primefaces

Melloware
@melloware on GitHub

> On Mar 30, 2022, at 5:50 PM, John Patrick  wrote:
> 
> That would probably need to be a major release as it would break backwards
> compatibility for other consumers.
> I don't know the roadmap for fileupload but I would suggest raising a jira
> ticket for this new feature request.
> 
> Looking at Tomcat 10.x it appears to be Servlet 5.0 specification which is
> either Jakarta EE 9 or Jakarta EE 9.1.
> Then looking at Jakarta EE 9 release in 2020-12-08, that did the breaking
> change from javax. to jakarta.
> 
> I think this type of issue will happen more as I don't think all Apache
> Commons are at Java 1.8, but once they support Java 9 or new and they can
> support Multi Jar Releases it will be easier to support newer Java LTS
> like, 11 and 17. Then in 15 months we get Java 21 which i understand is the
> new 2 year LTS release schedule instead of the 3 year release schedule.
> 
> Cheers,
> John
> 
> 
>> On Wed, 30 Mar 2022 at 21:33, Mark Foley  wrote:
>> 
>> Just now joining this list. I've installed Tomcat 10.0.17 which uses the
>> jakarta class, not javax. FileUpload 1.4 (the most recent as far as I
>> can tell) uses javax. Is FileUpload schedule for a new version using
>> jakarta?
>> 
>> Thanks --Mark

Re: GitHub license display confused by LICENSE-header.txt

2021-03-08 Thread Melloware Inc 
In commons beanutils we recommend using /src/conf for these type of files. 

Sent from my iPhone

> On Mar 8, 2021, at 8:13 PM, sebb  wrote:
> 
> On Tue, 9 Mar 2021 at 01:08, Bernd Eckenfels  wrote:
>> 
>> Checkstyle-header.txt sounds good and maybe also moving it to a subdir like 
>> src/build/ or src/test/?
> 
> There are other checkstyle files at the top-level; best to keep them together.
> 
>> Gruss
>> Bernd
>> 
>> 
>> --
>> http://bernd.eckenfels.net
>> 
>> Von: sebb 
>> Gesendet: Tuesday, March 9, 2021 1:41:02 AM
>> An: CommonsDev 
>> Betreff: GitHub license display confused by LICENSE-header.txt
>> 
>> Most of the Commons projects show up in GitHub as having the Apache 2.0 
>> License
>> 
>> However a few show up as 'other':
>> 
>> commons-codec
>> commons-csv
>> commons-dbutils
>> commons-exec
>> commons-jelly
>> commons-logging
>> commons-math
>> commons-rdf
>> commons-text
>> commons-weaver
>> 
>> AFAICT this is because there is more than 1 LICENSE file at the top level:
>> I forked codec and deleted the LICENSE-header.txt file, and the
>> license then showed up as AL 2.0.
>> 
>> I think it's not only GitHub that might be confused by such files, so
>> I suggest they are moved or renamed to avoid the confusion. They are
>> only needed for Checkstyle, so perhaps could be named accordingly,
>> e.g. checkstyle-header.txt
>> 
>> [Obviously there would need to be corresponding changes in the pom and
>> assembly files]
>> 
>> WDYT?
>> 
>> Sebb.
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [NET] org.apache.commons.net.SocketClient and Closeable

2020-09-08 Thread Melloware Inc 
I agree that would be expected behavior and allow it to work in try with 
resources. 

Sent from my iPhone

> On Sep 8, 2020, at 7:33 PM, Gary Gregory  wrote:
> 
> Hi All,
> 
> It seems to me that org.apache.commons.net.SocketClient should
> implement Closeable where close() can be implemented as calling
> disconnect().
> 
> WDYT?
> 
> Gary
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [All][Geometry] Commit log (Was: [GitHub] ...)

2020-07-05 Thread Melloware Inc 
Here is an excellent blog post summarizing what makes good commit messages:

https://chris.beams.io/posts/git-commit/



On Sun, Jul 5, 2020 at 7:38 AM Matt Juntunen 
wrote:

> Yes, I should have modified that commit message to indicate that the
> change was warranted.
> -Matt
> 
> From: Gilles Sadowski 
> Sent: Sunday, July 5, 2020 4:00 AM
> To: Commons Developers List 
> Subject: [All][Geometry] Commit log (Was: [GitHub] ...)
>
> Hello.
>
> I'd like to collect some opinions about enforcing a minimal form in
> commit messages.
> My preference is that a log message is either
>  * terse, when the commit is trivial (e.g. "Javadoc" or "Unused
> variable"), or
>  * detailed but factual, if the change is not obvious.
>
> IMHO, a commit message should rarely (if ever)
> * contain redundant words (such as "fix"),
> * be a plain rewording of a trivial change (rather that the purpose of
> the change),
> * make the reviewer second-guess whether the change is warranted.
>
> Informal and uninformative/noisy messages might seem the new normal on
> GitHub but does that mean that we pass on them in our projects?
>
> Regards,
> Gilles
>
> Le sam. 4 juil. 2020 à 13:48, GitBox  a écrit :
> >
> >
> > darkma773r commented on pull request #88:
> > URL:
> https://github.com/apache/commons-geometry/pull/88#issuecomment-653756040
> >
> >
> >Merged in commit 6c90e34ff11fb9fa279d9b060abf70c14ce3cd2a
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

-- 
==
Melloware
melloware...@gmail.com
http://melloware.com
==

Re: [test] Bug in StringSubstitutor?

2020-07-01 Thread Melloware Inc 


Gary,

I agree with you it’s a bug. I would not expect that behavior from that method. 

Mello 

> On Jun 30, 2020, at 8:25 PM, Gary Gregory  wrote:
> 
> Hi All:
> 
> I think we might have a bug in StringSubstitutor exemplified in a comment I
> just added in:
> 
> org.apache.commons.text.StringSubstitutorTest.testReplaceWeirdPattens()
> 
>doTestNoReplace("${");
>// TODO this looks like a bug since a $ is removed but this is not
> a variable.
>// doTestNoReplace("$${");
>// doTestNoReplace("$${a");
>// doTestNoReplace("$$${");
>// doTestNoReplace("$$${a");
> 
> I thought that we would only strip $ in front of a _complete_ variable, not
> anywhere in front of a variable _prefix_.
> 
> Granted this is an edge case but still...
> 
> Any thoughts?
> 
> Gary

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [io] can we delete release 20030203.000550 in maven central?

2020-06-14 Thread Melloware Inc 
Gary,

Maven Central Search does not. Se ethos URL:
https://search.maven.org/search?q=g:commons-io

Commons-IO 20030203.000550 is shown as the latest version incorrectly.

Mello

On Sun, Jun 14, 2020 at 10:29 AM Gary Gregory 
wrote:

> I'm not sure what you are using, but Maven Central sorts by release date:
> https://search.maven.org/artifact/commons-io/commons-io
>
> Gary
>
> On Sun, Jun 14, 2020 at 9:56 AM Xeno Amess  wrote:
>
> > It is strange to have an older version have a larger major version number
> > than a newer version.
> > Of course we might never witness a major version whose number be
> 1000+
> > in our life, but...
> > That just feels strange.
> >
> >
> > Gary Gregory  于2020年6月14日周日 下午9:52写道：
> >
> > > On Sun, Jun 14, 2020 at 9:51 AM Xeno Amess 
> wrote:
> > >
> > > > Or if we should create commons-io2  and commons-BeanUtils2 like what
> > > > we've done in lang3, as @John Patrick  suggested?
> > > >
> > >
> > > Why?
> > >
> > > Gary
> > >
> > >
> > > >
> > > > Gary Gregory  于2020年6月14日周日 下午9:39写道：
> > > >
> > > > > On Sun, Jun 14, 2020 at 6:40 AM Xeno Amess 
> > > wrote:
> > > > >
> > > > > > every time my update tool chain thinks 20030203.000550 is a
> greater
> > > > > version
> > > > > > than 2.7 (actually it is, if see it in number).
> > > > > > So have we some way to delete it from maven central? (or rename
> > it?)
> > > > > >
> > > > >
> > > > > Yes, but we will never do that. That would break applications
> > depending
> > > > on
> > > > > that version. There are rare cases where releases may be withdrawn.
> > > > >
> > > > > Gary
> > > > >
> > > > >
> > > > > > The same problem happened in BeanUtils, version 20030211.134440
> > > > > >
> > > > >
> > > >
> > >
> >
>


-- 
==
Melloware
melloware...@gmail.com
http://melloware.com
==

[beanutils2] CVE-2014-0114 Pull Request

2019-05-23 Thread Melloware Inc 
Hey All!,

First time contributor here.  My company has a corporate goal to only use
open source libraries with NO open Security CVE's marked as critical.

BeanUtils has CVE-2014-0114 marked as critical so I opened a ticket:
https://issues.apache.org/jira/browse/BEANUTILS-520

I submitted my first Apache Commons PR which addresses the issue which I
was hoping I could get code reviewed and hopefully merged.  I followed all
guidelines and included a specific unit test to prove the issue and the fix.

Pull Request:  https://github.com/apache/commons-beanutils/pull/7

I really feel like this is an important fix to have security on by default
and still allow the ability to opt-out and make it backwards compatible.  I
hope the Apache community feels the same way!

Thanks,
Melloware