You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by Emmanuel Hugonnet <eh...@apache.org> on 2021/01/27 16:19:06 UTC
[PROPOSAL] JakartaEE support
Hello,
JavaEE has become JakartaEE, and with JakartaEE 9 the 'old' JMS implementations have become obsolete.
While a lot of users are still using the 'old' JMS 2.0 API, we should provide JMS 3.0 client and server so that we can still evolve and provide our users with the future of those API.
As a first step and to avoid duplication of code (at least for now) I have worked on an Apache Maven plugin[1] using eclipse transformer to create the new implementations based on our existing code [2]. This is working nicely and I hope to be able to use WildFly to provide JakartaEE9 certification with the TCK. Thus we don't have to maintain both source code until we want to deprecate the JMS part to move on.
What do you think of this approach ?
Cheers,
Emmanuel
[1]: https://github.com/ehsavoie/batavia/tree/maven
[2]: https://github.com/ehsavoie/activemq-artemis/tree/batavia
Re: [PROPOSAL] JakartaEE support
Posted by Emmanuel Hugonnet <eh...@redhat.com>.
I've submitted https://github.com/apache/activemq-artemis/pull/3421
Cheers,
Emmanuel
Le 27/01/2021 à 17:55, Emmanuel Hugonnet a écrit :
> Yes, one of the issue that I have is the JMS version for the metadata.
> That's one of the change I made in the current source code, to be able to set it via a properties file.
> Emmanuel
>
> Le 27/01/2021 à 17:38, Jonathan Gallimore a écrit :
>> We've been doing this in TomEE (including the bundled ActiveMQ Classic) for
>> a little while (I actually got to contribute a little to the work in the
>> Eclipse Transformer itself :) ), and the rationale was much the same as
>> yours; we didn't want to maintain the code in two namespaces. There are a
>> few things the transformer didn't catch, but we're able to patch those in
>> as part of our build. As an approach, it seems to have worked quite well
>> so far, and I personally quite like it.
>>
>> Jon
>>
>> On Wed, Jan 27, 2021 at 4:19 PM Emmanuel Hugonnet <eh...@apache.org>
>> wrote:
>>
>>> Hello,
>>> JavaEE has become JakartaEE, and with JakartaEE 9 the 'old' JMS
>>> implementations have become obsolete.
>>> While a lot of users are still using the 'old' JMS 2.0 API, we should
>>> provide JMS 3.0 client and server so that we can still evolve and provide
>>> our users with the future of those API.
>>> As a first step and to avoid duplication of code (at least for now) I have
>>> worked on an Apache Maven plugin[1] using eclipse transformer to create the
>>> new implementations based on our existing code [2]. This is working nicely
>>> and I hope to be able to use WildFly to provide JakartaEE9 certification
>>> with the TCK. Thus we don't have to maintain both source code until we want
>>> to deprecate the JMS part to move on.
>>> What do you think of this approach ?
>>> Cheers,
>>> Emmanuel
>>>
>>>
>>> [1]: https://github.com/ehsavoie/batavia/tree/maven
>>> [2]: https://github.com/ehsavoie/activemq-artemis/tree/batavia
>>>
Re: [PROPOSAL] JakartaEE support
Posted by Emmanuel Hugonnet <eh...@redhat.com>.
Yes, one of the issue that I have is the JMS version for the metadata.
That's one of the change I made in the current source code, to be able to set it via a properties file.
Emmanuel
Le 27/01/2021 à 17:38, Jonathan Gallimore a écrit :
> We've been doing this in TomEE (including the bundled ActiveMQ Classic) for
> a little while (I actually got to contribute a little to the work in the
> Eclipse Transformer itself :) ), and the rationale was much the same as
> yours; we didn't want to maintain the code in two namespaces. There are a
> few things the transformer didn't catch, but we're able to patch those in
> as part of our build. As an approach, it seems to have worked quite well
> so far, and I personally quite like it.
>
> Jon
>
> On Wed, Jan 27, 2021 at 4:19 PM Emmanuel Hugonnet <eh...@apache.org>
> wrote:
>
>> Hello,
>> JavaEE has become JakartaEE, and with JakartaEE 9 the 'old' JMS
>> implementations have become obsolete.
>> While a lot of users are still using the 'old' JMS 2.0 API, we should
>> provide JMS 3.0 client and server so that we can still evolve and provide
>> our users with the future of those API.
>> As a first step and to avoid duplication of code (at least for now) I have
>> worked on an Apache Maven plugin[1] using eclipse transformer to create the
>> new implementations based on our existing code [2]. This is working nicely
>> and I hope to be able to use WildFly to provide JakartaEE9 certification
>> with the TCK. Thus we don't have to maintain both source code until we want
>> to deprecate the JMS part to move on.
>> What do you think of this approach ?
>> Cheers,
>> Emmanuel
>>
>>
>> [1]: https://github.com/ehsavoie/batavia/tree/maven
>> [2]: https://github.com/ehsavoie/activemq-artemis/tree/batavia
>>
Re: [PROPOSAL] JakartaEE support
Posted by Jonathan Gallimore <jo...@gmail.com>.
We've been doing this in TomEE (including the bundled ActiveMQ Classic) for
a little while (I actually got to contribute a little to the work in the
Eclipse Transformer itself :) ), and the rationale was much the same as
yours; we didn't want to maintain the code in two namespaces. There are a
few things the transformer didn't catch, but we're able to patch those in
as part of our build. As an approach, it seems to have worked quite well
so far, and I personally quite like it.
Jon
On Wed, Jan 27, 2021 at 4:19 PM Emmanuel Hugonnet <eh...@apache.org>
wrote:
> Hello,
> JavaEE has become JakartaEE, and with JakartaEE 9 the 'old' JMS
> implementations have become obsolete.
> While a lot of users are still using the 'old' JMS 2.0 API, we should
> provide JMS 3.0 client and server so that we can still evolve and provide
> our users with the future of those API.
> As a first step and to avoid duplication of code (at least for now) I have
> worked on an Apache Maven plugin[1] using eclipse transformer to create the
> new implementations based on our existing code [2]. This is working nicely
> and I hope to be able to use WildFly to provide JakartaEE9 certification
> with the TCK. Thus we don't have to maintain both source code until we want
> to deprecate the JMS part to move on.
> What do you think of this approach ?
> Cheers,
> Emmanuel
>
>
> [1]: https://github.com/ehsavoie/batavia/tree/maven
> [2]: https://github.com/ehsavoie/activemq-artemis/tree/batavia
>