Skip to main content

[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

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



Back to the top