If we only had build compatible extensions, they would probably be called "portable extensions" :-)
I don't see a good name here really. "Build compatible extensions" is a huge compromise and it sounds ugly, but I can't think of a better one. (I tried, there's a thread on cdi-dev, feel free to resurrect it.)
When it comes to current portable extensions, I'd prefer not to rename, simply because the name has been in use for too long. That itself, in my eyes, trumps the other arguments.
LT
Hi,
On Friday, January 28, 2022, Matej Novotny <manovotn@xxxxxxxxxx> wrote:
I wouldn't change what we needn't change.
But if need to change, we could change.
“Runtime only extensions” vs “Portable Extensions”.
Think about it in a different way, suppose those other extensions didn’t exist yet and we only had the build compatible ones. Now we had to vote on a name for those other ones.
What would be the chance you spontaneously would call them “Portable Extensions”?
The name build compatible extensions isn't perfect but the group came with no better. It basically captures the main intent for which they were proposed.
However, Lite is a subset of Full and as such Lite extensions can be executed in CDI Full as well in which case they will (most likely) be executed in runtime, just like portable extensions.
Basically, you can think of build compatible extensions as an extension model:
- working for CDI Lite
- portable between various CDI Lite implementations
- portable from CDI Lite to CDI Full
Matej
I think the reason why the name "build compatible extensions" stuck is that it is an extension of a runtime-only mechanism to build time. Portable extensions are not "runtime compatible", they are "runtime only". Build compatible extensions are runtime compatible too.
LT
Hi,
So if there's nothing vendor specific about the "build compatible extension API", and the word portable is completely superfluous (I agree), shall we rename portable extensions to "runtime compatible extension API"?
Kind regards,
Arjan Tijms
I think it's fair to say that the word "portable" is completely superfluous. If the extension mechanism is defined in the specification, it's portable by definition. The build compatible extension API is defined in the CDI specification (well mainly in the javadoc, just like portable extensions) and there shouldn't be anything vendor specific about it.
LT
Hi,
We now have two types of extensions in CDI; "Build compatible extensions" and "Portable extensions".
Do we mean to say that "Build compatible extensions" are not portable, and are vendor specific?
Kind regards,
Arjan Tijms
_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev