You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Matt Juntunen <ma...@gmail.com> on 2022/06/10 01:22:50 UTC
[configuration] Jakarta mailapi 2.0.1
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 javamail api (javax to jakarta).
This change has also been discussed recently for commons-email and
ultimately rejected in favor of backwards compatibility [2]. The
situation in configuration is a bit different, however, because
1. the mailapi dependency is optional and
2. it is not part of the public API and could be considered a
convenience type conversion.
As far as I can tell, the only impacted users would be those using the
Configuration.get(Class<T> cls, String key) method to get a mailapi
InternetAddress object. If we go with this change, calls using the
previous mailapi InternetAddress class, such as
Configuration.get(javax.mail.internet.InternetAddress.class, key)
would begin to throw ConversionExceptions. Users would then need to
update their mailapi version and begin using
Configuration.get(jakarta.mail.internet.InternetAddress.class, key)
Is anyone opposed to this change?
Regards,
Matt J
[1] https://github.com/apache/commons-configuration/pull/185
[2] https://github.com/apache/commons-email/pull/80
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [configuration] Jakarta mailapi 2.0.1
Posted by Bruno Kinoshita <br...@gmail.com>.
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
are certain a vast majority of users have migrated to jakarta.
Sorry for the radio silence in that PR, and thanks for taking over Matt! 🎉
-Bruno
On Sun, 12 Jun 2022 at 10:26, Matt Juntunen <ma...@gmail.com>
wrote:
> 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 support for the old API may actually require users to
> update their code (as described in my initial email), effectively
> breaking backwards compatibility. However, we do want to support the
> newer mailapi version as well so we do not force users to use an
> outdated dependency.
>
> So, unless anyone objects, I will plan on resurrecting Bruno's PR
> within the next few days and merging it in.
>
> Regards,
> Matt J
>
>
> [1] https://github.com/apache/commons-configuration/pull/107
>
> On Fri, Jun 10, 2022 at 4:32 PM Emmanuel Bourg <eb...@apache.org> wrote:
> >
> > 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-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [configuration] Jakarta mailapi 2.0.1
Posted by Matt Juntunen <ma...@gmail.com>.
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 support for the old API may actually require users to
update their code (as described in my initial email), effectively
breaking backwards compatibility. However, we do want to support the
newer mailapi version as well so we do not force users to use an
outdated dependency.
So, unless anyone objects, I will plan on resurrecting Bruno's PR
within the next few days and merging it in.
Regards,
Matt J
[1] https://github.com/apache/commons-configuration/pull/107
On Fri, Jun 10, 2022 at 4:32 PM Emmanuel Bourg <eb...@apache.org> wrote:
>
> 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [configuration] Jakarta mailapi 2.0.1
Posted by Emmanuel Bourg <eb...@apache.org>.
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [configuration] Jakarta mailapi 2.0.1
Posted by Rob Spoor <ap...@icemanx.nl>.
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
INTERNET_ADDRESS_CLASSNAME_JAVAX and INTERNET_ADDRESS_CLASSNAME_JAKARTA
as examples.
2) Let the toInternetAddress take an additional class name argument
that's used instead of the hard-coded constant.
3) Change the class name check:
} else if (cls.getName().equals(INTERNET_ADDRESS_CLASSNAME_JAVAX)
|| cls.getName().equals(INTERNET_ADDRESS_CLASSNAME_JAKARTA)) {
return toInternetAddress(value, cls.getName());
You can even have dependencies for both JavaMail versions at the same
time, so you can still unit test both.
On 10/06/2022 20:41, Matt Sicker wrote:
> Seems reasonable to me given the use case.
>
> —
> Matt Sicker
>
>> On Jun 9, 2022, at 20:23, Matt Juntunen <ma...@gmail.com> 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 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 javamail api (javax to jakarta).
>> This change has also been discussed recently for commons-email and
>> ultimately rejected in favor of backwards compatibility [2]. The
>> situation in configuration is a bit different, however, because
>> 1. the mailapi dependency is optional and
>> 2. it is not part of the public API and could be considered a
>> convenience type conversion.
>>
>> As far as I can tell, the only impacted users would be those using the
>> Configuration.get(Class<T> cls, String key) method to get a mailapi
>> InternetAddress object. If we go with this change, calls using the
>> previous mailapi InternetAddress class, such as
>>
>> Configuration.get(javax.mail.internet.InternetAddress.class, key)
>>
>> would begin to throw ConversionExceptions. Users would then need to
>> update their mailapi version and begin using
>>
>> Configuration.get(jakarta.mail.internet.InternetAddress.class, key)
>>
>> Is anyone opposed to this change?
>>
>> Regards,
>> Matt J
>>
>> [1] https://github.com/apache/commons-configuration/pull/185
>> [2] https://github.com/apache/commons-email/pull/80
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [configuration] Jakarta mailapi 2.0.1
Posted by Matt Sicker <bo...@gmail.com>.
Seems reasonable to me given the use case.
—
Matt Sicker
> On Jun 9, 2022, at 20:23, Matt Juntunen <ma...@gmail.com> 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 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 javamail api (javax to jakarta).
> This change has also been discussed recently for commons-email and
> ultimately rejected in favor of backwards compatibility [2]. The
> situation in configuration is a bit different, however, because
> 1. the mailapi dependency is optional and
> 2. it is not part of the public API and could be considered a
> convenience type conversion.
>
> As far as I can tell, the only impacted users would be those using the
> Configuration.get(Class<T> cls, String key) method to get a mailapi
> InternetAddress object. If we go with this change, calls using the
> previous mailapi InternetAddress class, such as
>
> Configuration.get(javax.mail.internet.InternetAddress.class, key)
>
> would begin to throw ConversionExceptions. Users would then need to
> update their mailapi version and begin using
>
> Configuration.get(jakarta.mail.internet.InternetAddress.class, key)
>
> Is anyone opposed to this change?
>
> Regards,
> Matt J
>
> [1] https://github.com/apache/commons-configuration/pull/185
> [2] https://github.com/apache/commons-email/pull/80
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>