EATS Development Journal

This is a starting point for an EATS Development Journal. The point of the journal is to provide something along the line of a historical timeline treatment to the documentation of software development activities and status as I begin the redevelopment of EATS related code under an Eclipse framework.

This journal is being started in conjunction with the restart of software development activities now that I have established a minimal documentation and information sharing environment in the form of this web site, architecturedfutures.net. At this point I haven't done much (any) coding in quite a while. But I do have a reasonable base of code built up which I want to re-establish into a functional base platform on an Eclipse framework, so I can then move forward with some of my grander ideas. I've also established Eclipse as my target development framework, but I don't really have as much development expertise with it as I feel I want to in order to really know how to best use it for my purposes. So my current task is to establish a plan to correct this situation.

As I've documented in part in the Eclipse reference book on this site, I have played with Eclipse to some extent. And some of that has been with portions of the more sophisticated tooling of the Eclipse Modeling Project. There is a lot of leverage and power in this tooling, but it also has a few problems:

• There is a general lack of informative documentation that explains how things actually get done. This may be a problem which exists in my own mind, in my ability to understand materials which are available; because I don't have the proper background understanding. Whatever the reason, it makes me leery about jumping into the GMF tooling space with both feet prior to obtaining a better foundation in Eclipse fundamentals.
• I'm concerned about ongoing support for development work which is fully dependent on some of this technology. Some of this work is reasonably sophisticated, and use of it seems dependent on the availability of ongoing support. Some of that support seems nebulous. There has been some very nice tooling made available through open source activities of major companies such as Borland and IBM. But some of that work has been proof-of-concept for the company, and there is no commitment to ongoing development and support. For example, the UML2 tooling which seemed useful as a base product now seems to have a dubious future. Instead, the Papyrus Project seems a more viable candidate for this purpose. And the GMF work was led by Richard Gronbach and sponsored by Borland as part of their Together product. Gronbach no longer works for Borland and Together is no longer listed as a product on the Borland web site. The Eclipse Community Forum contains the following comment:

UML2 Tools was an exemplary demonstration of GMF Tools developed by committers almost entirely funded by Borland. Unfortunately when Borland 'lost interest' in modeling, a number of Eclipse projects were left searching for new supporters. Extended UML functionality was reserved for a Borland proprietary product; just the same as IBM's extended UML functionality is reserved for IBM's proprietary product(s).

Riding the bleeding edge is always a problem, and I want to be careful how I build my dependencies on some of the Eclipse Modeling Project components. Some of the elements appear to be very solid with wide community support. For others, I want to be more careful. What I've established as a set of short term goals is the following:

1. Create an Eclipse-based EATS shell that can serve as the basis for new Eclipse-based EATS development in place of my previous proprietary framework.
2. Enable a rudimentary capability to persist EATS information models from the Eclipse-based facility.
3. Develop a capability to express and interact with EATS information model content in the form of Ecore components.

The first two of these three goals will provide an Eclipse version of the most rudimentary core portion of my existing proprietary solution. Ideally, getting this functional will also require the resolution of how to adapt my own logical architecture for the system with the requirements of the technical architecture of the Eclipse platform. The last element, the Ecore component, will provide the foundation for integration with other elements of the Eclipse Modeling Project.