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.
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).
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.
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.
- 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).
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).