God no. I can see api and rt-core being combined. However, none of the other rt-* artifacts should be combined into it. All of those are modular for a reason and should stay that way.
The separation of API and CORE is mostly to aid in javadoc generation. If someone can find a easy way to generate javadocs for all the stuff in api, but not the stuff in core if they are combined, fine. However, I don't consider a monser list of includes/excludes an "easy" way of doing it. Remember, not everyone uses fancy IDE's and stuff. Javadoc of the stuff users/devs should be aware of is important. Dan On Tuesday 27 March 2007 03:19, Andrea Smyth wrote: > The policy APIs in the api module are a good example - the reason they > are there and not, along with the impl in the cxf-rt-ws-policy module, > is the modularization of the rt modules in the first place: cxf-api so > far has been a solution to keeping the numerous cxf-rt-* modules free > from circular dependencies. > If we combined cxf-api and cxf-rt-* (with packages in the latter being > moved into impl or internal packages) that would not be an issue, but > the jar and its list of dependencies will become quite big. > Maybe we should define which transports, bindings, and other > functionality are 'core' (say http, or perhaps only a jetty > independent http client, and soap) and which ones optional (jms, xml)? > The compromise may still be too granular for some and have too many > dependencies for others. > > Andrea. > > > > All of the > > Dan Diephouse wrote: > > Agreed. We have lots of arbitrary distinctions going on right now > > too. For > > instance, if you look at the WS-Policy bits you'll see we have half > > about in > > the cxf-api module by necessity. If you look at the classes, I don't > > think > > thats really ideal as I don't think that under ideal conditions you > > would want it that way. > > > > - Dan > > > > On 3/26/07, Hani Suleiman <[EMAIL PROTECTED]> wrote: > >> On Mar 26, 2007, at 4:53 PM, Paul Brown wrote: > >> > 2) I can't think of a (good) reason that code layout choices > >> > (separation of interface and implementation codebases) or > >> > artificial constraints (maven's predilections about directories) > >> > should influence artifacts. These things are also confusing -- > >> > do I need both the ifact and impl JARs? (Ultimately, if it's not > >> > for public use, then it should be package private anyway...) > >> > >> Yep! It's a pretty awful abuse of jar files. It's not like cxf-api > >> is a spec or that it'll have more than one impl that could be > >> dropped in. It's pretty pretentious to split it up that way. If the > >> intent is to distinguish between public and private APIs, then this > >> is a very poor way of doing so, for the following reasons: > >> > >> - IDEs will have both in the classpath, how often does anyone check > >> what jar a dependency comes from, if it's been satisfied somehow? > >> - It ignores the fact that packages exist for exactly this reason. > >> - Nobody else does it this way > >> - While the build classpath is sometimes bigger than the runtime > >> one, this particular split seems to feel that sometimes it's the > >> opposite (1 jar for build and 2 for deployment), which is fairly > >> ....uhm (can't think of a polite word)... as no other framework > >> makes this odd assumption. > >> > >> You're far better served by moving the impl into a 'internal' or > >> 'impl' package. That way a glance at the imports tells you > >> everything you need to know. -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727 C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog
