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.
