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 <ehsav...@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 >>>
