On 5/27/07, Enrique Rodriguez <[EMAIL PROTECTED]> wrote:
On 5/27/07, Alex Karasulu <[EMAIL PROTECTED]> wrote: > Just wondering if your kerberos client will use the kerberos shared library? > If so I'm wondering if it should > go into shared/kerberos? However I guess it does depend on the core right > and this is why it is in the apacheds > project? That question wasn't totally clear on account of the "it"'s.
Yes I see that ambiguity as well now that I read it again. My point was if you are putting client PDU code for the kerberos codec into the kerberos shared module in apacheds then this means any client like a LoginModule which you write will have a dependency on the kerberos-shared jar. I don't
see why I would put a client into kerberos-shared.
I thought from your commit log that you were putting client PDUs into the kerberos-shared module. If I'm wrong that's fine. What other modules
would share a client? Instead, other modules would share components providing client-side support so what makes sense is to put shared Kerberos functionality in kerberos-shared, such as ASN.1 codecs and components for requesting TGTs and service tickets, which could be shared by different types of clients, be they CLI or RCP.
Ok I see so I was right that you are putting client PDUs into this module. This just means that clients will now have a dependency on ApacheDS jars since kerberos-shared is technically an ApacheDS module. This is so because it depends on core transitively through the protocol-shared module. 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? The Kerberos client I am working on is a CLI client with a dependency
on Commons CLI. The CLI Kerberos client currently does depend on kerberos-shared, hence my codec commits to kerberos-shared. This Kerberos client should be mostly wiring together Commons CLI with codecs and the aforementioned ticket request components.
Yep I get that but it also depends on apacheds-core. Kerberos-shared is a shared library, intended to be shared by servers
*or* clients.
Ok this is exactly why it might be better put into the shared project rather thank keeping it in the apacheds project. Basically it would be analogous to the shared/ldap module which does not depend on the core but can be used by it as well as any clients. We do not want these shared libraries for various protocols to be pulling in dependencies from the server. SNIP If you're wondering how this could work with enhancements to
LdapStudio, then I was picturing LdapStudio plugins would depend on kerberos-shared and not pick up any of the CLI-specific code in clients-kerberos.
No that's fine. I'm just thinking we might want to move the kerberos-shared module into the shared subproject instead of keeping it in the apacheds project and removing the dependency on core. This probably just means replacing or duplicating (if small) the code that the kerberos-shared module depends on in the protocol-shared module. Or another option is to move the code that is depended on into the kerberos-shared module. I'm sure there are other options as well but the whole point is to remove the dependency that kerberos-shared has transitively to the apacheds core. kerberos-shared shouldn't have any dependencies on core. I think it
is mostly in apacheds trunk for legacy reasons.
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. Though, it does have
a dependency on ConfigurationException, but that's easy to either get rid of or, since it occurs in single vs. multi-base searches, replace when we have a better solution for multi-base searching. 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. Alex
