[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakartaee-platform-dev] [External] : Re: Simplifying the platform by merging some specs?
|
On 3/8/22 8:50 AM, Romain Manni-Bucau wrote:
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.
there is no PDF for JSONP, so one would need to be created by someone -
add that to the overall "cost" of the merge.
Does anything block arbitrary user to create say
org.glassfish.jakarta.json with the proposed structure, deploy that to
central and advertise that as an entry point to Jakarta EE defined JSON
world in Java provided by GlaasFish project? Something like this should
also probably come with some "default" implementations to be really
useful for end users. (Feel free to replace GlassFish with whatever is
preferred, the "default" CI can be whatever the provider of such module
decides to use)
thanks,
--lukas
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
<https://urldefense.com/v3/__https://twitter.com/rmannibucau__;!!ACWV5N9M2RV99hQ!egoFkUMikujSDC9nytvcPgOeJ93Z4QQMN9SJjZrpyzgFDTZETliRSk-gbvV-xoSZbmU$>
| Blog
<https://urldefense.com/v3/__https://rmannibucau.metawerx.net/__;!!ACWV5N9M2RV99hQ!egoFkUMikujSDC9nytvcPgOeJ93Z4QQMN9SJjZrpyzgFDTZETliRSk-gbvV-WvtUSKA$> |
Old Blog
<https://urldefense.com/v3/__http://rmannibucau.wordpress.com__;!!ACWV5N9M2RV99hQ!egoFkUMikujSDC9nytvcPgOeJ93Z4QQMN9SJjZrpyzgFDTZETliRSk-gbvV--tTz2GY$>
| Github
<https://urldefense.com/v3/__https://github.com/rmannibucau__;!!ACWV5N9M2RV99hQ!egoFkUMikujSDC9nytvcPgOeJ93Z4QQMN9SJjZrpyzgFDTZETliRSk-gbvV-DAha-eU$> |
LinkedIn
<https://urldefense.com/v3/__https://www.linkedin.com/in/rmannibucau__;!!ACWV5N9M2RV99hQ!egoFkUMikujSDC9nytvcPgOeJ93Z4QQMN9SJjZrpyzgFDTZETliRSk-gbvV--MHBTEk$> |
Book
<https://urldefense.com/v3/__https://www.packtpub.com/application-development/java-ee-8-high-performance__;!!ACWV5N9M2RV99hQ!egoFkUMikujSDC9nytvcPgOeJ93Z4QQMN9SJjZrpyzgFDTZETliRSk-gbvV-N3CiuuI$>
Le lun. 7 mars 2022 à 23:51, Brian Stansberry
<brian.stansberry@xxxxxxxxxx <mailto:brian.stansberry@xxxxxxxxxx>> a écrit :
On Mon, Mar 7, 2022 at 4:07 PM arjan tijms <arjan.tijms@xxxxxxxxx
<mailto:arjan.tijms@xxxxxxxxx>> wrote:
Hi,
On Thu, Mar 3, 2022 at 8:47 PM Brian Stansberry
<brian.stansberry@xxxxxxxxxx
<mailto: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
<mailto:jakartaee-platform-dev@xxxxxxxxxxx>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
<https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!egoFkUMikujSDC9nytvcPgOeJ93Z4QQMN9SJjZrpyzgFDTZETliRSk-gbvV-HhnmLwM$>
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
He/Him/His
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
<mailto:jakartaee-platform-dev@xxxxxxxxxxx>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
<https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!egoFkUMikujSDC9nytvcPgOeJ93Z4QQMN9SJjZrpyzgFDTZETliRSk-gbvV-HhnmLwM$>
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!egoFkUMikujSDC9nytvcPgOeJ93Z4QQMN9SJjZrpyzgFDTZETliRSk-gbvV-HhnmLwM$
