I had promised an explanation of how we mapped ENVY concepts into Eclipse. Its probably a good idea to review how ENVY organized code. ENVY did this by provided first-class code organization structures:
- Classes were contained in Applications. Classes, in the normal OO style, owned the methods which were the basic level of version control.
- Applications, along with SubApplications, provided a tree-like structure, usually used to cover over platform dependencies. Applications also were able to express dependencies on other applications, providing scoping hints on which classes and methods should be available. Lifecycle events, such as image startup and application load, were sent to applications to allow them to set up and clean up state.
- Class extensions allowed adding methods to classes from other Applications
- Configuration Maps provided a grouping of Applications into logical sets. It was also possible for one config map to express dependencies on other config maps, providing a defined load order. This didn't prevent multiple config maps from including the same application, and this frequently occurred. Config Maps also provided configuration expressions which were evaluated prior to loading to ensure things like the to ensure that loading the config map was possible.
To get to our new world, we had to port these concepts into the Eclipse Resource model. Eclipse basically allows things to be organized into Projects containing directory trees of files. We opted to use a straight forward mapping: Configuration Maps become Projects, Applications become a Directory plus a file of the same name, SubApplications are identical to Applications except they must be stored in Application, and both classes and extensions became files.
There were a couple of things we had to give up to live in an Eclipse world:
- Applications can only belong to one Project (Config Map)
- Configuration expressions are now stored in separate files, called .smalltalk files.
- Version control happens on a per-file basis, not a per-method basis.
- Nothing is automatically stored in the repository any more.
Just because that's how we laid things out in the Eclipse Workspace, doesn't mean we wanted to live with just Eclipse's Project Explorer-style views. We wanted our browsers back! At this point, I need to say a big thanks to the guys at Instantiations for providing us with a couple of free copies of WindowBuilder to use on this project. Their tools have made our lives a lot easier, especially when we've been prototyping new UI designs. Meeting with John O'Keefe and Eric Clayberg at Smalltalk Solutions and not only seeing their enthusiasm for STDT, but also seeing the great things they are doing with VA Smalltalk, the successor to IBM's VisualAge Smalltalk, was an awesome experience.
So two Smalltalk perspectives were born:
the Smalltalk Applications perspective,
and the Smalltalk Classes Perspective.