+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:
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
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
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.
> >
> >
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
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
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
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
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
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
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
11 matches
Mail list logo
