I think it might help if I explicate my use case a bit better.

Bundle A contains code to set up a validator. It can do this, as you say, without TCCL manipulation, if it uses a provider. (The Validation class in the ServiceMix specs bundle is a helper for that. It's just, if you like, syntactic sugar around a provider.) I can put anything I need to in the manifest of A, including an import for 'com.sun.el'.

The validator created in Bundle A is then called, for the first time, by code in bundle B. The TCCL at this time is B's classloader, or some other class loader. Now, the hibernate validator asks for an EL provider, and fails. This is harder to deal with (if you don't know about the externalClassLoader).

Having run into this, I read everything I could find, and discovered a variety of people using a variety of more or less clumsy solutions. For example, the two jars in ServiceMix, and various exercises in TCCL manipulation. I set out to set up a clean solution. I don't want to avoid EL, I just want to make the classloading work. I didn't find the externalClassLoader. I'm happy to discover that I did a poor job of searching.

Reading the contents of the 5.2.2_Final MANIFEST, it looks as if the alternative bundle in ServiceMix is no longer needed, as the remaining hard-to-get packages are marked optional. I think that, for the Karaf feature, it would be better to omit the problem cases than to call them out with 'wrap', or to make two features. I would be happy to patch that bit.

As far as EL goes, ServiceMix 'spec' jars tend to contain some attempt to help with the SPI, and 'bundle' jars contain help for problematic (or missing) manifests. So it's no surprise that there's no 'bundle' for EL. My remark about 'spec' was to wonder about the EL lookup mechanism.

An improved upstream bundle for the API would be a great thing.

I have a small testbed project on github. I will attempt to make it work using what I've learned here; assuming success, perhaps I could offer some doc patches?