| Enrique Rodriguez 2007-05-28, 1:11 am |
| On 5/27/07, Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
> ...
> This might not be a good thing. If you build a CLI or RCP based client
> then it will pull in these dependencies. You see where I'm going with this?
OK, we're on the same page here. The problem isn't putting code that
would support a client into kerberos-shared, but rather that
kerberos-shared shouldn't have the dependencies that result in a core
dependency. I agree the full load of core deps shouldn't burden
clients.
> ...
> Hmmm it depends on protocol-shared which depends on apacheds-core even
> if it may not need the dependency. Probably there's some small peice of
> code
> in protocol-shared that depends on core code but that's not used by the
> kerberos
> shared module. Regardless though you have a dependency imposed due to the
> Maven dependency graph which will cause the apacheds-core jar to be pulled
> down. If we can do away with this it will be best.
The major culprit is ServiceConfiguration, which depends on
Configuraton and ConfigurationUtil, both of which are in the core.
Everything else in protocol-shared is easy to deal with.
>
> Yes this the point.
I can make that happen by moving kerberos-shared and protocol-shared
to the shared subproject. protocol-shared should move since it was
intented to be shared by protocols. That leaves core Configuration
deps. Any thoughts there? I think we talked at one point about
moving Configuration to its own module. We may need a separate base
class for service (protocol) configuration vs. core configuration.
That makes a lot of sense and of course Spring doesn't care. I
thought there was some requirement that a core Configuration had to be
in the env when obtaining a context using CoreContextFactory but I
could be mistaken.
Enrique
|