Group items tagged

Aspect-oriented computing is continuing to increase in popularity. The modularity inherent in OSGi and Eclipse offers unique opportunities for managing and applying aspects by supplying them in bundles and directing their application to particular sets of bundles. This incubator work area is dedicated to delivering an integration of aspects and OSGi. The goal is to allow developers to use the Equinox together with AspectJ by combining the benefits of both worlds. Using a load-time weaving extension you are able to add AspectJ aspects to your bundle-based system just by putting them into general OSGi bundles. It does not matter if the pointcuts you defined inside the aspects contain join points that are defined by classes within the same bundle or any other bundle in your installation. The load-time weaving extension will take care that your aspects are woven with the appropriate classes at load-time. To illustrate this lets assume the following situation: You would like to write an aspect that traces something within the JDT plug-ins of Eclipse. Without some kind of load-time aspect weaving you would somehow need to recompile those JDT plug-ins using AJDT (for example) together with your aspect. By using the load-time aspect weaving extension all you need is to implement your aspect and add that bundle to your system. The load-time aspect weaving extension takes care of weaving your aspect with the JDT code as it is loaded. And it doesn't matter if a new JDT is installed by the user later on. The next time your application is started the load-time aspect weaving will take care of weaving your aspect into these bundles as well, if necessary. With this technology is becomes possible to modularize crosscutting concerns across different plug-ins while keeping the idea of separate compilation for bundles. Goals Provide Runtime Modularity and Versioning for Crosscutting Concerns: Aspects are used to implement crosscutting concerns. However such concerns usually compr

The JDT project provides the tool plug-ins that implement a Java IDE supporting the development of any Java application, including Eclipse plug-ins. It adds a Java project nature and Java perspective to the Eclipse Workbench as well as a number of views, editors, wizards, builders, and code merging and refactoring tools. The JDT project allows Eclipse to be a development environment for itself.

The goal of the Eclipse Scout project is making it easy to build distributed enterprise applications based on the Eclipse platform. It consists of a runtime framework providing transparent service communication between the client and backend part and is shipped with a rich set of common user interface components. The user interface is not built for a particular rendering technology but it encapsulates the core functionality into a headless model. GUI factories are available for rendering the client model into a particular target UI platform. SWT and Swing are supported out of the box and an AJAX GUI factory could be easily added. Developing Scout applications is supported by the Scout SDK, a plug-in set built on top of Eclipse PDE and Eclipse JDT. The Scout SDK works directly on the bare Java resources and assists the development task by providing an augmented view on the underlying Java code. Additionally, it comes with a rich set of wizards and operations for modifying the Scout application project just by editing the underlying Java code. There is no meta-data required. Hence a developer can switch between editing resources using Eclipse's standard editors and leveraging the features of Scout SDK at any point in time. Eclipse Scout can be used to create multi-tier client/server applications, standalone client applications or OSGi-based server applications. Basically, there are three main advantages when choosing Scout as your framework for building such applications. First, the Scout runtime is service oriented by design. Almost every functionality is provided as an OSGi service. Every OSGi bundle may make use of them. Second, Scout provides a rich set of UI elements being uncoupled from a particular GUI technology. And third, building distributed client/server applications is as easy as if both parts would run within the same local JVM.