Back from PTO. More below.
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
There is nothing philosophical about what I stated. It is real-world execution that’s been in place for years. 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.
Not sure where “veto” came from. I never mentioned or implied it. I do feel the need to say that, as a MicroProfile WG member, the tone of the comment doesn’t feel neutral.
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 list jakartaee-platform-dev@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
|
