Re: [beanutils] Towards 1.10
Rob, I 100% agree since CVE-2014-0114 has been fixed in BeanUtils I think we need a release. However the 1.X branch seems dormant it seems for the last 3 years everything has been working on is BeanUtils2 which is where all the fixes have been made? Mello - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [beanutils] Towards 1.10
Do you think we could also get a BeanUtils2 release while we are at it? It supports Java 8 and has many fixes in the last 3 years. On 6/5/2019 8:37 AM, Rob Tompkins wrote: I can try to backport the fix to the 1.X branch. -Rob On 6/5/2019 8:09 AM, Melloware wrote: Rob, I 100% agree since CVE-2014-0114 has been fixed in BeanUtils I think we need a release. However the 1.X branch seems dormant it seems for the last 3 years everything has been working on is BeanUtils2 which is where all the fixes have been made? Mello - 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] Towards 2.0?
+1 from me - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [beanutils] Towards 2.0?
+1 as in I think the library is ready to go "as is" for 2.0 release. It's a feature rich stable library. It has always had the Commons Collections stuff in there but if you feel the need to rip it out then rip it out. If not then I would just release the 2.0 version of the library. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [beanutils] Towards 2.0?
Gary, I misunderstood I apologize. I see you are saying convert anywhere we are using Commons Collections with JDK8 native calls then yes I would definitely support that. Let me see if I can take a crack at it and submit a PR. Melloware - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [releases,dbutils] There are 4 staged copies of dbutils-1.8
Carl, It seems like there is just not enough PMC committers available for Commons projects. It should not take 4 months for you to get a release of DButils out. I have been trying to get Commons BeanUtils2 pushed for release for the last year. I know they are all volunteers and I appreciate their time, it just doesn't seem like there is enough PMC Committers to support all these Commons projects. Just my 2 cents... Melloware - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [CSV] Features that commons-csv nees to do
Chen, As with all open source you should submit your PR's on Github with good unit tests and then let the community review! Mello On 5/28/2020 10:28 AM, Chen wrote: Hi, gary Are there any features that commons-csv need to do? I'd like to implement them. If not, and I sorted out the issue list of commons-csv. I found two problems which are empty string columns or null value columns problem and obtaining raw data problem. The two problems occur mote times. I plan to write code to implement them. what is your opinion. empty string columns or null value columns: [CSV-254]https://issues.apache.org/jira/projects/CSV/issues/CSV-254?filter=allopenissues [CSV-253] https://issues.apache.org/jira/projects/CSV/issues/CSV-253?filter=allopenissues [CSV-93]https://issues.apache.org/jira/projects/CSV/issues/CSV-93?filter=allopenissues obtaining raw data: [CSV-50]https://issues.apache.org/jira/projects/CSV/issues/CSV-50?filter=allopenissues [CSV-151]https://issues.apache.org/jira/projects/CSV/issues/CSV-151?filter=allopenissues [CSV-196]https://issues.apache.org/jira/projects/CSV/issues/CSV-196?filter=allopenissues Best regards Chen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Commons Crypto AArch64 support
If you look through the mailing list for May 2020 you can see the Commons Crypto guys are asking for help to get it released. See: http://mail-archives.apache.org/mod_mbox/commons-dev/202005.mbox/%3CCACiFetSzYCPuSnEHr%2BHtwPfayqL4V36VziSCEVbwHqiJOWcDcw%40mail.gmail.com%3E On 5/28/2020 1:55 AM, ODI DEV wrote: Hi Team, Currently, Commons Crypto 1.0.0 jar available in the Maven repository does not have AArch64 support. Can you please release the jar for Commons Crypto 1.1.0 with AArch64 support? I have done cross/native compilation and tested the artifacts as well. If required I can help you with the same. Can you please share your opinion on adding AArch64 support and open to accept the changes? Thanks, Odidev - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Validator] Project dead?
And to add to that BeanUtils2 removed Commons Collection as a dependency entirely so whenever BeanUtils2 is released it can then be added to Validator as well. On 6/4/2020 2:21 PM, sebb wrote: On Thu, 4 Jun 2020 at 17:19, TvT wrote: yeah but more like a zombie ;-) But my mentioned issue 458 is a duplicate of https://issues.apache.org/jira/projects/VALIDATOR/issues/VALIDATOR-437 and already solved in 1.7 So the question remains when can we expect 1.7 AFAICT, that particular issue can be solved without needing a new release. It should be enough to adjust your pom. Also, unless you are actually using the parts of Validator that need beanutils, you should be able to remove the beanutils jar entirely. However it obviously would be good to get a new release out. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DRAFT] Board report this period
Looks good! On 6/10/2020 8:57 AM, Gary Gregory wrote: Hi All: This is the board report I plan to submit for this reporting period: ## Description: The mission of Apache Commons is the creation and maintenance of Java focused reusable libraries and components ## Issues: There are no issues requiring board attention. ## Membership Data: Apache Commons was founded 2007-06-19 (13 years ago) There are currently 150 committers and 38 PMC members in this project. The Committer-to-PMC ratio is roughly 5:2. Community changes, past quarter: - No new PMC members. Last addition was Alex Herbert on 2019-05-09. - Peter Lee was added as committer on 2020-03-13 ## Project Activity: We have released the following Apache Commons Components this reporting period: - BCEL-6.5.0 was released on 2020-06-08. - IO-2.7 was released on 2020-05-28. - NUMBERS-1.0-beta1 was released on 2020-04-08. - LANG-3.10 was released on 2020-03-27. - CONFIGURATION-2.7 was released on 2020-03-11. ## Community Health: We have a significant uptick in activity on the mailing lists and GitHub. Gary, you PMC chair. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Text] do we have number to word converter ?
On 6/30/2020 4:02 PM, sebb wrote: I think this is out of scope for Commons. Agreed this feels like a good Stack Overflow post that people can then take and modify for their own language or needs. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] Thoughts on build system maven -> gradle??
I agree with Gary. I know its been decided but I thought I would add my -1. Technology better have a compelling reason to switch and in the past we have had: Ant -> Maven was a big leap for convention over configuration and dependency management SVN -> GIT was a big leap for the handling of branches/merging and collaboration. Maven -> Gradle the only reason I constantly hear is its less verbose. Well Maven's verbosity is not a problem for me and switching to Groovy doesn't seem worth the leap. Just my two cents! Mello On 7/17/2020 9:01 AM, Gary Gregory wrote: Hi Rob, Even though I am on the minus side, I am glad you brought this up for discussion. I think it helped us better understand where we are, how we got here, and why we want to stay. Gary - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: A release train...
Commons BeanUtils2 Which we can then upgrade Commons Config to use BeanUtils2. On 7/18/2020 9:00 AM, Gary Gregory wrote: Hi All, We've just released Commons Lang 3.11. My goal is to release Text very soon. When Phil is done with his work on Pool, release Pool, then DBCP. I also want to look at Crypto again where building the different binaries is a challenge but I think I am getting close. There is also CSV that is probably ready or close to ready for a release. Gary - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all]should we really allow denpabot upgrade a dependency that changes major version?
Gary, I am a huge +1 on this feature for all those reasons. Nice work! Mello On 7/22/2020 11:34 AM, Gary Gregory wrote: Hi, There is no telling what any version change means to any library generically. We can only assume that some people follow semver and don't break BC. But there is no guarantee. IMO, it's better for Dependabot to make us aware of any change available. We also have the benefits of the PRs being built by GitHub which is nice. Gary On Wed, Jul 22, 2020 at 11:12 AM Xeno Amess wrote: as title. I see some dependency trying to upgrade from v1 to v2.3.1, and some plugin from 3.5.1 to 5.1.1 Just confused. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] github
I know there seems to to be a holy war about the use of GitHub going on here but I thought I would just chime in with some thoughts as an open source developer and avid user of GitHub. There have been so many different points I will only discuss a few that I think are important. 1. GitHub is the most popular open source repo in the world. Developers know how to use it, its easy to use and provides all the tools a good open source project needs. When I see an open source project is NOT on GitHub, but still on say SourceForge I am immediately not interested in contributing because of the barrier to entry vs GitHub. 2. The argument that PR's attract one time committers who don't stick around and doesn't build community??? I personally see this as an asset NOT a liability. On some open source projects some of the nastiest bugs or security flaws have been reported and closed by a "one time PR" and that person is never heard from again. But if its a quality PR and its improving the quality of the code who cares??? You just saved one of the active developers a lot of time. Even if the PR is not perfect its OK it can be massaged to meet standards. To me this is what makes GitHub great. 3. Things like Dependabot and other automated actions are AWESOME. They are scanning for changes and informing you when you don't have time to be constantly checking for dependencies or security flaws etc. This should be looked at as a huge plus but somehow on this mailing list it causes so much anger. GitHub is the future of open source. It is the reason Google Code shutdown and why SourceForge is dying a slow death etc. Young developers know GitHub and its their preferred open source repo. If Apache Commons decided to move away from it I think it would be a huge mistake and further isolate what already is a small community of committers. Mello - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] All Commons components on one page in GitHub
Gary: Try this URL: https://github.com/apache?q=commons&type=&language= That is what I used and haven't figured out a better way. It sorts by most recently touched. Mello On 8/5/2020 9:49 AM, Gary Gregory wrote: Hi All: Is there a way to put all of our Commons Components on one page in GitHub? Gary - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] All Commons components on one page in GitHub
Yep I get a 404 when I access that page. On 8/5/2020 11:03 AM, Gary Gregory wrote: I found this page labeled "Secret" by GitHub, presumably only accessible to Commons committers: https://github.com/orgs/apache/teams/commons-committers/repositories Gary On Wed, Aug 5, 2020 at 9:49 AM Gary Gregory wrote: Hi All: Is there a way to put all of our Commons Components on one page in GitHub? Gary - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ANNOUNCE] Matt Sicker Joins the Apache Commons Project PMC
Congrats Matt! On 8/9/2020 7:54 PM, Rob Tompkins wrote: Hello folks, I’d like to announce that Matt Sicker has been invited to join the Apache Commons Project, and he’s accepted. Please join me in welcoming Matt Cheers, -Rob - 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: 2nd Try: Apache Commons CLI actively maintained?
Abhishek, You can see here: https://github.com/apache/commons-cli It received a commit 11 hours ago so yes this library is still being maintained. Mello On 8/11/2020 7:40 AM, Abhishek Munnolimath wrote: Hi, Can someone please comment on this? Thanks, Abhishek Forwarded Message Subject: Apache Commons CLI actively maintained? Date: Tue, 14 Jul 2020 15:25:10 +0530 From: Abhishek Munnolimath Organization: Oracle Corporation To: dev-i...@commons.apache.org Hi, We use Apache Commons CLI 1.4 (latest/Stable release) in our product, can you please let us know if this "Apache Commons CLI" is actively being maintained? because we haven't received any updates on this product since a year or so. Thanks, Abhishek - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Security tab on GitHub
+1 this is a fantastic idea Gary. On 8/22/2020 9:26 AM, Gary Gregory wrote: Hi All, You may have noticed (or nor) that GitHub has a Security [1] tab for our repositories. On this tab, you can define a Security Policy.[2] in a SECURITY.md (just like we have a README.md). I would like to fill this in with the same text we now have here: https://commons.apache.org/security.html Each repository should end up with a SECURITY.md which in theory should be the same. Gary [1] https://github.com/apache/commons-compress/security [2] https://docs.github.com/en/github/managing-security-vulnerabilities/adding-a-security-policy-to-your-repository - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [vfs] consider about making FileObjectUtils be more like FileUtils in commons-io?
That is why I love Lombok's @UtilityClass. https://projectlombok.org/features/experimental/UtilityClass It enforces a static class is truly static by making the constructor private and throwing an exception, making sure all methods are static, marking the class as Final etc. On 9/6/2020 9:53 AM, Xeno Amess wrote: Inheritance in Java on the static side is not the same as on the instance side Yep, I know it. It will not override but just, hiding. I admit it might confuse people sometimes. subclassing a class that only provides static methods is no help. Well actually I personally use it for a shortcut or something. Of course we can do this by fork/wrap the static functions one by one, but extending it directly can make the codes shorter. Gary Gregory 于2020年9月6日周日 下午9:48写道： On Sun, Sep 6, 2020 at 9:44 AM Xeno Amess wrote: The idea behind not making *Util constructors private is that it makes people be able to extend that class. for example: https://github.com/apache/commons-lang/blob/master/src/main/java/org/apache/commons/lang3/StringUtils.java#L9627 I have not see a use case that requires instances of classes that only provide static methods in a long time, like the Javadoc mentions, there used to be JavaBean tools that needed this, and some UI builders IIRC, but I do not see a case of it today. Inheritance in Java on the static side is not the same as on the instance side, so subclassing a class that only provides static methods is no help. Gary Gary Gregory 于2020年9月6日周日 下午9:39写道： The idea behind making *Util constructors private is that it does not make sense to instantiate a class that only has static methods. Gary On Sun, Sep 6, 2020 at 12:49 AM Xeno Amess wrote: for example: can we make its constructor public instead of private? - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [vfs] consider about making FileObjectUtils be more like FileUtils in commons-io?
I am not a big fan of extending Static Utility classes. And Joshua
Bloch is not either from his book "Effective Java"...
See: https://www.informit.com/articles/article.aspx?p=1216151&seqNum=4
On 9/6/2020 10:06 AM, Xeno Amess wrote:
class AUtil {
public static String getStringA() {
return "A";
}
}
class ExtendedAUtil extends AUtil {
public static String getStringABCDE() {
return "ABCDE";
}
}
public class Main {
public static void main(String[] args) {
System.out.println(ExtendedAUtil.getStringA());
System.out.println(ExtendedAUtil.getStringABCDE());
}
}
Maybe it's better to add some runnable codes :)
Xeno Amess 于2020年9月6日周日 下午10:05写道：
Well sometimes we want to extend(or modify) some behaviors of one Util
Class.That is why I don't want the constructor be private.
For example, there be a AUtil:
public class AUtil{
public static String getStringA(){
return "A";
}
}
then some people need a function that returns "ABCDE".
Actually "ABCDE" is useless for any other repos, so we can never pass the
pr to put the getABCDE function to AUtil.
And that people also need the getStringA function.
So there be a way:
public class ExtendedAUtil extends{
public static String getStringABCDE(){
return "ABCDE";
}
}
In this way that people can use ExtendedAUtil as an extended AUtil.
I admit that might be sugar and tricky, but it will help shorten the codes.
BUT if we make the AUtil have only private constructor, then we cannot do
such things, as class who have private constructors only cannot be extended.
Melloware 于2020年9月6日周日 下午9:55写道：
That is why I love Lombok's @UtilityClass.
https://projectlombok.org/features/experimental/UtilityClass
It enforces a static class is truly static by making the constructor
private and throwing an exception, making sure all methods are static,
marking the class as Final etc.
On 9/6/2020 9:53 AM, Xeno Amess wrote:
Inheritance in Java on the static side is
not the same as on the instance side
Yep, I know it. It will not override but just, hiding.
I admit it might confuse people sometimes.
subclassing a class that only
provides static methods is no help.
Well actually I personally use it for a shortcut or something.
Of course we can do this by fork/wrap the static functions one by one,
but
extending it directly can make the codes shorter.
Gary Gregory 于2020年9月6日周日 下午9:48写道：
On Sun, Sep 6, 2020 at 9:44 AM Xeno Amess wrote:
The idea behind not making *Util constructors private is that it makes
people be able to extend that class.
for example:
https://github.com/apache/commons-lang/blob/master/src/main/java/org/apache/commons/lang3/StringUtils.java#L9627
I have not see a use case that requires instances of classes that only
provide static methods in a long time, like the Javadoc mentions, there
used to be JavaBean tools that needed this, and some UI builders IIRC,
but
I do not see a case of it today. Inheritance in Java on the static
side is
not the same as on the instance side, so subclassing a class that only
provides static methods is no help.
Gary
Gary Gregory 于2020年9月6日周日 下午9:39写道：
The idea behind making *Util constructors private is that it does not
make
sense to instantiate a class that only has static methods.
Gary
On Sun, Sep 6, 2020 at 12:49 AM Xeno Amess
wrote:
for example: can we make its constructor public instead of private?
-
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
[BEANUTILS2] Remove Collections Test Framework
I was hoping to get some reviewers on this PR: https://github.com/apache/commons-beanutils/pull/40 Basically it removes Commons Collections Test Framework 3.2.1 from BeanUtils2 and simply copies a couple of classes it needs for the test. The reason to get rid of Commons Collection Test Framework are: a) no longer supported. Looks like it used to be a separate JAR but Commons Collections no longer does this. b) has not been built since 2013 c) does NOT even have a pom in Maven Central its just a JAR. So BeanUtils2 should not be depending on it. This PR removes that dependency and brings in the code necessary for the unit tests. Thank you for your attention, Mello - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
BeanUtils2 PRs and Release
PMC Committers, I know you guys are busy but BeanUtils2 has some great PR's to be reviewed and merged and this is my _monthly_ plea asking for a BeanUtils2 release that has been 4+ years in the making. *Converter Updates:* https://github.com/apache/commons-beanutils/pull/50 https://github.com/apache/commons-beanutils/pull/49 https://github.com/apache/commons-beanutils/pull/47 *Testing (removal of Commons Collections Test Framework):* https://github.com/apache/commons-beanutils/pull/40 *ConcurrentWeakKeyHashMap (Doug Lea's implementation)* https://github.com/apache/commons-beanutils/pull/37 Thank you all for your attention and continued hard work! Mello
Re: BeanUtils2 PRs and Release
Just following up? On 11/5/2020 1:55 PM, Gary Gregory wrote: I should be able to take a look on Sunday. Gary On Thu, Nov 5, 2020, 09:02 Melloware wrote: PMC Committers, I know you guys are busy but BeanUtils2 has some great PR's to be reviewed and merged and this is my _monthly_ plea asking for a BeanUtils2 release that has been 4+ years in the making. *Converter Updates:* https://github.com/apache/commons-beanutils/pull/50 https://github.com/apache/commons-beanutils/pull/49 https://github.com/apache/commons-beanutils/pull/47 *Testing (removal of Commons Collections Test Framework):* https://github.com/apache/commons-beanutils/pull/40 *ConcurrentWeakKeyHashMap (Doug Lea's implementation)* https://github.com/apache/commons-beanutils/pull/37 Thank you all for your attention and continued hard work! Mello - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: BeanUtils2 PRs and Release
Ping... On 11/13/2020 1:05 PM, Gary Gregory wrote: I totally forgot about this, I am sorry. I will remember to look this weekend... On Fri, Nov 13, 2020, 11:22 Melloware wrote: Just following up? On 11/5/2020 1:55 PM, Gary Gregory wrote: I should be able to take a look on Sunday. Gary On Thu, Nov 5, 2020, 09:02 Melloware wrote: PMC Committers, I know you guys are busy but BeanUtils2 has some great PR's to be reviewed and merged and this is my _monthly_ plea asking for a BeanUtils2 release that has been 4+ years in the making. *Converter Updates:* https://github.com/apache/commons-beanutils/pull/50 https://github.com/apache/commons-beanutils/pull/49 https://github.com/apache/commons-beanutils/pull/47 *Testing (removal of Commons Collections Test Framework):* https://github.com/apache/commons-beanutils/pull/40 *ConcurrentWeakKeyHashMap (Doug Lea's implementation)* https://github.com/apache/commons-beanutils/pull/37 Thank you all for your attention and continued hard work! Mello - 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: BeanUtils2 PRs and Release
Sorry... bump :0 On 11/13/2020 1:05 PM, Gary Gregory wrote: I totally forgot about this, I am sorry. I will remember to look this weekend... On Fri, Nov 13, 2020, 11:22 Melloware wrote: Just following up? On 11/5/2020 1:55 PM, Gary Gregory wrote: I should be able to take a look on Sunday. Gary On Thu, Nov 5, 2020, 09:02 Melloware wrote: PMC Committers, I know you guys are busy but BeanUtils2 has some great PR's to be reviewed and merged and this is my _monthly_ plea asking for a BeanUtils2 release that has been 4+ years in the making. *Converter Updates:* https://github.com/apache/commons-beanutils/pull/50 https://github.com/apache/commons-beanutils/pull/49 https://github.com/apache/commons-beanutils/pull/47 *Testing (removal of Commons Collections Test Framework):* https://github.com/apache/commons-beanutils/pull/40 *ConcurrentWeakKeyHashMap (Doug Lea's implementation)* https://github.com/apache/commons-beanutils/pull/37 Thank you all for your attention and continued hard work! Mello - 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: BeanUtils2 PRs and Release
Bump??? On 11/13/2020 1:05 PM, Gary Gregory wrote: I totally forgot about this, I am sorry. I will remember to look this weekend... On Fri, Nov 13, 2020, 11:22 Melloware wrote: Just following up? On 11/5/2020 1:55 PM, Gary Gregory wrote: I should be able to take a look on Sunday. Gary On Thu, Nov 5, 2020, 09:02 Melloware wrote: PMC Committers, I know you guys are busy but BeanUtils2 has some great PR's to be reviewed and merged and this is my _monthly_ plea asking for a BeanUtils2 release that has been 4+ years in the making. *Converter Updates:* https://github.com/apache/commons-beanutils/pull/50 https://github.com/apache/commons-beanutils/pull/49 https://github.com/apache/commons-beanutils/pull/47 *Testing (removal of Commons Collections Test Framework):* https://github.com/apache/commons-beanutils/pull/40 *ConcurrentWeakKeyHashMap (Doug Lea's implementation)* https://github.com/apache/commons-beanutils/pull/37 Thank you all for your attention and continued hard work! Mello - 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
Jacoco 0.8.7
Jacoco 0.8.7 was released: https://github.com/jacoco/jacoco/releases/tag/v0.8.7 Any commons projects using Jacoco like BeanUtils2 should upgrade as it fixes JDK 15 and 16 issues. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Apache Commons BeanUtils and Commons Collection
I submitted this PR over a year ago to remove it.. https://github.com/apache/commons-beanutils/pull/40 On 7/27/2021 8:57 AM, sebb wrote: On Tue, 27 Jul 2021 at 13:54, Suraj Singh wrote: Hello, The beanutil JAR has a dependency on commons-collection v3.2.2. This version was released in 2015 and is EOL. Do you have any plans to use more recent versions of commons-collections4? The dependency is only needed for tests, so updating it is not a priority. It will likely be updated as part of the next release, whenever that is. Regards,Suraj - 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]
And and I have forked it and deployed to Maven Central com.melloware commons-beanutils2 2.0.0 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
Re: [beanutils]
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
Re: [Validator] Update to Java 8 and from Apache Commons Collections 3.x to 4.x
+1 from me on that Gary! On 6/6/2022 9:43 AM, Gary Gregory wrote: Hi All: I propose that we migrate Validator from Java 7 to 8 and from Apache Commons Collections 3.x to 4.x. Thoughts? 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: [lang] Considering a new String utility class
This sounds like a great idea! On 3/15/2023 8:58 AM, Gary Gregory wrote: PRs and issues like "[LANG-1682] Adding new startsWithAnyIgnoreCase method and tests cases" keep popping up from time to time. My preference is to stop adding APIs that are variations of other APIs based on case sensitivity (and Charset, Locale, and so on). Instead, I can see adding a new String utility class that tracks such attributes on its instance such that you'd say something like: - Strings.caseSensitive().someOperation(...) - Strings.caseInsensitive().someOperation(...). The 2 above would access pre-built instances probably. A builder would let you build an instance that your app can cache: Strings.builder().setCaseSensitivity(true).setCharset(...).build(); An instance of Strings or whatever to call such a class would track case sensitivity, a Locale, and maybe an input and output Charset, I'm not 100% sure yet. But you get the idea I hope. Any thoughts? 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: [commons-text] Additional CaseUtils type functionality that can handle snake, kebab, camel, pascal, and others
I have needed / hacked all of these in the past Daniel it would be great
if they were in Commons.
On 8/8/2023 4:03 PM, Daniel Watson wrote:
I have a bit of code that adds the ability to parse and format strings into
various case patterns. Wanted to check if it's of worth and in-scope for
commons-text...
Its a bit broader than the existing CaseUtils.toCamelCase(...) method.
Rather than simply formatting tokens into the case, this API adds the
additional goal of being able to transform one case to another. e.g.
SnakeCase.format(PascalCase.parse("MyPascalString")); // returns
My_Pascal_String
CamelCase.format(SnakeCase.parse("my_snake_string")); // returns
mySnakeString
KebabCase.format(CamelCase.parse("myCamelString")); // returns
my-Camel-String
//Note that kebab and snake do not alter the alphabetic case of the tokens,
as they are essentially case agnostic joining, according to this
implementation. Though this can be overridden by end users.
The API has one core interface: Case, which has format and parse methods.
There is a single abstract implementation of it - AbstractConfigurableCase
- which is a configuration driven way to create a case pattern. It has
enough options to accommodate the 4 popular cases, and thus the subclasses
just have to configure these options rather than implement them directly.
Any further extensions can override or extend the api as necessary.
There are five core concrete implementations:
PascalCase
CamelCase (extends PascalCase)
DelimitedCase
KebabCase (extends DelimitedCase)
SnakeCase (extends DelimitedCase)
Each has a static INSTANCE field to avoid redundant instantiation.
Some of my reasoning / concerns...
* I considered bundling all of this logic into static methods, similar to
CaseUtils, but that prevents the user from truly customizing or extending
the code for odd cases. This approach is, in my opinion, far easier to
understand, extend, and debug.
* I believe the parsing side should potentially have a loose / strict mode,
in that the logic can ignore non-critical rules on the parsing side. e.g.
the command CamelCase.parse("MyString") should work, even though the input
is not strictly camel case. Strict parsing would ensure (if possible) that
the input abides by all elements of the format.
* I'm still unsure about how best to handle reserved characters when
translating. e.g. How should
KebabCase.format(PascalCase.parse("MyPascal-String")) handle the hyphen?
Should the kebab case strip the reserved character from the token values?
Long story short - is this worth pursuing in the form of a pull request for
review? Or is it out of scope for commons-text?
Dan
--
Melloware
melloware@
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[beanutils2] CVE-2014-0114 Pull Request
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
Re: [io] can we delete release 20030203.000550 in maven central?
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 ==
Re: [test] Bug in StringSubstitutor?
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: [All][Geometry] Commit log (Was: [GitHub] ...)
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: [NET] org.apache.commons.net.SocketClient and Closeable
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: GitHub license display confused by LICENSE-header.txt
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: [fileupload] jakarta versus javax?
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: [beanutils]
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: [beanutils]
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: [all] SBOM Generation
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: [VOTE] Release Apache Commons Compress 1.26.1 based on RC1
gt; 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 intended as a helper and refresher for reviewers. > > Validating a release candidate > == > > These guidelines are NOT complete. > > Requirements: Git, Java, Maven. > > You can validate a release from a release candidate (RC) tag as follows. > > 1a) Clone and checkout the RC tag > > git clone https://gitbox.apache.org/repos/asf/commons-compress.git > --branch > <https://gitbox.apache.org/repos/asf/commons-compress.git--branch> > commons-compress-1.26.1-RC1 commons-compress-1.26.1-RC1 > cd commons-compress-1.26.1-RC1 > > 1b) Download and unpack the source archive from: > > https://dist.apache.org/repos/dist/dev/commons/compress/1.26.1-RC1/source > > 2) Check Apache licenses > > This step is not required if the site includes a RAT report page which > you then must check. > > mvn apache-rat:check > > 3) Check binary compatibility > > Older components still use Apache Clirr: > > This step is not required if the site includes a Clirr report page > which you then must check. > > mvn clirr:check > > Newer components use JApiCmp with the japicmp Maven Profile: > > This step is not required if the site includes a JApiCmp report page > which you then must check. > > mvn install -DskipTests -P japicmp japicmp:cmp > > 4) Build the package > > mvn -V clean package > > You can record the Maven and Java version produced by -V in your VOTE > reply. > To gather OS information from a command line: > Windows: ver > Linux: uname -a > > 5) Build the site for a single module project > > Note: Some plugins require the components to be installed instead of > packaged. > > mvn site > Check the site reports in: > - Windows: target\site\index.html > - Linux: target/site/index.html > > -the end- > > - > 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: [beanutils] any plan for a new release of beanutils?
Jia, Sadly it's the same reason I forked it and released it to Maven Central. My client needed to get rid of commons collections3 and BeanUtils 1.9.4 is tied to it. We wanted to only have Commons Collections4 in all our code. https://github.com/melloware/commons-beanutils2 com.melloware commons-beanutils2 2.0.0 On Sat, Aug 17, 2024 at 8:49 AM Gary D. Gregory wrote: > Hello Jia, > > A release will happen only if required to fix a bug that hampers > development. > > Is there a fix/change in the 1.X branch you need that is not in 1.9.4? > > See changes.xml > > Gary > > On 2024/08/17 09:51:55 吾名 wrote: > > dear Commons maintainers, > > > > > > Thank you for your greatr work in Apache Commons. It helps a lot. > > > > > > I noticed the beanutils 2.0 is being developed. And the recent release > of Apache Commons Beanutils was 1.9.4, which is released in 2019. Do you > have any plan on a new release of beanutils 1.x before 2.0 is released? > > > > > > I am looking forward for your reply. Thank you. > > > > > > regards, > > Jia > > - > 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: [beanutils] any plan for a new release of beanutils?
Gary, I know your time is limited. This is not a comment on you personally, I know how much time you put in Apache Commons. But it is a comment on Apache Commons in general and their strict release and release processes and limited number of people who can do releases. As I mentioned before some of my PR's sat open for 4 years. That is right 4 years. I am not constantly going to keep fixing merge conflicts in a PR that stays open for 4 years. That is not fair to ask of any open source contributor or community member. If a PR is open for more than 1-2 months in my opinion it's a sign that the open source project is not healthy. PR opened december 2020: https://github.com/apache/commons-beanutils/pull/56 I finally closed it and gave up...so me putting time into closing more BeanUtils issues that will never get merged doesn't make sense. It was easier and faster for me to fork and release on Maven Central. An open source project is not healthy when someone decides to fork it and release it to Maven Central because it's easier than getting the core library to do releases. All just my two cents...not trolling...just stating facts. On Sat, Aug 17, 2024 at 9:48 AM Gary Gregory wrote: > Why not help resolve one of the last issues, if not the last for 2.0 then: > pulling up the "2" type(s?) into their super types (I think there is only > one). The last time I tried, some tests failed. > > Gary > > On Sat, Aug 17, 2024, 9:38 AM Melloware Inc > wrote: > > > Jia, > > > > Sadly it's the same reason I forked it and released it to Maven Central. > > My client needed to get rid of commons collections3 and BeanUtils 1.9.4 > is > > tied to it. We wanted to only have Commons Collections4 in all our > code. > > > > https://github.com/melloware/commons-beanutils2 > > > > > > com.melloware > > commons-beanutils2 > > 2.0.0 > > > > > > > > On Sat, Aug 17, 2024 at 8:49 AM Gary D. Gregory > > wrote: > > > > > Hello Jia, > > > > > > A release will happen only if required to fix a bug that hampers > > > development. > > > > > > Is there a fix/change in the 1.X branch you need that is not in 1.9.4? > > > > > > See changes.xml > > > > > > Gary > > > > > > On 2024/08/17 09:51:55 吾名 wrote: > > > > dear Commons maintainers, > > > > > > > > > > > > Thank you for your greatr work in Apache Commons. It helps a lot. > > > > > > > > > > > > I noticed the beanutils 2.0 is being developed. And the recent > release > > > of Apache Commons Beanutils was 1.9.4, which is released in 2019. Do > you > > > have any plan on a new release of beanutils 1.x before 2.0 is released? > > > > > > > > > > > > I am looking forward for your reply. Thank you. > > > > > > > > > > > > regards, > > > > Jia > > > > > > - > > > 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 > > == > > > -- == Melloware melloware...@gmail.com http://melloware.com ==
Re: [beanutils] Thoughts on PR https://github.com/apache/commons-beanutils/pull/276
I feel like this PR is a good idea. Just from a safety perspective and not accidentally logging a password. On Mon, Aug 26, 2024 at 5:41 PM Gary D. Gregory wrote: > Hi All, > > Does anyone have thoughts on PR > https://github.com/apache/commons-beanutils/pull/276 ? > > TY, > Gary > > - > 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: [beanutils] BeanUtilsBean2 vs BeanUtilsBean, ConvertUtilsBean2 vs ConvertUtilsBean
+1 for Gary's second option as well. On Sun, Sep 1, 2024 at 3:47 AM Niall Pemberton wrote: > On Sat, 31 Aug 2024 at 20:45, Dávid Szigecsán wrote: > > > Hi, > > > > While I'm still getting familiar with things here, I'd like to share my > > thoughts on this issue. In my view, version 2.0 typically signifies a > break > > in backward compatibility, which makes the second solution—changing the > > supertype's behavior—acceptable. Given the existence of BeanUtilsBean2 > and > > ConvertUtilsBean2, it seems the plan was to modify the behavior in the > next > > major release (2.0). > > > > The only reason the 2nd beans were added was to preserve compatibility at > the time > https://issues.apache.org/jira/browse/BEANUTILS-285 > > Original JIRA: > https://issues.apache.org/jira/browse/BEANUTILS-258 > > > > My question is whether we intend to support the "old" behavior in any > > capacity. If so, I believe an alternative solution is necessary, rather > > than relying on the first solution, which involves overriding methods in > a > > subclass. This approach might violate the SOLID principles, specifically > > the Liskov Substitution Principle, by altering behavior in a subclass. > > > > No, we should IMO remove it - there were only downsides in the old > behaviour that limited users. The new behaviour allowed the users to > configure whatever they want. A user could register converters which > reproduce the old behaviour if they wanted. > > IMO we should definitely go with Gary's second option: > "pull up the "2" classes's method into their respective supertype and > adjust the tests to make the "2" behavior the _only_ behavior" > > Niall > > > > > > Regards, > > David > > > > Gary Gregory ezt írta (időpont: 2024. aug. 31., > > Szo, 20:09): > > > > > Hi All, > > > > > > I want us to decide what we want for 2.0 with the classes > > > BeanUtilsBean2 vs BeanUtilsBean, and ConvertUtilsBean2 vs > > > ConvertUtilsBean. > > > > > > For your convenience: > > > - > > > > > > https://github.com/apache/commons-beanutils/blob/master/src/main/java/org/apache/commons/beanutils2/BeanUtilsBean2.java > > > - > > > > > > https://github.com/apache/commons-beanutils/blob/master/src/main/java/org/apache/commons/beanutils2/BeanUtilsBean.java > > > - > > > > > > https://github.com/apache/commons-beanutils/blob/master/src/main/java/org/apache/commons/beanutils2/ConvertUtilsBean2.java > > > - > > > > > > https://github.com/apache/commons-beanutils/blob/master/src/main/java/org/apache/commons/beanutils2/ConvertUtilsBean.java > > > > > > I plan on doing a 2.0.0-M1 release in mid-September if we can resolve > > > this and put the new package out in the wild. > > > > > > Possible solutions: > > > > > > 1) Do nothing, keep both classes and explain when to use one vs. the > > other > > > 2) The "simplest" change is to pull up the "2" classes's method into > > > their respective supertype and adjust the tests to make the "2" > > > behavior the _only_ behavior > > > > > > What needs addressing no matter what IMO is to remove the global > > > variable BeanUtilsBean.BEANS_BY_CLASSLOADER. Even with class loader > > > independence, you can still have multiple libraries and your app > > > competing for setting and using the default. > > > > > > Thoughts? > > > > > > Gary > > > > > > - > > > 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: [beanutils] BeanUtilsBean2 vs BeanUtilsBean, ConvertUtilsBean2 vs ConvertUtilsBean
Gary, I just built the SNAPSHOT locally and tested against my production scenarios and all is good! On Tue, Sep 3, 2024 at 8:03 AM Gary Gregory wrote: > Hi All, > > The pull-up refactoring and adjusted tests are now in git master. > Pease verify your use cases if any. > > Gary > > On Sun, Sep 1, 2024 at 8:00 AM Melloware Inc > wrote: > > > > +1 for Gary's second option as well. > > > > On Sun, Sep 1, 2024 at 3:47 AM Niall Pemberton < > niall.pember...@gmail.com> > > wrote: > > > > > On Sat, 31 Aug 2024 at 20:45, Dávid Szigecsán > wrote: > > > > > > > Hi, > > > > > > > > While I'm still getting familiar with things here, I'd like to share > my > > > > thoughts on this issue. In my view, version 2.0 typically signifies a > > > break > > > > in backward compatibility, which makes the second solution—changing > the > > > > supertype's behavior—acceptable. Given the existence of > BeanUtilsBean2 > > > and > > > > ConvertUtilsBean2, it seems the plan was to modify the behavior in > the > > > next > > > > major release (2.0). > > > > > > > > > > The only reason the 2nd beans were added was to preserve compatibility > at > > > the time > > > https://issues.apache.org/jira/browse/BEANUTILS-285 > > > > > > Original JIRA: > > > https://issues.apache.org/jira/browse/BEANUTILS-258 > > > > > > > > > > My question is whether we intend to support the "old" behavior in any > > > > capacity. If so, I believe an alternative solution is necessary, > rather > > > > than relying on the first solution, which involves overriding > methods in > > > a > > > > subclass. This approach might violate the SOLID principles, > specifically > > > > the Liskov Substitution Principle, by altering behavior in a > subclass. > > > > > > > > > > No, we should IMO remove it - there were only downsides in the old > > > behaviour that limited users. The new behaviour allowed the users to > > > configure whatever they want. A user could register converters which > > > reproduce the old behaviour if they wanted. > > > > > > IMO we should definitely go with Gary's second option: > > > "pull up the "2" classes's method into their respective supertype > and > > > adjust the tests to make the "2" behavior the _only_ behavior" > > > > > > Niall > > > > > > > > > > > > > > Regards, > > > > David > > > > > > > > Gary Gregory ezt írta (időpont: 2024. aug. > 31., > > > > Szo, 20:09): > > > > > > > > > Hi All, > > > > > > > > > > I want us to decide what we want for 2.0 with the classes > > > > > BeanUtilsBean2 vs BeanUtilsBean, and ConvertUtilsBean2 vs > > > > > ConvertUtilsBean. > > > > > > > > > > For your convenience: > > > > > - > > > > > > > > > > > > > https://github.com/apache/commons-beanutils/blob/master/src/main/java/org/apache/commons/beanutils2/BeanUtilsBean2.java > > > > > - > > > > > > > > > > > > > https://github.com/apache/commons-beanutils/blob/master/src/main/java/org/apache/commons/beanutils2/BeanUtilsBean.java > > > > > - > > > > > > > > > > > > > https://github.com/apache/commons-beanutils/blob/master/src/main/java/org/apache/commons/beanutils2/ConvertUtilsBean2.java > > > > > - > > > > > > > > > > > > > https://github.com/apache/commons-beanutils/blob/master/src/main/java/org/apache/commons/beanutils2/ConvertUtilsBean.java > > > > > > > > > > I plan on doing a 2.0.0-M1 release in mid-September if we can > resolve > > > > > this and put the new package out in the wild. > > > > > > > > > > Possible solutions: > > > > > > > > > > 1) Do nothing, keep both classes and explain when to use one vs. > the > > > > other > > > > > 2) The "simplest" change is to pull up the "2" classes's method > into > > > > > their respective supertype and adjust the tests to make the "2" > > > > > behavior the _only_ behavior > > > > > > > > > > What needs addressing no matter what IMO is to remove the global > > > > > variable BeanUtilsBean.BEANS_BY_CLASSLOADER. Even with class > loader > > > > > independence, you can still have multiple libraries and your app > > > > > competing for setting and using the default. > > > > > > > > > > Thoughts? > > > > > > > > > > Gary > > > > > > > > > > > - > > > > > 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 > > == > > - > 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: [beanutils] Thoughts on PR https://github.com/apache/commons-beanutils/pull/276
I could be wrong but his whole intent of that PR was not logging a bean.toString() that might accidentally expose a password. That seems to be his entire goal. So if there is a better way to achieve that goal is what i think the developer was going for. On Tue, Sep 3, 2024 at 9:52 AM Gary D. Gregory wrote: > On 2024/08/31 12:44:19 Melloware Inc wrote: > > I feel like this PR is a good idea. Just from a safety perspective and > not > > accidentally logging a password. > > The PR does nothing to avoid logging passwords. It only plays games when a > bean implements toString() which might have unexpected consequences. I'm > not sure. > > I took another look and I'm not sure this is helpful though, and it also > contains some global variable editing that will be problematic IMO. See my > comments in the PR. > > Gary > > > > > On Mon, Aug 26, 2024 at 5:41 PM Gary D. Gregory > wrote: > > > > > Hi All, > > > > > > Does anyone have thoughts on PR > > > https://github.com/apache/commons-beanutils/pull/276 ? > > > > > > TY, > > > Gary > > > > > > - > > > 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 > > == > > > > - > 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: [beanutils] Should Commons BeanUtil types implement Serializable
+1 from me. On Tue, Sep 3, 2024 at 12:51 PM Gary D. Gregory wrote: > Hi All, > > Considering the long history of problematic Serializable implementations > throughout the Java ecosystem, not just in Commons, I propose that no > BeanUtils types implement Serializable in the upcoming new major version > 2.0. > > Instead, we would document that if you want to serialize objects, you > should implement a serialization proxy as suggested in Effective Java by > Joshua Bloch. > > The alternative would be to write a large amounts of tests to insure no > security issues occur on top of fixing all read/write security bugs like > BEANUTILS-556 [1]. > > WDYT? > > [1] https://issues.apache.org/jira/browse/BEANUTILS-556 > > - > 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: [beanutils] For 2.0, WeakFastHashMap vs ConcurrentHashMap
I think this is a good idea. On Thu, Sep 12, 2024 at 1:00 PM Gary D. Gregory wrote: > Hi All, > > For the upcoming 2.0.0-M1, I plan on replacing the custom WeakFastHashMap > with the stock ConcurrentHashMap. > > If you think this is a bad idea, please tell us why. > > Gary > > - > 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: [beanutils] Java plaform for 2.0
My vote would be for 11 but I am ok with 8 if people feel strongly. On Thu, Sep 12, 2024 at 1:21 PM Gary D. Gregory wrote: > Hi All, > > Any thoughts on the minimum Java platform requirement for 2.0? > > Options are (IMO): 8, 11, 17, or 21. > > Some perhaps helpful information: > > - > https://www.azul.com/wp-content/uploads/final-2023-state-of-java-report.pdf > - https://www.jetbrains.com/lp/devecosystem-2023/java/ > - https://newrelic.com/resources/report/2024-state-of-the-java-ecosystem > - > https://sdtimes.com/softwaredev/report-java-17-is-now-the-most-used-version-of-java-in-production/ > > Gary > > - > 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: [beanutils] For 2.0, WeakFastHashMap vs ConcurrentHashMap
I submitted this PR years ago using ConcurrentWeakKeyHashMap from Doug Lea and the Netty team but Gary had concerns from legal about being able to use it. PR is here: https://github.com/apache/commons-beanutils/pull/56 On Sat, Sep 14, 2024 at 7:22 AM Xeno Amess wrote: > I thought old d-lea bro have a concurrent weak hashmap implement > somewhere...why not just ask him > after all nobody here more expert than him in this area > > From: Niall Pemberton > Sent: Saturday, September 14, 2024 1:46:32 PM > To: Commons Developers List > Subject: Re: [beanutils] For 2.0, WeakFastHashMap vs ConcurrentHashMap > > On Thu, 12 Sep 2024 at 19:59, Gary D. Gregory wrote: > > > Hi All, > > > > For the upcoming 2.0.0-M1, I plan on replacing the custom WeakFastHashMap > > with the stock ConcurrentHashMap. > > > > If you think this is a bad idea, please tell us why. > > > It’s a good idea for the “fast” part, but the “weak” aspect also needs to > be retained - so in principle yes, but the implementation detail matters. > > BeanUtils caused memory issues in multiple ClassLoader environments (e.g. > WebApp containers) because of strong references to classes prevented them > from being garbage collected if the app was reloaded/restarted. So this > weak map was introduced to resolve that issue. > > Niall > > > > > > Gary > > > > - > > 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: [beanutils] For 2.0, WeakFastHashMap vs ConcurrentHashMap
Well in my PR the license in the file says this. Written by Doug Lea with assistance from members of JCP JSR-166 Expert Group and released to the public domain, as explained at @see http://creativecommons.org/licenses/publicdomain";>Creative Commons it says its public domain. On Sat, Sep 14, 2024 at 9:01 AM Xeno Amess wrote: > why not write an email to lea ..maybe he be so kind that would be glad to > offer one mit-like license copy of that class > > From: Melloware Inc > Sent: Saturday, September 14, 2024 8:32:38 PM > To: Commons Developers List > Subject: Re: [beanutils] For 2.0, WeakFastHashMap vs ConcurrentHashMap > > I submitted this PR years ago using ConcurrentWeakKeyHashMap from Doug Lea > and the Netty team but Gary had concerns from legal about being able to use > it. > > PR is here: https://github.com/apache/commons-beanutils/pull/56 > > On Sat, Sep 14, 2024 at 7:22 AM Xeno Amess wrote: > > > I thought old d-lea bro have a concurrent weak hashmap implement > > somewhere...why not just ask him > > after all nobody here more expert than him in this area > > > > From: Niall Pemberton > > Sent: Saturday, September 14, 2024 1:46:32 PM > > To: Commons Developers List > > Subject: Re: [beanutils] For 2.0, WeakFastHashMap vs ConcurrentHashMap > > > > On Thu, 12 Sep 2024 at 19:59, Gary D. Gregory > wrote: > > > > > Hi All, > > > > > > For the upcoming 2.0.0-M1, I plan on replacing the custom > WeakFastHashMap > > > with the stock ConcurrentHashMap. > > > > > > If you think this is a bad idea, please tell us why. > > > > > > It’s a good idea for the “fast” part, but the “weak” aspect also needs to > > be retained - so in principle yes, but the implementation detail matters. > > > > BeanUtils caused memory issues in multiple ClassLoader environments (e.g. > > WebApp containers) because of strong references to classes prevented them > > from being garbage collected if the app was reloaded/restarted. So this > > weak map was introduced to resolve that issue. > > > > Niall > > > > > > > > > > Gary > > > > > > - > > > 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 > == > -- == Melloware melloware...@gmail.com http://melloware.com ==
Re: [beanutils] Java plaform for 2.0
+1 for Java8 if it speeds this up! On Wed, Sep 25, 2024 at 3:46 PM Josh Fenlason wrote: > While some might have some preferences on more recent Java versions, I > haven't seen any objections to Java 8. Staying on Java 8 shouldn't really > cause issues for anyone. Can we settle on Java 8 so this isn't an > impediment to getting a new BeanUtils 2.0 release out the door? > Josh. > > -Original Message- > From: Xeno Amess > Sent: Wednesday, September 18, 2024 5:21 AM > To: Commons Developers List > Subject: Re: [beanutils] Java plaform for 2.0 > > > CAUTION: This email originated from outside the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. If you believe this is a phishing email, use the Report to > Cybersecurity icon in Outlook. > > > > I'd prefer 17 for myself, but I know it might be slightly > aggresive/radical . > Anyway, if using versions equals/under 17, we can use Spring as a shield > or something, as for people they wanna upgrade spring version they must > upgrade their program to support jdk17 = = "don't blame us, Spring did the > upgrade first" or something lol > > Gary Gregory 于2024年9月17日周二 05:03写道： > > > I think that for now I am leaning towards staying on Java 8. > > > > Gary > > > > On Sat, Sep 14, 2024, 3:42 AM Xeno Amess wrote: > > > > > for 90%+ normal user each version under which spring using be OK > > > > > > From: Richard Zowalla > > > Sent: Saturday, September 14, 2024 12:59:15 PM > > > To: Commons Developers List > > > Subject: Re: [beanutils] Java plaform for 2.0 > > > > > > My 2 cents are: BeanUtils is often used in the EE ecosystem EE 9.1 > > targets > > > 8/11, EE 10 targets 11/17, EE 11 targets 17 or higher. > > > > > > People are still doing the EE8 to 9.1/10 move (thanks to the name > > change). > > > So perhaps 11 or 17 would be a good fit for a baseline version. > > > > > > Gruß > > > Richard > > > > > > Am 14. September 2024 00:00:48 MESZ schrieb sebb : > > > >On Fri, 13 Sept 2024 at 22:01, Gary Gregory > > > > > > > wrote: > > > >> > > > >> The age does not really matter Elric, it's the percentage of > > > >> people > > > using a > > > >> platform. See the links in my previous email. I think the highest > > > >> we > > > can go > > > >> is 17, but that's just me. > > > > > > > >According to the 3rd link, Java version usage in 2024 is > > > > > > > >7 - 0.2% > > > >8 - 28.8% > > > >11 - 32.9% > > > >17 - 35.4% > > > >21 - 1.4% > > > > > > > >Here is the list showing the percentages that will no longer be > > > >supported by choosing a particular version: > > > > > > > >7 - 0% > > > >8 - 0.2% > > > >11 - 29% > > > >17 - 61.9% > > > >21 - 97.3% > > > > > > > >Bigger is definitely not better here. > > > > > > > >> Gary > > > >> > > > >> On Fri, Sep 13, 2024, 4:11 PM Elric wrote: > > > >> > > > >> > On 12/09/2024 19:21, Gary D. Gregory wrote: > > > >> > > Hi All, > > > >> > > > > > >> > > Any thoughts on the minimum Java platform requirement for 2.0? > > > >> > > > > > >> > > Options are (IMO): 8, 11, 17, or 21. > > > >> > > > > >> > I have no vote, but I would go for 21. This will likely be a > > decision > > > >> > that will have an impact for a long time. 21 is 1 year old, 17 > > > >> > is 3 years old, 11 is already already 6 years old, and 8 is > > > >> > over 10 years > > > old. > > > >> > > > > >> > People can continue to use 1.x if they are stuck on ancient > > > >> > Java versions, but there should be no need to for any major > > > >> > release of > > any > > > >> > commons project to stick to older versions. > > > >> > > > > >> > > > - > > > >> > 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 > > > > > > > > > > -- == Melloware melloware...@gmail.com http://melloware.com ==
Re: [VOTE] Release Apache Commons BeanUtils 1.10.0 based on RC1
RC1/RELEASE-NOTES.txt > > > > > https://dist.apache.org/repos/dist/dev/commons/beanutils/1.10.0-RC1/site/changes-report.html > > > > Site: > > > > > https://dist.apache.org/repos/dist/dev/commons/beanutils/1.10.0-RC1/site/index.html > > (note some *relative* links are broken and the 1.10.0 directories are > > not yet created - these will be OK once the site is deployed.) > > > > JApiCmp Report (compared to 1.9.4): > > > > > https://dist.apache.org/repos/dist/dev/commons/beanutils/1.10.0-RC1/site/japicmp.html > > > > Note that the above report notes several errors. > > These are considered OK because we bump the platform requirement from > > Java 6 to 8. > > > > RAT Report: > > > > > https://dist.apache.org/repos/dist/dev/commons/beanutils/1.10.0-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) > > > > The following is intended as a helper and refresher for reviewers. > > > > Validating a release candidate > > == > > > > These guidelines are NOT complete. > > > > Requirements: Git, Java, Maven. > > > > You can validate a release from a release candidate (RC) tag as follows. > > > > 1a) Clone and checkout the RC tag > > > > git clone https://gitbox.apache.org/repos/asf/commons-beanutils.git > > --branch commons-beanutils-1.10.0-RC1 commons-beanutils-1.10.0-RC1 > > cd commons-beanutils-1.10.0-RC1 > > > > 1b) Download and unpack the source archive from: > > > > > https://dist.apache.org/repos/dist/dev/commons/beanutils/1.10.0-RC1/source > > > > 2) Check Apache licenses > > > > This step is not required if the site includes a RAT report page which > you > > then must check. > > > > mvn apache-rat:check > > > > 3) Check binary compatibility > > > > Older components still use Apache Clirr: > > > > This step is not required if the site includes a Clirr report page which > > you then must check. > > > > mvn clirr:check > > > > Newer components use JApiCmp with the japicmp Maven Profile: > > > > This step is not required if the site includes a JApiCmp report page > which > > you then must check. > > > > mvn install -DskipTests -P japicmp japicmp:cmp > > > > 4) Build the package > > > > mvn -V clean package > > > > You can record the Maven and Java version produced by -V in your VOTE > > reply. > > To gather OS information from a command line: > > Windows: ver > > Linux: uname -a > > > > 5) Build the site for a single module project > > > > Note: Some plugins require the components to be installed instead of > > packaged. > > > > mvn site > > Check the site reports in: > > - Windows: target\site\index.html > > - Linux: target/site/index.html > > > > -the end- > > > > > -- == Melloware melloware...@gmail.com http://melloware.com ==
Re: [VOTE] Release Apache Commons BeanUtils 2.0.0-M1 based on RC1
My non binding +1 Melloware @melloware on GitHub > On Dec 26, 2024, at 8:16 PM, Gary Gregory wrote: > > This is a major new version, under the beanutils2 package name instead of > beanutils. > > Apache Commons BeanUtils 2.0.0-M1 RC1 is available for review here: >https://dist.apache.org/repos/dist/dev/commons/beanutils/2.0.0-M1-RC1 > (svn revision 73870) > > The Git tag commons-beanutils-2.0.0-M1-RC1 commit for this RC is > e4eb3568ab6076585cb51b4a6d3f329ae04d2efb which you can browse here: > > https://gitbox.apache.org/repos/asf?p=commons-beanutils.git;a=commit;h=e4eb3568ab6076585cb51b4a6d3f329ae04d2efb > You may checkout this tag using: >git clone https://gitbox.apache.org/repos/asf/commons-beanutils.git > --branch commons-beanutils-2.0.0-M1-RC1 commons-beanutils-2.0.0-M1-RC1 > > Maven artifacts are here: > > https://repository.apache.org/content/repositories/orgapachecommons-1794/org/apache/commons/commons-beanutils2/2.0.0-M1/ > > These are the artifacts and their hashes: > > #Release SHA-512s > #Fri Dec 27 01:08:15 UTC 2024 > commons-beanutils2-2.0.0-M1-bin.tar.gz=a3d327ade76c1d4ef848386325694116bb6a4e66e844567e9aeb766557f56329cdbb937bbad4c0cfa0bec55d3c0d711dbacb47e2e82d9b33a218b012e74ce4b1 > commons-beanutils2-2.0.0-M1-bin.zip=4bc98cb444d7d51c063a745588da3edc21c0650ad826780353853ce7465df4b514f09b10733d31545987cca7898d8bb781f4a2f883337741df81710a95a9c3b9 > commons-beanutils2-2.0.0-M1-bom.json=6687f38e36d4e08d8ca72131e54bb9abc4eab4df008abc0259e0c95d8be860ae32a7fdb79cedc74b73d91b7de44af23a9de076595db4cfbec168b8c09adc8fc6 > commons-beanutils2-2.0.0-M1-bom.xml=1e341f646b4057b740cc44f0c594c55c6eceee65147aa3228425740379adbfa868577453fb2b7bd961fe4ca044a2f3af38c705702934c7461d8c3e3e66c16296 > commons-beanutils2-2.0.0-M1-javadoc.jar=a117460982f6ec759fe8d17a0723ef944d914d1b0e3c923679b6d6b15354d4c12b106b925857dbdd404c7e1b825e5cfb41db1269d05c02f2109f7e181c9e5f19 > commons-beanutils2-2.0.0-M1-sources.jar=6bbda8274391feedb22195f3f9a5d01081ec47e15028e9fbcb9fbda04ae07a2685269ac34211d2ba5affcc4b82f4589ac791f18d2e93c0938ace133e204f7fbf > commons-beanutils2-2.0.0-M1-src.tar.gz=157cf25e470c123e5aee504385d98f06044c4af6e0e314afc52085e4cf988cd346fe75cec6ab58b824450b12d28a22701df8183b090cba17785f51d7abc9dbfa > commons-beanutils2-2.0.0-M1-src.zip=d490b0239bd59ff71fdc74871e67f1f42f642aec144ad7c2ffc7fb51627f4933c3f3b016b546b3d71f540d7aa3ce4a5af8a645ac1c4dd718d2e0ecd0f3b61e5a > commons-beanutils2-2.0.0-M1-test-sources.jar=2b87383e42618af45814aea5d60a3c36524ed671018f722094908aa450467bdce698d653bb7e434e1184c7c75baff66c9649727cde333c5dd0218bde2763da8d > commons-beanutils2-2.0.0-M1-tests.jar=aa3f3afcee100aed8a5a0e7df1913ea12e1ad75ef83c89ec24b4e41bf352fcc767b4c27ce14a4f24f4892a4f75e9f36cdd9c3b9a356c1ba2b67be46efefcee7b > org.apache.commons_commons-beanutils2-2.0.0-M1.spdx.json=b4492942c25dd6b4de7f2d3b66f5a6f29ff3136fca2d006f70b99966e6ded013e26fa61b748d7482b1d0e058409d47b1cd93e199a57d5f1faa5054735427f00e > > > > I have tested this with ***'mvn clean install site'*** using: > *** > Use the output from "mvn -version" for each combination you tested. > Windows: ver > Linux: uname -a > *** > > Details of changes since 2.0.0-SNAPSHOT are in the release notes: > > https://dist.apache.org/repos/dist/dev/commons/beanutils/2.0.0-M1-RC1/RELEASE-NOTES.txt > > https://dist.apache.org/repos/dist/dev/commons/beanutils/2.0.0-M1-RC1/site/changes-report.html > > Site: > > https://dist.apache.org/repos/dist/dev/commons/beanutils/2.0.0-M1-RC1/site/index.html >(note some *relative* links are broken and the 2.0.0-M1 directories are > not yet created - these will be OK once the site is deployed.) > > JApiCmp Report (compared to 1.9.4): >There is no report, the package name is different: beanutils2 vs, > beanutils. > > RAT Report: > > https://dist.apache.org/repos/dist/dev/commons/beanutils/2.0.0-M1-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) > > The following is intended as a helper and refresher for reviewers. > > Validating a release candidate > == > > These guidelines are NOT complete. > > Requirements: Git, Java, Maven. > > You can validate a release from a release candidate (RC) tag as follows. > > 1a) Clone and checkout the RC tag > > git clone https://gitbox.apache.org/repos/asf/commons-beanutils.git > --br
Re: [VOTE] Release Apache Commons BeanUtils 1.10.1 based on RC1
> 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) > > > > The following is intended as a helper and refresher for reviewers. > > > > Validating a release candidate > > == > > > > These guidelines are NOT complete. > > > > Requirements: Git, Java, and Maven. > > > > You can validate a release from a release candidate (RC) tag as follows. > > > > 1a) Download and decompress the source archive from: > > > > > https://dist.apache.org/repos/dist/dev/commons/beanutils/1.10.1-RC1/source > > > > 1b) Check out the RC tag from git (optional) > > > > This is optional, as a reviewer must check source distributions as a > minimum. > > > > git clone https://gitbox.apache.org/repos/asf/commons-beanutils.git > > --branch commons-beanutils-1.10.1-RC1 commons-beanutils-1.10.1-RC1 > > cd commons-beanutils-1.10.1-RC1 > > > > 2) Checking the build > > > > All components should include a default Maven goal, such that you can > > run 'mvn' from the command line by itself. > > > > 2) Check Apache licenses > > > > This step is not required if the site includes a RAT report page which > > you then must check. > > This check should be included in the default Maven build, but you can > > check it with: > > > > mvn apache-rat:check > > > > 3) Check binary compatibility > > > > This step is not required if the site includes a JApiCmp report page > > which you then must check. > > This check should be included in the default Maven build, but you can > > check it with: > > > > mvn verify -DskipTests -P japicmp japicmp:cmp > > > > 4) Build the package > > > > This check should be included in the default Maven build, but you can > > check it with: > > > > mvn -V clean package > > > > You can record the Maven and Java version produced by -V in your VOTE > reply. > > To gather OS information from a command line: > > Windows: ver > > Linux: uname -a > > > > 4b) Check reproducibility > > > > To check that a build is reproducible, run: > > > > mvn clean verify artifact:compare -DskipTests > > -Dreference.repo= > https://repository.apache.org/content/repositories/staging/ > > '-Dbuildinfo.ignore=*/*.spdx.json' > > > > Note that this excludes SPDX files from the check. > > > > 5) Build the site for a single module project > > > > Note: Some plugins require the components to be installed instead of > packaged. > > > > mvn site > > Check the site reports in: > > - Windows: target\site\index.html > > - Linux: target/site/index.html > > > > -the end- > > - > 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: [ALL] Maven module expert needed please
Can’t you do “mvn -U clean package” the -U ignores the local cache timing. Melloware @melloware on GitHub > On Feb 11, 2025, at 6:47 PM, sebb wrote: > > Commons weaver seems to have an issue with its pom module settings. > > One symptom is that the following fails: > > $ mvn dependency:list > > with > > Could not resolve dependencies for project > org.apache.commons:commons-weaver-maven-plugin:maven-plugin:2.1-SNAPSHOT: > Failure to find > org.apache.commons:commons-weaver-processor:jar:2.1-SNAPSHOT in > https://repository.apache.org/snapshots was cached in the local > repository, resolution will not be reattempted until the update > interval of apache.snapshots has elapsed or updates are forced > > This can be fixed using 'mvn install', but surely that should not be > necessary? > Is there some bootstrapping issue here? > > Much the same problem occurs when using japicmp in the maven-plugin module. > [So it was temporarily disabled to allow builds to complete] > > Can anyone provide any assistance here? > > 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
Re: [beanutils2] Question about the official final 2.0.0 release timeline
I +1 this vote for an official BeanUtils 2.0.0 release. I am using it in Production as M1 for months now without issue. On Tue, May 20, 2025 at 10:47 AM Zach Dove wrote: > Hello, > > I’d like to ask about the plans for an official release of BeanUtils2 > (2.0.0 final). We are tracking this for our migration to Java 21 and > JasperReports 7. > > The milestone releases (2.0.0-M1) are helpful, but is there a timeline or > roadmap for a stable, non-milestone release? > I'm referencing from > *https://commons.apache.org/proper/commons-beanutils/changes.html > <https://commons.apache.org/proper/commons-beanutils/changes.html>* . > > Mitigation for https://issues.apache.org/jira/browse/BEANUTILS-532 looks > a release was made through 'melloware' group as a non-Apache alternative to > swap 2.0.0-M1 to 2.0.0. > I've followed up with melloware on the issue of > https://github.com/Jaspersoft/jasperreports/issues/260 > > > Currently the lack of a vision for an official final release of BeanUtils2 > remains a concerning blocker for our migration of our software suite from > Java 11 to Java 21 and a blocker for continuing with Jasper Reports 7. > > > In addition, https://github.com/apache/commons-beanutils/security does > not contain any disclaimer disregarding a continuous concern within the > community for "security issue" Cx78f40514-81ff / sonatype-2024-3350 / > COLLECTIONS-701, revolving around the concerns of the changes made in > commons-collections4, 4.2, > > Https://github.com/apache/commons-collections/commit/1979a6e31067a18c9ede59ad4518f738512eba82#diff-8e53271d5d8299a76d43b0e3c81740fbe660083ae71c5bf2be63846d52156f23 > <https://github.com/apache/commons-collections/commit/1979a6e31067a18c9ede59ad4518f738512eba82#diff-8e53271d5d8299a76d43b0e3c81740fbe660083ae71c5bf2be63846d52156f23> > > > I took the time to look through the dependencies in commons-beanutils, > commons-beanutils2, commons-digester, collections 3.2 / > commons-collections4 and was unable to find SetUniqueList being used > across these components that directly impacts commons-beanutils > functionality & security. > > > In short, could you please advise / response on: > - The expected timeline or requirements for a stable/final BeanUtils2 > 2.0.0 release? > - Whether there are any remaining blockers or areas where the community > can assist? > - Any official position on the referenced security concern in beanutils > 1.9.x-1.10.x, given the current dependency structure? > > Best, > > *Zach Dove,* Software Developer, D2, Store Transactions > *P* 828.265.2907* | <https://www.ecrs.com>** www.ecrs.com > <https://www.ecrs.com>* > > * <https://www.ecrs.com> <https://www.ecrs.com>** <https://www.ecrs.com/>* > > * <https://hubs.li/Q02rFH810>* * <https://hubs.li/Q02rFH1C0>* * > <https://hubs.li/Q02rFGDm0>* * <https://hubs.li/Q02rFGPZ0>* > > * <https://hubs.li/Q03lHLjF0>* > > * <https://hubs.li/Q03kr_3k0>* > > -- == Melloware melloware...@gmail.com http://melloware.com ==
Re: [beanutils2] Question about the official final 2.0.0 release timeline
I guess that is a question for the JasperReports team. Melloware @melloware on GitHub > On May 20, 2025, at 5:37 PM, Gary Gregory wrote: > > Creating a PR in JasperReports runs... zero tests? > > Gary > > >> On Tue, May 20, 2025 at 4:41 PM Melloware Inc >> wrote: >> >> Note I have already submitted a JasperReports PR against BeanUtils 2.0.0-M1 >> months ago but the author doesn't like its an M1. >> >> See: https://github.com/Jaspersoft/jasperreports/pull/488 >> >> On Tue, May 20, 2025 at 1:49 PM Gary Gregory >> wrote: >> >>> Hi Zach, >>> >>> There is no official or unofficial release date yet because I would like >> to >>> get more community feedback before we set the API in stone for 2.0.0. >>> >>> It would be painful if your port from 1.x to 2.x revealed issues >> requiring >>> API changes that we couldn't make until 3.x. Would you use 2.0.0-M1 and >>> report your findings? >>> >>>> blocker for our migration of our software suite from Java 11 to Java 21 >>> >>> I'm not sure what this has to do with BU as BU 1.x and 2.x are both >> tested >>> against all Java LTS versions: 8, 11, 17, 21 (See GitHub). >>> >>> Issue https://issues.apache.org/jira/browse/BEANUTILS-532 is handled in >>> 2.0.0-M1. >>> >>> WRT COLLECTIONS-701 ( >>> >>> >> https://github.com/apache/commons-collections/commit/1979a6e31067a18c9ede59ad4518f738512eba82#diff-8e53271d5d8299a76d43b0e3c81740fbe660083ae71c5bf2be63846d52156f23 >>> ), >>> this can only happen due to a programming error, and was fixed in 4.3. >>> >>>> The expected timeline or requirements for a stable/final BeanUtils2 >> 2.0.0 >>> release? >>> >>> See above, in brief, please port to 2.0.0-M1. >>> >>>> Whether there are any remaining blockers or areas where the community >> can >>> assist? >>> >>> - Testing 2.0.0-M1 and/or 2.0.0-M2-SNAPSHOT in your environment would be >>> the most helpful. >>> - You can also see Jira and GitHub pull requests to see if there are open >>> issues that would matter to you. >>> >>>> Any official position on the referenced security concern in beanutils >>> 1.9.x-1.10.x, given the current dependency structure? >>> >>> If by security concern you mean >>> https://issues.apache.org/jira/browse/BEANUTILS-532, this is addressed >> in >>> BU 2.0.0-M1 and cannot be fixed in BU 1 since updating Commons >>> Collections 3.x to 4.x would break binary compatibility. >>> >>> HTH, >>> Gary >>> >>> >>> On Tue, May 20, 2025 at 10:47 AM Zach Dove >> wrote: >>> >>>> Hello, >>>> >>>> I’d like to ask about the plans for an official release of BeanUtils2 >>>> (2.0.0 final). We are tracking this for our migration to Java 21 and >>>> JasperReports 7. >>>> >>>> The milestone releases (2.0.0-M1) are helpful, but is there a timeline >> or >>>> roadmap for a stable, non-milestone release? >>>> I'm referencing from * >>> https://commons.apache.org/proper/commons-beanutils/changes.html >>>> <https://commons.apache.org/proper/commons-beanutils/changes.html>* . >>>> >>>> Mitigation for https://issues.apache.org/jira/browse/BEANUTILS-532 >> looks >>>> a release was made through 'melloware' group as a non-Apache >> alternative >>> to >>>> swap 2.0.0-M1 to 2.0.0. >>>> I've followed up with melloware on the issue of >>>> https://github.com/Jaspersoft/jasperreports/issues/260 >>>> >>>> >>>> Currently the lack of a vision for an official final release of >>> BeanUtils2 >>>> remains a concerning blocker for our migration of our software suite >> from >>>> Java 11 to Java 21 and a blocker for continuing with Jasper Reports 7. >>>> >>>> >>>> In addition, https://github.com/apache/commons-beanutils/security does >>>> not contain any disclaimer disregarding a continuous concern within the >>>> community for "security issue" Cx78f40514-81ff / sonatype-2024-3350 / >>>> COLLECTIONS-701, revolving around the concerns of the changes made in >>>> commons-collections4, 4.2, >>>> >>>> >>> >> Http
Re: [beanutils2] Question about the official final 2.0.0 release timeline
Note I have already submitted a JasperReports PR against BeanUtils 2.0.0-M1 months ago but the author doesn't like its an M1. See: https://github.com/Jaspersoft/jasperreports/pull/488 On Tue, May 20, 2025 at 1:49 PM Gary Gregory wrote: > Hi Zach, > > There is no official or unofficial release date yet because I would like to > get more community feedback before we set the API in stone for 2.0.0. > > It would be painful if your port from 1.x to 2.x revealed issues requiring > API changes that we couldn't make until 3.x. Would you use 2.0.0-M1 and > report your findings? > > > blocker for our migration of our software suite from Java 11 to Java 21 > > I'm not sure what this has to do with BU as BU 1.x and 2.x are both tested > against all Java LTS versions: 8, 11, 17, 21 (See GitHub). > > Issue https://issues.apache.org/jira/browse/BEANUTILS-532 is handled in > 2.0.0-M1. > > WRT COLLECTIONS-701 ( > > https://github.com/apache/commons-collections/commit/1979a6e31067a18c9ede59ad4518f738512eba82#diff-8e53271d5d8299a76d43b0e3c81740fbe660083ae71c5bf2be63846d52156f23 > ), > this can only happen due to a programming error, and was fixed in 4.3. > > > The expected timeline or requirements for a stable/final BeanUtils2 2.0.0 > release? > > See above, in brief, please port to 2.0.0-M1. > > > Whether there are any remaining blockers or areas where the community can > assist? > > - Testing 2.0.0-M1 and/or 2.0.0-M2-SNAPSHOT in your environment would be > the most helpful. > - You can also see Jira and GitHub pull requests to see if there are open > issues that would matter to you. > > > Any official position on the referenced security concern in beanutils > 1.9.x-1.10.x, given the current dependency structure? > > If by security concern you mean > https://issues.apache.org/jira/browse/BEANUTILS-532, this is addressed in > BU 2.0.0-M1 and cannot be fixed in BU 1 since updating Commons > Collections 3.x to 4.x would break binary compatibility. > > HTH, > Gary > > > On Tue, May 20, 2025 at 10:47 AM Zach Dove wrote: > > > Hello, > > > > I’d like to ask about the plans for an official release of BeanUtils2 > > (2.0.0 final). We are tracking this for our migration to Java 21 and > > JasperReports 7. > > > > The milestone releases (2.0.0-M1) are helpful, but is there a timeline or > > roadmap for a stable, non-milestone release? > > I'm referencing from * > https://commons.apache.org/proper/commons-beanutils/changes.html > > <https://commons.apache.org/proper/commons-beanutils/changes.html>* . > > > > Mitigation for https://issues.apache.org/jira/browse/BEANUTILS-532 looks > > a release was made through 'melloware' group as a non-Apache alternative > to > > swap 2.0.0-M1 to 2.0.0. > > I've followed up with melloware on the issue of > > https://github.com/Jaspersoft/jasperreports/issues/260 > > > > > > Currently the lack of a vision for an official final release of > BeanUtils2 > > remains a concerning blocker for our migration of our software suite from > > Java 11 to Java 21 and a blocker for continuing with Jasper Reports 7. > > > > > > In addition, https://github.com/apache/commons-beanutils/security does > > not contain any disclaimer disregarding a continuous concern within the > > community for "security issue" Cx78f40514-81ff / sonatype-2024-3350 / > > COLLECTIONS-701, revolving around the concerns of the changes made in > > commons-collections4, 4.2, > > > > > Https://github.com/apache/commons-collections/commit/1979a6e31067a18c9ede59ad4518f738512eba82#diff-8e53271d5d8299a76d43b0e3c81740fbe660083ae71c5bf2be63846d52156f23 > > < > https://github.com/apache/commons-collections/commit/1979a6e31067a18c9ede59ad4518f738512eba82#diff-8e53271d5d8299a76d43b0e3c81740fbe660083ae71c5bf2be63846d52156f23 > > > > > > > > I took the time to look through the dependencies in commons-beanutils, > > commons-beanutils2, commons-digester, collections 3.2 / > > commons-collections4 and was unable to find SetUniqueList being used > > across these components that directly impacts commons-beanutils > > functionality & security. > > > > > > In short, could you please advise / response on: > > - The expected timeline or requirements for a stable/final BeanUtils2 > > 2.0.0 release? > > - Whether there are any remaining blockers or areas where the community > > can assist? > > - Any official position on the referenced security concern in beanutils > > 1.9.x-1.10.x, given the current dependency structure? > > >
Re: [VOTE] Release Apache Commons BeanUtils 2.0.0-M2 based on RC1
al incompatibilities. > These are considered OK since until we finalize 2.0.0. > > RAT Report: > > https://dist.apache.org/repos/dist/dev/commons/beanutils/2.0.0-M2-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 24 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) > > The following is intended as a helper and refresher for reviewers. > > Validating a release candidate > == > > These guidelines are NOT complete. > > Requirements: Git, Java, and Maven. > > You can validate a release from a release candidate (RC) tag as follows. > > 1a) Download and decompress the source archive from: > > > https://dist.apache.org/repos/dist/dev/commons/beanutils/2.0.0-M2-RC1/source > > 1b) Check out the RC tag from git (optional) > > This is optional, as a reviewer must check source distributions as a > minimum. > > git clone https://gitbox.apache.org/repos/asf/commons-beanutils.git > --branch > <https://gitbox.apache.org/repos/asf/commons-beanutils.git--branch> > commons-beanutils-2.0.0-M2-RC1 commons-beanutils-2.0.0-M2-RC1 > cd commons-beanutils-2.0.0-M2-RC1 > > 2) Checking the build > > All components should include a default Maven goal, such that you can > run 'mvn' from the command line by itself. > > 2) Check Apache licenses > > This step is not required if the site includes a RAT report page which > you then must check. > This check should be included in the default Maven build, but you can > check it with: > > mvn apache-rat:check > > 3) Check binary compatibility > > This step is not required if the site includes a JApiCmp report page > which you then must check. > This check should be included in the default Maven build, but you can > check it with: > > mvn verify -DskipTests -P japicmp japicmp:cmp > > 4) Build the package > > This check should be included in the default Maven build, but you can > check it with: > > mvn -V clean package > > You can record the Maven and Java version produced by -V in your VOTE > reply. > To gather OS information from a command line: > Windows: ver > Linux: uname -a > > 4b) Check reproducibility > > To check that a build is reproducible, run: > > mvn clean verify artifact:compare -DskipTests > -Dreference.repo= > https://repository.apache.org/content/repositories/staging/ > '-Dbuildinfo.ignore=*/*.spdx.json' > > Note that this excludes SPDX files from the check. > > 5) Build the site for a single module project > > Note: Some plugins require the components to be installed instead of > packaged. > > mvn site > Check the site reports in: > - Windows: target\site\index.html > - Linux: target/site/index.html > > -the end- > > - > 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 ==
