Hi, While doing a code scan for opensource legal approval to use Shindig in our software products, we have some concerns on jsecurity cryptographic referenced in the social-api/org.apache.shindig.social.sample.SampleRealm. This class is used by SampleModule, which is an example for developers to follow to build their own production ready GUICE module.
Since this code is used just for examples, one thing we'd like to do is restructure the code to make it easier to tease it out from the core of shindig. In Shindig core projects (social-api, gadgets, common, etc.) there's a "samples" project where this code resides. We think it makes sense to move the whole social-api/org.apache.shindig.social.sample to the samples folder. Refactoring the code out from social-api will keep the project clean of sample code. We've tested this refactoring out and have not run into any issues. There are, of course, a few configuration steps that we had to do: 1. We added "samples" project to the buildpath to point to the new location of the package so that shindig-project code would compile. 2. We added "samples" project dependency in the main pom.xml and the server pom.xml so that the war includes the sample code and wouldn't break the sample container examples. 3. We're currently investigating how to create an additional server maven build profile so that we can build a war without the sample code for production usage. In this scenario, it's expected that the user will add in their own GUICE module that provides similar functionality as SampleModule/ SampleRealm. IF they don't do that, the war will very likely be broken and unusable, but since we're all required to implement our own GUICE module for this case, a drop of a jar of some similar method should fix this. We will document these steps so everyone is on the same page. We will open a JIRA bug for this effort, any other suggestion and/or solution is welcome. Thanks, Han
