My +1 for most of the bullet points, except:
This point should NOT be part of the profiles.
I'd be very happy if we could get this one into a spec of its own, then have it added to every single profile.
I'd love to have this as a spec, mainly, because it would make it easier to move between environments/vendors/impls (or, at least, it wouldn't add another set of migration issues).
The specifics of the implementations, as always, would be left on the vendors hands, but we might be able to at least define a general definition for what we would want the mechanism to do, and maybe a couple standard config schemas (parameters, values, maybe some standard format for XML/JSON/whatever languages to use for config), that the vendor could extend as they wish... Something similar to the way the JVM is configured, where we have a set of standard params, values, gcs, etc for every JVM, then every vendor has added extras as needed/wanted.
Doesn’t the new module system cover this?
Just as with the previous bullet point, this is way outside of the realm of profiles.
Again, this could be a spec or project on itself, for some kind of tool or tech.
We need to keep the differences between Spec, Profile, and Impl in mind.
The profile should be the spec/doc/cert/etc that allows us to define a set of standardized platforms/environments/stacks/APIs for the Java Community to work on (be it vendors with impls and certs, or users with envs).
+1
We can't forget that profiles serve two main purposes: environment/stack standardization and certification.
Anything that strays from those two should not be considered as part of a profile, but specs and techs that could be part of, or used to extend, a profile.
+1
Also, going back to the bullet point about inheritance, I agree that we should make sure we keep the profiles as decoupled as viable, but we need to make sure of a few things:
- We should be careful not to end up with dozens of utterly unrelated profiles (make sure the vendor needs don't supercede the users/community needs). If every single implementation in the wild has their own profile, then profiles become pretty much worthless.
+1
- While we might find it very difficult, or even illogical, to keep every single profile inheriting from a base one (just to allow a certain interoperability between all profiles), we should still have at least an ordered hierarchy.
Maybe we could define more than one "base" profile, and then sub-profiles for each base? For example, we could have a base for each type of environment/server/stack (app server, web server, mobile, cloud, desktop), which would be the equivalent of the current full profile (every single API that might make sense in that environment), then have a few pared down profiles for each (just as the web profile is a sub-set of the full profile).
I’ve always had in mind a “Core Profile”. The Core Profile is basically the absolutely minimum things that any profile should have. There are lots of possibilities here but lets remember that the purpose of Jakarta EE is “enterprise applications” which mean that we should be thinking of compontized business logic. Designing a profile that runs on an embedded device would be outside of that scope. Designing a profile that allows the processing of information from a web of embedded devices would be within the scope.
If the foundation of Jakarta EE is support for business components and cross cutting concerns than the Core Profile, the profile on which all other profiles may be based, would specify one or more component models and some subset of cross cutting concerns as well as standardized configuration.
In that case, I would suggest CDI, Interceptors, Annotations, Servlets, and Security as a minimum.
I include Servlets because the processing of HTTP/TCP requests is at the core of so many technologies over the past 25 years. I would not require JSP or JSF in the Core because those are specific to a web browser presentation, but any profile could add a technology on top of the Core to extend the Servlet model. The Web Profile might, for example, include the Core and JSP and JSF.
CDI is, I think, is an obvious choice here. It’s use is rapidly spreading to everything from EJB-style business components to beans in JSF and JSP to MIcroProfile.
Interceptors are an excellent way to introduce new functionality including cross cutting concerns (e.g. Transations).
Finally, I think Security is the one cross-cutting concern that must be part of the Core. At the very least it should address authentication, authorization, and encryption of communications (e.g. HTTPS).
The Core Profile would not have to be the only base profile - eventually there could be another - but I think it provides a solid foundation for getting started.
Following that mindset, we could still have a Full Profile at the top, then a first level of base profiles, followed by one or more levels of less general profiles (e.g., Micro as a level two subset of Cloud)
On the matter of naming, I'd always connect the term "Full Profile" to the one with every single spec, including the legacy ones (that's why it's the full profile, it has everything)
I'd call the legacy free profile something indicative of that ("Legacy Free Full Profile", and its permutations, sound horrible to me, but I can't get any better idea right now).
I prefer “Legacy Profile” for what we now call Java EE and “Full Profile” for everything all together. That idea of a “Full Profile” is important because in order for Jakarta EE to be a true platform all the different APIs have to be able to work together even if they are not specifically described within the same profile. That way, a vendor can offer a product that supports multiple profiles without fear of conflicts between profiles.
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community