Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Google Summer of Code 2013
Clone this wiki locally
Google Summer of Code 2013
Welcome! This page hosts ideas for Google's 2013 Summer of Code. This should be used as a starting point for student's that are interested in contributing but feel free to expound upon these ideas or come up with your own! Additional ideas should be posted/discussed at our forums
Information for Students
Thanks for expressing interest in contributing to Broadleaf! If you have any questions or would like to connect to us directly, please feel free to post on the forums or send us a direct email. We recommend that students that would like to contribute to Broadleaf have at least some Java experience, while the ideal student would have some experience with the following (some of which is dependent on your specific project idea):
- Spring Framework and Spring MVC (a huge plus)
- Familiarity with web technologies
- Familiarities with other web frameworks
- Java web application development in general (a big plus)
We have also pointed out recommended experience specifically for each suggested project. Again, this is recommended experience but not required. If you are a self-motivated person then you should be able to pick up specific domain knowledge as you work throughout the summer.
Write a mobile application to exercise/demo our REST APIs
We have optimized most of our Heat Clinic application (which serves as our demo site and can be viewed at http://demo.broadleafcommerce.org/heatclinic) for the mobile web using media queries. This way, if you are on your phone and go to a Broadleaf site (or just the Heat Clinic application) you'll have a mobile-specific experience and different elements will resize themselves to support the smaller screen. However, we do not have a good demo of our REST APIs (which we offer in XML and JSON) which could also be used in mobile applications. Ideas for utilizing this could be:
- Using the previously created client framework, build a demo application that allows for product/category browse, add/remove/update cart and checkout completion. This would represent the most basic functionality but this could also be enhanced to include viewing your account (like order history)
- Through this process, identify gaps in what we offer for our REST APIs and what would be required to fill in the gaps (for instance, our content management system is not REST-enabled)
- Familiarity with using REST APIs
- If you are developing a mobile application, some experience in that domain is preferred
Add security to our REST APIs
This could technically be wrapped up into the previous idea but could also be tackled as a separate project. We do not offer any security (either OAuth or generic API security outlined by http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/). For a little more detail:
- API Security - security on an application level. Individual sites that utilize Broadleaf might want to implement some sort of security level for which REST clients have access. This would prevent unauthorized REST client access to the APIs of a Broadleaf site.
- OAuth Security - this could be either OAuth v1 or v2. This is slightly different than general API security; rather than authenticating a particular REST client as a whole, this would authenticate a REST client for use of specific Customer data (like username/password and obtaining order history).
- Databases - you will likely be making domain changes to support any kind of security you are adding
- Spring MVC/Spring Security - Some modification in this domain will likely be required
- Jackson - this is the server-side framework we use for our REST APIs that you will likely need to deal with in order to properly implement any type of REST security
Fix/Update our Grails plugin
We started on a Grails plugin but it has fallen into disrepair. This targets Broadleaf version 1.7 (latest stable version: 2.2.0) and Grails 2.0.3 (latest stable version: 2.2.1). This would be a great project for someone that wants to learn Groovy and/or Grails which has been steadily gaining traction in the Java community.
Improve Broadleaf's Test Coverage
Our test coverage is currently pretty lacking and could definitely be improved. A good solution to this would look like the following:
- Get our test coverage to above 70%
- Ensure that there are at least some tests for each of our core modules (for instance, our admin code currently has 0% test coverage)
- Write better tests for our Spring applicationContext merge process
- Hook up Broadleaf to something like Sonar or Cobertura (which has a maven plugin we are using in some of our integration modules). This well help us publicize our test coverage and identify exactly what areas of Broadleaf are missing tests
- Some previous eCommerce experience to write good tests
Write new integration modules
We are always looking to enhance our third party integration offerings. These could be separated into different categories such as:
- Payment Modules (PayPal, Authorize.net)
- Shipping Modules (USPS, FedEx)
- Fulfillment/OMS (ShipWire, Order Harmony)
- CRM Integrations (SugarCRM, SalesForce, Zoho)
Java. If you have integrated with a provider in a different language or for a different project and would like to port that integration over into Broadleaf, that would be awesome but that is certainly not required.
Integrate with new services that have a non-US focus
While the Broadleaf organization is in the USA, we have a lot of interest from international markets, mainly based in Europe where open source (and Java) is very attractive for various organizations. Any additional integrations that have a specific focus on sites based outside of the US (for instance, UK mail) would be great.
Other more concrete ideas for possible integrations that we do not have currently:
Support additional features in existing integration modules
For example, we built a UPS integration and utilize their rate estimation (calculating cost of shipping). There are many other services that UPS offers that we do not have support for. This applies to other integrations we have built like Authorize.net; we built the standard authorize+debit but did not build splitting up authorize and debit at different times or handling refunds.