Babylone, enabling Eclipse with framework assistance tooling Mireille Blay-Fornarino and Estelle Ringenbach University of Nice / I3S Laboratory 930, route des Colles 06903 Sophia-Antipolis, France {blay|ringenba}@essi.fr Abstract In order to facilitate framework usage, and capture framework dependencies in Eclipse, we present the Active HotSpot Model and its implementation Babylone. 1 Introduction Although Eclipse raised the standard of program- mer assistance in providing concepts such as quick- fixes, refactorings or code templates, it falls short of help in the usage of framework. This article presents Babylone an eclipse implementation of the Active HotSpot Model(AHSM). After an introduc- tion of the problematic, we describe the model and its integration in eclipse, before giving perspectives on this work. 2 Background, problematic In a few years, frameworks became the corner- stones of application developments covering do- mains as various as enterprise management, soft- ware components or IDE. Fitted with well-known hot spots, framework ready-to-use structure en- ables the creation of bigger and bigger applications in less and less time, since the applications devel- opers using frameworks only have to focus on their business code. Although hot spots clearly identify the feature they will enable, fulfilling one of these is not always easy, since it is often required to under- stand the inner behavior of the framework to fully take advantage of it. This would not happen if some documentation and information available at design- time were made available at reuse-time. Figure 1: EJB framework and a customization In order to facilitate framework usage and avoid the loss of design-time information, a twofold model named Active HotSpot Model has been de- veloped [5, 6]. This language independent model focus on the expression of structural and behavioral dependencies from design- to reuse- time and so promote the documentation to be a major actor of the user assistance. In this article we only focus on the structural aspect and the underlying problems. Structural dependencies capture framework us- age constraints that must be respected when a customization is done by the framework user. For a given framework, those constraints are the expressions of design choices made by the framework developer. On a pragmatic point of view, structural dependencies are relations bind- ing two or more heterogeneous elements of a framework (class, method, file, etc.) in the way that if an action is done on one element (cre- ation/deletion/modification) an action should be done on the others. In order to show an example of what struc- tural dependencies are, we use the EJB frame- work (which allows to build distributed Java com- ponents, see figure 1) to create an EJB compo- 1