This brings up a couple issues. 1) How we resolve the conflict 2) How we continue with ejb3-ext-api-impl (if at all) 1 - Resolving the conflict with ClusteredImpl may be a bit more involved than it seems because AS5 Beta3 shipped with @Clustered within the ha-client version 1.0.0.BETA1. Beta4 is currently gunning to use the same version, but if Brian's got changes he needs to get into the release, @Clustered will disappear (as it's been moved to ejb3-ext-api). So we've got three projects tied together (for the time being), ejb3-ext-api, ejb3-ext-api-impl, and ha-client. If we bump up any of these releases for Beta4, we must bump up all. This binding was intended for structural changes to code in ext-api and ext-api-impl. So resolution depends, then, on what version of ha-client will be used in Beta4. If we stay on 1.0.0.BETA1 then we'd have to backport the annotation impls, unless... 2 - Moving forward, we'll go with the conventions we've set forth for versioning: 0.2.x should be the next series, not 0.1.4. This way we won't have to increment betas (Beta2 in the case you'd shown isn't really Beta2, its got new featuresets). However, I thought the point of moving these annotation impls into their own package was for the following benefits: * Discourage interdependencies within projects * Allow for separate, frozen lifecycle * Logically divide code and keep components small For instance, if both Core and Interceptors need ExcludeClassInterceptorsImpl, wouldn't it be better for them both to depend on an ejb3-ext-api-impl than Core > Interceptors or vise-versa? I suppose point 2) is a matter of preference. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4123290#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...