[jboss-dev-forums] [Design of EJB 3.0] - Re: New Build Artifact - EJB3 External API

The problem with extracting the external API into its own project is that we introduce cyclic compile dependencies all over the place: EJB3 Core Depends on ext-api, and it's very difficult to ensure that ext-api doesn't depend on Core without losing compile-time constraints. An example we've been discussing over the past couple weeks is @Cache, which historically took a value of a cache implementation, and now accepts a factory. But either way, eventually one of the classes in ext-api must extend from or implement Cache in core. One benefit of the monolithic layout to EJB3 in AS is that the entire source is available in one tree, compiled simultaneously, and we can pluck out individual classes and manually JAR them to make the ext-api. Proposed solutions using separate modules have included using a registered factory like: @CacheFactory(type="NoPassivationCache") ...where the "type" String is configured in an MC Bean and bound to an actual cache impl or factory. But here the bean provider loses compile-time constraints. So I'm going to draw up some rules. 1) Core depends on ext-api to compile 2) ext-api cannot depend on Core; must compile on its own Given both 1) and 2), something has to give, either: A) We ditch some compile-time constraints to get around the circular dependencies B) We keep ext-api as a build artifact in EJB3 Core, produced by the build script C) We undergo some surgery to clear up and redesign how @Cache and @Pool are used and try to separate out concerns in StatefulContainer and StatelessContainer Thoughts? I'm in circles. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102748#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...