| Scott,
Everyone will agree with your statement that there must be a good reason to develop a new specification. But “MicroProfile did it first” is not a valid argument against doing so.
Let me repeat what I said earlier: the official policy of the Eclipse Foundation is that projects and specifications can compete. The fact that something has been specified in MicroProfile does not prevent Jakarta EE from acting in the best interest of its technology and community. Those decisions should be made based on the technical requirements, not on FUD.
As John Clingan pointed out, MicroProfile is proudly different than Jakarta EE. And those differences mean there are valid technical and non-technical reasons why an MP spec cannot be used by Jakarta EE. I think others have been pointing some such reasons out on this thread.
To answer Mark Little’s earlier question: just because Jakarta EE *can* compete, does not mean that it *will* compete. That’s a decision to be made by the group within the governance and policy framework provided by the Eclipse Foundation.
Have a great weekend everyone. Mike Milinkovich mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx (m) +1.613.220.3223 On Nov 11, 2022, at 12:15 PM, Scott Stark <starksm64@xxxxxxxxx> wrote:
For specification projects in a related space, the existence of more than one needs to be justified. There is a reason everyone involved in specification/standards work raises this well trodden satire out at some point:
John,
Good points. There are indeed non-technical differentiators
between MircoProfile and Jakarta EE. No one would dispute that.
But since we are discussing important philosophical points, let
us add the fact that the Eclipse Foundation has always and will
always permit competing projects, and that extends to
specifications as well. We will never endorse the allocation of a
market to one coalition of vendors over another set of vendors. So
just because MicroProfile has a specification in a particular
domain in no way prevents Jakarta EE from creating a similar spec.
That work may or may not be based on prior work done at
MicroProfile, so "move" doesn't really factor into the discussion.
As you point out, there are important non-technical differences
between the two. Any one of those could be a good reason why
Jakarta EE may wish to have its own specifications which overlap
or compete with MicroProfile specs. In other words, there can be
a myriad of reasons why competing specs may occur: business,
technical, community, vendor support, etc etc. But "MicroProfile
did it first" does not provide it with any sort of veto.
On 2022-11-10 1:29 p.m., John Clingan
wrote:
I’m inserting this as a general point in this discussion, which
is related to joining the MP JWT call.
There are non-technical reasons MicroProfile exists.
MicroProfile is a flatter working group with fewer processes,
somewhat different values (like backwards compatibility
differences), releases more often, and is $250,000 USD cheaper *annually* (for large organizations) than
joining Jakarta EE Working Group as a strategic member. Whenever
talk of moving a specification to Jakarta, I feel the need to
remind folks of the non-technical differences between Jakarta
and MicroProfile.
For these reasons, I am against moving *any*
specifications out of MicroProfile to Jakarta, although I am
open to the idea of moving Jakarta specifications to
MicroProfile. The exception is concurrency, which was always
intended to move to Jakarta.
My two cents.
Hi,
MP
JWT does define bindings for EJB, Servlets,
JACC, JASPIC, etc.
True, although essentially
spelling out everything is unnecessary if
one just says that MP JWT in a Jakarta EE
environment is/exposes itself as an Jakarta
Security Authentication Mechanism. All those
other things then follow from that.
Specifically this authentication mechanism
bit is missing there. I do see identity
store being mentioned, and perhaps it comes
from the confusion that many people have
between the concept of an authentication
mechanism (FORM, BASIC, etc) and an identity
store (DB, LDAP, FILE, etc).
I'd be on board for making these kinds
of changes and improvements in MP JWT. The next
version planned is 3.0, so we can even make breaking
changes if we needed to accommodate. The next MP
JWT call is Thursday, November 17th at 8:00am
Pacific. Are you open to attending at least once
and discussing? Here's the call information:
#
Procedural
In CN4J we did agree to some technical
principles. One of them is that duplication
should be avoided.
That is basically a good thing.
The problem here is a little that MP JWT in a
sense "hi-jacked" the JWT authentication
mechanism from underneath Jakarta Security. Of
course it's not that black and white in
practice, and there were many valid arguments
for MP to introduce JWT in the way it did. But
the matter of fact remains that Jakarta
Security planned for a number of
authentication mechanisms that went beyond the
ones provided by servlet, such as Open ID
Connect (OAuth) and JWT.
These didn't make it into 1.0, and
because of the move to Eclipse the new
features effort was stalled for years. In that
timeframe JWT was introduced in MP. Currently
Jakarta EE is open for new features again, but
it finds some features are now "controversial"
only because MP implemented them in the
meantime. Again, there was no malintent (I was
even part of the original MP JWT team then),
but it's an unfortunate situation.
I do understand how things can feel that way from an
emotional perspective. My emotional perspective is that
we're fortunate to have this conversation at all,
because when MicroProfile and MP JWT were created Java
EE was dead with no plans to continue. I'm thankful and
proud of MicroProfile for its impact on the decision to
open source Java EE. I'm happy that both Jakarta EE and
MicroProfile now live at the Eclipse Foundation and are
implemented side-by-side in most the major
implementations.
Sure, we don't want duplication between
specs, but we also don't want duplication between say
two specs in Jakarta EE. Compared to the challenges
we've faced over the last 6 or 7 years, this feels
very manageable.
-David
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
--
Mike Milinkovich
Executive Director | Eclipse Foundation AISBL
Twitter:@mmilinkov
_______________________________________________jakartaee-platform-dev mailing listjakartaee-platform-dev@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
|
