| Re: [jakarta.ee-community] Fork Eclipse MicroProfile Configuration as Jakarta Configuration. |
Werner
_______________________________________________Unfortunately I also have the view that we have heard more than enough from vendors and Red Hat employees specifically. It is time to try to make a bit more space for non-vendors to have a fair chance to voice their views.Reza RahmanJakarta EE Ambassadors, Author, Blogger, SpeakerPlease note views expressed here are my own as an individual community member and do not reflect the views of my employer.Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone-------- Original message --------From: Werner Keil <werner.keil@xxxxxxxxx>Date: 4/7/20 9:13 AM (GMT-05:00)To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>Subject: Re: [jakarta.ee-community] Fork Eclipse MicroProfile Configuration as Jakarta Configuration.Better listen to your users like Gilberto, they say precisely what I did in a different message.So instead of fake pride like "I am the Creator of MicroProfile which is so much better than Spring and everything else and nobody will take that away" let's focus on what is best for the wider community and users like Gilberto and many others who also shared their opinion in this discussion over the last few days.Werner
On Tue, Apr 7, 2020 at 3:09 PM Werner Keil <werner.keil@xxxxxxxxx> wrote:David,It's Mark who is unprofessional and denies the facts or tries to build alternate realities that suit his follower base inside MP, which is why we are in this situation.Help resolve it either on the MP side by getting your act together and create the necessary WGs or everything else and stop the needles shouting and trying to justify why you got yourselves into a somewhat blocked situation.Werner
On Tue, Apr 7, 2020 at 3:02 PM David Lloyd <david.lloyd@xxxxxxxxxx> wrote:Werner, you're being unprofessional and needlessly antagonistic. Is
this what you think Jakarta is all about?
On Tue, Apr 7, 2020 at 5:53 AM Werner Keil <werner.keil@xxxxxxxxx> wrote:
>
> Yes, just keep it that way and stay healthy unlike your PM.
>
> Werner
>
>
>
>
>
> On Tue, Apr 7, 2020 at 12:43 PM Mark Little <mlittle@xxxxxxxxxx> wrote:
>>
>> OK Werner, 'nuff said.
>>
>> Mark.
>>
>> On Tue, Apr 7, 2020 at 11:37 AM Werner Keil <werner.keil@xxxxxxxxx> wrote:
>>>
>>> Please stop embarrassing yourself.
>>>
>>> As long as Google or Spring does not use Jakarta Inject, it is a fork situation of a similar kind with one community having taken the steps while the other sticks to JSR 330.
>>>
>>> Red Hat forked it based on decisions by the Jakarta EE Spec Committee where I also have a vote, but claiming it was no fork or the situation would be different, if the Spec Committee found picking up JSR 382 in a similar way is in the best interest for Jakarta EE just denies reality and while you have a lot of that (science and reality denial) in Britain these days, I hoped some of you would be better than this.
>>>
>>> Werner
>>>
>>>
>>>
>>> On Tue, Apr 7, 2020 at 11:32 AM Mark Little <mlittle@xxxxxxxxxx> wrote:
>>>>
>>>> Werner, thanks for confirming you were involved and hence do know that Red Hat did not fork JSR 330 in the way you were implying.
>>>>
>>>> Mark.
>>>>
>>>>
>>>> On 7 Apr 2020, at 10:10, Werner Keil <werner.keil@xxxxxxxxx> wrote:
>>>>
>>>> Mark,
>>>>
>>>> I was involved, so stop telling me from the sidelines what I already know.
>>>>
>>>> Better listen to the other threads and answer to Mike what he tried to help solve the entire problem that especially the "pullers" caused.
>>>>
>>>> DI and Spring was the tiniest of all example cases, but as the others like Hibernate or Spring Batch every single one of them was offered by their contributing people or companies in the way your two options called "Push", but in this case only Oracle (because it knows how that worked back in the JCP) voted for such an approach. Now all the others have to sort things out.
>>>>
>>>> Werner
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Apr 7, 2020 at 10:56 AM Mark Little <mlittle@xxxxxxxxxx> wrote:
>>>>>
>>>>> Werner, stop attributing words to me which I didn’t state. Putting things in quotes like that below does precisely that and it is inaccurate. if you cannot stick to the facts then perhaps you should just keep quiet :)
>>>>>
>>>>> To this very specific point about whether Red Hat forked 330, I will keep saying the same thing because it is true: 330 was forked on behalf of the entire Jakarta EE community at the behest of the Steering Committee because none of the original owners of that JSR were responding to requests to move it to Jakarta EE. I believe Scott has also stated the same thing because he was involved too.
>>>>>
>>>>> Mark.
>>>>>
>>>>>
>>>>> On 6 Apr 2020, at 12:40, werner.keil@xxxxxxxxx wrote:
>>>>>
>>>>> Mark,
>>>>>
>>>>> I am in the Spec Committee and who other than Eclipse Foundation was responsible for creating the Config JSR?
>>>>>
>>>>> So I recommend you stop Arguments like „You can’t do that with MP because MP is Special“ because they just deny the Facts.
>>>>>
>>>>> Fact is (and I know that because unlike you I am in the Spec Committee)
>>>>> there is an existing community (Spring, Guice and others) that drove the Injecct JSR (I was also in the JCP EC Talking to Rod Johnson the only time he ever showed up Long before you replaced Sacha or demanded the Spec Leads improved their inadequate TCK) which was not willing to collaborate on moving it to Jakarta Inject.
>>>>>
>>>>> While it remains to be seen, if Spring Framework in future versions adopts Jakarta Inject there is currently no sign of the Guava/Guice or Dagger community doing that, so there is a fork of the Framework whether you accept that or not.
>>>>>
>>>>> Werner
>>>>>
>>>>> From: Mark Little
>>>>> Sent: Monday, April 6, 2020 13:31
>>>>> To: Jakarta EE community discussions
>>>>> Subject: Re: [jakarta.ee-community] Fork Eclipse MicroProfile Configuration as Jakarta Configuration.
>>>>>
>>>>> Werner, that fork was on behalf of the Jakarta EE spec committee and Eclipse Foundation so we could release Jakarta EE 8. So before you go further I recommend you get your facts right.
>>>>>
>>>>> Mark.
>>>>>
>>>>> On Mon, Apr 6, 2020 at 12:23 PM <werner.keil@xxxxxxxxx> wrote:
>>>>>
>>>>> This sounds totally hypocritic because you (Red Hat) did just that with JSR 330 when the contributors and Spec Leads were unwilling to contribute to Jakarta EE, so RH (Scott) forked it into Jakarta Inject Based on the mentioned ASLv2 allowing it.
>>>>>
>>>>>
>>>>>
>>>>> There is currently no evidence Google, Square or any of the other users of the Guice community are adopting Jakarta Inject, so it is just a fork whether anybody touches those old annotations or not.
>>>>>
>>>>>
>>>>>
>>>>> So why did you do it for Inject and say this should not be done with MP or the fork that already was done with JSR 382?
>>>>>
>>>>>
>>>>>
>>>>> Werner
>>>>>
>>>>>
>>>>>
>>>>> From: Mark Little
>>>>> Sent: Monday, April 6, 2020 13:14
>>>>> To: Jakarta EE community discussions
>>>>> Subject: Re: [jakarta.ee-community] Fork Eclipse MicroProfile Configuration as Jakarta Configuration.
>>>>>
>>>>>
>>>>>
>>>>> "There is no inherent right for Jakarta EE to do this with MP"
>>>>>
>>>>>
>>>>>
>>>>> And your reference to the licence whilst legally correct ignores the fact that just because you can do something doesn't mean you should do something! There are communities here. If we all believed that just because project X is ASLv2 licenced means we have some right to fork it, regardless of the community, then open source wouldn't be as vibrant as it is today. I'm kind of disappointed I seem to need to explain that.
>>>>>
>>>>>
>>>>>
>>>>> Mark.
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Apr 6, 2020 at 12:07 PM Ondro Mihályi <ondrej.mihalyi@xxxxxxxxx> wrote:
>>>>>
>>>>> I don't understand, Mark. Did you mean there IS or IS NOT an inherent right to fork MP by JEE or that there is?
>>>>>
>>>>>
>>>>>
>>>>> I believe that since MP specs are Apache licenced, JEE has an inherent right to fork them. Or did you mean something else?
>>>>>
>>>>>
>>>>>
>>>>> Dňa po 6. 4. 2020, 13:01 Mark Little <mlittle@xxxxxxxxxx> napísal(a):
>>>>>
>>>>> Hi Ondro.
>>>>>
>>>>>
>>>>>
>>>>> Not sure if you read my longer email earlier today but let me summarise one point: it's for the Jakarta EE community to decide whether or not to fork *any* other open source project, not just MP, and take the consequences of that on themselves. There is no inherent right for Jakarta EE to do this with MP just as there's no inherent right for MP to fork any of the Jakarta EE specs (which it has not done).
>>>>>
>>>>>
>>>>>
>>>>> Mark.
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Apr 6, 2020 at 11:57 AM Ondro Mihályi <ondrej.mihalyi@xxxxxxxxx> wrote:
>>>>>
>>>>> Hi, Mark,
>>>>>
>>>>>
>>>>>
>>>>> I appreciate that your intension with yhe Pull model wasn't to suggest forking. But the text approved by boting explicitly mentions forking as an option. So don't be surprised that some people in JakartaEE consider it as an option. If we want to change that, MP should either reconsider that Pull statement or provide more detailed explanation for it.
>>>>>
>>>>>
>>>>>
>>>>> Dňa po 6. 4. 2020, 11:56 Mark Little <mlittle@xxxxxxxxxx> napísal(a):
>>>>>
>>>>> Rudy, I was the one who first proposed the pull versus push model at the MP hangout in February and I definitely did not use the fork at the time or include it in any text. It is not necessary to fork any project, whether it’s a spec based project or one which produces libraries, for instance, when becoming dependant upon it. Collaborating communities can do just that: collaborate and embed.
>>>>>
>>>>>
>>>>>
>>>>> Mark.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 5 Apr 2020, at 08:44, Rudy De Busscher <rdebusscher@xxxxxxxxx> wrote:
>>>>>
>>>>>
>>>>>
>>>>> Can everyone who voted for PULL, stop complaining against the Jakarta people for exactly doing what you have voted for.
>>>>>
>>>>>
>>>>>
>>>>> The word fork was removed last minute from the pull text but it was always part of it during the discussions during months and the intention. But this downstream project is exactly doing what is in the PULL text, defining the lifecycle, compatibility requirements and namespace.
>>>>>
>>>>>
>>>>>
>>>>> And don't start about having 2 different hats. There is only 1 world, 1 reality in which Jakarta does exactly what is needs to do based on the outcome of the PULL vs PUSH vote.
>>>>>
>>>>>
>>>>>
>>>>> The fork is the only viable solution if vendors want to keep combining Jakarta EE and MicroProfile in one product when some of the MP specs are used by Jakarta Specs.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Fri, 3 Apr 2020 at 20:11, David Lloyd <david.lloyd@xxxxxxxxxx> wrote:
>>>>>
>>>>> You are simply factually wrong in this regard. You're defining
>>>>> "caring about compatibility" as being synonymous with "forcing strict
>>>>> compatibility rules", when this is not true in any respect.
>>>>>
>>>>> I voted "Pull" because the chief goal of MP ought to be to meet user
>>>>> needs effectively and quickly, even if that means (in the worst case)
>>>>> bumpy compatibility at first. As I said, compatibility is a quality
>>>>> measure (just one of many) and it arises from a good specification.
>>>>> Making a specification be compatible doesn't make it good or useful.
>>>>> It's far better to add compatibility restrictions *after* the
>>>>> specification is already stable, rather than to add such restrictions
>>>>> to a specification that is still rapidly developing (thereby greatly
>>>>> diminishing its usefulness in the name of stamping a logo on it in the
>>>>> short term). This is (IMO) a good indicator of when it makes sense to
>>>>> "graduate" a spec into Jakarta. The consumers of Jakarta are looking
>>>>> for long term stability, and that comes from quality, not from a
>>>>> compatibility contract.
>>>>>
>>>>> Voting "Push" would have done nothing to improve the quality of
>>>>> specifications and would have obstructed the process of cross-vendor
>>>>> standardization - an already inherently politically and socially
>>>>> obstructive process. It was a very cynical option IMO.
>>>>>
>>>>> On Fri, Apr 3, 2020 at 12:55 PM Werner Keil <werner.keil@xxxxxxxxx> wrote:
>>>>> >
>>>>> > Everyone who voted for this "Pull" option voted against compatibility and supporting it, not sure how many votes Red Hat got there and who was eligible but the majority voted for the "I don't care about compatibility" option, did you vote for "Push"?
>>>>> >
>>>>> >
>>>>> >
>>>>> > On Fri, Apr 3, 2020 at 7:33 PM David Lloyd <david.lloyd@xxxxxxxxxx> wrote:
>>>>> >>
>>>>> >> AFAICT the only people claiming that MP doesn't care about
>>>>> >> compatibility are MP detractors. MP doesn't *prioritize*
>>>>> >> compatibility, but I for one *care* about it quite a lot. When your
>>>>> >> first priority is meeting use cases, then compatibility becomes a
>>>>> >> quality measure: the easier it is to retain compatibility in the face
>>>>> >> of new use cases, the more likely it is that the specification is
>>>>> >> already useful for use cases beyond those originally imagined. The
>>>>> >> more useful a specification is, the wider its adoption.
>>>>> >>
>>>>> >> On Fri, Apr 3, 2020 at 12:18 PM Werner Keil <werner.keil@xxxxxxxxx> wrote:
>>>>> >> >
>>>>> >> > And especially one claiming it doesn't care about compatibility or the consumers of its frameworks or APIs while the other by definition has to.
>>>>> >> >
>>>>> >> > Werner
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> > On Fri, Apr 3, 2020 at 7:11 PM Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:
>>>>> >> >>
>>>>> >> >> Hi David,
>>>>> >> >>
>>>>> >> >> I agree nobody wants to duplicate effort. Which is why it is non-sensical to have two separate specification bodies defining specifications which are intertwined as these discussions on both sides demonstrate.
>>>>> >> >>
>>>>> >> >> Steve
>>>>> >> >>
>>>>> >> >> -----Original Message-----
>>>>> >> >> From: jakarta.ee-community-bounces@xxxxxxxxxxx <jakarta.ee-community-bounces@xxxxxxxxxxx> On Behalf Of David Lloyd
>>>>> >> >> Sent: 03 April 2020 16:49
>>>>> >> >> To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
>>>>> >> >> Subject: Re: [jakarta.ee-community] Fork Eclipse MicroProfile Configuration as Jakarta Configuration.
>>>>> >> >>
>>>>> >> >> On Fri, Apr 3, 2020 at 9:56 AM Werner Keil <werner.keil@xxxxxxxxx> wrote:
>>>>> >> >> >
>>>>> >> >> > All of these are defined by standard bodies with strong compatibility requirements like W3C or the JCP.
>>>>> >> >> >
>>>>> >> >> > The namespace is not so much a problem as the "Not My Problem" attitude the MP stakeholders expressed in their vote for the option called "Pull". That is even a stronger argument against using a feature like MP Config as is instead of a "fork" or writing something heavily inspired by it from scratch in Jakarta EE.
>>>>> >> >>
>>>>> >> >> Who would do the work? We're rapidly innovating in MP Config right now, learning a lot about the problem space and processing real user feedback, and applying that knowledge in a way that can be consumed today. If you fork, you're going to end up with probably a separate body of people (where will these people come from?), developing a separate piece of software from scratch which, instead of being based on working and useful implementations, is top-down designed and has no initial implementations - discarding that learning process just to spite MP out of impatience AFAICT. It seems silly to me.
>>>>> >> >>
>>>>> >> >> If the bar for Jakarta EE is stability, you can't clear that bar by crapping out some code and calling it "stable", no matter how brilliant you are. It has to be proven in the laboratory of the real world - an iterative process. MP Config is going through that process right now, in fact, and rapid innovation is the direct result of that.
>>>>> >> >> We're not breaking things for fun, and in fact we put forth some effort to not break things anyway (despite being allowed to). Perhaps there will be a time where most people are mostly happy with it and few new use cases arise, rendering the specification mostly quiescent, but until that time, anything you do to call the field of standardized configuration in Java "stable" will effectively be a lie, just to check a box. Such lies do little to enhance the reputation of specification bodies which perpetuate them.
>>>>> >> >>
>>>>> >> >> > Not giving a damn about compatibility requirements means, Jakarta EE probably would have to fork the TCK for such MP feature anyway because if the project suddenly decides to run the TCK with Spock or JUnit 5 instead of TestNG while the Jakarta EE platform has other foundations of its TCKs, then Jakarta EE might as well just fork the whole of it instead of bothering with a TCK fork or trying to integrate it somehow without support by the authors.
>>>>> >> >>
>>>>> >> >> I guess it depends on how much you enjoy doing busy work. I for one really dislike doing it; any time spent working on a (possibly
>>>>> >> >> inferior) parallel specification to one that is in wide use is time wasted, to me; I can only imagine that my co-collaborators on MP Config feel similarly. Who would be left to work on the specification when all of the experienced engineers don't want to do it? What kind of specification would that be?
>>>>> >> >>
>>>>> >> >> It's far more rational to let MP Config continue to do the "dirty work" of figuring out what works and what doesn't work, and then revisit the question at a more appropriate time. Consuming MP Config could be a far more attractive option in, say, 12-18 months time.
>>>>> >> >> Moving it wholesale to Jakarta might similarly be a more reasonable option at that time. It's better than spending 12-18 months arguing over a new specification anyway - how tiresome that would be.
>>>>> >> >> --
>>>>> >> >> - DML
>>>>> >> >>
>>>>> >> >> _______________________________________________
>>>>> >> >> jakarta.ee-community mailing list
>>>>> >> >> jakarta.ee-community@xxxxxxxxxxx
>>>>> >> >> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>>>>> >> >> _______________________________________________
>>>>> >> >> jakarta.ee-community mailing list
>>>>> >> >> jakarta.ee-community@xxxxxxxxxxx
>>>>> >> >> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>>>>> >> >
>>>>> >> > _______________________________________________
>>>>> >> > jakarta.ee-community mailing list
>>>>> >> > jakarta.ee-community@xxxxxxxxxxx
>>>>> >> > To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> --
>>>>> >> - DML
>>>>> >>
>>>>> >> _______________________________________________
>>>>> >> jakarta.ee-community mailing list
>>>>> >> jakarta.ee-community@xxxxxxxxxxx
>>>>> >> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>>>>> >
>>>>> > _______________________________________________
>>>>> > jakarta.ee-community mailing list
>>>>> > jakarta.ee-community@xxxxxxxxxxx
>>>>> > To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> - DML
>>>>>
>>>>> _______________________________________________
>>>>> jakarta.ee-community mailing list
>>>>> jakarta.ee-community@xxxxxxxxxxx
>>>>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>>>>>
>>>>> _______________________________________________
>>>>> jakarta.ee-community mailing list
>>>>> jakarta.ee-community@xxxxxxxxxxx
>>>>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>>>>>
>>>>>
>>>>>
>>>>> ---
>>>>> Mark Little
>>>>> mlittle@xxxxxxxxxx
>>>>>
>>>>> JBoss, by Red Hat
>>>>> Registered Address: Red Hat Ltd, 6700 Cork Airport Business Park, Kinsale Road, Co. Cork.
>>>>> Registered in the Companies Registration Office, Parnell House, 14 Parnell Square, Dublin 1, Ireland, No.304873
>>>>> Directors:Michael Cunningham (USA), Vicky Wiseman (USA), Michael O'Neill, Keith Phelan, Matt Parson (USA)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> jakarta.ee-community mailing list
>>>>> jakarta.ee-community@xxxxxxxxxxx
>>>>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>>>>>
>>>>> _______________________________________________
>>>>> jakarta.ee-community mailing list
>>>>> jakarta.ee-community@xxxxxxxxxxx
>>>>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>>>>>
>>>>> _______________________________________________
>>>>> jakarta.ee-community mailing list
>>>>> jakarta.ee-community@xxxxxxxxxxx
>>>>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>>>>>
>>>>> _______________________________________________
>>>>> jakarta.ee-community mailing list
>>>>> jakarta.ee-community@xxxxxxxxxxx
>>>>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> jakarta.ee-community mailing list
>>>>> jakarta.ee-community@xxxxxxxxxxx
>>>>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>>>>>
>>>>> _______________________________________________
>>>>> jakarta.ee-community mailing list
>>>>> jakarta.ee-community@xxxxxxxxxxx
>>>>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>>>>>
>>>>>
>>>>> ---
>>>>> Mark Little
>>>>> mlittle@xxxxxxxxxx
>>>>>
>>>>> JBoss, by Red Hat
>>>>> Registered Address: Red Hat Ltd, 6700 Cork Airport Business Park, Kinsale Road, Co. Cork.
>>>>> Registered in the Companies Registration Office, Parnell House, 14 Parnell Square, Dublin 1, Ireland, No.304873
>>>>> Directors:Michael Cunningham (USA), Vicky Wiseman (USA), Michael O'Neill, Keith Phelan, Matt Parson (USA)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> jakarta.ee-community mailing list
>>>>> jakarta.ee-community@xxxxxxxxxxx
>>>>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>>>>
>>>> _______________________________________________
>>>> jakarta.ee-community mailing list
>>>> jakarta.ee-community@xxxxxxxxxxx
>>>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>>>>
>>>>
>>>> ---
>>>> Mark Little
>>>> mlittle@xxxxxxxxxx
>>>>
>>>> JBoss, by Red Hat
>>>> Registered Address: Red Hat Ltd, 6700 Cork Airport Business Park, Kinsale Road, Co. Cork.
>>>> Registered in the Companies Registration Office, Parnell House, 14 Parnell Square, Dublin 1, Ireland, No.304873
>>>> Directors:Michael Cunningham (USA), Vicky Wiseman (USA), Michael O'Neill, Keith Phelan, Matt Parson (USA)
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> jakarta.ee-community mailing list
>>>> jakarta.ee-community@xxxxxxxxxxx
>>>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>>>
>>> _______________________________________________
>>> jakarta.ee-community mailing list
>>> jakarta.ee-community@xxxxxxxxxxx
>>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>>
>> _______________________________________________
>> jakarta.ee-community mailing list
>> jakarta.ee-community@xxxxxxxxxxx
>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>
> _______________________________________________
> jakarta.ee-community mailing list
> jakarta.ee-community@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
--
- DML
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community