Re: [jakartaee-platform-dev] [External] : Re: Simplifying the platform b

[Romain Manni-Bucau <rmannibucau@xxxxxxxxx>]

The key in this discussion is the goal merging everything would reach.

The only gain I see is to make the release smoother.

The drawbacks I see is to couple more specs quite easily, increase the contribution level (spec becomes more complex by becoming plural, think how easy it is to contribute to an EE server compared to a standalone implementation for ex) and therefore reduce the number of people in the spec and by consequence the quality of the industry covering of the releases.

But at the end if it is to merge specs to keep them independent it has no real value IMHO. If it is to really merge them (ex: JSON-P+JSON-B in the same PDF), then it will increase the user entry cost too so reduce the adoption.

So overall the question from my window is: is the release cost so high? The RC discussion seems to answer that it is "no" so I'm not sure there is a benefit there.

Romain Manni-Bucau
@rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book

Le lun. 7 mars 2022 à 23:51, Brian Stansberry <brian.stansberry@xxxxxxxxxx> a écrit :

On Mon, Mar 7, 2022 at 4:07 PM arjan tijms <arjan.tijms@xxxxxxxxx> wrote:

Hi,

On Thu, Mar 3, 2022 at 8:47 PM Brian Stansberry <brian.stansberry@xxxxxxxxxx> wrote:

Agreed. I know in WildFly we integrate a number of libraries that use JSONP but not JSONB, and those libraries are used outside of appservers.

And in WildFly you can configure a server installation without JSONB support if you don't need it. I know other servers provide similar slimming ability.

Is it absolutely needed to have the specs split to enable that?

What about having multiple modules within the spec? E.g. jakarta.json as a module that includes both jakarta.json.processing and jakarta.json.bind. Application developers who want to use JSON could simply use jakarta.json. But libraries that specifically need to bind to jakarta.json.processing, can bind to only that.

We considered splitting up Faces in dozens of modules, so people could omit things they do not want (say, omit the navigation rules, or omit the resource library contracts). Naturally we don't dream of splitting up Faces in a dozen new specs.

Sure, as long as the specs are producing finer grained artifacts and impls do the same we can create JBoss Modules modules that allow your slimmed server to just have what you want.

A risk of combining things even though they are modularized within the spec is that modularization breaks down over time, but that kind of risk can be managed.

Kind regards,

Arjan

 

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

--

Brian Stansberry

Principal Architect, Red Hat JBoss EAP

He/Him/His

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev