+1
It worries me that Jakarta EE is attempting to lift-and-shift ideas from other communities or standards bodies in a very non-open source manner. When no Java APIs exist(ed) for those standards or from those communities it makes sense to create one that everyone can get behind. But when they do exist, copying and renaming does not make as much sense unless, as you say, there are impediments to using those APIs/specifications in situ and the original community is unable to accommodate. It's also not very collaborative. It’s essentially forking the other community efforts and those things tend not to go well.
If you've got communities innovating elsewhere and Jakarta EE sees benefit in bringing those technologies/APIs to users, we need to consider not just existing users of those technologies/APIs but also the people/groups who have created that innovation. I'm not going to spend time going into this in a lot of detail as everyone on this list should be experienced enough with open source as contributors and users but ...
- telling existing users of those APIs/technologies that they need to re-code to using some new Jakarta EE API if they want to use them in (new) applications which use Jakarta EE is one sure way to suggest to them that perhaps Jakarta EE isn't something they should be considering;
- it's entirely logical to assume that the developers of those technologies/APIs will question why their efforts are being copied/forked when they've gone to the effort of building their own communities and why collaboration upstream in the original community was not possible, as per good open source practices?
And of course following on from this is the question Jakarta EE should be asking: who is going to work on the forked stream if the original continues on regardless of what Jakarta EE might do? If those external communities/efforts (the ones which produced the APIs/technologies in the first place) gain critical mass from end users, or maybe had it from the start, then it is not in Jakarta's best interests to copy/fork. Jakarta should not return to the relative isolation/silo-ed days of Java EE, which arguably existed because there was a dearth of open source community work at the time). It should be reaching out to these other communities and embracing them even if that means developers have to consider different namespaces for a range of capabilities. IDEs these days are a heck of a lot better at hiding those details than they were 20 years ago!
Mark.
Sure, and that is allowed. Projects cannot and should not be force fed to use a specification just because it is there. I'm not sure what the point is about the community of committers being from Redhat is or why I should care if they are from Redhat.
My point is that specification WG should have a vested interest in making their specifications useable to the largest audience, including other WG specifications.
Tom
Mike/Tom, Vertx not only the Oauth2 module (https: //vertx. io/docs/vertx-auth-oauth2/java/) is a very good example for a project developed at Eclipse Foundation (also by a large number of committers from Red Hat) that interacts with OIDC or
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
Mike/Tom,
Vertx not only the Oauth2 module (https://vertx.io/docs/vertx-auth-oauth2/java/)
is a very good example for a project developed at Eclipse Foundation (also by a large number of committers from Red Hat) that interacts with OIDC or JWT without using either Jakarta Security or MicroProfile JWT despite largely written in Java.
Werner
There is competition and there is reinventing the wheel. Both are absolutely allowed by the various projects at the Eclipse Foundation. I would not argue for the Eclipse
Foundation to put any inhibitors from such activities.
What I would like to see out of the specifications developed from the various Eclipse Specification working groups are technologies that are successful and generally
useable by the largest group possible. Something that always grates on me is when I hear one specification WG claim they cannot use a perfectly good and well specified technology simply because it is not from the X specification working group.
Something seems wrong if specifications developed within the various specification working groups are not viewed as highly attractive for use and depended upon by other
specifications being developed in a separate Eclipse working group. There may be valid reasons the current versions of the specification cannot be used, but these should be identified and hopefully expressed as valid requirements which could be considered
by the specification WG for enhancements to their future versions.
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
This Message Is From an External Sender
This message came from outside your organization.
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.
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.
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.
_______________________________________________
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@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
|
