No objections from me. I'm +1 to normally killing old code too, but I think
in this case it might be simple to keep both working in [configuration] as
users appear to be still transitioning JEE apps to the jakarta namespace.
We might just need to remember to remove the old package/namespace when we
I'm glad I asked this question :-) Bruno actually submitted a PR with
support for both the old and new namespaces [1] but we decided not to
go with it since it felt like too much to support both versions of the
API. However, this discussion is making me rethink that choice. For
one, dropping suppor
On 10/06/2022 22:16, Rob Spoor wrote:
Since reflection is used to create the instances, isn't it possible to
support both?
+1, we should support both
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.or
Since reflection is used to create the instances, isn't it possible to
support both? There are plenty of containers like JBoss EAP that still
use javax instead of jakarta.
The code changes would be quite small in PropertyConverter:
1) Use two class name constants instead of one. Let's use
INT
Seems reasonable to me given the use case.
—
Matt Sicker
> On Jun 9, 2022, at 20:23, Matt Juntunen wrote:
>
> Hello,
>
> We are slowly getting closer to a 2.8.0 release for
> commons-configuration. One remaining item on the list is a PR [1] for
> bumping the com.sun.mail:mailapi optional depe
Hello,
We are slowly getting closer to a 2.8.0 release for
commons-configuration. One remaining item on the list is a PR [1] for
bumping the com.sun.mail:mailapi optional dependency from 1.6.7 to
2.0.1. I'd like to get community input on this change since it
involves a package name change in the j
