1. Page 1 © April 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG© März 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG To Boldly Go...... Where No IDE Has Gone Before Component-Based Development with Eclipse – A Tangible Vision Thorsten Fink, Ph.D. Wolfgang Metzner GmbH & Co KG

2. Page 2 © April 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG Starting with a quote The plug-in extension model of Eclipse provides a powerful and general paradigm for architecting extensible systems based on loosely-coupled components. [Bolour]

3. Page 3 © April 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG Background We agree with the quote, but at the same time believe that the Plugin Development Environment has much more to offer than a paradigm. Because: PDE is the only IDE known to us which offers real support for component-based development. The developers of Eclipse had to overcome many obstacles, in order to produce a component-based software. So they created their own development environment (PDE). Developers of Java applications face similar problems when trying to develop component-based applications. Todays reality is that component-based development is frequently given up in favor of monolithic development. One of the reasons being that todays IDEs do not offer sufficient support in that direction. This is where our vision starts!!

4. Page 4 © April 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG The Vision Our vision is an extension of the Eclipse Java Development Environment (JDT) offering the following functionality Component dependencies by id and version Manifest Files for components, modules, applications --and editors for these JDT offers infrastructure classes that can used in the application (supporting component extensions) Direct support of components, modules (couple of components) and applications (couple of modules) Build takes component dependencies into account, validates, that all necessary component configurations are in place, automatically creates a property file (left-hand side only) with all parameters needed by the components Components communicate the way in which they can be parametrized, configured and extended in their manifest files

5. Page 5 © April 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG Component Hierarchy: An Example ain ain-clientain-persistence dbo.coredbo.ain util client.coreclient.ain Component Module Application enthält hängt ab An application consists of modules which in turn consist of components. Only components can be extended and configured (by other components). In our example dbo.ain configures the component dbo.core.

6. Page 6 © April 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG Manifest Files (in a Nutshell) Each component has a manifest file with the name component.xml A component is what today is an Eclipse Project. The manifest file component.xml contains the following information. main information: id, name, version dependencies on other components runtime information: name of the component jar (and possibly other jars) parameter information: which parameters are necessary to parametrize this component (e.g. database url)? configuration information: how can this component be configured by one and only one other component? An example would be metadata in an xml instance document. listener-point: which listener can be registered with this component? listener registration: welche Listener are registered with another component? Possibly other extensions and uses thereof

7. Page 7 © April 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG Component Manifest: Example

8. Page 8 © April 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG <configuration-point name="attribute-names" fileName="attribute-names.xml" schema="attribute-names.xsd" description="Meta data of persistent attributes" /> <configuration-point name="record-names" fileName="record-names.xml" schema="record-names.xsd" description=" Meta data of persistent records" /> Component Manifest: Example (ctd)

9. Page 9 © April 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG component.xml: the elements Main information component-id : unique id of the component component-name : name of the component component-version : version of the component requires : dependencies on other components (referring to id and version) runtime : name of the build jar (and possibly other jars) param-point : name of parameters needed by this component. Using these parameter names a property file for the application will be created (or validated) configuration-point : name of a file used in the configuration of this component. The component itself does not contain the file. In the context of an application or a module there is exactly on other component configuring this component (see: next element configuration ) configuration : location of the configuration file used in the configuration of another component.

10. Page 10 © April 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG component.xml: the elements (ctd) startup : classes which are instantiated at the time of application startup. After instantiation their method initalize(Properties properties) will be called. listener-point : this is where other components can register their listeners. listener : here a component declares that it registers a listener at anothers component listener-point. There might very well be other extension elements. We would prefer to concretely model these elements (as weve done in the case of listener-point and listener). This way important features of the communication between components do not get lost in general extension- point, extension pairs. We believe that in the case of applications a restriction to a few selected forms of communication should be possible.

11. Page 11 © April 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG Build: An Overview The manifest files of the components, modules and applications are used in the build process – internally by Eclipse as well as externally by Ant. Well only consider the Eclipe build process (but see: Appendix). Dependency analysis and use In the case of inconsistences, problems (tasks) are created. Examples for inconsistencies are a component of the referenced version is not available. references to different versions of the same component exist within a module or an application. a configurable component is not (or more than once) configured within the context of a module or an application. All components are build as specified in the manifest files. The parameters (in param ) are written to a property file. The startup information (in startup ) is collected in a startup.xml. The file is used during application startup.

12. Page 12 © April 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG Build: An Overview (ctd) Additional information is collected for use by the infrastructure classes The exact process and the functionality of the infrastructure classes is to be determined. The infrastructure classes are used by Eclipse and by the Java application.

13. Page 13 © April 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG Build: Component Parametrization The param elements of all components of a given application are collected during the build process. A property file will be created or a given one will be validated (completeness) on their basis. component.xml Application.properties – left-hand sides are created ## Parameters of component: dbo database.url= database.user= database.password=

14. Page 14 © April 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG Build: Component Configuration A component may specify that it can (and should) be configured by an XML instance document. <configuration-point name="attribute-names" fileName="attribute-names.xml" schema="attribute-names.xsd" description="Meta data of persistent attributes" /> In the context of a module or an application, one and only one other component configures the above component. The component doing the configuration contains the required XML instance document. <configuration point="de.vfst.persistence.attribute-names" path="de/vfst/persistence/metadata/ain" />

15. Page 15 © April 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG Modules Modules consist of (configured) components. Modules cannot be configured. They are described by manifest files with the name module.xml.

16. Page 16 © April 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG Applications Applications consist of modules and possibly (configured) components. Applications cannot be configured. They are described by manifest files with the name application.xml.

17. Page 17 © April 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG Outlook There are many obstacles to overcome and gaps to fill in on the way to a complete support of component-based development. We believe that the route outlined in this document is promising and can be taken. Selected functionality could possibly be migrated from PDE to JDT or quickly implemented by Monkey See, Monkey Do. Pleasant side effects should not go unmentioned Reverse Engineering of Component Diagrams on the basis of manifest files, and other yet undiscovered possibilities. Architects can be sure that their architecture is reality. Developers, designers can base their discussions also on the content of manifest files. A heigthened appeal to create product-independent or platform- independent components (which will have a higher degree of re-usability).

18. Page 18 © April 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG Literature [Bolour] Azad Bolour, Notes on the Eclipse Plug-in Architecture, in: Eclipse Corner Article, http://www.eclipse.org/articles/index.html, Juli 2003http://www.eclipse.org/articles/index.html [Gamma, Beck] Erich Gamma, Kent Beck, Contributing to Eclipse, Addison-Wesley, 2004

19. Page 19 © April 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG Appendix: Build Management The vision for the build management is as follows In order to build an application you only need access to the configuration management system (CMS), as well as a manifest file application.xml The build process pulls the needed components in their correct version from the CMS, validates the component dependencies and starts the application build during which property and startup files are created components are configured Infrastructure classes (for e.g. listener registration) are build