Stop the Architecture Erosion of Eclipse And Open Source Projects at EclipseCon 2011

Bernhard and Frederic began their talk defining software architecture and architectural erosion, which means that your system becomes deprecated and overloaded

Then, Bernhard evoked Findbugs, saying that

  • back in March 2004, only 4 packages for version 0.7.2, very simple
  • new features added for annotations for example, few months later, still looking good
  • in May 2005, a first cyclic dependency appeared, in the svn log, « temporary hack »appears
  • June 2006, version 1.0.0 many packages,   new cyclic dependency,
  • 2009 : many, many tangles

Can you still maintain easily this project ?

He followed his explanation with a tool called Sotoarc to show the dependency between classes and packages; he also mentioned PDE dependency visualization

To check your dependency, you can perform architectural inspection with some architectural tools.

Then Frederic explained to the audience the critical aspect of the architectural quality of an open source project: it is used by many many consumers.

He then enumerated the risks of Erosion in FOSS :

  • contributors from several organizations (different processes)
  • lower pressure from management
  • hazardous funding

What about Eclipse project then ? Bernhard analyzed the architecture of JDT, and found out that the org.eclipse.ant.ui plugin uses JDT, and this dependency could have be avoided.

Also, duplication of code can cause problems of maintenance; he demonstrated this problem with a DialogField class in Eclipse, duplicated since 2.0

Frederic introduced to us the recommendations of the Architecture Council.

Also, some new eclipse projects, such as Orion, the web based ide, introduce new architectures.

To migrate your plugins from Eclipse 3.x to e4 , you have to go through an architectural modernization process which consists in auditing, testing, etc…

To do that, he suggests to use models to represent and manipulate artifacts of existing projects, using MoDisco; so that you can get in EMF the model of  a plugin (sources folder, plugin.xml, etc..

Once you have the model represented, you can proceed to the migration of this model to the model of e4 for example.

You need to analyze and proceed to modernization of your tools.

http://www.eclipsecon.org/2011/sessions/?page=sessions&id=2001