Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-community] Fork Eclipse MicroProfile Configuration as Jakarta Configuration.

Yes, I recall it.  But regardless, I do not think that that kind of
discourse is an example we should be emulating, just on the sole basis
of it having *happened* in the past.  Did Gavin and Bob set a great
example at the time?  Probably not, but that's just my opinion.  I
haven't always had perfect behavior either if we're being honest.  But
regardless of the history, we don't want a repeat of Java EE.  We want
something better, more professional, higher quality, more open.  Isn't
that the point of this?  I for one don't really care what happened in
the past or what people said in the past (including you).  I want us
to move to a higher level of discourse and to stay there.  I want us
to all agree to have conduct becoming of a professional specification
organization. I want us to emulate only the best examples of
specification stewardship and personal behavior.  That's the only way
I see Jakarta succeeding.

We can either be successful by being adult, professional, skilled, and
objective, or we can be an industry joke and cautionary tale.  We have
this choice in our hands every day, but it's not always an easy
choice.  We only gain a reputation for quality by maintaining
acceptable conduct without exception; OTOH bad conduct can at a single
stroke undermine the legitimacy of the entire organization and
alienate many potential users and markets.

On Tue, Apr 7, 2020 at 9:10 AM Werner Keil <werner.keil@xxxxxxxxx> wrote:
>
> David,
>
> I may not have kids in high school or university of my own but I assume we are more or less the same age.
>
> I happened to be involved in the creation of CDI and JSR 330 as were a few others and believe me (or look it up) they (Bob Lee and Gavin King) were really personal and nasty to each other in those discussions at times.
> Show me a single piece of what I said here that is not professional or insult to either of you.
>
> It is nothing to be ashamed of to enter a certain community at a later stage, but trying to rewrite history or telling those who were there first hand from day 1 (CDI 1 or the Inject JSR) how things were when you only read those in the minutes from over 10 years ago or on Wikipedia is not professional, so please try to stay professional again.
>
> Thanks,
>
> Werner
>
>
>
>
>
> On Tue, Apr 7, 2020 at 4:01 PM David Lloyd <david.lloyd@xxxxxxxxxx> wrote:
>>
>> Werner, I think that you're well out of line.  I (and Mark) have
>> stated very clear facts, beliefs, and positions, but you continually
>> attribute malice to everything we do.  I have several teenagers at
>> home, so I've seen it all before and I for one am not impressed by it.
>> This is IMO unprofessional and in no way becoming of a member of a
>> serious specification body.  You seem to be angry because neither Mark
>> nor I agree with your perception (which you repeatedly and vehemently
>> state as objective fact), and feeling angry is fine, but you need to
>> modulate it and rise above it, and find a way to move forward
>> professionally and keep your feelings to yourself.
>>
>> A common meme these days for assessing the appropriateness of a
>> statement goes like this:
>>
>> "THINK":
>> * Is it True?
>> * Is it Helpful?
>> * Is it Inspiring?
>> * Is it Necessary?
>> * Is it Kind?
>>
>> Of course you don't have to apply such a test if you don't want to,
>> but I think you should consider it.  I think that having (and
>> supporting) this kind of blowup has really undermined the legitimacy
>> of Jakarta.  Do you think that some company or user would look at
>> responses like "denies reality and while you have a lot of that
>> (science and reality denial) in Britain these days" and think to
>> themselves, "Yes, this looks like a legitimate standard, and I will
>> bring this to my professional organization"?  If it were me, I'd be
>> thinking "this is a circus, and these are not serious people".
>> Particularly if I happened to be British - imagine!
>>
>> An important facet of truth is understanding and clearly communicating
>> whether something is /objective fact/, or whether it is /a belief/
>> (regardless of how strongly held it is) or /an opinion/.  I think
>> these things have gotten muddled when you say people are "denying
>> reality" when clearly (to outside observers, for example) it is your
>> belief that is being denied.  And as I said, when someone disagrees
>> with you over whether something is fact, it is important to respond
>> professionally and *give the benefit of the doubt* where possible.
>>
>> On Tue, Apr 7, 2020 at 8:23 AM Werner Keil <werner.keil@xxxxxxxxx> wrote:
>> >
>> > Well tell David to stop it, I was under the impression everything that needs to be said here was said, and we rather focus on sorting out what dozens of actual users (nobody builds any of that for themselves, but I am also on the front working with customers who use those kinds of things unlike some others who may not do this so often any more) ask us to solve as well.
>> >
>> > So keep your pride and prejudice to yourself please.
>> >
>> >
>> > On Tue, Apr 7, 2020 at 3:15 PM Mark Little <mlittle@xxxxxxxxxx> wrote:
>> >>
>> >> Werner, I thought we had agreed to disagree and move on. Yet you've brought me back into the thread with unfounded insinuations. David didn't refer to me and you didn't need to give the kind of response you did. I'm asking you, Werner, to stop now before it goes too far.
>> >>
>> >> Thanks,
>> >>
>> >> Mark.
>> >>
>> >> On Tue, Apr 7, 2020 at 2:10 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
>> >>
>> >> _______________________________________________
>> >> 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



Back to the top