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
Thanks, and a skeleton is fine for now.

On Feb 17, 2022 at 7:10:29 AM, Ondrej Mihályi <ondrej.mihalyi@xxxxxxxxxxx> wrote:
Hi Scott,

I've created a draft PR for release review here: https://github.com/jakartaee/specifications/pull/455. It's really just a skeleton, I'll update it once the release artifacts are available.


Kind regards,

Ondrej Mihályi

Senior Payara Service Engineer
Payara - Supported Enterprise Software for Jakarta EE and MicroProfile Applications
US: +1 415 523 0175 | UK: +44 207 754 0481

----------------------------------------------------------------------------------------------------------------------

Payara is a proud recipient of the prestigious Queen's Award for Enterprise: International Trade 2021

Payara-Tech LDA, Registered Office: Rua Nova de São Pedro no. 54, 2nd floor, room “D�, 9000 048 Funchal, Ilha da Madeira, Portugal

VAT: PT 515158674 | www.payara.fish | info@xxxxxxxxxxx | @Payara_Fish

From: messaging-dev <messaging-dev-bounces@xxxxxxxxxxx> on behalf of Scott Stark <starksm64@xxxxxxxxx>
Sent: 16 February 2022 00:04
To: EE4J Messaging project developer discussions <messaging-dev@xxxxxxxxxxx>
Subject: Re: [messaging-dev] Meeting minutes from 16th June 2021
 
+1, please create a draft PR in the https://github.com/jakartaee/specifications/pulls project as soon as possible.

On Feb 15, 2022 at 4:36:19 PM, Ondro Mihályi <ondrej.mihalyi@xxxxxxxxx> wrote:
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
_______________________________________________
messaging-dev mailing list
messaging-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org
_______________________________________________
messaging-dev mailing list
messaging-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org

Back to the top