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.
-- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
