Re: [VOTE] Release Apache Commons DBCP 2.12.0 based on RC1

[Bruno Kinoshita]

+1

Building fine on

Apache Maven 3.8.5 (3599d3414f046de2324203b78ddcf9b5e4388aa0)
Maven home: /opt/apache-maven-3.8.5
Java version: 17.0.10, vendor: Private Build, runtime:
/usr/lib/jvm/java-17-openjdk-amd64
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.15.0-97-generic", arch: "amd64", family:
"unix"

Release notes OK, dist area archive sigs OK, site reports OK.

Thanks!

On Thu, 29 Feb 2024 at 23:48, Gary Gregory  wrote:

> Hi All,
>
> We have fixed a few bugs and added some enhancements since Apache
> Commons DBCP 2.11.0 was released, so I would like to release Apache
> Commons DBCP 2.12.0.
>
> Apache Commons DBCP 2.12.0 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1
> (svn revision 67637)
>
> The Git tag commons-dbcp-2.12.0-RC1 commit for this RC is
> 49270ef2445b775ed0a6673757d15185d859e6ac which you can browse here:
>
> https://gitbox.apache.org/repos/asf?p=commons-dbcp.git;a=commit;h=49270ef2445b775ed0a6673757d15185d859e6ac
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-dbcp.git
> --branch 
> commons-dbcp-2.12.0-RC1 commons-dbcp-2.12.0-RC1
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1693/org/apache/commons/commons-dbcp2/2.12.0/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Thu Feb 29 22:33:36 UTC 2024
> Apache\ Commons\
>
> DBCP-2.12.0.spdx.rdf.xml=2a949b0ab04a69ed12d826e29fdd22aa4d92fdccd6188974263364323a9a6ac99a099f851299f6237af5b272e042a28e41de71dbb11934b0d10b27a82cd2d31f
>
> commons-dbcp2-2.12.0-bin.tar.gz=2202dbb7145e67ed4c99a4ac9a6716a4886110e4d219ac869c4d81bfe75981cf0535664e2d939b3db5ae3515338101dcc29e10aa7e69576155c42789b6ca966b
>
> commons-dbcp2-2.12.0-bin.zip=d2141744d0a7ad48e456aa0a6254efb706b491f30c6fc0056e2029de9b21f97ac6265508f1513631347e9f72d2da2269815745a0967dc6f3a8d621cb0fb818ce
>
> commons-dbcp2-2.12.0-bom.json=f128916347a2a72e8dd7705f54049041814e40765f75536c10ef18fa43ca1d7e5a77a74a74aa10f446927be35189f3d092edf6abc9436c616eddce293bfa590a
>
> commons-dbcp2-2.12.0-bom.xml=3b4e2a3066085d3ea0ecb1e1c8106ed0b817a7939e85df7fd4d6d2cd386206f1d2a774e77998f25e1c39c577d784c02078d470f2b7998f8af175a22de3f7bc89
>
> commons-dbcp2-2.12.0-javadoc.jar=dac615d144c5e72efb7a46862e4d82ca8726705600731be5e5573ab76061013cdcd9cd301d15e610e5403f223c955040fabdebaa24fe20a17f74cfde02f9
>
> commons-dbcp2-2.12.0-sources.jar=a35d60fcc5835be64f93049823c17c65bd34ceb6fb4c444de122be5e2ea9039dd1df755ff7dd80c2a82a120a8e4dea1beb2d4f178efd8762e00b42e491c17bdb
>
> commons-dbcp2-2.12.0-src.tar.gz=2e115574abd2e8582202dcd35c90b093d5a39c24a1bb7abc6930ec6f10c9eee1c90f00061adcf9e3249a175e4de4eb71374dbf94c81e39bf395dbb360749b01a
>
> commons-dbcp2-2.12.0-src.zip=c2597d665fbc2bfc1adac2a7120295d3a1d72a6fd36d5c02de07cc6735bfb375abb920eba8b78b0d2d562e31207acb1d330cfc558c0769d6d0a0580c85cc796a
>
> commons-dbcp2-2.12.0-test-sources.jar=2262f12da577c7458ef7e12c57ecea399be2837b6a0a675355859e78c337aa961e9a0f99225ad0d15e64ca25b321fb6aaea1aa4ec8e65350c9ace7eeb15eee22
>
> commons-dbcp2-2.12.0-tests.jar=c1fbe0ef2655f32ec8c04ce853d5418176d16bf84f7af94193d8e37c465ef9e26c150e35c9ef0e35fdabfb366f9a49596212c01280f3524198323eaeb00980fe
>
> I have tested this with:
>
> mvn -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site
> deploy
>
> using:
>
> openjdk version "21.0.2" 2024-01-16
> OpenJDK Runtime Environment Homebrew (build 21.0.2)
> OpenJDK 64-Bit Server VM Homebrew (build 21.0.2, mixed mode, sharing)
>
> Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
> Maven home: /usr/local/Cellar/maven/3.9.6/libexec
> Java version: 21.0.2, vendor: Homebrew, runtime:
> /usr/local/Cellar/openjdk/21.0.2/libexec/openjdk.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "14.3.1", arch: "x86_64", family: "mac"
>
> Darwin  23.3.0 Darwin Kernel Version 23.3.0: Wed Dec 20 21:28:58
> PST 2023; root:xnu-10002.81.5~7/RELEASE_X86_64 x86_64
>
> Details of changes since 2.11.0 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1/RELEASE-NOTES.txt
>
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1/site/changes-report.html
>
> Site:
>
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1/site/index.html
> (note some *relative* links are broken and the 2.12.0 directories
> are not yet created - these will be OK once the site is deployed.)
>
> JApiCmp Report (compared to 2.11.0):
>
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1/site/japicmp.html
> RAT Report:
>
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.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 

[VOTE] Release Apache Commons DBCP 2.12.0 based on RC1

[Gary Gregory]

Hi All,

We have fixed a few bugs and added some enhancements since Apache
Commons DBCP 2.11.0 was released, so I would like to release Apache
Commons DBCP 2.12.0.

Apache Commons DBCP 2.12.0 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1
(svn revision 67637)

The Git tag commons-dbcp-2.12.0-RC1 commit for this RC is
49270ef2445b775ed0a6673757d15185d859e6ac which you can browse here:

https://gitbox.apache.org/repos/asf?p=commons-dbcp.git;a=commit;h=49270ef2445b775ed0a6673757d15185d859e6ac
You may checkout this tag using:
git clone https://gitbox.apache.org/repos/asf/commons-dbcp.git
--branch commons-dbcp-2.12.0-RC1 commons-dbcp-2.12.0-RC1

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1693/org/apache/commons/commons-dbcp2/2.12.0/

These are the artifacts and their hashes:

#Release SHA-512s
#Thu Feb 29 22:33:36 UTC 2024
Apache\ Commons\
DBCP-2.12.0.spdx.rdf.xml=2a949b0ab04a69ed12d826e29fdd22aa4d92fdccd6188974263364323a9a6ac99a099f851299f6237af5b272e042a28e41de71dbb11934b0d10b27a82cd2d31f
commons-dbcp2-2.12.0-bin.tar.gz=2202dbb7145e67ed4c99a4ac9a6716a4886110e4d219ac869c4d81bfe75981cf0535664e2d939b3db5ae3515338101dcc29e10aa7e69576155c42789b6ca966b
commons-dbcp2-2.12.0-bin.zip=d2141744d0a7ad48e456aa0a6254efb706b491f30c6fc0056e2029de9b21f97ac6265508f1513631347e9f72d2da2269815745a0967dc6f3a8d621cb0fb818ce
commons-dbcp2-2.12.0-bom.json=f128916347a2a72e8dd7705f54049041814e40765f75536c10ef18fa43ca1d7e5a77a74a74aa10f446927be35189f3d092edf6abc9436c616eddce293bfa590a
commons-dbcp2-2.12.0-bom.xml=3b4e2a3066085d3ea0ecb1e1c8106ed0b817a7939e85df7fd4d6d2cd386206f1d2a774e77998f25e1c39c577d784c02078d470f2b7998f8af175a22de3f7bc89
commons-dbcp2-2.12.0-javadoc.jar=dac615d144c5e72efb7a46862e4d82ca8726705600731be5e5573ab76061013cdcd9cd301d15e610e5403f223c955040fabdebaa24fe20a17f74cfde02f9
commons-dbcp2-2.12.0-sources.jar=a35d60fcc5835be64f93049823c17c65bd34ceb6fb4c444de122be5e2ea9039dd1df755ff7dd80c2a82a120a8e4dea1beb2d4f178efd8762e00b42e491c17bdb
commons-dbcp2-2.12.0-src.tar.gz=2e115574abd2e8582202dcd35c90b093d5a39c24a1bb7abc6930ec6f10c9eee1c90f00061adcf9e3249a175e4de4eb71374dbf94c81e39bf395dbb360749b01a
commons-dbcp2-2.12.0-src.zip=c2597d665fbc2bfc1adac2a7120295d3a1d72a6fd36d5c02de07cc6735bfb375abb920eba8b78b0d2d562e31207acb1d330cfc558c0769d6d0a0580c85cc796a
commons-dbcp2-2.12.0-test-sources.jar=2262f12da577c7458ef7e12c57ecea399be2837b6a0a675355859e78c337aa961e9a0f99225ad0d15e64ca25b321fb6aaea1aa4ec8e65350c9ace7eeb15eee22
commons-dbcp2-2.12.0-tests.jar=c1fbe0ef2655f32ec8c04ce853d5418176d16bf84f7af94193d8e37c465ef9e26c150e35c9ef0e35fdabfb366f9a49596212c01280f3524198323eaeb00980fe

I have tested this with:

mvn -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site deploy

using:

openjdk version "21.0.2" 2024-01-16
OpenJDK Runtime Environment Homebrew (build 21.0.2)
OpenJDK 64-Bit Server VM Homebrew (build 21.0.2, mixed mode, sharing)

Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
Maven home: /usr/local/Cellar/maven/3.9.6/libexec
Java version: 21.0.2, vendor: Homebrew, runtime:
/usr/local/Cellar/openjdk/21.0.2/libexec/openjdk.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "14.3.1", arch: "x86_64", family: "mac"

Darwin  23.3.0 Darwin Kernel Version 23.3.0: Wed Dec 20 21:28:58
PST 2023; root:xnu-10002.81.5~7/RELEASE_X86_64 x86_64

Details of changes since 2.11.0 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1/RELEASE-NOTES.txt

https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1/site/changes-report.html

Site:

https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1/site/index.html
(note some *relative* links are broken and the 2.12.0 directories
are not yet created - these will be OK once the site is deployed.)

JApiCmp Report (compared to 2.11.0):

https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1/site/japicmp.html
RAT Report:

https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.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)

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-dbcp.git
--branch commons-dbcp-2.12.0-RC1 commons-dbcp-2.12.0-RC1
cd commons-dbcp-2.12.0-RC1

1b) Download and 

Re: [Net] JUnit 5 migration discussion

[Alex Herbert]

Use of abstract classes does work in JUnit 5. I've written a lot of JUnit 5
tests that use abstract test classes which define the
@ParameterizedTest/@Test fixtures and then concrete child classes that are
run by the framework. It is supported but IIRC it is not recommended in the
JUnit 5 documentation. It has been a while since I looked to see
what alternatives are provided.

IMO the use of an abstract base class that has all the tests is still a
useful pattern. It is used in Commons Collections for the Bloom filter
package to test that implementations of the BloomFilter interfaces all
provide the required functionality. A more convoluted abstract test class
structure is used in Commons Statistics in the distribution and descriptive
packages. These abstract classes define methods to test interface
implementations. The child classes then provide instances of the interface
to test with standard data, and can provide custom data to test them with.
I do not think it is as configurable to have a single class with
@ParameterizedTest methods to test lots of different implementations. It
requires a very large method to stream all the different instances to test
and their data. This pattern is used in Commons RNG to test instances of a
random generator interface, or distribution samplers.

A quick browse of the API finds @TestTemplate which requires registering
providers and a lot more setup. Note that @ParameterizedTest is a built-in
specialization of @TestTemplate. So this is a JUnit5 way to create more
configurable tests which provide combinations of parameters for the test.

I found that using an abstract class I was able to create a test framework
that tested what was required and allowed testing of each implementation
individually. So I could do what I wanted. However I cannot state if it
would be better with @TestTemplate or some other JUnit 5 way to achieve the
same result. I remember trying a few other options but cannot remember why
I gave up and resorted to the abstract class pattern.

Note that it would be better to have VFS on JUnit 5 using abstract classes
than on JUnit 3 or 4. I would try and upgrade one test and see if it works.

Alex


On Thu, 29 Feb 2024 at 20:43, Gary Gregory  wrote:

> Thank you for digging into this Eric.
>
> Another component to consider for JUnit 5 migration is Commons VFS. This
> one is challenging due to some similar JUnit 3 and 4 heritage issues.
>
> It is possible that between Net and VFS, what we need are custom JUnit
> extensions. I had started a Commons Testing repository a long time ago but
> never got far with adding what at the time were JUnit 4 rules.
>
> I too find some of the JUnit 5 changes baffling but that's what we got...
> unless we want to switch to TextNG or some other test framework which would
> be a big change.
>
> Gary
>
>
> On Thu, Feb 29, 2024, 3:13 PM Elric V  wrote:
>
> > Hi folks,
> >
> > I recently made some changes to commons-cli to move it from JUnit 4 to
> > JUnit 5. This was mostly straightforward, and I think it went pretty
> well.
> >
> > Currently looking into doing the same for commons-net, but there are a
> > couple of tricky tests that probably require some up front discussion,
> > mostly JUnit 3 style tests, and one tricky JUnit 4 Parameterized Test.
> >
> > In previous versions, test classes could be extended and their test
> > methods would be executed as part of the child class' execution. This
> > was true for testt methods annotated with JUnit 4's @Test, or JUnit 3's
> > test-prefix naming convention.
> >
> > Unfortunately, this is no longer the case in JUnit 5. I think this is a
> > poor design decision on their part, as it makes it significantly harder
> > to move to JUnit 5, and it makes certain types of tests just plain
> > difficult. There is some discussion about this in the JUnit community
> > [1], but I can't predict whether this will ever be resolved in a way to
> > makes commons-net's upgrade any easier.
> >
> > One of those cases is AbstractFTPParseTest and its children. This
> > abstract base class has 11 concrete test classes. I'm struggling to see
> > a minimally invasive way to migrate these to JUnit 5. I'm loath to use a
> > heavy handed approach there.
> >
> > A second tricky case is FTPSClientTest, which is a Parameterized test of
> > a form that no longer exists in JUnit 5. It basically creates two
> > instances of a test class with a boolean flag (once true, once false).
> >
> > JUnit 5's @ParameterizedTest annotation operates on the **test method**
> > level, not on the class level, which I think would make the test case
> > slower and harded to read.
> >
> > An alternative approach would be to use Dynamic Tests, which basically
> > generate test cases programmatically, but again, that makes grokking the
> > test a lot more difficult as it requires a greater understanding of
> > JUnit's features.
> >
> > Any insights into this would be greatly appreciated.
> >
> > Best,
> >
> > Elric
> >
> > [1] 

Re: [Net] JUnit 5 migration discussion

[sebb]

Would it make sense to just convert the JUnit 3 tests to JUnit4?
Or would that be a waste of time?

On Thu, 29 Feb 2024 at 21:19, Gary Gregory  wrote:
>
> Oops, I mean TestNG.
>
> Gary
>
> On Thu, Feb 29, 2024, 3:41 PM Gary Gregory  wrote:
>
> > Thank you for digging into this Eric.
> >
> > Another component to consider for JUnit 5 migration is Commons VFS. This
> > one is challenging due to some similar JUnit 3 and 4 heritage issues.
> >
> > It is possible that between Net and VFS, what we need are custom JUnit
> > extensions. I had started a Commons Testing repository a long time ago but
> > never got far with adding what at the time were JUnit 4 rules.
> >
> > I too find some of the JUnit 5 changes baffling but that's what we got...
> > unless we want to switch to TextNG or some other test framework which would
> > be a big change.
> >
> > Gary
> >
> >
> > On Thu, Feb 29, 2024, 3:13 PM Elric V  wrote:
> >
> >> Hi folks,
> >>
> >> I recently made some changes to commons-cli to move it from JUnit 4 to
> >> JUnit 5. This was mostly straightforward, and I think it went pretty well.
> >>
> >> Currently looking into doing the same for commons-net, but there are a
> >> couple of tricky tests that probably require some up front discussion,
> >> mostly JUnit 3 style tests, and one tricky JUnit 4 Parameterized Test.
> >>
> >> In previous versions, test classes could be extended and their test
> >> methods would be executed as part of the child class' execution. This
> >> was true for testt methods annotated with JUnit 4's @Test, or JUnit 3's
> >> test-prefix naming convention.
> >>
> >> Unfortunately, this is no longer the case in JUnit 5. I think this is a
> >> poor design decision on their part, as it makes it significantly harder
> >> to move to JUnit 5, and it makes certain types of tests just plain
> >> difficult. There is some discussion about this in the JUnit community
> >> [1], but I can't predict whether this will ever be resolved in a way to
> >> makes commons-net's upgrade any easier.
> >>
> >> One of those cases is AbstractFTPParseTest and its children. This
> >> abstract base class has 11 concrete test classes. I'm struggling to see
> >> a minimally invasive way to migrate these to JUnit 5. I'm loath to use a
> >> heavy handed approach there.
> >>
> >> A second tricky case is FTPSClientTest, which is a Parameterized test of
> >> a form that no longer exists in JUnit 5. It basically creates two
> >> instances of a test class with a boolean flag (once true, once false).
> >>
> >> JUnit 5's @ParameterizedTest annotation operates on the **test method**
> >> level, not on the class level, which I think would make the test case
> >> slower and harded to read.
> >>
> >> An alternative approach would be to use Dynamic Tests, which basically
> >> generate test cases programmatically, but again, that makes grokking the
> >> test a lot more difficult as it requires a greater understanding of
> >> JUnit's features.
> >>
> >> Any insights into this would be greatly appreciated.
> >>
> >> Best,
> >>
> >> Elric
> >>
> >> [1] https://github.com/junit-team/junit5/issues/960
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >>

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

Re: [Net] JUnit 5 migration discussion

[Gary Gregory]

Oops, I mean TestNG.

Gary

On Thu, Feb 29, 2024, 3:41 PM Gary Gregory  wrote:

> Thank you for digging into this Eric.
>
> Another component to consider for JUnit 5 migration is Commons VFS. This
> one is challenging due to some similar JUnit 3 and 4 heritage issues.
>
> It is possible that between Net and VFS, what we need are custom JUnit
> extensions. I had started a Commons Testing repository a long time ago but
> never got far with adding what at the time were JUnit 4 rules.
>
> I too find some of the JUnit 5 changes baffling but that's what we got...
> unless we want to switch to TextNG or some other test framework which would
> be a big change.
>
> Gary
>
>
> On Thu, Feb 29, 2024, 3:13 PM Elric V  wrote:
>
>> Hi folks,
>>
>> I recently made some changes to commons-cli to move it from JUnit 4 to
>> JUnit 5. This was mostly straightforward, and I think it went pretty well.
>>
>> Currently looking into doing the same for commons-net, but there are a
>> couple of tricky tests that probably require some up front discussion,
>> mostly JUnit 3 style tests, and one tricky JUnit 4 Parameterized Test.
>>
>> In previous versions, test classes could be extended and their test
>> methods would be executed as part of the child class' execution. This
>> was true for testt methods annotated with JUnit 4's @Test, or JUnit 3's
>> test-prefix naming convention.
>>
>> Unfortunately, this is no longer the case in JUnit 5. I think this is a
>> poor design decision on their part, as it makes it significantly harder
>> to move to JUnit 5, and it makes certain types of tests just plain
>> difficult. There is some discussion about this in the JUnit community
>> [1], but I can't predict whether this will ever be resolved in a way to
>> makes commons-net's upgrade any easier.
>>
>> One of those cases is AbstractFTPParseTest and its children. This
>> abstract base class has 11 concrete test classes. I'm struggling to see
>> a minimally invasive way to migrate these to JUnit 5. I'm loath to use a
>> heavy handed approach there.
>>
>> A second tricky case is FTPSClientTest, which is a Parameterized test of
>> a form that no longer exists in JUnit 5. It basically creates two
>> instances of a test class with a boolean flag (once true, once false).
>>
>> JUnit 5's @ParameterizedTest annotation operates on the **test method**
>> level, not on the class level, which I think would make the test case
>> slower and harded to read.
>>
>> An alternative approach would be to use Dynamic Tests, which basically
>> generate test cases programmatically, but again, that makes grokking the
>> test a lot more difficult as it requires a greater understanding of
>> JUnit's features.
>>
>> Any insights into this would be greatly appreciated.
>>
>> Best,
>>
>> Elric
>>
>> [1] https://github.com/junit-team/junit5/issues/960
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>

Re: [Net] JUnit 5 migration discussion

[Gary Gregory]

Thank you for digging into this Eric.

Another component to consider for JUnit 5 migration is Commons VFS. This
one is challenging due to some similar JUnit 3 and 4 heritage issues.

It is possible that between Net and VFS, what we need are custom JUnit
extensions. I had started a Commons Testing repository a long time ago but
never got far with adding what at the time were JUnit 4 rules.

I too find some of the JUnit 5 changes baffling but that's what we got...
unless we want to switch to TextNG or some other test framework which would
be a big change.

Gary


On Thu, Feb 29, 2024, 3:13 PM Elric V  wrote:

> Hi folks,
>
> I recently made some changes to commons-cli to move it from JUnit 4 to
> JUnit 5. This was mostly straightforward, and I think it went pretty well.
>
> Currently looking into doing the same for commons-net, but there are a
> couple of tricky tests that probably require some up front discussion,
> mostly JUnit 3 style tests, and one tricky JUnit 4 Parameterized Test.
>
> In previous versions, test classes could be extended and their test
> methods would be executed as part of the child class' execution. This
> was true for testt methods annotated with JUnit 4's @Test, or JUnit 3's
> test-prefix naming convention.
>
> Unfortunately, this is no longer the case in JUnit 5. I think this is a
> poor design decision on their part, as it makes it significantly harder
> to move to JUnit 5, and it makes certain types of tests just plain
> difficult. There is some discussion about this in the JUnit community
> [1], but I can't predict whether this will ever be resolved in a way to
> makes commons-net's upgrade any easier.
>
> One of those cases is AbstractFTPParseTest and its children. This
> abstract base class has 11 concrete test classes. I'm struggling to see
> a minimally invasive way to migrate these to JUnit 5. I'm loath to use a
> heavy handed approach there.
>
> A second tricky case is FTPSClientTest, which is a Parameterized test of
> a form that no longer exists in JUnit 5. It basically creates two
> instances of a test class with a boolean flag (once true, once false).
>
> JUnit 5's @ParameterizedTest annotation operates on the **test method**
> level, not on the class level, which I think would make the test case
> slower and harded to read.
>
> An alternative approach would be to use Dynamic Tests, which basically
> generate test cases programmatically, but again, that makes grokking the
> test a lot more difficult as it requires a greater understanding of
> JUnit's features.
>
> Any insights into this would be greatly appreciated.
>
> Best,
>
> Elric
>
> [1] https://github.com/junit-team/junit5/issues/960
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[Net] JUnit 5 migration discussion

[Elric V]

Hi folks,

I recently made some changes to commons-cli to move it from JUnit 4 to 
JUnit 5. This was mostly straightforward, and I think it went pretty well.


Currently looking into doing the same for commons-net, but there are a 
couple of tricky tests that probably require some up front discussion, 
mostly JUnit 3 style tests, and one tricky JUnit 4 Parameterized Test.


In previous versions, test classes could be extended and their test 
methods would be executed as part of the child class' execution. This 
was true for testt methods annotated with JUnit 4's @Test, or JUnit 3's 
test-prefix naming convention.


Unfortunately, this is no longer the case in JUnit 5. I think this is a 
poor design decision on their part, as it makes it significantly harder 
to move to JUnit 5, and it makes certain types of tests just plain 
difficult. There is some discussion about this in the JUnit community 
[1], but I can't predict whether this will ever be resolved in a way to 
makes commons-net's upgrade any easier.


One of those cases is AbstractFTPParseTest and its children. This 
abstract base class has 11 concrete test classes. I'm struggling to see 
a minimally invasive way to migrate these to JUnit 5. I'm loath to use a 
heavy handed approach there.


A second tricky case is FTPSClientTest, which is a Parameterized test of 
a form that no longer exists in JUnit 5. It basically creates two 
instances of a test class with a boolean flag (once true, once false).


JUnit 5's @ParameterizedTest annotation operates on the **test method** 
level, not on the class level, which I think would make the test case 
slower and harded to read.


An alternative approach would be to use Dynamic Tests, which basically 
generate test cases programmatically, but again, that makes grokking the 
test a lot more difficult as it requires a greater understanding of 
JUnit's features.


Any insights into this would be greatly appreciated.

Best,

Elric

[1] https://github.com/junit-team/junit5/issues/960

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

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

[Romain Manni-Bucau]

Added a comment to explain splitting will have more impacts and BOM does
not even solve it inline.

But stepping back the only issue compress has today is [io] and a bit
[codec].
Most of the needed dependencies can be restore in [compress] - keep in mind
before the dependency code was hosted in [compress] and everyone was happy.
It will also avoid a design pitfall [compress] got since, it integrates
with some 3rd parties but not genericly so it would be saner to define a
real API for these integration (unwrapping etc) rather than integrating
with some other commons and forgetting about all other wrappers we'll
encounter.

So my plan would be for:

1. revert to drop the optional and additional dependencies (or keep it
really optional for the (de)compresser algorithm really needing it but
typically tar/tar.gz/zip shouldn't need any 3rd party for ex)
2. check how to integrate with custom io (including [io]) types properly
3. use java-templating plugin or a properties to explicitly list the
dependency to add when a dependency is missing and required for advanced
algo (7z, pack200 out of my head).


Le jeu. 29 févr. 2024 à 13:29, sebb  a écrit :

> On Thu, 29 Feb 2024 at 09:53, Piotr P. Karwasz 
> wrote:
> >
> > Hi sebb,
> >
> > On Thu, 29 Feb 2024 at 10:25, sebb  wrote:
> > > > but dependency management can be used to
> > > > prevent version mismatches.
> > >
> > > What dependency management is that? Does Maven manage this?
> > > Seems like users would be forced to use extra controls to ensure only
> > > comaptible combinations of artifacts were used.
> >
> > Maven users would be forced to add a new `commons-compress-bom`
> > artifact (in my PR) to their dependency management. As far as I know
> > other build systems (Gradle, Coursier, probably Apache Ivy) resolve
> > version conflicts with a "highest version wins strategy", so the
> > change will be a no-op for them.
>
> Are you sure about that?
> What if a component specifies a version range?
>

It is a bit worse, the transitivity will be broken since often [io] or
[codec] are used for other needs and [compress] requires some version.
BOM are just working in a single case: when you have a single BOM in the
full project or they don't overlap...almost no way it works for commons.


>
> > Yes, this change might require a developer to supervise the upgrade,
> > so it might require a major version bump to drive their attention.
> > However personally I find it less problematic than having half the
> > dependency stack using `o.a.c.compress` and half of it using
> > `o.a.c.compress2`.
>
> Agreed that might be harder to change automatically.
> But my solution in this case would be a complete package/Maven coord break.
>
> A one-off global edit, but no worries about missing dependency
> restrictions.
>
> > The necessity to align the versions of a multi-module project is
> > something many users are aware of (and the others use Spring Boot
> > dependency management ;-) ).
>
> Or they expect Maven to take care of version management for them.
>
> > Piotr
> >
> > -
> > 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-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

[sebb]

On Thu, 29 Feb 2024 at 09:53, Piotr P. Karwasz  wrote:
>
> Hi sebb,
>
> On Thu, 29 Feb 2024 at 10:25, sebb  wrote:
> > > but dependency management can be used to
> > > prevent version mismatches.
> >
> > What dependency management is that? Does Maven manage this?
> > Seems like users would be forced to use extra controls to ensure only
> > comaptible combinations of artifacts were used.
>
> Maven users would be forced to add a new `commons-compress-bom`
> artifact (in my PR) to their dependency management. As far as I know
> other build systems (Gradle, Coursier, probably Apache Ivy) resolve
> version conflicts with a "highest version wins strategy", so the
> change will be a no-op for them.

Are you sure about that?
What if a component specifies a version range?

> Yes, this change might require a developer to supervise the upgrade,
> so it might require a major version bump to drive their attention.
> However personally I find it less problematic than having half the
> dependency stack using `o.a.c.compress` and half of it using
> `o.a.c.compress2`.

Agreed that might be harder to change automatically.
But my solution in this case would be a complete package/Maven coord break.

A one-off global edit, but no worries about missing dependency restrictions.

> The necessity to align the versions of a multi-module project is
> something many users are aware of (and the others use Spring Boot
> dependency management ;-) ).

Or they expect Maven to take care of version management for them.

> Piotr
>
> -
> 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-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

[Piotr P. Karwasz]

Hi sebb,

On Thu, 29 Feb 2024 at 10:25, sebb  wrote:
> > but dependency management can be used to
> > prevent version mismatches.
>
> What dependency management is that? Does Maven manage this?
> Seems like users would be forced to use extra controls to ensure only
> comaptible combinations of artifacts were used.

Maven users would be forced to add a new `commons-compress-bom`
artifact (in my PR) to their dependency management. As far as I know
other build systems (Gradle, Coursier, probably Apache Ivy) resolve
version conflicts with a "highest version wins strategy", so the
change will be a no-op for them.

Yes, this change might require a developer to supervise the upgrade,
so it might require a major version bump to drive their attention.
However personally I find it less problematic than having half the
dependency stack using `o.a.c.compress` and half of it using
`o.a.c.compress2`.

The necessity to align the versions of a multi-module project is
something many users are aware of (and the others use Spring Boot
dependency management ;-) ).

Piotr

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

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

[sebb]

On Thu, 29 Feb 2024 at 00:13, Piotr P. Karwasz  wrote:
>
> Hi sebb,
>
> On Wed, 28 Feb 2024 at 23:48, sebb  wrote:
> > > Remark that I am talking about moving whole packages to new artifacts.
> >
> > Will these packages be renamed?
> >
> > If not, then I don't see how you can prevent possible class duplication.
>
> Do they need to be renamed? This breaks backward compatibility.

Yes, to avoid class chaos.

> A user could have duplicated classes if he has an old
> `commons-compress` 1.26.0 together with a newer
> `commons-compress-core`,

My point exactly.

> but dependency management can be used to
> prevent version mismatches.

What dependency management is that? Does Maven manage this?
Seems like users would be forced to use extra controls to ensure only
comaptible combinations of artifacts were used.

> Since an example is better than a thousand words I submitted a PoC on
> how to split Commons Compress:
>
> https://github.com/apache/commons-compress/pull/490
>
> A simple `mvn clean verify` succeeds. I just need to smoothen out the
> CI's failures.

A single build cannot prove that the solution works in the Maven
environment with multiple releases present.

> Piotr
>
> -
> 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