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: [beanutils] Java plaform for 2.0
+1 On Wed, 25 Sept 2024 at 20:51, Melloware Inc wrote: > > +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 > == - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [CLI] [DISCUSS] Help formatter extension proposal
I have to agree that Serializer is an overloaded term and should be avoided, and I knew when I named it that the name would have to change. But I don't like "Render" because it is a verb and the noun for something that renders would be a renderer. And to my ears (and fingers) that seems clunky. How about "Producer" for the interface, and TextProducer, XmlProducer, MarkdownProcucer, as the concrete class names? -- LinkedIn: http://www.linkedin.com/in/claudewarren
Re: [CLI] [DISCUSS] Help formatter extension proposal
That sounds similar to java.io.Writer. Maybe this should be a HelpWriter?
On Wed, Sep 25, 2024, 7:11 PM Claude Warren wrote:
> Actually the Producer constructor takes an "Appendable" as an argument and
> then provides methods like
>
> printPara("Some text here")
>
> Which would output a paragraph of "Some text here"
>
> TestProducer appends "Some text here\n\n" (where \n is
> System.lineSeparator) to the appendable
> XmlProducer would append something like "Some text here" to the
> appendable.
>
> (they really are serializing the data to an output format)
>
> Claude
>
> --
> LinkedIn: http://www.linkedin.com/in/claudewarren
>
[ANNOUNCE] Apache Commons CSV Version 1.12.0
The Apache Commons Team is pleased to announce Apache Commons CSV Version 1.12.0 Commons CSV reads and writes files in Comma Separated Value (CSV) format variations. Commons CSV requires Java 8 or higher. The Apache Commons CSV library provides a simple interface for reading and writing CSV files of various types. Historical list of changes: https://commons.apache.org/proper/commons-csv/changes-report.html For complete information on Apache Commons CSV, including instructions on how to submit bug reports, patches, or suggestions for improvement, see the Apache Commons CSV website: https://commons.apache.org/proper/commons-csv/ Download page: https://commons.apache.org/proper/commons-csv/download_csv.cgi Have fun! Gary Gregory -Apache Commons CSV team - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[LAZY][VOTE] Release Apache Commons Parent 76 based on RC1
We have fixed a few bugs and added enhancements since Apache Commons Parent 75 was released, so I would like to release Apache Commons Parent 76. Apache Commons Parent 76 RC1 is available for review here: https://dist.apache.org/repos/dist/dev/commons/parent/76-RC1 (svn revision 71883) The Git tag commons-parent-76-RC1 commit for this RC is 5c09ca8f175fcb1fbc41cac29109fbed6a5398f7 which you can browse here: https://gitbox.apache.org/repos/asf?p=commons-parent.git;a=commit;h=5c09ca8f175fcb1fbc41cac29109fbed6a5398f7 You may checkout this tag using: git clone https://gitbox.apache.org/repos/asf/commons-parent.git --branch commons-parent-76-RC1 commons-parent-76-RC1 Maven artifacts are here: https://repository.apache.org/content/repositories/orgapachecommons-1781/org/apache/commons/commons-parent/76/ These are the artifacts and their hashes: #Release SHA-512s #Wed Sep 25 19:40:35 UTC 2024 commons-parent-76-bom.json=a6757b2c02d65b1aa477a4b1e0ac3346009b4ef801339e2b69fc48926dd0a9dcc77242aff39b651915f9b5e6e4df089751db5308b73e69ae6d9c1568d3766bc7 commons-parent-76-bom.xml=107da41d82916ed431291ad49da88b1c5db8bf27d2df3b44873552af0944f16cdcea0ff7f183bf5324dc55ef2a60dc8fd90079f080ff69c62067d1fdd4495da8 commons-parent-76-site.xml=5f045989b2c281c567467548678fe8685efabf5c13104299eea87b6ab6b6a75c9e98b590d7b288b8ec3a06934061709d0851a6dd9d9b45100ee2950908ec2d6c commons-parent-76-src.tar.gz=5aa3f91670695e38f1cb157660829c9d2404106a78a065ce87c6f07b5e0ab11da2a82cd22aa2e50abcfc6614621487cedc9058655d0156d69d8ef553ec8bab7e commons-parent-76-src.zip=6235c551574069c279e51f5cf50868f1be12c85f256cbd309111e3f8d943583b4ee963a3844f8bb42135c0dc4e35e4551a70b88f7cbb518c2510396020b5f064 org.apache.commons_commons-parent-76.spdx.json=86a8e6ee7785e0868ce69027b1c1d10b64874e04b1a8c5ec6516ca88f340a9ff240a9045866e0e4e03040ac9276ca6aad95ee7123ad78303cac09157d8774271 I have tested this with 'mvn' and 'mvn -e -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site deploy' using: openjdk version "21.0.4" 2024-07-16 OpenJDK Runtime Environment Homebrew (build 21.0.4) OpenJDK 64-Bit Server VM Homebrew (build 21.0.4, mixed mode, sharing) Apache Maven 3.9.9 (8e8579a9e76f7d015ee5ec7bfcdc97d260186937) Maven home: /usr/local/Cellar/maven/3.9.9/libexec Java version: 21.0.4, vendor: Homebrew, runtime: /usr/local/Cellar/openjdk@21/21.0.4/libexec/openjdk.jdk/Contents/Home Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "15.0", arch: "x86_64", family: "mac" Darwin 24.0.0 Darwin Kernel Version 24.0.0: Mon Aug 12 20:54:30 PDT 2024; root:xnu-11215.1.10~2/RELEASE_X86_64 x86_64 Details of changes since 75 are in the release notes: https://dist.apache.org/repos/dist/dev/commons/parent/76-RC1/RELEASE-NOTES.txt https://dist.apache.org/repos/dist/dev/commons/parent/76-RC1/site/changes-report.html Site: https://dist.apache.org/repos/dist/dev/commons/parent/76-RC1/site/index.html (note some *relative* links are broken and the 76 directories are not yet created - these will be OK once the site is deployed.) RAT Report: https://dist.apache.org/repos/dist/dev/commons/parent/76-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-parent.git --branch commons-parent-76-RC1 commons-parent-76-RC1 cd commons-parent-76-RC1 1b) Download and unpack the source archive from: https://dist.apache.org/repos/dist/dev/commons/parent/76-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 re
RE: [beanutils] Java plaform for 2.0
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 > > > > > >
Re: [beanutils] For 2.0, WeakFastHashMap vs ConcurrentHashMap
I'll ping this thread when there is something in git master to test in more depth. Gary On Wed, Sep 25, 2024 at 4:01 PM Josh Fenlason wrote: > > Excellent, thanks for that encouraging update! Is there anything I can > assist with? > Josh. > > -Original Message- > From: Gary Gregory > Sent: Wednesday, September 25, 2024 2:52 PM > To: Commons Developers List > Subject: Re: [beanutils] For 2.0, WeakFastHashMap vs ConcurrentHashMap > > > 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. > > > > FWIW, I have a patch in progress using the Apache Grooy's version of the > class, so licensing will not be an issue, Apache to Apache. > > If you look at the recent commits in git master, you'll see that I've started > adding missing tests we need before we add anything else... > > I also have tests written that fit in the existing test framework. > These will likely need to be beefed up. I saw zero tests for this class in > the Groovy code base. > > Stay tuned. > > Gary > > On Wed, Sep 25, 2024 at 3:37 PM Josh Fenlason > wrote: > > > > Are legal concerns of using Netty's ConcurrentWeakKeyHashMap the only issue > > with Melloware's PR (https://github.com/apache/commons-beanutils/pull/56) > > from a couple of years ago? That PR mentions > > http://creativecommons.org/licenses/publicdomain for details on the > > license, which unfortunately no longer works. However, looking at the > > Netty source > > (https://github.com/netty/netty/blob/3.9/src/main/java/org/jboss/netty/util/internal/ConcurrentWeakKeyHashMap.java), > > they have an Apache 2 license. Doesn't that alleviate any license > > concerns? Can we resuscitate Melloware's PR and wrap up this issue? > > Thanks, > > Josh. > > > > -Original Message- > > From: Gary Gregory > > Sent: Monday, September 16, 2024 4:26 PM > > To: Commons Developers List > > Subject: Re: [beanutils] For 2.0, WeakFastHashMap vs ConcurrentHashMap > > > > > > 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. > > > > > > > > Which points to: > > https://issu/ > > es.apache.org%2Fjira%2Fbrowse%2FBEANUTILS-509&data=05%7C02%7CJosh.Fenl > > ason%40veritas.com%7C594b7769bda54bbd892d08dcdd9ba40c%7Cfc8e13c0422c4c > > 55b3eaca318e6cac32%7C0%7C0%7C638628907749754165%7CUnknown%7CTWFpbGZsb3 > > d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7 > > C0%7C%7C%7C&sdata=SGR%2B0SfgS%2F7gmd8VCPOlTmmlwQQNNp77J05QI5fFaBc%3D&r > > eserved=0 > > > > Gary > > > > On Mon, Sep 16, 2024, 5:24 PM Gary Gregory wrote: > > > > > Related: > > > https://issu/ > > > es.apache.org%2Fjira%2Fbrowse%2FCOLLECTIONS-700&data=05%7C02%7CJosh. > > > Fe > > > nlason%40veritas.com%7Ca17c9a6a13a540debe7f08dcd6963dfb%7Cfc8e13c042 > > > 2c > > > 4c55b3eaca318e6cac32%7C0%7C0%7C638621188049710140%7CUnknown%7CTWFpbG > > > Zs > > > b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0% > > > 3D > > > %7C0%7C%7C%7C&sdata=UspxFjiRSi4rTJSW7wNHs2XESjZ0Cvbm350jrmVMD3I%3D&r > > > es > > > erved=0 > > > > > > Gary > > > > > > On Sat, Sep 14, 2024, 10:16 AM Xeno Amess wrote: > > > > > >> IMO I think it ok...so Gary which part do you feel unsafe in it ？I > > >> must admit I am not that familiar to lawyer things.. > > >> > > >> From: Melloware Inc > > >> Sent: Saturday, September 14, 2024 9:18:08 PM > > >> To: Commons Developers List > > >> Subject: 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 > >> href="https://nam12.safelinks.protection.outlook.com/?url=http%3A%252 > > >> F%25 > > >> 2Fcreativecommons.org%2Flicenses%2Fpublicdomain&data=05%7C02%7CJosh > > >> .F > > >> enlason%40veritas.com%7Ca17c9a6a13a540debe7f08dcd6963dfb%7Cfc8e13c0 > > >> 42 > > >> 2c4c55b3eaca318e6cac32%7C0%7C0%7C638621188049723177%7CUnknown%7CTWF > > >> pb > > >> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6 > > >> Mn > > >> 0%3D%7C0%7C%7C%7C&sdata=Vgo5BT3zXWMHgn4iv1PKrw0kZd2JMUo2V1o78%2FMuF > > >> po > > >> %3D&reserved=0">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 > >
Re: [validator] Collections 4
On Wed, Sep 25, 2024 at 4:06 PM Josh Fenlason wrote: > > Is the Validator 2.0 release still being planned for the near future? Yes, maybe within a month or so. > > Is that PR for moving the Commons Collections dependency from 3 to 4 still in > active? Or would it help for someone to take another pass at that? No, this will be done as part of 2.0. > > The package structure still needs to be updated from > "org.apache.commons.validator" to "org.apache.commons.validator2", correct? > Would it help if I created a PR to do that? No, because this will touch every single file and will make a PR too hard and tedious to review (all files will be deleted and added). Gary > > Josh. > > -Original Message- > From: Josh Fenlason > Sent: Wednesday, September 11, 2024 9:46 AM > To: Commons Developers List > Subject: RE: [validator] Collections 4 > > > 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 was looking through the jira items for validator. > > I see one item that looks like it would be necessary for a Validator 2.X > release, VALIDATOR-390, for updating to Commons Collections 4. I see a > relatively recent PR, https://github.com/apache/commons-validator/pull/53, > for that though. I know that breaks binary compatibility an would therefore > require a new Validator 2 release. Since it looks like there is momentum for > that, is the plan to accept that PR? Or is a different solution necessary > for that? > > One other thing is that I believe the convention is for new major releases to > bump the version in the package name, refactoring from > "org.apache.commons.validator" to "org.apache.commons.validator2", correct? > I am not seeing a jira item for that. Did I miss it? Would it be helpful > for me to create a PR with that refactoring? > > Thanks, > Josh. > > -Original Message- > From: Gary D. Gregory > Sent: Wednesday, September 4, 2024 8:32 AM > To: dev@commons.apache.org > Subject: RE: [validator] Collections 4 > > > 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. > > > > On 2024/09/03 19:54:05 Josh Fenlason wrote: > > That is great to hear! Is there anything I can do to assist with that? > > Watch this list and test builds and release candidates when they become > available. > > You can also scan Jira and pull requests on GitHub and see if anything > catches your eye. > > Gary > > > > > -Original Message- > > From: Gary Gregory > > Sent: Tuesday, September 3, 2024 2:53 PM > > To: Commons Developers List > > Subject: Re: [validator] Collections 4 > > > > > > 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 am planning on what will likely be a new major version as we cannot break > > binary compatibility. Maybe within the next few weeks. > > > > Gary > > > > On Tue, Sep 3, 2024, 3:10 PM Josh Fenlason > > wrote: > > > > > I have requirements to eliminate collections3 from my project. > > > The latest Validator released is dependent on collections3 though. > > > What are the chances of a new Validator release that is dependent on > > > collections4? What could I do to assist with making that happen? > > > Thanks, > > > Josh. > > > > > > > - > 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] For 2.0, WeakFastHashMap vs ConcurrentHashMap
Sounds good. I'll keep an eye out for it. -Original Message- From: Gary Gregory Sent: Wednesday, September 25, 2024 3:22 PM To: Commons Developers List Subject: Re: [beanutils] For 2.0, WeakFastHashMap vs ConcurrentHashMap 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'll ping this thread when there is something in git master to test in more depth. Gary On Wed, Sep 25, 2024 at 4:01 PM Josh Fenlason wrote: > > Excellent, thanks for that encouraging update! Is there anything I can > assist with? > Josh. > > -Original Message- > From: Gary Gregory > Sent: Wednesday, September 25, 2024 2:52 PM > To: Commons Developers List > Subject: Re: [beanutils] For 2.0, WeakFastHashMap vs ConcurrentHashMap > > > 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. > > > > FWIW, I have a patch in progress using the Apache Grooy's version of the > class, so licensing will not be an issue, Apache to Apache. > > If you look at the recent commits in git master, you'll see that I've started > adding missing tests we need before we add anything else... > > I also have tests written that fit in the existing test framework. > These will likely need to be beefed up. I saw zero tests for this class in > the Groovy code base. > > Stay tuned. > > Gary > > On Wed, Sep 25, 2024 at 3:37 PM Josh Fenlason > wrote: > > > > Are legal concerns of using Netty's ConcurrentWeakKeyHashMap the only issue > > with Melloware's PR (https://github.com/apache/commons-beanutils/pull/56) > > from a couple of years ago? That PR mentions > > http://creativecommons.org/licenses/publicdomain for details on the > > license, which unfortunately no longer works. However, looking at the > > Netty source > > (https://github.com/netty/netty/blob/3.9/src/main/java/org/jboss/netty/util/internal/ConcurrentWeakKeyHashMap.java), > > they have an Apache 2 license. Doesn't that alleviate any license > > concerns? Can we resuscitate Melloware's PR and wrap up this issue? > > Thanks, > > Josh. > > > > -Original Message- > > From: Gary Gregory > > Sent: Monday, September 16, 2024 4:26 PM > > To: Commons Developers List > > Subject: Re: [beanutils] For 2.0, WeakFastHashMap vs > > ConcurrentHashMap > > > > > > 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. > > > > > > > > Which points to: > > https://issu/ > > es.apache.org%2Fjira%2Fbrowse%2FBEANUTILS-509&data=05%7C02%7CJosh.Fe > > nl > > ason%40veritas.com%7C594b7769bda54bbd892d08dcdd9ba40c%7Cfc8e13c0422c > > 4c > > 55b3eaca318e6cac32%7C0%7C0%7C638628907749754165%7CUnknown%7CTWFpbGZs > > b3 > > d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D > > %7 > > C0%7C%7C%7C&sdata=SGR%2B0SfgS%2F7gmd8VCPOlTmmlwQQNNp77J05QI5fFaBc%3D > > &r > > eserved=0 > > > > Gary > > > > On Mon, Sep 16, 2024, 5:24 PM Gary Gregory wrote: > > > > > Related: > > > https://issu/ > > > es.apache.org%2Fjira%2Fbrowse%2FCOLLECTIONS-700&data=05%7C02%7CJosh. > > > Fe > > > nlason%40veritas.com%7Ca17c9a6a13a540debe7f08dcd6963dfb%7Cfc8e13c0 > > > 42 > > > 2c > > > 4c55b3eaca318e6cac32%7C0%7C0%7C638621188049710140%7CUnknown%7CTWFp > > > bG > > > Zs > > > b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn > > > 0% > > > 3D > > > %7C0%7C%7C%7C&sdata=UspxFjiRSi4rTJSW7wNHs2XESjZ0Cvbm350jrmVMD3I%3D > > > &r > > > es > > > erved=0 > > > > > > Gary > > > > > > On Sat, Sep 14, 2024, 10:16 AM Xeno Amess wrote: > > > > > >> IMO I think it ok...so Gary which part do you feel unsafe in it > > >> ？I > > >> must admit I am not that familiar to lawyer things.. > > >> > > >> From: Melloware Inc > > >> Sent: Saturday, September 14, 2024 9:18:08 PM > > >> To: Commons Developers List > > >> Subject: 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 > >> href="https://nam12.safelinks.protection.outlook.com/?url=http%3A > > >> %252 > > >> F%25 > > >> 2Fcreativecommons.org%2Flicenses%2Fpublicdomain&data=05%7C02%7CJo > > >> sh > > >> .F > > >> enlason%40veritas.com%7Ca17c9a6a13a540debe7f08dcd6963dfb%7Cfc8e13 > > >> c0 > > >> 42 > > >> 2c4c55b3eaca318e6cac32%7C0%7C0%7C638621188049723177%
RE: [beanutils] For 2.0, WeakFastHashMap vs ConcurrentHashMap
Excellent, thanks for that encouraging update! Is there anything I can assist with? Josh. -Original Message- From: Gary Gregory Sent: Wednesday, September 25, 2024 2:52 PM To: Commons Developers List Subject: Re: [beanutils] For 2.0, WeakFastHashMap vs ConcurrentHashMap 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. FWIW, I have a patch in progress using the Apache Grooy's version of the class, so licensing will not be an issue, Apache to Apache. If you look at the recent commits in git master, you'll see that I've started adding missing tests we need before we add anything else... I also have tests written that fit in the existing test framework. These will likely need to be beefed up. I saw zero tests for this class in the Groovy code base. Stay tuned. Gary On Wed, Sep 25, 2024 at 3:37 PM Josh Fenlason wrote: > > Are legal concerns of using Netty's ConcurrentWeakKeyHashMap the only issue > with Melloware's PR (https://github.com/apache/commons-beanutils/pull/56) > from a couple of years ago? That PR mentions > http://creativecommons.org/licenses/publicdomain for details on the license, > which unfortunately no longer works. However, looking at the Netty source > (https://github.com/netty/netty/blob/3.9/src/main/java/org/jboss/netty/util/internal/ConcurrentWeakKeyHashMap.java), > they have an Apache 2 license. Doesn't that alleviate any license concerns? > Can we resuscitate Melloware's PR and wrap up this issue? > Thanks, > Josh. > > -Original Message- > From: Gary Gregory > Sent: Monday, September 16, 2024 4:26 PM > To: Commons Developers List > Subject: Re: [beanutils] For 2.0, WeakFastHashMap vs ConcurrentHashMap > > > 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. > > > > Which points to: > https://issu/ > es.apache.org%2Fjira%2Fbrowse%2FBEANUTILS-509&data=05%7C02%7CJosh.Fenl > ason%40veritas.com%7C594b7769bda54bbd892d08dcdd9ba40c%7Cfc8e13c0422c4c > 55b3eaca318e6cac32%7C0%7C0%7C638628907749754165%7CUnknown%7CTWFpbGZsb3 > d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7 > C0%7C%7C%7C&sdata=SGR%2B0SfgS%2F7gmd8VCPOlTmmlwQQNNp77J05QI5fFaBc%3D&r > eserved=0 > > Gary > > On Mon, Sep 16, 2024, 5:24 PM Gary Gregory wrote: > > > Related: > > https://issu/ > > es.apache.org%2Fjira%2Fbrowse%2FCOLLECTIONS-700&data=05%7C02%7CJosh. > > Fe > > nlason%40veritas.com%7Ca17c9a6a13a540debe7f08dcd6963dfb%7Cfc8e13c042 > > 2c > > 4c55b3eaca318e6cac32%7C0%7C0%7C638621188049710140%7CUnknown%7CTWFpbG > > Zs > > b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0% > > 3D > > %7C0%7C%7C%7C&sdata=UspxFjiRSi4rTJSW7wNHs2XESjZ0Cvbm350jrmVMD3I%3D&r > > es > > erved=0 > > > > Gary > > > > On Sat, Sep 14, 2024, 10:16 AM Xeno Amess wrote: > > > >> IMO I think it ok...so Gary which part do you feel unsafe in it ？I > >> must admit I am not that familiar to lawyer things.. > >> > >> From: Melloware Inc > >> Sent: Saturday, September 14, 2024 9:18:08 PM > >> To: Commons Developers List > >> Subject: 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 >> href="https://nam12.safelinks.protection.outlook.com/?url=http%3A%252 > >> F%25 > >> 2Fcreativecommons.org%2Flicenses%2Fpublicdomain&data=05%7C02%7CJosh > >> .F > >> enlason%40veritas.com%7Ca17c9a6a13a540debe7f08dcd6963dfb%7Cfc8e13c0 > >> 42 > >> 2c4c55b3eaca318e6cac32%7C0%7C0%7C638621188049723177%7CUnknown%7CTWF > >> pb > >> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6 > >> Mn > >> 0%3D%7C0%7C%7C%7C&sdata=Vgo5BT3zXWMHgn4iv1PKrw0kZd2JMUo2V1o78%2FMuF > >> po > >> %3D&reserved=0">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 her
Re: [CLI] [DISCUSS] Help formatter extension proposal
On Wed, Sep 25, 2024 at 6:09 PM Claude Warren wrote: > > I have to agree that Serializer is an overloaded term and should be > avoided, and I knew when I named it that the name would have to change. > But I don't like "Render" because it is a verb and the noun for something > that renders would be a renderer. And to my ears (and fingers) that seems > clunky. > > How about "Producer" for the interface, and TextProducer, XmlProducer, > MarkdownProcucer, as the concrete class names? Hi Claude, Better :-) Java has the general-use Supplier, so... assuming a producer creates something, could this be an actual Supplier, like a TextSupplier that implements a get()? Or, does the class draw/render/print _onto_ something in which case it could be a Java Consumer. Some of this depends on details I've not looked at in your branch yet... (working on something else ATM ;-) HTH, Gary > > -- > LinkedIn: http://www.linkedin.com/in/claudewarren - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
RE: [beanutils] For 2.0, WeakFastHashMap vs ConcurrentHashMap
Are legal concerns of using Netty's ConcurrentWeakKeyHashMap the only issue with Melloware's PR (https://github.com/apache/commons-beanutils/pull/56) from a couple of years ago? That PR mentions http://creativecommons.org/licenses/publicdomain for details on the license, which unfortunately no longer works. However, looking at the Netty source (https://github.com/netty/netty/blob/3.9/src/main/java/org/jboss/netty/util/internal/ConcurrentWeakKeyHashMap.java), they have an Apache 2 license. Doesn't that alleviate any license concerns? Can we resuscitate Melloware's PR and wrap up this issue? Thanks, Josh. -Original Message- From: Gary Gregory Sent: Monday, September 16, 2024 4:26 PM To: Commons Developers List Subject: Re: [beanutils] For 2.0, WeakFastHashMap vs ConcurrentHashMap 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. Which points to: https://issues.apache.org/jira/browse/BEANUTILS-509 Gary On Mon, Sep 16, 2024, 5:24 PM Gary Gregory wrote: > Related: > https://issu/ > es.apache.org%2Fjira%2Fbrowse%2FCOLLECTIONS-700&data=05%7C02%7CJosh.Fe > nlason%40veritas.com%7Ca17c9a6a13a540debe7f08dcd6963dfb%7Cfc8e13c0422c > 4c55b3eaca318e6cac32%7C0%7C0%7C638621188049710140%7CUnknown%7CTWFpbGZs > b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D > %7C0%7C%7C%7C&sdata=UspxFjiRSi4rTJSW7wNHs2XESjZ0Cvbm350jrmVMD3I%3D&res > erved=0 > > Gary > > On Sat, Sep 14, 2024, 10:16 AM Xeno Amess wrote: > >> IMO I think it ok...so Gary which part do you feel unsafe in it ？I >> must admit I am not that familiar to lawyer things.. >> >> From: Melloware Inc >> Sent: Saturday, September 14, 2024 9:18:08 PM >> To: Commons Developers List >> Subject: 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 >> > href="https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%25 >> 2Fcreativecommons.org%2Flicenses%2Fpublicdomain&data=05%7C02%7CJosh.F >> enlason%40veritas.com%7Ca17c9a6a13a540debe7f08dcd6963dfb%7Cfc8e13c042 >> 2c4c55b3eaca318e6cac32%7C0%7C0%7C638621188049723177%7CUnknown%7CTWFpb >> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn >> 0%3D%7C0%7C%7C%7C&sdata=Vgo5BT3zXWMHgn4iv1PKrw0kZd2JMUo2V1o78%2FMuFpo >> %3D&reserved=0">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://g/ >> > ithub.com%2Fapache%2Fcommons-beanutils%2Fpull%2F56&data=05%7C02%7CJ >> > osh.Fenlason%40veritas.com%7Ca17c9a6a13a540debe7f08dcd6963dfb%7Cfc8 >> > e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638621188049734927%7CUnknow >> > n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWw >> > iLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ERcuJKHJW%2F7plLn9Pj5nUaA4rFCukB >> > s8V6WP%2BABCzRc%3D&reserved=0 >> > >> > 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 relo
Re: [beanutils] For 2.0, WeakFastHashMap vs ConcurrentHashMap
FWIW, I have a patch in progress using the Apache Grooy's version of the class, so licensing will not be an issue, Apache to Apache. If you look at the recent commits in git master, you'll see that I've started adding missing tests we need before we add anything else... I also have tests written that fit in the existing test framework. These will likely need to be beefed up. I saw zero tests for this class in the Groovy code base. Stay tuned. Gary On Wed, Sep 25, 2024 at 3:37 PM Josh Fenlason wrote: > > Are legal concerns of using Netty's ConcurrentWeakKeyHashMap the only issue > with Melloware's PR (https://github.com/apache/commons-beanutils/pull/56) > from a couple of years ago? That PR mentions > http://creativecommons.org/licenses/publicdomain for details on the license, > which unfortunately no longer works. However, looking at the Netty source > (https://github.com/netty/netty/blob/3.9/src/main/java/org/jboss/netty/util/internal/ConcurrentWeakKeyHashMap.java), > they have an Apache 2 license. Doesn't that alleviate any license concerns? > Can we resuscitate Melloware's PR and wrap up this issue? > Thanks, > Josh. > > -Original Message- > From: Gary Gregory > Sent: Monday, September 16, 2024 4:26 PM > To: Commons Developers List > Subject: Re: [beanutils] For 2.0, WeakFastHashMap vs ConcurrentHashMap > > > 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. > > > > Which points to: https://issues.apache.org/jira/browse/BEANUTILS-509 > > Gary > > On Mon, Sep 16, 2024, 5:24 PM Gary Gregory wrote: > > > Related: > > https://issu/ > > es.apache.org%2Fjira%2Fbrowse%2FCOLLECTIONS-700&data=05%7C02%7CJosh.Fe > > nlason%40veritas.com%7Ca17c9a6a13a540debe7f08dcd6963dfb%7Cfc8e13c0422c > > 4c55b3eaca318e6cac32%7C0%7C0%7C638621188049710140%7CUnknown%7CTWFpbGZs > > b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D > > %7C0%7C%7C%7C&sdata=UspxFjiRSi4rTJSW7wNHs2XESjZ0Cvbm350jrmVMD3I%3D&res > > erved=0 > > > > Gary > > > > On Sat, Sep 14, 2024, 10:16 AM Xeno Amess wrote: > > > >> IMO I think it ok...so Gary which part do you feel unsafe in it ？I > >> must admit I am not that familiar to lawyer things.. > >> > >> From: Melloware Inc > >> Sent: Saturday, September 14, 2024 9:18:08 PM > >> To: Commons Developers List > >> Subject: 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 > >> >> href="https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%25 > >> 2Fcreativecommons.org%2Flicenses%2Fpublicdomain&data=05%7C02%7CJosh.F > >> enlason%40veritas.com%7Ca17c9a6a13a540debe7f08dcd6963dfb%7Cfc8e13c042 > >> 2c4c55b3eaca318e6cac32%7C0%7C0%7C638621188049723177%7CUnknown%7CTWFpb > >> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn > >> 0%3D%7C0%7C%7C%7C&sdata=Vgo5BT3zXWMHgn4iv1PKrw0kZd2JMUo2V1o78%2FMuFpo > >> %3D&reserved=0">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://g/ > >> > ithub.com%2Fapache%2Fcommons-beanutils%2Fpull%2F56&data=05%7C02%7CJ > >> > osh.Fenlason%40veritas.com%7Ca17c9a6a13a540debe7f08dcd6963dfb%7Cfc8 > >> > e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638621188049734927%7CUnknow > >> > n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWw > >> > iLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ERcuJKHJW%2F7plLn9Pj5nUaA4rFCukB > >> > s8V6WP%2BABCzRc%3D&reserved=0 > >> > > >> > 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 > >> > > > >> > > O
RE: [validator] Collections 4
Is the Validator 2.0 release still being planned for the near future? Is that PR for moving the Commons Collections dependency from 3 to 4 still in active? Or would it help for someone to take another pass at that? The package structure still needs to be updated from "org.apache.commons.validator" to "org.apache.commons.validator2", correct? Would it help if I created a PR to do that? Josh. -Original Message- From: Josh Fenlason Sent: Wednesday, September 11, 2024 9:46 AM To: Commons Developers List Subject: RE: [validator] Collections 4 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 was looking through the jira items for validator. I see one item that looks like it would be necessary for a Validator 2.X release, VALIDATOR-390, for updating to Commons Collections 4. I see a relatively recent PR, https://github.com/apache/commons-validator/pull/53, for that though. I know that breaks binary compatibility an would therefore require a new Validator 2 release. Since it looks like there is momentum for that, is the plan to accept that PR? Or is a different solution necessary for that? One other thing is that I believe the convention is for new major releases to bump the version in the package name, refactoring from "org.apache.commons.validator" to "org.apache.commons.validator2", correct? I am not seeing a jira item for that. Did I miss it? Would it be helpful for me to create a PR with that refactoring? Thanks, Josh. -Original Message- From: Gary D. Gregory Sent: Wednesday, September 4, 2024 8:32 AM To: dev@commons.apache.org Subject: RE: [validator] Collections 4 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. On 2024/09/03 19:54:05 Josh Fenlason wrote: > That is great to hear! Is there anything I can do to assist with that? Watch this list and test builds and release candidates when they become available. You can also scan Jira and pull requests on GitHub and see if anything catches your eye. Gary > > -Original Message- > From: Gary Gregory > Sent: Tuesday, September 3, 2024 2:53 PM > To: Commons Developers List > Subject: Re: [validator] Collections 4 > > > 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 am planning on what will likely be a new major version as we cannot break > binary compatibility. Maybe within the next few weeks. > > Gary > > On Tue, Sep 3, 2024, 3:10 PM Josh Fenlason > wrote: > > > I have requirements to eliminate collections3 from my project. > > The latest Validator released is dependent on collections3 though. > > What are the chances of a new Validator release that is dependent on > > collections4? What could I do to assist with making that happen? > > Thanks, > > Josh. > > > - 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: [CLI] [DISCUSS] Help formatter extension proposal
Actually the Producer constructor takes an "Appendable" as an argument and
then provides methods like
printPara("Some text here")
Which would output a paragraph of "Some text here"
TestProducer appends "Some text here\n\n" (where \n is
System.lineSeparator) to the appendable
XmlProducer would append something like "Some text here" to the
appendable.
(they really are serializing the data to an output format)
Claude
--
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: [CLI] [DISCUSS] Help formatter extension proposal
Some initial code. Note the "help" package name. We can discuss keeping it or not but it is here to make it easy to see what is new. Also, some methods added to Util.java https://github.com/Claudenw/commons-cli/tree/Help_formatter_extension/src/main/java/org/apache/commons/cli/help Overview because I have not written the javadocs yet. - HelpFormatter -- the replacement for the current help formatter. Much of the formatting functionality has moved. - Serializer -- a semantic serialization component. Semantic meaning you serialize things like paragraph, table, header. Serialize meaning you write a specific serialization format (e.g. text, xhtml, Markdown, etc). Serializers write to any Appendable implementation. (e.g. StringBuilder or Writer) - OptionFormatter -- Handles the formatting of Options (e.g. the '<' and '>' around arg names, '[' and ']' for optional data, etc Generally does not need to be set. Defaults match current settings. - TextStyle -- Guidelines for how to display the text. Serializers are not required to follow the guidelines. HelpFormatter uses an instance to set the left padding, the maximum width of the display, and the indent for paragraphs. - TableDef a collection of headers, TextStyle (one for each column), and a list of rows. Where rows are lists of strings one for each column. The Text style will specify the left padding, max and min text width, indents for continuation lines, text alignment, and whether the column can be scaled (FIXED = no). In the test classes I added an org.example package that contains an AptSerializer as an example for markdown and other cases as well as a "WeirdOptionFormat" which defines a completely different table definition for the option display. Generally extension points are: - Writing new Serializers. (set with HelpFormatter.Builder) - Creating custom table definitions. (set with HelpFormatter.Builder, or used directly with the Serializer) - Overriding "printHelp" in the AbstractHelpFormatter" to create a custom page. This may include calling the serializer and creating new tables with definitions for custom argument names for example. I will continue to work on this, getting the javadoc in order and ensuring that we have enough test coverage. Right now you have to run maven with the "-Djacoco.skip=true" flag to get past the test coverage issue. Let me know what you think. Claude On Mon, Sep 23, 2024 at 10:58 PM Eric Pugh wrote: > Keep us posted! I would love to contribute a Markdown format. > > > On Sep 23, 2024, at 7:20 AM, Claude Warren wrote: > > > > I have a system that mostly works. But implementing XML output requires > > StringEscapeUtils from commons-text. I know we are reluctant to include > > other packages. So my thought is that we provide the XML option as an > > example so that we don't include the commons-text in the package. > > > > My strategy is to separate the formatting into 2 components. > > > > OptionFormat -- Defines the output format for options. What gets > displayed > > on the syntax options, and the option table contents. I have a default > > implementation that provides the same data as the current HelpFormatter > one. > > > > OutputFormat -- Defines the serialization format for the OptionFormat. I > > have two implementations. Text which outputs the current format, XML > for > > xml output option format data, and APT format in an example. > > > > My next step is to verify that I can implement the Rat help system. > > > > > > > > Imp > > > > On Fri, Sep 20, 2024 at 12:47 PM Gary Gregory > > wrote: > > > >> Looking forward to it 😀 > >> > >> Gary > >> > >> On Fri, Sep 20, 2024, 3:56 AM Claude Warren wrote: > >> > >>> I have been working on Rat and have a set of classes that output > >> markdown. > >>> I think I can make CLI HelpFormtter system take a class to output the > >> data > >>> in any given format. > >>> > >>> What rat is doing now is writing help to a file and using APT format to > >>> include that using Velocity. > >>> > >>> Gary's point that XML provides broad support, and Eric's point about > >>> markdown and the general case for text seems to indicate that > >> applications > >>> need a way to specify how to format the data, as well as access to the > >>> current tooling that makes generating/aggregating the text easier. I > >> will > >>> work on this and create a pull request where we can discuss how it > works. > >>> > >>> On Thu, Sep 19, 2024 at 1:00 PM Eric Pugh < > >> ep...@opensourceconnections.com > > >>> wrote: > >>> > I would love to see the ability to output the help docs in a format > >> that > could be dropped into documentation. In Solr we basically cut and > >> paste > the -h output into the Reference Guide, it works but it’s ugly and > >>> manual. > I’ve been experimenting with some tools that let you run a tool, > >> capture > the output, and incorpo
Re: [CLI] [DISCUSS] Help formatter extension proposal
Quick comment: I don't think we should call anything "seriialize*", it's too close to Java serialization. I'd use "render". Gary On Wed, Sep 25, 2024 at 7:11 AM Claude Warren wrote: > > Some initial code. Note the "help" package name. We can discuss keeping > it or not but it is here to make it easy to see what is new. Also, some > methods added to Util.java > > https://github.com/Claudenw/commons-cli/tree/Help_formatter_extension/src/main/java/org/apache/commons/cli/help > > Overview because I have not written the javadocs yet. > > >- HelpFormatter -- the replacement for the current help formatter. Much >of the formatting functionality has moved. >- Serializer -- a semantic serialization component. Semantic meaning >you serialize things like paragraph, table, header. Serialize meaning you >write a specific serialization format (e.g. text, xhtml, Markdown, etc). >Serializers write to any Appendable implementation. (e.g. StringBuilder or >Writer) >- OptionFormatter -- Handles the formatting of Options (e.g. the '<' and >'>' around arg names, '[' and ']' for optional data, etc Generally does >not need to be set. Defaults match current settings. >- TextStyle -- Guidelines for how to display the text. Serializers are >not required to follow the guidelines. HelpFormatter uses an instance to >set the left padding, the maximum width of the display, and the indent for >paragraphs. >- TableDef a collection of headers, TextStyle (one for each column), and >a list of rows. Where rows are lists of strings one for each column. The >Text style will specify the left padding, max and min text width, indents >for continuation lines, text alignment, and whether the column can be >scaled (FIXED = no). > > In the test classes I added an org.example package that contains an > AptSerializer as an example for markdown and other cases as well as a > "WeirdOptionFormat" which defines a completely different table definition > for the option display. > > Generally extension points are: > >- Writing new Serializers. (set with HelpFormatter.Builder) >- Creating custom table definitions. (set with HelpFormatter.Builder, or >used directly with the Serializer) >- Overriding "printHelp" in the AbstractHelpFormatter" to create a >custom page. This may include calling the serializer and creating new >tables with definitions for custom argument names for example. > > > I will continue to work on this, getting the javadoc in order and ensuring > that we have enough test coverage. Right now you have to run maven with > the "-Djacoco.skip=true" flag to get past the test coverage issue. > > Let me know what you think. > Claude > > > > On Mon, Sep 23, 2024 at 10:58 PM Eric Pugh > wrote: > > > Keep us posted! I would love to contribute a Markdown format. > > > > > On Sep 23, 2024, at 7:20 AM, Claude Warren wrote: > > > > > > I have a system that mostly works. But implementing XML output requires > > > StringEscapeUtils from commons-text. I know we are reluctant to include > > > other packages. So my thought is that we provide the XML option as an > > > example so that we don't include the commons-text in the package. > > > > > > My strategy is to separate the formatting into 2 components. > > > > > > OptionFormat -- Defines the output format for options. What gets > > displayed > > > on the syntax options, and the option table contents. I have a default > > > implementation that provides the same data as the current HelpFormatter > > one. > > > > > > OutputFormat -- Defines the serialization format for the OptionFormat. I > > > have two implementations. Text which outputs the current format, XML > > for > > > xml output option format data, and APT format in an example. > > > > > > My next step is to verify that I can implement the Rat help system. > > > > > > > > > > > > Imp > > > > > > On Fri, Sep 20, 2024 at 12:47 PM Gary Gregory > > > wrote: > > > > > >> Looking forward to it 😀 > > >> > > >> Gary > > >> > > >> On Fri, Sep 20, 2024, 3:56 AM Claude Warren wrote: > > >> > > >>> I have been working on Rat and have a set of classes that output > > >> markdown. > > >>> I think I can make CLI HelpFormtter system take a class to output the > > >> data > > >>> in any given format. > > >>> > > >>> What rat is doing now is writing help to a file and using APT format to > > >>> include that using Velocity. > > >>> > > >>> Gary's point that XML provides broad support, and Eric's point about > > >>> markdown and the general case for text seems to indicate that > > >> applications > > >>> need a way to specify how to format the data, as well as access to the > > >>> current tooling that makes generating/aggregating the text easier. I > > >> will > > >>> work on this and create a pull request where we can discuss how it > > works. > > >>> > > >>> On Thu, Sep 19, 2024 at 1:00 PM Eric Pugh < > > >> ep...@opensourceconnections.com >
