Re: [beanutils] Java plaform for 2.0
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: [CLI] [DISCUSS] Help formatter extension proposal
After more exploration it seems that HelpFormatter is really not designed to be extended. I will have to rethink this. It may make sense to make some of the HelpFormatter methods static so that they can be used in other implementations. On Wed, Sep 18, 2024 at 9:29 AM Claude Warren wrote: > Greetings, > > I have a case in RAT where we want to append a line to the help text when > the option has multiple arguments or when we have defined a default value. > > I have implemented this in a renderOptions() implementation in CLI 1.8.0. > In both cases we use the Option to check for some state and then append to > the optBuf. > > I am now migrating to 1.9.0 and have to do the same thing, but 1.9.0 adds > more functionality to the default renderOptions() method so I have to > rework my implementation. However, had I not known this was the case, I > would have missed the changes and we would have had some rather interesting > bugs later. > > What I am proposing is a new parameter to renderOptions(). A > "Optional Function". If the function returns a String then > it is appended to the optBuf. > > This method would be called near the end of renderOptions. > > Thoughts? > Claude > > -- > LinkedIn: http://www.linkedin.com/in/claudewarren > -- LinkedIn: http://www.linkedin.com/in/claudewarren
Re: [CLI] [DISCUSS] Help formatter extension proposal
Or a new better formatting class? Gary On Wed, Sep 18, 2024, 9:45 AM Claude Warren wrote: > After more exploration it seems that HelpFormatter is really not designed > to be extended. I will have to rethink this. It may make sense to make > some of the HelpFormatter methods static so that they can be used in other > implementations. > > On Wed, Sep 18, 2024 at 9:29 AM Claude Warren wrote: > > > Greetings, > > > > I have a case in RAT where we want to append a line to the help text when > > the option has multiple arguments or when we have defined a default > value. > > > > I have implemented this in a renderOptions() implementation in CLI 1.8.0. > > In both cases we use the Option to check for some state and then append > to > > the optBuf. > > > > I am now migrating to 1.9.0 and have to do the same thing, but 1.9.0 adds > > more functionality to the default renderOptions() method so I have to > > rework my implementation. However, had I not known this was the case, I > > would have missed the changes and we would have had some rather > interesting > > bugs later. > > > > What I am proposing is a new parameter to renderOptions(). A > > "Optional Function". If the function returns a String > then > > it is appended to the optBuf. > > > > This method would be called near the end of renderOptions. > > > > Thoughts? > > Claude > > > > -- > > LinkedIn: http://www.linkedin.com/in/claudewarren > > > > > -- > LinkedIn: http://www.linkedin.com/in/claudewarren >
Re: [VOTE] Release Apache Commons IO 2.17.0 based on RC1
[+1] Builds ok, site looks good, javadoc ok, reports ok. - Using: mvn clean install site -s "$HOME/.m2/commons-settings.xml" - On: Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63) Maven home: /Users/hbiestro/Java/apache-maven-3.8.6 Java version: 1.8.0_352, vendor: Azul Systems, Inc., runtime: /Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "14.6.1", arch: "aarch64", family: "Mac" Cheers - 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 think that help formatting really comes down to building a textual matrix
from a list of Options. To do this we need to have several things:
1. A list of headers (text for the columns in the table)
2. The minimum and maximum width for each column. (perhaps as a % of the
width)
3. A method that converts the Option into the columns.
Interface TableDef {
String header();
String footer();
List columnHeaders();
int[] minimumColumnSize();
int[] maximumColumnSize();
Iterator> rows();
}
abstract class AbstractHelpFormatter {
int width;
List tables;
printUsage(PrintWriter writer, String commandLineSyntax) {
// print the command line syntax.
for(TableDef table : tables) {
writer.println(table.header())
for(String line :
formatColumns(table.minimumColumnSize(), table.maximumColumnSize(),
columnHeaders())) {
writer.println(line);
}
Iterator> rows = table.rows();
while(rows.hasNext()) {
formatColumns(table.minimumColumnSize(),
table.maximumColumnSize(), row.next()).forEach(writer::println);
}
writer.println(table.footer())
}
}
}
where formatColumns is a static method in HelpFormatter that will produce a
list of Strings necessary to properly display the wrapped columns. Any
helper functions for formatColumns() would also be public static so that
they can be reused for other implementations.
The concrete implementation would be the implementation we currently have
adapted to fit this pattern.
I have code like this in the new RAT code.
Does this make sense to you?
Claude
On Wed, Sep 18, 2024 at 2:57 PM Eric Pugh
wrote:
> In Solr we added some additional formatting methods to our Tool.java
> interface to help with formatting the various tools that use commons-cli:
>
> [image: solr.png]
>
> solr/solr/core/src/java/org/apache/solr/cli/Tool.java at main · apache/solr
>
> github.com
>
>
>
>
> PackageTool had a very very custom help output that we didn’t want to lose
> when we redid things, so it has a custom getHeader:
>
>
>
> [image: solr.png]
>
> solr/solr/core/src/java/org/apache/solr/cli/PackageTool.java at main ·
> apache/solr
>
> github.com
>
>
>
>
> Whereas CreateTool had a short bit of additional text, and then the
> options:
> https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/cli/CreateTool.java#L70
>
> And our PostLogsTool doesn’t use any of those extra formatting helpers:
> https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/cli/PostLogsTool.java
>
>
> I do wish this had been part of commons-cli!
>
> Eric
>
>
>
> On Sep 18, 2024, at 9:52 AM, Gary Gregory wrote:
>
> Or a new better formatting class?
>
> Gary
>
> On Wed, Sep 18, 2024, 9:45 AM Claude Warren wrote:
>
> After more exploration it seems that HelpFormatter is really not designed
> to be extended. I will have to rethink this. It may make sense to make
> some of the HelpFormatter methods static so that they can be used in other
> implementations.
>
> On Wed, Sep 18, 2024 at 9:29 AM Claude Warren wrote:
>
> Greetings,
>
> I have a case in RAT where we want to append a line to the help text when
> the option has multiple arguments or when we have defined a default
>
> value.
>
>
> I have implemented this in a renderOptions() implementation in CLI 1.8.0.
> In both cases we use the Option to check for some state and then append
>
> to
>
> the optBuf.
>
> I am now migrating to 1.9.0 and have to do the same thing, but 1.9.0 adds
> more functionality to the default renderOptions() method so I have to
> rework my implementation. However, had I not known this was the case, I
> would have missed the changes and we would have had some rather
>
> interesting
>
> bugs later.
>
> What I am proposing is a new parameter to renderOptions(). A
> "Optional Function". If the function returns a String
>
> then
>
> it is appended to the optBuf.
>
> This method would be called near the end of renderOptions.
>
> Thoughts?
> Claude
>
> --
> LinkedIn: http://www.linkedin.com/in/claudewarren
>
>
>
> --
> LinkedIn: http://www.linkedin.com/in/claudewarren
>
>
> ___
> *Eric Pugh **| *Founder | OpenSource Connec
[CLI] [DISCUSS] Help formatter extension proposal
Greetings, I have a case in RAT where we want to append a line to the help text when the option has multiple arguments or when we have defined a default value. I have implemented this in a renderOptions() implementation in CLI 1.8.0. In both cases we use the Option to check for some state and then append to the optBuf. I am now migrating to 1.9.0 and have to do the same thing, but 1.9.0 adds more functionality to the default renderOptions() method so I have to rework my implementation. However, had I not known this was the case, I would have missed the changes and we would have had some rather interesting bugs later. What I am proposing is a new parameter to renderOptions(). A "Optional Function". If the function returns a String then it is appended to the optBuf. This method would be called near the end of renderOptions. Thoughts? Claude -- LinkedIn: http://www.linkedin.com/in/claudewarren
Re: [CLI] [DISCUSS] Help formatter extension proposal
If we create something new, it would be nice to have example in tests that
show rendering to XHTML and XML. This means the abstract superclass should
not assume console output. A site can use its own CSS for styling. If we
are flexible enough we should not need to create yet another thing in
the future.
Gary
On Wed, Sep 18, 2024, 11:23 AM Claude Warren wrote:
> I think that help formatting really comes down to building a textual
> matrix from a list of Options. To do this we need to have several things:
>
>1. A list of headers (text for the columns in the table)
>2. The minimum and maximum width for each column. (perhaps as a % of
>the width)
>3. A method that converts the Option into the columns.
>
>
> Interface TableDef {
> String header();
> String footer();
> List columnHeaders();
> int[] minimumColumnSize();
> int[] maximumColumnSize();
> Iterator> rows();
> }
>
> abstract class AbstractHelpFormatter {
> int width;
> List tables;
>
> printUsage(PrintWriter writer, String commandLineSyntax) {
>// print the command line syntax.
>for(TableDef table : tables) {
>writer.println(table.header())
>for(String line :
> formatColumns(table.minimumColumnSize(), table.maximumColumnSize(),
> columnHeaders())) {
>writer.println(line);
>}
>Iterator> rows = table.rows();
>while(rows.hasNext()) {
>formatColumns(table.minimumColumnSize(),
> table.maximumColumnSize(), row.next()).forEach(writer::println);
>}
>writer.println(table.footer())
> }
> }
> }
>
> where formatColumns is a static method in HelpFormatter that will produce
> a list of Strings necessary to properly display the wrapped columns. Any
> helper functions for formatColumns() would also be public static so that
> they can be reused for other implementations.
>
> The concrete implementation would be the implementation we currently have
> adapted to fit this pattern.
>
> I have code like this in the new RAT code.
>
> Does this make sense to you?
>
> Claude
>
>
>
>
> On Wed, Sep 18, 2024 at 2:57 PM Eric Pugh
> wrote:
>
>> In Solr we added some additional formatting methods to our Tool.java
>> interface to help with formatting the various tools that use commons-cli:
>>
>> [image: solr.png]
>>
>> solr/solr/core/src/java/org/apache/solr/cli/Tool.java at main ·
>> apache/solr
>>
>> github.com
>>
>>
>>
>>
>> PackageTool had a very very custom help output that we didn’t want to
>> lose when we redid things, so it has a custom getHeader:
>>
>>
>>
>> [image: solr.png]
>>
>> solr/solr/core/src/java/org/apache/solr/cli/PackageTool.java at main ·
>> apache/solr
>>
>> github.com
>>
>>
>>
>>
>> Whereas CreateTool had a short bit of additional text, and then the
>> options:
>> https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/cli/CreateTool.java#L70
>>
>> And our PostLogsTool doesn’t use any of those extra formatting helpers:
>> https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/cli/PostLogsTool.java
>>
>>
>> I do wish this had been part of commons-cli!
>>
>> Eric
>>
>>
>>
>> On Sep 18, 2024, at 9:52 AM, Gary Gregory wrote:
>>
>> Or a new better formatting class?
>>
>> Gary
>>
>> On Wed, Sep 18, 2024, 9:45 AM Claude Warren wrote:
>>
>> After more exploration it seems that HelpFormatter is really not designed
>> to be extended. I will have to rethink this. It may make sense to make
>> some of the HelpFormatter methods static so that they can be used in other
>> implementations.
>>
>> On Wed, Sep 18, 2024 at 9:29 AM Claude Warren wrote:
>>
>> Greetings,
>>
>> I have a case in RAT where we want to append a line to the help text when
>> the option has multiple arguments or when we have defined a default
>>
>> value.
>>
>>
>> I have implemented this in a renderOptions() implementation in CLI 1.8.0.
>> In both cases we use the Option to check for some state and then append
>>
>> to
>>
>> the optBuf.
>>
>> I am now migrating to 1.9.0 and have to do the same thing, but 1.9.0 adds
>> more functionality to the default renderOptions() method so I have to
>> rework my implementation. However, had I not known this was the case,
[RESULT][VOTE] Release Apache Commons IO 2.17.0 based on RC1
This vote passes with the following binding +1s: - Gary Gregory (ggregory) - Rob Tompkins (chtompki) - Henri Biestro (henrib) Gary On Wed, Sep 18, 2024 at 1:06 PM Henri Biestro wrote: > > > [+1] > > Builds ok, site looks good, javadoc ok, reports ok. > > - Using: > mvn clean install site -s "$HOME/.m2/commons-settings.xml" > - On: > Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63) > Maven home: /Users/hbiestro/Java/apache-maven-3.8.6 > Java version: 1.8.0_352, vendor: Azul Systems, Inc., runtime: > /Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x", version: "14.6.1", arch: "aarch64", family: "Mac" > > Cheers > > - > 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
[RESULT][VOTE][LAZY] Release Apache Commons Parent 75 based on RC1
This lazy vote passes with the following binding +1s: - Gary Gregory (ggregory) Gary On Sun, Sep 15, 2024 at 9:36 AM Gary Gregory wrote: > > My +1 > > Gary > > On Sat, Sep 14, 2024 at 3:53 PM Gary Gregory wrote: > > > > We have updated dependencies since Apache Commons Parent 74 was > > released, so I would like to release Apache Commons Parent 75. > > > > Apache Commons Parent 75 RC1 is available for review here: > > https://dist.apache.org/repos/dist/dev/commons/parent/75-RC1 (svn > > revision 71588) > > > > The Git tag commons-parent-75-RC1 commit for this RC is > > 7ad3fff5ea3017d2dabd593da9ff034d5465cadf which you can browse here: > > > > https://gitbox.apache.org/repos/asf?p=commons-parent.git;a=commit;h=7ad3fff5ea3017d2dabd593da9ff034d5465cadf > > You may checkout this tag using: > > git clone https://gitbox.apache.org/repos/asf/commons-parent.git > > --branch commons-parent-75-RC1 commons-parent-75-RC1 > > > > Maven artifacts are here: > > > > https://repository.apache.org/content/repositories/orgapachecommons-1778/org/apache/commons/commons-parent/75/ > > > > These are the artifacts and their hashes: > > > > #Release SHA-512s > > #Sat Sep 14 19:48:21 UTC 2024 > > commons-parent-75-bom.json=a249d7d8b3367fa935ed745fa626dafde4a039fe0149a1ed52b9c73a19c8b5fca65479ac1c0c54e7d68a08ef0d20c47ba18b30e1731047ae2d8090a3a7b7553b > > commons-parent-75-bom.xml=74c795cc6c8e0c943536c955aa965e7c87974edd2de9a5f268a0a3c0909a81d4c968094c5f613412c6a01a831f05c7b759c909688941d25a81024f288240cfe4 > > commons-parent-75-site.xml=5f045989b2c281c567467548678fe8685efabf5c13104299eea87b6ab6b6a75c9e98b590d7b288b8ec3a06934061709d0851a6dd9d9b45100ee2950908ec2d6c > > commons-parent-75-src.tar.gz=0213ccb19c08cd5f3ed9da65cd82674d157c6de428e7856586a3aa8b1c149849eab673c95085a69f4f686167ca87abf7faf56268681e04cfda5ad53e73a9 > > commons-parent-75-src.zip=f4859457aa1e158ab126f3eca720f5451074cab52b192d373fdbca1dd6d028ad6c0b7f2b6f120d7c6b319f45e85b20aa986da17a2b76f15ac5f1172ea09e59d0 > > org.apache.commons_commons-parent-75.spdx.json=a1bf8155efcae7c0061bf1d2533544095bbbfe8b369ca049e3e4a9ba03c1c4af0aa1b53ad80c6dd5c3fb40ed6a40eb4f72df02fd54eff8e88e5bcd84f65db75a > > > > I have tested this with 'mvn -e -V -Prelease -Ptest-deploy -P jacoco > > -P japicmp clean package site deploy' using: > > > > openjdk version "17.0.12" 2024-07-16 > > OpenJDK Runtime Environment Homebrew (build 17.0.12+0) > > OpenJDK 64-Bit Server VM Homebrew (build 17.0.12+0, mixed mode, sharing) > > > > Apache Maven 3.9.9 (8e8579a9e76f7d015ee5ec7bfcdc97d260186937) > > Maven home: /usr/local/Cellar/maven/3.9.9/libexec > > Java version: 17.0.12, vendor: Homebrew, runtime: > > /usr/local/Cellar/openjdk@17/17.0.12/libexec/openjdk.jdk/Contents/Home > > Default locale: en_US, platform encoding: UTF-8 > > OS name: "mac os x", version: "14.6.1", arch: "x86_64", family: "mac" > > > > Darwin 23.6.0 Darwin Kernel Version 23.6.0: Mon Jul 29 21:13:00 > > PDT 2024; root:xnu-10063.141.2~1/RELEASE_X86_64 x86_64 > > > > Details of changes since 74 are in the release notes: > > > > https://dist.apache.org/repos/dist/dev/commons/parent/75-RC1/RELEASE-NOTES.txt > > > > https://dist.apache.org/repos/dist/dev/commons/parent/75-RC1/site/changes-report.html > > > > Site: > > > > https://dist.apache.org/repos/dist/dev/commons/parent/75-RC1/site/index.html > > (note some *relative* links are broken and the 75 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/75-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-75-RC1 commons-parent-75-RC1 > > cd commons-parent-75-RC1 > > > > 1b) Download and unpack the source archive from: > > > > https://dist.apache.org/repos/dist/dev/commons/parent/75-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
