Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdi-dev] Build compatible extensions vs Portable extensions - naming

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


On Fri, Jan 28, 2022 at 8:56 AM Ladislav Thon <lthon@xxxxxxxxxx> wrote:
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

On Thu, Jan 27, 2022 at 6:04 PM arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
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

On Thu, Jan 27, 2022 at 4:41 PM Ladislav Thon <lthon@xxxxxxxxxx> wrote:
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

On Thu, Jan 27, 2022 at 4:22 PM arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
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

Back to the top