On 5/27/07, Alex Karasulu <[EMAIL PROTECTED]> 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.
> If you're wondering if kerberos-shared can be moved to the shared code > outside of trunk, then I think that makes sense, with a little > refactoring to remove minor deps on core. 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
