Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [messaging-dev] Meeting minutes from 16th June 2021
Hi all,

I found out that after the github repositories were moved to a new location, the link to the meeting notes changed to:
We should now release version 3.1 so that it makes it into Jakarta EE 10, even with the few changes that we currently have in the master branch: https://github.com/jakartaee/messaging/pulls?q=label%3A3.1+.
Once we have that, we can come back to our discussion from last year and start thinking about the new lite API which we agreed is the best approach to evolve Jakarta Messaging in the future.

All the best,

Ondro

ut 22. 6. 2021 o 1:09 Ondro Mihályi <ondrej.mihalyi@xxxxxxxxx> napísal(a):
Hi all,

Here are minutes from our meeting the previous week. They are published at https://eclipse-ee4j.github.io/messaging/minutes/2021-06-16.html. I copy the minutes also here:

16th June 2021

Attendees

  • Ivar Grimstad (Eclipse Foundation)
  • Ed Bratt (Oracle)
  • David Blevins (Tomitribe)
  • Jonathan Gallimore (Tomitribe)
  • Emmanuel Hugonnet (Red Hat).
  • Daniel Kec (Oracle)
  • Tanja Obradovic (Eclipse Foundation)
  • Luke Saker (IBM)
  • Reza Rahman
  • Clebert Suconic (Red Hat)
  • Ondro Mihalyi (Payara)

Minutes

  • (Ondro) EE Messaging 3.1 plan as was approved recently didn’t have high goals, maybe we can add new features, but we aim here to discuss longer plans for EE Messaging
  • (Clebert) JMS is more than 20 years long and has a lot of legacy, which isn’t needed anymore and there’s a lot of usecases where it’s complicated or not possible to use it in the current state
  • (Reza) Presented a document that triages existing issues into categories and priorities
  • (Ondro) An idea: old API should be separated or maybe even create a new messaging spec side by side with the old spec
  • (David) it makes sense to separate the old API and and make it optional, maybe even create a “lite” profile with only the new API
  • (David and Clebert) The new API should be simple and allow that semantics are up to the implementation
  • (Ondro) We should revisit MicroProfile Messaging because they tried to achieve a similar goal
  • (David) it seems we have a consensus
  • (Reza) If there’s a consensus, MS (Azure Service Bus team) is interested to join and collaborate
  • (Ivar) To confirm a consensus, there should be a vote
  • (David) if we leave semantics to the implementations then it’s possible to find a good trade-off between speed and reliability by choosing an appropriate implementation
  • (David) We should create a new issue to cover the “lite” profile or reuse existing related issues - optional/relaxed delivery semantics and guarantees, etc.
  • Some existing related issues
  • (David) Let’s have an issue for each specific guarantee to relax them or make them optional
  • (David) Presented a proposed structure for the messaging-propsals repository, with a structure in the README file for each proposal, for example README for JSON-B proposal

Back to the top