Initial steps toward breaking Spring Social into more cohesive submodules
First pass at connect work.
Upgraded to latest version of Scribe (1.0.8) which includes the fix for some improperly escaped characters, including the asterisk issue described in SOCIAL-59 and GREENHOUSE-471
Workaround for SOCIAL-53: Jetty doesn't like <description> within <tag-file>. Commented out <description> so that Spring Social can be used in applications deployed to Jetty.
Refined .gitignore
Temporarily rolled out account ID resolver and web packages, so that I can step through the essentials of SOCIAL-17 first.
Transitioned the pertinent tests from Greenhouse to the Spring Social connect module (along with a tiny bit of unfortunate duplication).
Added account ID resolver so that each individual client of a service provider won't have to pass in the account ID for all of the methods of ServiceProvider. SOCIAL-66
Merge branch 'connect'
Moved ConnectController and ConnectInterceptor into Spring Social in a new web connect module. SOCIAL-78 and SOCIAL-81.
Moved in FacebookConnectController (minus photo and status update functionality) from Greenhouse. Also cleaned up some stuff and added a few missing Apache license headers.
Initial work for SOCIAL-43: Customization of SQL queries. At this point it works, but I'm considering renaming the query properties.
Renamed the custom SQL methods on JdbcAccountConnectionRepository and JdbcServiceProviderFactory. Also, added accessor methods for all custom SQL properties on JdbcServiceProviderFactory that pass through to JdbcAccountConnectionRepository, as it is JdbcServiceProviderFactory that is configured in an application. SOCIAL-43.
Renamed property in JdbcServiceProviderFactory and added JavaDoc to be consistent with the other customer query properties. SOCIAL-43
First pass at adding methods to enable multiple connections per provider.
Further work on enabling multiple connections per provider.
Reworked FacebookWebArgumentResolver to throw an IllegalStateException in the case where a value can't be resolved, but the annotation in question is set as required. Otherwise, it will return either the resolved value or null if the value can't be resolved and the annotation is set to not be required.
Added a new getServiceOperations() method that takes the user's ID from the provider as an argument. Useful for getting an operations object specific to a particular connection in a multi-connection scenario. SOCIAL-84.
Added very basic Twitter sample app.
Since there's only one provider in the Twitter example, the abstract serviceProvider bean is unnecessary. Simplified example by removing it.