[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakarta.ee-community] Options for Jakarta EE and MP alignment
|
To be honest, I try to understand these patterns to the best of my
abilities both in the day job and also just as a matter of personal
interest. I have to say there are no patterns that I am that comfortable
with. I routinely see mission critical "old school" monoliths who's
maintainers don't seem to care at all about open standards. There are
people that can make a legitimate claim that they are developing
containerized, cloud native distributed applications on "old school"
runtimes and still care very much about the stability,
vendor-neutrality, reliability and compatibility that open standards
bring. This last set also seems to have no problems using MicroProfile
with Java EE where there is a use case but expects some kind of eventual
convergence via Jakarta EE where it makes clear sense. All else being
equal, I have never come across anyone that objects to using an open
standard for common, mature, well understood use cases. I even see
people that say microservices and containers isn't all that they thought
it would be and are getting back to basics with monoliths.
I think the best course of action is to be disciplined and principled
about when to coalesce things around a Jakarta EE stable common core and
when it is really necessary to take a different path with MicroProfile,
Spring, Quarkus. etc. Both approaches have space for healthy
co-existence. I think we can all come to a reasonable consensus as to
where that healthy balance is for the ecosystem if we work together a
bit harder in good faith.
On a slightly different topic - do we know who would be early supporters
of Jakarta Configuration today (I guess this is mainly a question for
Otavio at this point)? What is our best guess as to how a voting pattern
in the right Jakarta EE decision making body would be right now? Or are
we just still feeling things out?
Reza Rahman
Jakarta EE Ambassador, Author, Speaker, Blogger
Please note views expressed here are my own as an individual community
member and do not reflect the views of my employer.
On 4/3/2020 3:47 PM, Jason Greene wrote:
Something that is also worth noting, which I also think is relevant,
is that software delivery and development methodology has also been
evolving as part of the shift to containers/cloud/microservices, and
notably never-ending framework ABI compatibility is just not as
critical in that environment as it in in a classic bare metal /
traditional application server setting. The code for the app and the
runtime are updated together as one unit, (as opposed to being dropped
in and expected to work), and often more frequently as organizations
adopt continuous delivery. Further applications are more decoupled
and utilize communication with formal contracts between components as
services, thus allowing more flexibility on the backing implementation
of each piece.
-Jason
On Apr 3, 2020, at 2:03 PM, Jason Greene <jason.greene@xxxxxxxxxx> wrote:
Technically no, it’s not quite 1:1 for product and spec like that. WildFly implements both EE and MP for example.
I would say it’s more that applications have differing needs that are best served with a solution targeting their respective concerns and priorities. Teams maintaining brownfield often want incremental improvement but wish to avoid major changes triggering major refactoring. Greenfield work on the other hand is more concerned with technologies that best meet new and future needs. In periods of paradigm shift (cloud & microservices), it becomes harder to satisfy all usage patterns with the same exact set of APIs. You needs some differentiation.
On Apr 3, 2020, at 12:23 PM, Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:
So RedHat is looking to align Specification bodies one for each of your products?
It's a solvable thing to incorporate stability and backwards compatibility with innovation in a single organisation as long as the rules are specified. We could follow a similar model within Jakarta EE to the Java SE model to achieve those two conflicting goals in a single group without confusion, duplication of effort; or increased bureaucracy and wearing of multiple hats.
Steve
-----Original Message-----
From: jakarta.ee-community-bounces@xxxxxxxxxxx <jakarta.ee-community-bounces@xxxxxxxxxxx> On Behalf Of Scott Stark
Sent: 03 April 2020 17:30
To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-community] Options for Jakarta EE and MP alignment
This is a limited point of view however. I have said this before when this comment that the MP and Jakarta membership is largely the same.
Red Hat has multiple products and multiple user bases that leverage the EE and MP technologies in different ways with different timeframe requirements. There is a conflict with the historic stability focus of EE with a desire to explore MP innovations. Perhaps there needs to be a hybrid profile in Jakarta EE10 that bridges the two and allows for continued MP rapid development, along with additional platforms to support Jakarta EE 8 customers.
On Fri, Apr 3, 2020 at 9:51 AM arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
Hi,
On Fri, Apr 3, 2020 at 5:41 PM Werner Keil <werner.keil@xxxxxxxxx> wrote:
Which is why I mentioned, if this MP WG comes to a better conclusion
[...]
Which partially is a funny statement when you realise it's mostly the same people as are also active in Jakarta.
Thinking out loud, but maybe there's something to say for merging only those projects for which there's an overlap of people into Jakarta EE, and keeping the projects mainly worked on by people not also in Jakarta EE in MP?
For instance, if Config was fully moved to Jakarta, and then the rest of MP depending on the Jakarta version of Config henceforth, wouldn't that work?
Kind regards,
Arjan
(not even sure, how binding the vote on the mailing list was?) and it follows an established process like the EFSP, then it may come to a different agreement, that makes other options feasible, right now based on these two options on its own mailing list, only the first one seems doable without constant pain and compatibility issues.
On Fri, Apr 3, 2020 at 5:36 PM Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:
It’s a good option but I didn’t add it in my email as that depends on the MicroProfile community agreeing.
From: jakarta.ee-community-bounces@xxxxxxxxxxx
<jakarta.ee-community-bounces@xxxxxxxxxxx> On Behalf Of Otavio
Santana
Sent: 03 April 2020 12:53
To: Jakarta EE community discussions
<jakarta.ee-community@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-community] Options for Jakarta EE and MP
alignment
Use MicroProfile as a flow to Jakarta EE Specifications
In this model, we'll keep the MicroProfile as a space to innovate and get more maturity to the project and then we move the MicroProfile API to Jakarta and makes MicroProfile one as deprecated.
Pros
Jakarta EE can pick and choose which MicroProfile APIs are appropriate.
Jakarta EE still have a place to innovate There is not support to
two API later, once the project when became Jakarta EE, it will deprecate the MicroProfile API.
Cons
It requires a move of the namespace for the API Developers will have
the migration process every time that the API became a Jakarta EE.
In the begging, the provider will have to support both APIs for awhile.
On Fri, Apr 3, 2020 at 8:24 AM Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:
All,
There has been a recent debate on to fork or not to fork MicroProfile Config. I wanted to outline what I feel are the 3 options available to the Jakarta EE community in adopting MicroProfile apis. The last two options are predicated on the MicroProfile community bootstrapping a working group and putting their apis through a specification process.
Graduate MicroProfile apis into Jakarta EE Specifications
In this model Jakarta EE takes relevant MicroProfile apis as inspiration and starts a specification project to move the ideas from the MicroProfile api into the jakarta namespace and create an equivalent Jakarta EE specification that can be integrated across the platform in a unified and coherent manner.
Pros
Jakarta EE can pick, choose and adapt ideas from MicroProfile to its
needs to ensure consistency across the platform
Jakarta EE is free to diverge from the MicroProfile api if it is
developing in a direction which Jakarta does not require
All Jakarta EE apis are in the same namespace and under control of the Jakarta EE community so can retain backwards compatibility.
Any product could be both Jakarta EE version X compliant and MicroProfile version Y compliant.
Cons
It requires a move of namespace for the api
Developers have 2 apis to choose from if they develop to both the
latest MicroProfile and Jakarta EE apis in a runtime that supports
both
It requires more effort to maintain a potentially diverging api
The Jakarta EE Platform Release incorporates a MicroProfile Platform
Release by Reference
In this model Jakarta EE version X platform specification could declare it incorporates the entirety of MicroProfile version Y by reference.
Pros
Jakarta EE is incorporating a well defined MicroProfile platform and can ensure specifications can integrate with it where possible.
No move of namespace of MicroProfile apis therefore only 1 api to support and develop to.
A runtime can be both Jakarta EE X compliant and MP Y compliant.
Cons
An individual runtime will likely be behind the curve on MicroProfile compatibility as it will be difficult to support 2 versions of MicroProfile in the same product version.
It may not be possible for Jakarta EE to retain backwards compatibility across platform releases as MicroProfile allows breaking changes across major versions.
Jakarta EE developers are using two namespaces.
The MicroProfile api may develop in a direction of no relevance to the Jakarta EE community as they are separate communities.
By referencing a whole MicroProfile platform release the Jakarta EE platform will incorporate apis which may have no relevance to Jakarta EE developers or are not stable.
Jakarta EE incorporates a subset of a MicroProfile platform release
In this model a Jakarta EE version X platform specification could
cherry pick individual MicroProfile apis for inclusion by reference.
For example MP Config X and REST Client Y …
Pros
Jakarta EE can pick and choose which MicroProfile apis are appropriate.
No move of namespace of MicroProfile apis therefore only 1 api to support and develop to.
Cons
An individual runtime may not be able to be MicroProfile compliant and Jakarta EE compliant or it will be behind the curve on MicroProfile compliance due to missing apis or conflicting api versions.
It may not be possible for Jakarta EE to retain backwards compatibility across platform releases as MicroProfile allows breaking changes across api major versions.
Jakarta EE developers are using two namespaces
The MicroProfile api may develop in a direction of no relevance to the Jakarta EE community as they are separate communities.
If there are other options feel free to shout and I can develop a doc for comments.
Steve
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
--
Otávio Santana
twitter: http://twitter.com/otaviojava
site: http://about.me/otaviojava
_______________________________________________
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
