Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] [External] : Simplifying the platform by merging some specs?

I should also add that the proliferation of specs makes it more confusing for end users. Having three specs for security is overkill. This would also help us optimize resources, which I think is what Arjun is thinking about.
___

Kito D. Mann | @kito99 | Java Champion | Google Developer Expert | LinkedIn
Expert training and consulting: PrimeFaces, PrimeNG, JSF, Java EE, Web Components, Angular
Virtua, Inc. | virtua.tech 

* Enterprise development, front and back. Listen to stackdpodcast.com.




On Tue, Mar 1, 2022 at 8:12 AM Lukas Jungmann <lukas.jungmann@xxxxxxxxxx> wrote:
On 3/1/22 11:43 AM, arjan tijms wrote:
> Hi,
>
> In the past we've split out functionality from specs where it made sense
> into new specs and that worked quite well.
>
> Currently however we also have a number of specs which I think are never
> or rarely shared, and should perhaps be considered to be merged.
>
> For instance;
>
> *Jakarta Mail and Jakarta Activation*
> *
> *
> Does anything out there ever use Jakarta Activation in a context not
> related to Mail?

Yes. XML specs (XML Binding, SOAP as well as and XML Web Services) at least.

thanks,
--lukas


  Seeing as they are always implemented and released
> together, it may make sense to merge them.
>
> *Jakarta Pages and Jakarta (Standard) Tags*
> *
> *
> I don't think Tags are ever used outside Jakarta Pages. Does it
> really make sense to have the core tags for Pages in a separate spec?
> For instance, Faces has a number of core tags too, but despite us
> desperately wanting to slim the spec, I don't think anyone would dream
> of making those Faces core tags a separate spec.
>
> *Jakarta Security, Jakarta Authentication and Jakarta Authorization*
> *
> *
> It has been proposed before to merge these, but hasn't been done yet. In
> this case the lower level specs are used standalone, but there's no
> independent development or teams working on either of them in isolation,
> and actually never have been. So for these making Jakarta Authentication
> and Authorization sub-specs of Security might be the way to go (so they
> automatically have the same committer team, same CI, etc)
>
> *Jakarta Dependency Injection and Jakarta Contexts and Dependency
> Injection and Jakarta Interceptors*
>
> Within Jakarta EE the split between Jakarta Dependency Injection and
> Jakarta Contexts and Dependency Injection is rather superficial, only
> brought about because of the competing JSR 330 at the time. Like in
> security, there is no individual team with its own roadmap maintaining
> Jakarta Dependency Injection. Here too it may simplify things by making
> it at least a subspec of Jakarta Contexts and Dependency Injection (and
> while at it, renaming it to simply Jakarta Inject).
>
> Interceptors was originally split off from EJB, and it still applies to
> Jakarta Enterprise Beans. But as the platform has been migrating all
> Enterprise Beans services to CDI compatible ones, and there is no desire
> to advance Enterprise Beans in any way, practically speaking
> Interceptors would only be advanced in the context of CDI.
>
> Thoughts?
>
> Kind regards,
> Arjan Tijms
>
>
> _______________________________________________
> 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!f2IPl1k9GUy7A-ebnCGVrNgwugkVjnNNu9ePuIYoNaD2pytfixVTy05_WCQiHjokwWA$

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

Back to the top