Sample Dataconnector for Shib 3.1

[Krug, Jeff]

I spent a bit of time reviewing the content of idp-attribute-resolver-spring, and specifically the class that I imported, the AbstractDataConnectorParser, and that has a quite a bit of functionality that I would expect anyone writing a Data Connector would want...  

I don't mind taking on the risk of having to update my code with point releases given the value I see in reusing this part of the IDP code, but I would be curious to see how a data connector should be written if what I am doing is wrong.  I certainly do not mind reworking the code I have if there is a better way.  

Thanks,
Jeff

________________________________________
From: dev <dev-bounces at shibboleth.net> on behalf of Cantor, Scott <cantor.2 at osu.edu>
Sent: Monday, May 11, 2015 2:04 PM
To: Shib Dev
Subject: Re: Sample Dataconnector for Shib 3.1

On 5/11/15, 2:01 PM, "Krug, Jeff" <Jeff.Krug at gtri.gatech.edu> wrote:

>Does that mean I should not have a dependency on idp-attribute-resolver-spring?  Or that it's subject to change with 3.* release?  Or both?

If you have a dependency on it that isn't just test scope, then I'm saying you definitely can't guarantee plugin compatibility across releases ever. Whether that's a fatal issue is obviously dependent on one's scenario, what the plugin audience is, etc.

If in fact that's the change that broke your plugin, that wouldn't be a bug on our part is what I'm saying.

>I had no dependencies on -impl libraries, but I did on that spring library and on net.shibboleth.ext.spring-extensions and net.shibboleth.utilities.java-support.

spring-extensions and java-support are API (as I said, none of this is clear to outsiders and we have to get it documented). The difference is, now we have an explicit dividing line we didn't really have before.

-- Scott

--
To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net