Another 3rd-party version policy question

[Tom Zeller]

> On Nov 2, 2015, at 3:46 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> 
> On 11/2/15, 4:44 PM, "dev on behalf of Cantor, Scott" <dev-bounces at shibboleth.net on behalf of cantor.2 at osu.edu> wrote:
> 
>> It's not impossible, if the dependency is truly internal only. It's not just a function of which module of ours is using something, but how it's using it. But clearly that's easier to wall off if it's an implementation class on our side, and I guess if it's only a transitive dependency via an impl module, that wouldn't be visible to correct maven file for a plugin.
> 
> That is a change, BTW. With V2, when this policy was generally thought up, anything that OpenSAML depended on would be transitively a dependency of any IdP plugin, in the majority of cases, so there'd be no way to know you were using a private jar.
> 
> I think that's not so much true now for at least the multi-module projects, in at least some cases. Not every case though. Keep in mind we dumped the idea of impl modules, we only really have impl classes now, so if those were in a module that had API classes, you'd have the same problem identifying that you were using something from a private jar.

Maybe it’s wrong of me to try and define the kinds of dependencies I’m thinking of (e.g. spymemcached) as dependencies of impl projects, that doesn’t work / is too difficult in general. But a “true implementation dependency” (like spymemcached) seems like it should not have to follow the “api” rules for code, but I guess for configuration it would have to anyway, so the point either seems moot or too complex to be worthwhile.

Thanks.