Group items tagged

" Jump to: navigation, search Welcome to our Wiki. This is the Wiki home page for the Buckminster Component Assembly project, an Eclipse Tools sub project. Buckminster is a component resolution & materialization framework. Its purpose is to get software components for you and materialize them in a context of choice, typically a workspace or file system. This applies whether you are looking at what's available on your local machine, within your development organization or in the public open source cloud. Buckminster reuses existing investments in a wide range of build and source management tools - Maven, ANT, CVS, SVN, PDE, etc. It removes ambiguity from component descriptions, enables component sharing and increases productiveness when applied in development, build, assembly and deploy scenarios. "

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.

As Eclipse plug-in and Rich Client Platform developers, we face unique challenges in how we structure and execute our unit tests. In this article, I suggest an approach to unit testing based on Eclipse fragments that can help us overcome these challenges. If you find yourself frustrated with your current plug-in testing options, read on! But before going into detail on a fragment based solution, let's examine the current approaches and the pros and cons associated with each. The first approach is the one most of us start with as we learn the ropes of plug-in development: placing all code in a single plug-in.

Bndtools is an Eclipse-based development environment for OSGi bundles and applications that focuses on: Ease of use and a rapid development lifecycle; Encouraging OSGi best practices; Producing accurate bundle metadata to maximise re-usability; Integration with offline build tools and users of other IDEs. See Features for a summary of Bndtools features. Bndtools is based on Bnd, the powerful bundle tool created by Peter Kriens. Please read Why Bndtools? to learn why Bndtools has been created and why you should use it for OSGi development in Eclipse.

The packaging type eclipse-repository was originally introduced for building products that can be updated with p2 (cf. TYCHO-188). This requires the following build results: a p2 repository which contains the product IU, and a zip file with the installed product. (Although this is technically no longer needed since the Update Manager was replaced by p2, zip files are still the primary way to distribute Eclipse/RCP installations.) For ease of implementation, this was done in the same packaging type eclipse-repository. In the meantime, eclipse-repository has gained in capabilities (in particular through TYCHO-491), making it difficult for users to choose the right packaging types. This page lays out the mid-term plan of how we want to build products, update site categories, and p2 repositories in Tycho. It also contains a few details how the transition todays (0.11.0) packaging types (eclipse-repository, eclipse-application, eclipse-update-site) to the new types eclipse-repository and eclipse-product.