Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jms-dev] Jakarta Messaging Plan for version 3.1 (Jakarta EE 10)

> On May 4, 2021, at 4:29 PM, Ondro Mihályi <ondrej.mihalyi@xxxxxxxxx> wrote:
> Because we didn't have any discussion about new features recently, we could introduce something from the roadmap outlined by David in 2019 in a github issue. I would only go after things that are rather straightforward, long overdue, and already well documented. So from the items in that issue, I suggest to consider only:
> 	• Annotation-Based API for Consuming Messages #243
> 	• CDI Message Consumers #244
> 	• MessagingClient #249
> Additionally, we can support repeatable annotations in some cases, e.g. for JMSDestinationDefinition.
> Should we plan to add the new features as I suggested above? Or it's much more that we can handle and it's better to submit a plan just to add fixes and possibly support repeatable annotations?

My primary influence over thoughts for the plan review is the "for Jakarta EE 10" target.  If we're not targeting a specific release and have unlimited time, I'd go for something more like the first suggestion.  If we're targeting something that has to be done by EE 10, then I'd go for fixes and repeatable annotations.  Note, we can revise our plans via any number of Progress Reviews, so it is possible to start small and add things as they look to become attainable.

There are some practicalities that I think need to be dealt with before we're really positioned to make major changes:

 - Not enough people familiar with adding/modifying tests to the TCK.
 - Effort to separate JMS tests from jakartaee-tck to a project here
 - More compatible implementations filing CCRs

I think it'll be a community effort to separate the JMS section of the TCK from the overall EE TCK and in that process we'll naturally come out the other side with many more people who are positioned to write tests for the ideas we put in the spec.

In terms of implementations, I know I'll need some time to get ActiveMQ classic through the Messaging 3.0 tests.  Once that is done, I personally am in a better place to work on new features/tests.  I don't know what position other implementations are in such as RabbitMQ or RocketMQ, but we should at least reach out to them about interest in passing the current tests.  They could be using the same time to get caught up and we could collectively come out the other side with a lot of implementations at the table.

Anyway, those are some high level thoughts.

I could be persuaded to go for the more aggressive plan, I just don't think it'll be ready for Jakarta EE 10, so it'd probably be better to start small and add to the plan as things become actionable.

My $0.02 for the moment.


Back to the top