List of project ideas for
Google Summer of Code 2013

Our organization is mostly presented by students from Sevastopol National Technical University (SevNTU), Ukraine. But this is just historical fact, we are open for help from any other contributors/students.
Organization is supervised by developers from Revere Data LLC, however, we are open to any mentors from other organizations who have interest.
License of code is GNU LESSER GENERAL PUBLIC LICENSE Version 2.1.


Roman Ivanov: romanivanov [dash] jr [a] gmail [d] com



Brief explanation:
Our project is extension to EclipseCS plugin. You can install our project from Eclipse update site of EclipseCS plugin in "Uncategorized" group. List of our already implemented Checks is here.

Our project is a sort of a test area for many of non-standard Checkstyle Checks; some of them are presented in main stream of Checkstyle project and some have not yet shown up in there. Unfortunately, generating an idea of a new code-rule is not a trivial task. An idea has to be proven and tested throughly on a wide range of projects in open-source community, before it can finally get into the main project and become of use for most of the developers.

Our team collects ideas for the project from our experience, books, blogs and forums. We automate these ideas, integrate them into our Checkstyle plugin. We improve Eclipse to “drop hints” to developers about error-prone practices, thus, speeding up the process of their self-education, and assisting advanced developers.

We have ideas and we cannot wait till Checkstyle project apply our patches. Eclipse plugin allow developers to take advantage of our ideas right now and give them freedom to choose those Checks they need and consider reasonable. But we also provide extension to maven-chestyle-plugin, so anyone can use our Checks in maven site generation or build validation.

This project is the best way to study Java from the syntax point of view. It helps students to acquire best practice approaches right from the beginning of their developer's career, instead of going through long and tiring trial and error method. After completing writing a Check, student will get knowledge about how to automate the process of error-detection in code, and he will use that results in all his future work places, and help all other developers avoid writing a 'bad' code. Writing a Check requires only basic Java knowledge. Code of one Check is in average of 400 lines, so it makes it easier for a student to complete task on time.

Issue Tracker entries: #90, #86 , #83 , #82 , #81 , #80 , #79 , #77 , #76 , #75 , #74 , #73 , #72 , #71 , #70 , #69 , #68 , #67 , #66 , #65 , #63 , #58 , #47 , #32

Expected results: All issues have to be closed; all code is to be covered with UTs; JavaDoc has to be created for each class; each Check should be tested against huge open-source projects (Spring, Hibernate, Log4j, …); patches should be created for Checkstyle project.

Knowledge Prerequisite: basic Java (Java SE) skills, basic knowledge of parsers and syntactic analysis.

Mentor: Roman Ivanov

Mailing list: sevntu-checkstyle [at] google groups [dot] com, web page

IRC: #sevntu.checkstyle on Freenode

Wiki: to help student setup development enviroment quickly


Brief explanation:
Dependency Structure Matrix (DSM) is a very powerful approach in the analysis of the software architecture and design. It allows a developer or an architect to see inter-module dependencies in a more convenient way than the traditional graph ("box and arrows") technique allow. Graph representation is too difficult to be used for applications that are bigger than 20 classes.

Dependency analysis is usually under-estimated during development or even completely ignored. It proves its effectiveness only on the stage when one try to divide project/class into several parts, or try to refactor code, or exchange part of project/class with new implementation, or try to UT code. The more dependencies a class has, the more complicated and painful the refactoring can be. Most of the unwanted dependencies are unintentional. They represent remnants after refactoring or incorrect selection during Intellisense suggestions (developer was too tired to notice that his DAO package started to use classes from UI package).

DSM already exist in popular IDEs (Idea, MS Visual Studio), and as separate application Lattix, NDepend, Sonar.

Our idea is to create native to Eclipse plugin with free license to let all Java developers that use Eclipse to integrate DSM analysis during code writing process instead of analyzing the code after task completion. In that milestone we will focus on UI presentation. DSM structure will be taken from open-source dtangler library. Additionally, we will focus on improving convenience of DSM usage in Eclipse and simplifying navigation from matrix to real code. Usage of dtangler library was already successfully tested in our dsm-maven-plugin. Detailed description of Eclipse-dsm-viewer project could be found here.

Issue Tracker entries:
Main task: #24
Satellite tasks: #22, #23 , #25 , #26 , #27 , #28 , #29 , #30

Expected results:
  • Integration with Eclipse (pop-up menus, preferences, rendering as Eclipse View)
  • Existing or self-written UI control has to be used to show dependency matrix in a similar way as it is shown here. (Levels of dependencies should be drawn in the flat manner, highlighting circles in matrix, tracing "from" and "to" dependency, showing difference in levels and strength of dependency between modules).
  • Provide navigation from Matrix to Java code editor.
  • Plugin has to be tested on huge open-source projects (Spring, Hibernate, Log4j, ...) to examine its usability and performance.

  • Knowledge Prerequisite: basic Java (Java SE) skills, SWT, Eclipse RCP.

    Mentor: Roman Ivanov

    Mailing list: eclipse-dsm-viewer [at] google groups [dot] com, web page

    IRC: #eclipse-dsm-viewer on Freenode