For GenericFX/BrainFX/BAMMfx (the software), year 2005 sees the completion of
basic user-oriented features. To tell the truth, there is not much excitment year especially when compared to previous year as we roll out the innovative Input Data Spreadsheet. The excitment is mainly in the development front focusing on how the concept of GenericFX evolves. The year was also spent experimenting with different features offered by the Eclipse Platform such as Update Sites.
The next article will discuss a few development plans worth considering and explore in 2006.
Review of Year 2005
User-front
As mentioned before, compared to 2004, 2005 was not so exciting on the user front. I had completed the basic functionalites expected by the users. Year 2005 was mainly spent on experimenting with user-oriented functions offered by Eclipse with the view of incorporating them into the software. Features experimented with includes "Update Sites", "Features Discovery Site" and "Eclipse Intro Support".
Some users will notice that we introduced a "
lite" version of the software. This is the manifestation of changes in GenericFX's overall development plan. This is discussed in more detail in the next section.
Development front
Creation of GenericFX and BrainFX SourceForge.net Project Site
In order to demonstrate commitment to open source, SourceForge sites for GenericFX and BrainFX's are created. SourceForge.net is the custodian of the source code for the two softwares. I uploads tested-release onto those sites. Originally, I planned for a three months interval between releases. After doing this for three quarters of a year I find that the amount of testing required (a month) before uploading to sourceforge.net is unbearable, therefore I am moving into a twice yearly schedule.
Major Shift in Development Strategy
Improving useability by stripping down BAMMfx
Originally, GenericFX was designed to be use inside the main Eclipse Platform. It supplies pipeline-related facilities for the main Eclipse Platform. The idea is to make GenericFX available alongside other facilities of the Eclipse Platform. To use GenericFX, users must first fire up the Eclipse Platform. GenericFX can then be invoked through the appropriate user interface elements (menu/toolbars/editors).
The first test-drive of BAMMfx by a BAMM developer shows that this approach is problematic for end users. End Users only want to use the pipeline facilities. Hence, the available of other facilities offerred by Eclipse Platform is "irrelevent". Their presence, as far as end users are concerned, pollute the user interface of BAMMfx and reduce useability. This is made worse by the fact that the facilities contributed by BAMMfx is always going to be miniscule compared to that offerred by the Eclipse Platform. Hence, for end users, it is going to be like searching for a needle (BAMMfx facilities) in a haystack (Eclipse Platform).
To solve this problem, it is decided that it will be necessary to strip Eclipse Platform down to remove these clutter and to deliver an interface which spot BAMMfx related functions only. To this end, it is decided that we shall start on delivering only the most important feature of BAMM first: Batch Processing. Therefore, the first strip down version will feature the Input Data Spreadsheet only and the minimal set of facilities needed to support batch processing. We call this the BAMMfx-lite version.
I used Eclipse Rich Client Platform Technology (RCP) to deliver BAMMfx-lite while leveraging existing work on BAMMfx. Although a lot of components from BAMMfx were reused in BAMMfx-lite, nonetheless, maintaining both BAMMfx and BAMMfx-lite involves maintaining two separate user interface.
New Strategy
With the inception of BAMMfx-lite, the strategy was to made BAMmfx-lite a subset of BAMMfx proper. The strategy proved to be problematic because any changes in BAMMfx-lite must be evaluated against the need for its larger cousin BAMMfx proper.
I decide to following the strategy proposed by Chapter 23 of the book Eclipse Rich Client Platform. The strategy called for a separation between "product", what the users see and use and the development "platform", i.e., a pool of reuseable source code (in the form of plug-ins). The idea is to maintain them separately. This allow the development of distinct but highly-related "product"s from the same "pool" of plug-ins. "Products" takes as much as it can from the common "pool", then write stuff that is missing from it to complete itself. This strategy make BAMMfx-lite an equal peer of BAMMfx proper and allow other products to be developed, as necessary.
As for the common pool of plugins, I will maintain the separation between User Interface (UI) and the program actual functionality (framework). There will be three tier of user interface, defined by its dependency on Eclipse Platform components :
- swt/jface - Dependent on "org.eclipse.swt" and "org.eclipse.jface". No dependency on "org.eclipse.ui". Dependency on "org.eclipse.core.runtime" (the Eclipse Platform) is inevitable because of the way the "Framework" is developed (org.genericfx.data package in particular).
- workbench = dependent on "org.eclipse.ui" only
- IDE - dependent on both "org.eclipse.ui.ide" and "org.eclipse.ui"
Refactoring the Software Code and Moving to Eclipse 3.1.1
In late November, a decision was made to refactor the software code and migrate the software from Eclipse 3.0 to Eclipse 3.1.1. The decision was motivated by better support for RCP technology in Eclipse 3.1.1, the need to refactor the software to suit the new development strategy and to remove accumulated problems in the source code.
Moving to Eclipse 3.1.1
Eclipse 3.0's support for RCP technology is vastly different from that of Eclipse 3.1.1. RCP technology was introduced in Eclipse 3.0 as a stepping stone to that used in Eclipse 3.1. This means there are not as many sources of help (books, articles etc) for RCP in Eclipse 3.0 compared to Eclipse 3.1. Support for development of RCP is also lacking in Eclipse 3.0 compared with Eclipse 3.1.
The original BAMMfx-lite was developed using RCP in Eclipse 3.0. It was mainly a proof-of-concept prototype. As it is inevitable to move to the RCP model in Eclipse 3.1, I decided the project will be better off if we start development using Eclipse 3.1 RCP model to avoid future rework.
Removing Accummulated Problems in the Source Code and Refactoring for the New Development Strategy
Changes in project name from EPLlab to a combination of GenericFX and BrainFX means it is necessary to rename "org.epllab" to "org.genericfx" and "org.brainfx", to change prefixes (from "EPL" to "GFX" and "epl" to "gfx"). Small errors that accumulates, such as using "org.genericfx.file" instead of "org.genericfx.files" are removed.
Moreover, the new development strategy requires careful consideration of software dependency (with respect to dependencies on the Eclipse Plaform)to support the different configurations. The original code does not pay much attention to this aspect of software dependency because it was unnecessary.
The concept of separation between development platform and target platforms as advocated by Chapter 4 of Eclipse Rich Client Platform is used to facilitate testing/packaging of the software. This made refactoring w.r.t. dependencies on the Eclipse Platform) more important than before.
Conclusion
On reflection, year 2005 is more a year for internal review of how the software is developed rather than breaking new grounds in terms of user useablility. Changes are mostly not visible to the outside world but can prove to be crucial in the continuing development of the software.
This is a follow up of the review of year 2005 and yes, I did write workplans. At present, I have a few possible directions to go on developing the software. I have yet to decide on one yet. Two important sections affecting the final work plan: Compu
Tracked: Jan 05, 16:31