*** empty log message ***
diff --git a/Article-Eclipse-and-Maven2/article.xml b/Article-Eclipse-and-Maven2/article.xml
index 9234c33..1bb54f8 100644
--- a/Article-Eclipse-and-Maven2/article.xml
+++ b/Article-Eclipse-and-Maven2/article.xml
@@ -1,14 +1,14 @@
<?xml version="1.0" encoding="utf-8"?>
<!--
- $Id: article.xml,v 1.3 2007/02/08 19:46:57 wbeaton Exp $
+ $Id: article.xml,v 1.4 2007/02/08 19:50:16 wbeaton Exp $
Copyright (c) 2006, Princeton Softech Inc. All rights reserved.
PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.
-->
-<!--
+
<!DOCTYPE article
PUBLIC "-//OASIS//DTD DocBook V4.1//EN"
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
- -->
+
<article>
<articleinfo>
<title>Building Eclipse Plugins with Maven 2</title>
@@ -59,7 +59,6 @@
<section label="0.0">
<title>Environment</title>
<note>
- <title>Setup</title>
<para>The information provided in this article pertains to the following:</para>
<itemizedlist>
<listitem>
@@ -81,7 +80,6 @@
</itemizedlist>
</note>
<note>
- <title>Upgrade</title>
<para>Since we began writing this article, we have actually successfully upgraded Callisto from SDK 3.2.0 to SDK 3.2.1 along
with most of the rest of the Callisto projects.</para>
</note>
diff --git a/Article-Eclipse-and-Maven2/index.html b/Article-Eclipse-and-Maven2/index.html
index 02ee1f8..d743d62 100644
--- a/Article-Eclipse-and-Maven2/index.html
+++ b/Article-Eclipse-and-Maven2/index.html
@@ -11,7 +11,7 @@
Copyright ©
2006
- Princeton Softech, Inc.</div><div class="date"><span class="date">February 13, 2006<br></span></div></div><div class="content"><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N1003F"></a>Environment</h2></div></div></div><div class="note" style="margin-left: 0.38in; margin-right: 0.38in;"><table class="note-table"><tr><td><img alt="[Note]" src="images/note.gif"></td><td><p>The information provided in this article pertains to the following:</p><div class="itemizedlist"><ul type="disc"><li>
+ Princeton Softech, Inc.</div><div class="date"><span class="date">February 13, 2006<br></span></div></div><div class="content"><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N10040"></a>Environment</h2></div></div></div><div class="note" style="margin-left: 0.38in; margin-right: 0.38in;"><table class="note-table"><tr><td><img alt="[Note]" src="images/note.gif"></td><td><p>The information provided in this article pertains to the following:</p><div class="itemizedlist"><ul type="disc"><li>
<a href="http://download.eclipse.org/eclipse/downloads/drops/R-3.2-200606291905/index.php" target="_new">Eclipse 3.2.0
(Callisto)</a>
</li><li>
@@ -19,8 +19,8 @@
</li><li>
<a href="http://maven.apache.org/continuum/download.html" target="_new">Continuum 1.0.3</a>
</li></ul></div></td></tr></table></div><div class="note" style="margin-left: 0.38in; margin-right: 0.38in;"><table class="note-table"><tr><td><img alt="[Note]" src="images/note.gif"></td><td><p>Since we began writing this article, we have actually successfully upgraded Callisto from SDK 3.2.0 to SDK 3.2.1 along
- with most of the rest of the Callisto projects.</p></td></tr></table></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N10063"></a>Introduction</h2></div></div></div><p>Before delving into the nitty-gritty details, let's start with a little bit of background on Eclipse and Maven 2 and also
- cover the goals and requirements for the build system we put together.</p><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N10069"></a>Eclipse</h3></div></div></div><p>If you've already worked with Eclipse on a daily basis, you can probably skip this section. If not, a little background
+ with most of the rest of the Callisto projects.</p></td></tr></table></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N10060"></a>Introduction</h2></div></div></div><p>Before delving into the nitty-gritty details, let's start with a little bit of background on Eclipse and Maven 2 and also
+ cover the goals and requirements for the build system we put together.</p><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N10066"></a>Eclipse</h3></div></div></div><p>If you've already worked with Eclipse on a daily basis, you can probably skip this section. If not, a little background
about how Eclipse likes (or wants) to do things might be helpful.</p><p>Like most other IDEs, Eclipse organizes your work into projects. A project is essentially a directory, in which your
packages, source files and other resources (like XML files, icons, images and resource bundles) are created and modified.
What sets Eclipse apart from most other IDEs is its notion of a workspace. Eclipse cannot function without one and
@@ -31,13 +31,13 @@
thumb, an Eclipse workspace cannot have Java projects that exist in a hierarchy, so people have gotten used to simply
organizing their projects as a flat list of top-level directories and then manage their inter-dependencies through Eclipse's
built-in facility for project dependencies and build path management. For most tools and add-ons, this constraint is not
- necessarily a problem, and e.g. Ant is often used in conjunction with Eclipse to do automated builds and testing.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N1007B"></a>Maven 2</h3></div></div></div><p>Maven 2 is an elegant project build/management framework that follows the mantra of "Convention over Configuration" made
+ necessarily a problem, and e.g. Ant is often used in conjunction with Eclipse to do automated builds and testing.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N10078"></a>Maven 2</h3></div></div></div><p>Maven 2 is an elegant project build/management framework that follows the mantra of "Convention over Configuration" made
popular by the "Ruby on Rails" community. The premise is that by following the conventions laid out by Maven 2, a developer
can very quickly put together a project that can be compiled, tested and packaged in a meaningful way and even get code
coverage to boot! </p><p>Maven 2 can be used to build pretty much anything. It does this by stepping through a series of
<span class="emphasis"><em>phases</em></span> in an attempt to reach the <span class="emphasis"><em>goal</em></span> of the build. All these phases put together
are called a <span class="emphasis"><em>lifecycle</em></span>. The phases that come into play for a given lifecycle depend on the kind of
- library or executable you are building. The default lifecycle for building Java "jar" libraries is as follows: <div class="figure"><a name="N1008C"></a><p class="title"><b>Figure 1. Maven 2 default lifecycle</b></p><div class="figure-contents"><div class="mediaobject"><img src="images/lifecycle.png" alt="Maven 2 default lifecycle"></div></div></div><br class="figure-break"> You can find a reference to all the build phases here <a href="http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html" target="_new">Introduction to the
+ library or executable you are building. The default lifecycle for building Java "jar" libraries is as follows: <div class="figure"><a name="N10089"></a><p class="title"><b>Figure 1. Maven 2 default lifecycle</b></p><div class="figure-contents"><div class="mediaobject"><img src="images/lifecycle.png" alt="Maven 2 default lifecycle"></div></div></div><br class="figure-break"> You can find a reference to all the build phases here <a href="http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html" target="_new">Introduction to the
Lifecycle</a>. As you will see later on we tie into some of these build phases to facilitate the building and testing of
Eclipse plugins. </p><p>Following of the conventions in Maven 2 mostly boils down to abiding by the directory structure that Maven 2 predefines.
In other words, any code in the predefined source directory will be compiled and packaged, and any test code in the
@@ -45,7 +45,7 @@
root of your project . We often say in-house, "if it ain't in the POM, it doesn't exist". POMs, and therefore projects, can
be arranged in hierarchies. A POM will inherit properties that it does not define itself from its parent. This inheritance
feature can obviously be powerful when attempting to manage projects and can reduce duplicated effort, but may irk some of
- our well loved IDEs.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N100A0"></a>Goals and Requirements</h3></div></div></div><p>When choosing the tools to use in a development and build environment, it's important to understand what the goals are.
+ our well loved IDEs.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N1009E"></a>Goals and Requirements</h3></div></div></div><p>When choosing the tools to use in a development and build environment, it's important to understand what the goals are.
For example, in some development organizations the primary concern is developer productivity while "ancillary" disciplines
like change and configuration management; build; integration and testing take a back seat to that. In other organizations,
it's the other way around and developers may well suffer from having to work with a difficult or arcane build environment.</p><p>Today, many development organizations have managed to come up with a reasonable "middle of the road" tooling and
@@ -59,12 +59,12 @@
requirements and caveats.</p><p>Our first conclusion was that relying on Ant to get all this done would be a huge effort - especially in the area of
dependency management and transparency.</p><p>Our second conclusion was that it would be imperative to not cripple or impede the tools we picked. For example, we wanted
to leverage all of Eclipse's Plugin Development Environment (PDE) to ensure developer productivity, but we also wanted to
- use Maven 2 the way it was meant to be used.</p><p>The result is an environment that allowed for very little compromise on neither Eclipse's nor Maven 2's part.</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N100C7"></a>Using Eclipse and Maven 2 with Standard Packaging</h2></div></div></div><p>Before getting knee-deep in the intricacies of building Eclipse plugins with Maven 2, we want to cover the details of how to
+ use Maven 2 the way it was meant to be used.</p><p>The result is an environment that allowed for very little compromise on neither Eclipse's nor Maven 2's part.</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N100C5"></a>Using Eclipse and Maven 2 with Standard Packaging</h2></div></div></div><p>Before getting knee-deep in the intricacies of building Eclipse plugins with Maven 2, we want to cover the details of how to
use Eclipse and Maven 2 together in general. So, if you build plain old jars and/or J2EE deployable artifacts, like ears and
wars, this section covers most of what you need.</p><p>The primary thing that kept us sane (or at least on track), while getting the build environment together, was keeping in mind
that from the point of view of Maven 2, there is no Eclipse. Like the kid in The Matrix, telling Neo that "there is no spoon",
we repeatedly had to remind each other that "there is no Eclipse."</p><p>For most things, this is actually not that big of an issue, but as you'll see below, it's not quite that straightforward for
- Eclipse plugins.</p><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N100D1"></a>Location of Source Code</h3></div></div></div><p>The first, and perhaps most crucial, thing to get in place (and get used to) is the location of the source code. As
+ Eclipse plugins.</p><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N100CF"></a>Location of Source Code</h3></div></div></div><p>The first, and perhaps most crucial, thing to get in place (and get used to) is the location of the source code. As
mentioned above, most Eclipse developers are probably used to simply stashing away all their source in a flat workspace, but
Maven 2 ultimately doesn't like that. More accurately: Maven 2 <span class="emphasis"><em>can</em></span> handle a flat layout, but a lot of
Maven 2 plugins and ancillary tools assume that the source is hierarchical (and since Maven 2 inherently understands that,
@@ -74,7 +74,7 @@
workspace.</p><p>The net result of this is that we, by convention, keep all our source code in a directory called <code class="code">projects</code> and
only use the Eclipse workspace for the metadata. On Windows we keep the <code class="code">projects</code> directory in the root of
either the <code class="code">C:\</code> or <code class="code">D:\</code> drive (for command-line convenience) and on other OS's we keep it in the
- user's home directory. We keep the Eclipse workspace in the default location (usually the user's home directory).</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N100E8"></a>Source Code Layout</h3></div></div></div><p>The second thing to get used to is having your projects organized in a hierarchy. As mentioned above, a hierarchical
+ user's home directory. We keep the Eclipse workspace in the default location (usually the user's home directory).</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N100E6"></a>Source Code Layout</h3></div></div></div><p>The second thing to get used to is having your projects organized in a hierarchy. As mentioned above, a hierarchical
project structure is the Maven 2 convention and when adhering to that, Maven 2 can provide you with more help.</p><p>By convention, a project created underneath another project becomes a child of that. In Maven 2 terminology the child
project becomes a <code class="code">module</code> in the parent project. This is crucial for cutting down on configuration (remember:
Maven 2 is all about "Convention over Configuration") and we leverage this capability to both organize and configure our
@@ -85,7 +85,7 @@
further down the hierarchy. For example, all the repository and plugin configuration that is common to all the projects sits
in the "super POM" and configuration specific to all the Eclipse plugins sits in the Eclipse plugin parent POM. This way,
comparatively little configuration is needed in each of the projects that most developers are working on. Specifically, our
- plugin project POMs only contain the group ID, artifact ID and version of the parent and the plugin itself.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N100F8"></a>Source Code Management (SCM)</h3></div></div></div><p>Source code management is largely "business as usual", but a few things must be kept in mind. We happen to use CVS, but
+ plugin project POMs only contain the group ID, artifact ID and version of the parent and the plugin itself.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N100F6"></a>Source Code Management (SCM)</h3></div></div></div><p>Source code management is largely "business as usual", but a few things must be kept in mind. We happen to use CVS, but
other supported SCM systems, like e.g. Subversion, should be usable with the same results and caveats described below.</p><p>As mentioned above, we decided to go the hierarchical route. One major contributor to that decision happens to be
Continuum, which has some hard and fast assumptions about how things are organized. While trying to use Maven 2 with a flat
layout, we found out the hard way that Continuum (at the time of writing, we're using version 1.0.3) does not grok the flat
@@ -102,7 +102,7 @@
under its parent. This leads to mixed messages about whether or not a project's code and resources are up to date or not;
and when adding a new child project to CVS, we often end up seeing the newly created <code class="code">CVS</code> directories as new
Java packages. More often than not, a quick refresh in the right spot will fix everything, but sometimes we need to close
- and reopen a project to get rid of the normally hidden <code class="code">CVS</code> directories.</p><div class="note" style="margin-left: 0.38in; margin-right: 0.38in;"><table class="note-table"><tr><td><img alt="[Tip]" src="images/tip.gif"></td><td><p>Getting used to hitting <code class="code">F5</code> in the topmost parent project, helps keep things synchronized.</p></td></tr></table></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N10113"></a>The Maven 2 Plugin for Eclipse</h3></div></div></div><p>As we point out throughout this document, Maven 2, like Eclipse, is a framework that relies on plugins to do the actual
+ and reopen a project to get rid of the normally hidden <code class="code">CVS</code> directories.</p><div class="note" style="margin-left: 0.38in; margin-right: 0.38in;"><table class="note-table"><tr><td><img alt="[Tip]" src="images/tip.gif"></td><td><p>Getting used to hitting <code class="code">F5</code> in the topmost parent project, helps keep things synchronized.</p></td></tr></table></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N10111"></a>The Maven 2 Plugin for Eclipse</h3></div></div></div><p>As we point out throughout this document, Maven 2, like Eclipse, is a framework that relies on plugins to do the actual
work. In the case of Maven 2, plugins are responsible for things like compilation, testing, code instrumentation (e.g. for
code coverage), reporting and packaging. Not surprisingly, Maven 2 plugins can be built in a number of different ways (even
using different languages) and also not surprisingly, you can use Maven 2 to build and package Maven 2 plugins. Maven 2
@@ -117,20 +117,20 @@
project's POM file and conveniently generates appropriate <code class="code">.project</code> and <code class="code">.classpath</code> files as well as
the rest of the necessary Eclipse artifacts. As mentioned above we keep all our code in a <code class="code">projects</code> directory,
so at this point a developer would use Eclipse's <code class="code">Import -> Existing projects into Workspace</code> option to get the
- project into Eclipse.</p><p>This whole process allows us to maintain a single source of truth for all project information, the POM.</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N10139"></a>What Makes Eclipse Plugins a Special Case?</h2></div></div></div><p>Now that we've covered Eclipse and Maven 2 in general, we can move on to dealing with the Eclipse plugins. What makes Eclipse
+ project into Eclipse.</p><p>This whole process allows us to maintain a single source of truth for all project information, the POM.</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N10137"></a>What Makes Eclipse Plugins a Special Case?</h2></div></div></div><p>Now that we've covered Eclipse and Maven 2 in general, we can move on to dealing with the Eclipse plugins. What makes Eclipse
plugins so different that they need special attention in the first place? Well, it depends on what you're trying to accomplish.
If your only goal is to build plugins using Maven 2, you could almost use Maven 2 out-of-the-box, but if you also want to be
able to use PDE for launch and debug and have the ability to do automated tests, code coverage, etc., then you need to handle a
few things in a way that Maven 2 doesn't support without some tweaking.</p><div class="note" style="margin-left: 0.38in; margin-right: 0.38in;"><table class="note-table"><tr><td><img alt="[Note]" src="images/note.gif"></td><td><p> When we talk about Maven 2, we're actually talking about the available Maven 2 plugins rather than Maven 2 proper. Like
Eclipse/RCP, Maven 2 is a framework in which numerous capabilities have been implemented. As you'll see in the following
- sections, we've solved the plugin special case handling by creating a Maven 2 plugin that does what we need.</p></td></tr></table></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N10142"></a>Packaging</h3></div></div></div><p>At face value, an Eclipse plugin is nothing special: it's a jar or directory containing the usual suspects:<div class="itemizedlist"><ul type="disc"><li>Compiled classes</li><li>The manifest</li><li>I18N/L10N resources</li><li>Images and icons</li></ul></div>and of course the plugin specifics:<div class="itemizedlist"><ul type="disc"><li>plugin.xml</li><li>plugin.properties</li></ul></div>possibly along with:<div class="itemizedlist"><ul type="disc"><li>Other jars</li></ul></div></p><div class="note" style="margin-left: 0.38in; margin-right: 0.38in;"><table class="note-table"><tr><td><img alt="[Note]" src="images/note.gif"></td><td><p>With Eclipse now being OSGi based, the manifest technically is also a plugin-specific resource. The manifest now
+ sections, we've solved the plugin special case handling by creating a Maven 2 plugin that does what we need.</p></td></tr></table></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N10140"></a>Packaging</h3></div></div></div><p>At face value, an Eclipse plugin is nothing special: it's a jar or directory containing the usual suspects:<div class="itemizedlist"><ul type="disc"><li>Compiled classes</li><li>The manifest</li><li>I18N/L10N resources</li><li>Images and icons</li></ul></div>and of course the plugin specifics:<div class="itemizedlist"><ul type="disc"><li>plugin.xml</li><li>plugin.properties</li></ul></div>possibly along with:<div class="itemizedlist"><ul type="disc"><li>Other jars</li></ul></div></p><div class="note" style="margin-left: 0.38in; margin-right: 0.38in;"><table class="note-table"><tr><td><img alt="[Note]" src="images/note.gif"></td><td><p>With Eclipse now being OSGi based, the manifest technically is also a plugin-specific resource. The manifest now
declares things like name, ID and version of the plugin (or <span class="emphasis"><em>bundle</em></span> in OSGi speak) as well as the
dependencies; all these details used to be expressed in the <code class="code">plugin.xml</code> file.</p></td></tr></table></div><p>In the case where a plugin contains other jars it is deployed as a directory-based plugin, whereas a plugin that does not
have jars and also doesn't need a directory-based home, can (and should) be packaged as a single jar.</p><p>In the latter case, this maps well to the default Maven 2 packaging type of <code class="code">jar</code>, but Maven 2 really doesn't
have the notion of a <code class="code">directory</code> packaging, so it is necessary to use the <code class="code">pom</code> type. The reason for
this is that when a plugin exposes packages that live in one or more jars, Maven 2 needs to know about those jars, so that
it can satisfy dependencies. Without this, other plugins that depend upon classes in such a jar could never be
- compiled.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N10178"></a>Layout</h3></div></div></div><p>One of the really nice features of PDE is its ability to do self-hosting of plugins under development. Essentially, PDE
+ compiled.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N10176"></a>Layout</h3></div></div></div><p>One of the really nice features of PDE is its ability to do self-hosting of plugins under development. Essentially, PDE
can launch a second instance of your development environment that also contains the plugin(s) under development. This
behavior makes debug and testing very easy, but requires that the plugin projects are laid out exactly the way the plugin
will be packaged when released.</p><div class="note" style="margin-left: 0.38in; margin-right: 0.38in;"><table class="note-table"><tr><td><img alt="[Tip]" src="images/tip.gif"></td><td><p>The default behavior of PDE is to launch the second instance of Eclipse with all the plugins of the development
@@ -138,10 +138,10 @@
launch configuration editor's "Plug-ins" tab.</p></td></tr></table></div><p>The challenge here is that Maven 2, by default, expects everything to be neatly tucked away under the
<code class="code">src/main/resources</code> directory. If we stuck all the plugin's icons and images along with the
<code class="code">plugin.xml</code> and <code class="code">plugin.properties</code> files in that directory, Maven 2 would correctly package the
- plugin for release but PDE wouldn't be able to launch it correctly, making debugging the plugin virtually impossible.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N1018C"></a>Dependency Management</h3></div></div></div><p>Maven 2 must have all the dependencies spelled out in the POM for it to resolve and manage them. In contrast, Eclipse
+ plugin for release but PDE wouldn't be able to launch it correctly, making debugging the plugin virtually impossible.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N1018A"></a>Dependency Management</h3></div></div></div><p>Maven 2 must have all the dependencies spelled out in the POM for it to resolve and manage them. In contrast, Eclipse
plugins must have dependencies clearly defined in their manifest file. This is a major point of conflict, but while Maven 2
can be taught otherwise, Eclipse will not budge on this issue. All dependencies <span class="emphasis"><em>must</em></span> exist in the
- manifest and they are resolved from there during development as well as in the runtime.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N10195"></a>Testing</h3></div></div></div><p>Perhaps the biggest difference between plain old jar projects and an Eclipse plugin project is that of unit testing.</p><p>The PDE folks have, of course, done an excellent job of making running, debugging and testing plugins easy. For the most
+ manifest and they are resolved from there during development as well as in the runtime.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N10193"></a>Testing</h3></div></div></div><p>Perhaps the biggest difference between plain old jar projects and an Eclipse plugin project is that of unit testing.</p><p>The PDE folks have, of course, done an excellent job of making running, debugging and testing plugins easy. For the most
part, there is really no difference between unit testing a set of "normal" classes and a set of plugin classes when working
in Eclipse.</p><p>The challenge, when using Maven 2 (or Ant or another "external to Eclipse" build infrastructure), is that unit testing has
to take place in the context of an Eclipse instance. All but the simplest plugin classes cannot execute correctly without
@@ -161,7 +161,7 @@
the Eclipse SDK proper.</p><p>A final, minor thing needs to be dealt with: Eclipse, of course, uses JNI to provide the underlying implementation for
SWT. When working in Eclipse, this is effectively not an issue because the PDE self hosting mechanism makes both the
cross-platform SWT API as well as the platform specific implementation available. In a multi-platform environment, the
- correct SWT plugin needs to be made available for the compile phase, before any testing can take place.</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N101B4"></a>The Solution</h2></div></div></div><p>Now that you understand the various problems we were facing you can hopefully appreciate that we didn't just run straight to
+ correct SWT plugin needs to be made available for the compile phase, before any testing can take place.</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N101B2"></a>The Solution</h2></div></div></div><p>Now that you understand the various problems we were facing you can hopefully appreciate that we didn't just run straight to
the keyboard to write some Mojo's just because we could (cough, cough).</p><p>Just to re-iterate, the solution keeps in mind two key requirements of our development process. The first being that when the
developer is writing, compiling and testing the code in Eclipse, he/she should not really have to care about Maven 2. The other
requirement being that the developer or machine building and testing the Eclipse plugins using Maven 2, should/will not have any
@@ -180,7 +180,7 @@
existing Mojos. These are all described in some detail in the following sub-sections. Most of the Mojo's we wrote help existing
Maven 2 plugins do their work in spite of putting information that they need in places that they do not inherently understand
(but Eclipse does). Some Mojos we wrote go the other way and help take information from a Maven 2 POM and generate appropriate
- files that allow Eclipse to obtain the same information.</p><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N101E0"></a>Maven 2 Plugin (Mojos)</h3></div></div></div><p>
+ files that allow Eclipse to obtain the same information.</p><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N101DE"></a>Maven 2 Plugin (Mojos)</h3></div></div></div><p>
<div class="itemizedlist"><ul type="disc"><li><p><b>Deploy Mojo. </b>(Issue: Maven 2 has to find Eclipse dependencies)</p><p>We set out to use Maven 2 the way it was meant to. Maven 2 does an excellent job of dependency management. All
it needs is a <code class="code">groupId</code>, <code class="code">artifactId</code> and a <code class="code">version</code> to locate any artifact in
a repository. We were at first diligent about trying to find all the Eclipse plugins that our plugins would
@@ -189,7 +189,7 @@
file that contains all the <code class="code">mvn deploy</code> commands needed to deploy all the jars.</p><p>For a jar based plugin, we simply deploy the jar, using the plugin's id and version as the Maven 2 artifact id
and version.</p><p>For a directory based plugin, we deploy a <code class="code">pom</code> for the entire plugin that contains the
dependencies on the jars it needs and/or provides. This way, when another plugin depends on it, the POM provides
- all the jars so that compilation will work.</p><div class="example"><a name="N10204"></a><p class="title"><b>Example 1. Eclipse Scrape and Deploy</b></p><div class="example-contents"><pre class="programlisting">
+ all the jars so that compilation will work.</p><div class="example"><a name="N10202"></a><p class="title"><b>Example 1. Eclipse Scrape and Deploy</b></p><div class="example-contents"><pre class="programlisting">
protected void doExecute()
throws MojoExecutionException, MojoFailureException {
if (!eclipseHome.isDirectory()) {
@@ -252,7 +252,7 @@
manifest file, Maven 2 can't resolve any of the dependencies for us. The solution here is to dynamically augment
the POM, during the build, with information from the Eclipse plugin's manifest. Thus we created this Mojo that
parses out the manifest file and <span class="emphasis"><em>modifies</em></span> the POM (in memory) with the dependencies in the
- appropriate build <span class="emphasis"><em>phase</em></span>.</p><div class="example"><a name="N10220"></a><p class="title"><b>Example 2. In-Memory POM Modification</b></p><div class="example-contents"><pre class="programlisting">
+ appropriate build <span class="emphasis"><em>phase</em></span>.</p><div class="example"><a name="N1021F"></a><p class="title"><b>Example 2. In-Memory POM Modification</b></p><div class="example-contents"><pre class="programlisting">
protected void doExecute()
throws MojoExecutionException, MojoFailureException {
if (logModifications) {
@@ -357,7 +357,7 @@
remotely.</li><li><p>We support the configuration of the plugin packaging in the POM, so before resolving a dependency
we check that configuration and if found - we're done. For this we employ the use of properties in
Maven 2. Using properties we map the <code class="code">artifactId</code> of an artifact to its packaging type.
- The listing below is a snippet from a pom.xml file. <div class="example"><a name="N1025B"></a><p class="title"><b>Example 3. Properties Map Artifact Packaging </b></p><div class="example-contents"><pre class="programlisting">
+ The listing below is a snippet from a pom.xml file. <div class="example"><a name="N1025C"></a><p class="title"><b>Example 3. Properties Map Artifact Packaging </b></p><div class="example-contents"><pre class="programlisting">
<properties>
<org.eclipse.core.runtime>
jar
@@ -407,7 +407,7 @@
extension mechanism for packaging types we couldn't define our <code class="code">binary-plugin</code> as a kind of
<code class="code">pom</code> packaging. Hence these Mojos that know how to treat our packagings.</p><p>This Mojo, while packaging, will also pick the manifest file from the <code class="code">META-INF</code> directory located
at the root of the plugin project. At the time of writing this article, the default jar packager in Maven 2
- would ignore this manifest file even if it was specified as a resource.</p><div class="example"><a name="N10279"></a><p class="title"><b>Example 4. Eclipse Plugin Packaging</b></p><div class="example-contents"><pre class="programlisting">
+ would ignore this manifest file even if it was specified as a resource.</p><div class="example"><a name="N1027B"></a><p class="title"><b>Example 4. Eclipse Plugin Packaging</b></p><div class="example-contents"><pre class="programlisting">
protected void doExecute()
throws MojoExecutionException, MojoFailureException {
String packaging = project.getPackaging();
@@ -438,7 +438,7 @@
will have a problem because it requires a valid manifest and all the jars to actually exist in the project.</p><p>The solution here is to get all the project information, stored in the POM, from Maven 2 and have the Mojo
create a valid Eclipse plugin manifest on the fly. Also, since it spells out the dependencies the Mojo can copy
all the jars from the Maven 2 repository into the right spot in the plugin project, enabling PDE to execute any
- other plugin that depends on <code class="code">binary-plugin</code> type plugin.</p><div class="example"><a name="N10291"></a><p class="title"><b>Example 5. Eclipse Plugin Manifest Generation</b></p><div class="example-contents"><pre class="programlisting">
+ other plugin that depends on <code class="code">binary-plugin</code> type plugin.</p><div class="example"><a name="N10294"></a><p class="title"><b>Example 5. Eclipse Plugin Manifest Generation</b></p><div class="example-contents"><pre class="programlisting">
protected void doExecute()
throws MojoExecutionException, MojoFailureException {
File manifestDirectory = new File(
@@ -493,7 +493,7 @@
<code class="code">run</code> targets are pretty much the same for all plugins but the <code class="code">suite</code> target contains
an Ant call (to the provided build file) for each test. Maintaining this target, of course, is a manual and
error-prone task.</p></td></tr></table></div><p>The solution, provided by this Mojo, is to automatically orchestrate the entire test phase - and do it in such
- a way that the rest of the Maven 2 build infrastructure can work with it.</p><div class="example"><a name="N102D0"></a><p class="title"><b>Example 6. The PDE Test Orchestration</b></p><div class="example-contents"><pre class="programlisting">
+ a way that the rest of the Maven 2 build infrastructure can work with it.</p><div class="example"><a name="N102D4"></a><p class="title"><b>Example 6. The PDE Test Orchestration</b></p><div class="example-contents"><pre class="programlisting">
protected void doExecute()
throws MojoExecutionException, MojoFailureException {
if (!needsToRunTests()) {
@@ -562,7 +562,7 @@
self hosting, like PDE, a second Eclipse instance is required for testing. By convention, we keep that in the
user's home directory, but the location can be configured. So before doing anything else, a sanity check is made
to ensure that there <span class="emphasis"><em>is</em></span> a valid Eclipse instance with the correct version of the test
- framework installed.</p><div class="example"><a name="N102E0"></a><p class="title"><b>Example 7. The PDE Test Eclipse Validation</b></p><div class="example-contents"><pre class="programlisting">
+ framework installed.</p><div class="example"><a name="N102E5"></a><p class="title"><b>Example 7. The PDE Test Eclipse Validation</b></p><div class="example-contents"><pre class="programlisting">
protected void doExecute()
throws MojoExecutionException, MojoFailureException {
File eclipseDirectory = getEclipseDirectory();
@@ -639,7 +639,7 @@
the reverse internet domain notation, the default list will contain a single entry with the entire artifact id
(in which case you probably will need to configure the list). Any plugin that has an id that matches any of the
prefix(es) is simply deleted (so do <span class="emphasis"><em>not</em></span> configure that list with <code class="code">org.eclipse</code>
- as that will render your Eclipse installation fairly useless).</p><div class="example"><a name="N102F6"></a><p class="title"><b>Example 8. The PDE Test Cleanup</b></p><div class="example-contents"><pre class="programlisting">
+ as that will render your Eclipse installation fairly useless).</p><div class="example"><a name="N102FC"></a><p class="title"><b>Example 8. The PDE Test Cleanup</b></p><div class="example-contents"><pre class="programlisting">
protected void doExecute()
throws MojoExecutionException, MojoFailureException {
File eclipseDirectory = getEclipseDirectory();
@@ -679,7 +679,7 @@
to be moved to the home directory of Eclipse and it needs to be moved back after the run. In either case, the
JUnit XML report files, needed by Surefire for formatting, need to be copied to the plugin's
<code class="code">target/surefire-reports</code> directory. Since Ant is so excellent at doing this, we simply construct
- the build file with all the necessary file operations.</p><div class="example"><a name="N1030C"></a><p class="title"><b>Example 9. The PDE Test Ant File Construction</b></p><div class="example-contents"><pre class="programlisting">
+ the build file with all the necessary file operations.</p><div class="example"><a name="N10313"></a><p class="title"><b>Example 9. The PDE Test Ant File Construction</b></p><div class="example-contents"><pre class="programlisting">
protected void doExecute()
throws MojoExecutionException, MojoFailureException {
getLog().info(
@@ -716,7 +716,7 @@
<code class="code">target/pde-test</code>, since we obviously never check it in or otherwise manipulate it
manually.</p></td></tr></table></div><p>You can take a look at a sample <a href="test.xml" target="_new">test.xml</a> file, built for a Cobertura analysis,
here.</p><p>The fourth step, done by the Mojo, is to deploy the plugin under test along with all of its dependencies. This
- is actually a fairly easy thing to do, since Maven 2 has all the information needed.</p><div class="example"><a name="N1031F"></a><p class="title"><b>Example 10. The PDE Test Artifact Deployment</b></p><div class="example-contents"><pre class="programlisting">
+ is actually a fairly easy thing to do, since Maven 2 has all the information needed.</p><div class="example"><a name="N10327"></a><p class="title"><b>Example 10. The PDE Test Artifact Deployment</b></p><div class="example-contents"><pre class="programlisting">
protected void doExecute()
throws MojoExecutionException, MojoFailureException {
getLog().info(
@@ -762,7 +762,7 @@
<code class="code">binary-plugin</code> and as outlined above, the only artifact we keep around for those is the
<code class="code">pom.xml</code> file. As also mentioned earlier, we need to reify these plugins on the fly to enable
PDE launch, debug and test, so the PDE test Mojo reuses that code to create each binary plugin directly in the
- Eclipse <code class="code">plugins</code> directory.</p><div class="example"><a name="N10335"></a><p class="title"><b>Example 11. The PDE Test Dependency Deployment</b></p><div class="example-contents"><pre class="programlisting">
+ Eclipse <code class="code">plugins</code> directory.</p><div class="example"><a name="N1033E"></a><p class="title"><b>Example 11. The PDE Test Dependency Deployment</b></p><div class="example-contents"><pre class="programlisting">
/**
* Deploys the plugin artifact's dependencies.
* @throws MojoExecutionException
@@ -801,7 +801,7 @@
</pre></div></div><br class="example-break"><p>The fifth, and last, step for the Mojo is to launch Eclipse with the newly constructed build file. For that
purpose, we've created a simple program runner class that uses standard Java <code class="code">Runtime.exec()</code> method
to launch a <code class="code">Process</code> along with a couple of <code class="code">Thread</code>s to read the standard output and
- error streams.</p><div class="example"><a name="N10345"></a><p class="title"><b>Example 12. The PDE Test Execution</b></p><div class="example-contents"><pre class="programlisting">
+ error streams.</p><div class="example"><a name="N1034F"></a><p class="title"><b>Example 12. The PDE Test Execution</b></p><div class="example-contents"><pre class="programlisting">
protected void doExecute()
throws MojoExecutionException, MojoFailureException {
String command = createCommand();
@@ -825,7 +825,7 @@
Lastly, from an Ant perspective each test execution is a successful build if the Ant file runs without error -
regardless of whether or not any errors were found. This can be confusing for developers who are used to
Surefire, so in addition to listing the test results on standard out, the Mojo also checks to see if there were
- any failures or errors - and if so, it fails the Maven build.</p><div class="example"><a name="N1034E"></a><p class="title"><b>Example 13. The PDE Test Dump and Extract</b></p><div class="example-contents"><pre class="programlisting">
+ any failures or errors - and if so, it fails the Maven build.</p><div class="example"><a name="N10359"></a><p class="title"><b>Example 13. The PDE Test Dump and Extract</b></p><div class="example-contents"><pre class="programlisting">
/**
* Extracts errors and failures from the surefire reports.
* @throws MojoExecutionException
@@ -904,7 +904,7 @@
being the new packaging type. So in this case it would be <code class="code">.source-plugin</code>. We play a little
trick here and say that the extension for <code class="code">source-plugin</code> artifacts should be
<code class="code">jar</code>. Thus anything java still knows what the artifact is and can compile against it.</p></td></tr></table></div>
- <div class="example"><a name="N1038A"></a><p class="title"><b>Example 14. Components entry for source-plugin</b></p><div class="example-contents"><pre class="programlisting">
+ <div class="example"><a name="N10396"></a><p class="title"><b>Example 14. Components entry for source-plugin</b></p><div class="example-contents"><pre class="programlisting">
<component>
<role>
org.apache.maven.lifecycle.mapping.LifecycleMapping
@@ -953,7 +953,7 @@
<code class="code">components.xml</code> in our plugin. <div class="note" style="margin-left: 0.38in; margin-right: 0.38in;"><table class="note-table"><tr><td><img alt="[Note]" src="images/note.gif"></td><td><p>Again, like in the <code class="code">source-plugin</code> case, we play a similar trick and define the extension
of all <code class="code">binary-plugin</code> artifacts to be <code class="code">pom</code>. Thereby, we have only ever either
poms or jars to deal with.</p></td></tr></table></div>
- <div class="example"><a name="N103A8"></a><p class="title"><b>Example 15. Components entry for binary-plugin</b></p><div class="example-contents"><pre class="programlisting">
+ <div class="example"><a name="N103B5"></a><p class="title"><b>Example 15. Components entry for binary-plugin</b></p><div class="example-contents"><pre class="programlisting">
<component>
<role>
org.apache.maven.lifecycle.mapping.LifecycleMapping
@@ -1022,10 +1022,10 @@
</component>
</pre></div></div><br class="example-break">
</p></li></ul></div>
- </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N103AF"></a>Configuration</h3></div></div></div><p>We have arranged our project hierarchy so that all our Eclipse plugin projects sit under one parent. We call this our
+ </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N103BD"></a>Configuration</h3></div></div></div><p>We have arranged our project hierarchy so that all our Eclipse plugin projects sit under one parent. We call this our
Eclipse Plugin Super POM. This has been convenient as all configuration that plugin projects require can be defined once.</p><p>Besides the configuration for the Maven 2 plugin that we provide (described later in <a href="#pom-config" title="POM Configuration">the section called “POM Configuration”</a>) the
only necessary configuration for all of this to work is that of the resources</p><p>
- <div class="example"><a name="N103BC"></a><p class="title"><b>Example 16. Resources configuration for Eclipse plugins</b></p><div class="example-contents"><pre class="programlisting">
+ <div class="example"><a name="N103CA"></a><p class="title"><b>Example 16. Resources configuration for Eclipse plugins</b></p><div class="example-contents"><pre class="programlisting">
<resources>
<resource>
<directory>src/main/java</directory>
@@ -1045,13 +1045,13 @@
</resource>
</resources>
</pre></div></div><br class="example-break">
- </p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N103C2"></a>Putting It All Together</h2></div></div></div><p>Now that we have a gone through in some detail, what the issues are, and how we went about resolving them, you probably just
+ </p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N103D1"></a>Putting It All Together</h2></div></div></div><p>Now that we have a gone through in some detail, what the issues are, and how we went about resolving them, you probably just
want to know how to pull it all together. In brief, you need our Mojos, you need to configure your POM(s) and you need to
provide an Eclipse installation for testing purposes, other than the Eclipse you use for development. The reason for this is
that the test framework requires that all the plugins under test (and their dependencies) are installed. Unlike PDE, it cannot
- (yet) magically add the plugin(s) under development and not touch the Eclipse installation.</p><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N103C8"></a>Getting the Mojos</h3></div></div></div><div class="note" style="margin-left: 0.38in; margin-right: 0.38in;"><table class="note-table"><tr><td><img alt="[Note]" src="images/note.gif"></td><td><p>We would like to provide the complete source for our Mojos and ultimately contribute everything to the community. At
+ (yet) magically add the plugin(s) under development and not touch the Eclipse installation.</p><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N103D7"></a>Getting the Mojos</h3></div></div></div><div class="note" style="margin-left: 0.38in; margin-right: 0.38in;"><table class="note-table"><tr><td><img alt="[Note]" src="images/note.gif"></td><td><p>We would like to provide the complete source for our Mojos and ultimately contribute everything to the community. At
the time of writing, we and our legal counsel are poring over various licenses etc. trying to figure out how to do this.
- We expect this to be resolved in a hopefully satisfactorily manner as soon as possible.</p></td></tr></table></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N103CF"></a>Installing the Test Eclipse Instance</h3></div></div></div><p>If you follow the convention over configuration mantra, install a Callisto release into your home directory. I.e. on
+ We expect this to be resolved in a hopefully satisfactorily manner as soon as possible.</p></td></tr></table></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N103DE"></a>Installing the Test Eclipse Instance</h3></div></div></div><p>If you follow the convention over configuration mantra, install a Callisto release into your home directory. I.e. on
Windows your Eclipse directory would be <code class="code">C:\Documents and
Settings\</code><span class="emphasis"><em>username</em></span><code class="code">\eclipse</code>; on Unix/Linux/BSD it would be
<code class="code">/home/</code><span class="emphasis"><em>username</em></span><code class="code">/eclipse</code> and on Mac OS X it would be
@@ -1066,11 +1066,11 @@
directory and may therefore wreak havoc on your development environment. Since the test instance is ever only used for
the automated testing, the repeated deploy/clean cycles only happen when it's not actually running.</p></td></tr></table></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="pom-config"></a>POM Configuration</h3></div></div></div><p>To have some chance of success, you will need to stick the following configuration in your Eclipse plugin projects' POM,
or in a super POM for all your Eclipse plugin projects. You can also take a look at all the below configuration put together
- in a super POM <a href="example-pom.xml" target="_new">here</a>.</p><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="N1040B"></a>Configuring the PST Maven 2 Eclipse plugin</h4></div></div></div><p>Once you have obtained our plugin (we are calling it the "PST Maven 2 Eclipse plugin" for now) you can configure it
+ in a super POM <a href="example-pom.xml" target="_new">here</a>.</p><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="N1041A"></a>Configuring the PST Maven 2 Eclipse plugin</h4></div></div></div><p>Once you have obtained our plugin (we are calling it the "PST Maven 2 Eclipse plugin" for now) you can configure it
the following way. <div class="note" style="margin-left: 0.38in; margin-right: 0.38in;"><table class="note-table"><tr><td><img alt="[Note]" src="images/note.gif"></td><td><p>Please make a special observation of the <code class="code"><extensions/></code> element. If you wind up
writing your own plugin that contains a <code class="code">components.xml</code> you will need to specify the configuration
element <code class="code"><extensions>true</extensions></code></p></td></tr></table></div>
- <div class="example"><a name="N1041D"></a><p class="title"><b>Example 17. PST Eclipse configuration</b></p><div class="example-contents"><pre class="programlisting">
+ <div class="example"><a name="N1042C"></a><p class="title"><b>Example 17. PST Eclipse configuration</b></p><div class="example-contents"><pre class="programlisting">
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-psteclipse-plugin</artifactId>
@@ -1105,8 +1105,8 @@
</executions>
</plugin>
</pre></div></div><br class="example-break">
- </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="N10423"></a>Configuring the Maven 2 Eclipse plugin</h4></div></div></div><p>To get the Maven 2 Eclipse plugin (i.e. <code class="code">mvn eclipse:eclipse</code>) to generate the correct Eclipse project
- artifacts for your Eclipse plugins you will need to configure it the following way. <div class="example"><a name="N1042C"></a><p class="title"><b>Example 18. Eclipse plugin configuration</b></p><div class="example-contents"><pre class="programlisting">
+ </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="N10433"></a>Configuring the Maven 2 Eclipse plugin</h4></div></div></div><p>To get the Maven 2 Eclipse plugin (i.e. <code class="code">mvn eclipse:eclipse</code>) to generate the correct Eclipse project
+ artifacts for your Eclipse plugins you will need to configure it the following way. <div class="example"><a name="N1043C"></a><p class="title"><b>Example 18. Eclipse plugin configuration</b></p><div class="example-contents"><pre class="programlisting">
<plugin>
<artifactId>maven-eclipse-plugin</artifactId>
<configuration>
@@ -1137,8 +1137,8 @@
</configuration>
</plugin>
</pre></div></div><br class="example-break">
- </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="N10432"></a>Adding Profiles for various platforms</h4></div></div></div><p>This configuration is to mainly aid our Test Mojos in loading dependencies without knowing about the platform it is
- running on. The use of Maven 2 Profiles comes in good for being able to write platform neutral Mojos. <div class="example"><a name="N10438"></a><p class="title"><b>Example 19. Sample Profile Configuration</b></p><div class="example-contents"><pre class="programlisting">
+ </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="N10443"></a>Adding Profiles for various platforms</h4></div></div></div><p>This configuration is to mainly aid our Test Mojos in loading dependencies without knowing about the platform it is
+ running on. The use of Maven 2 Profiles comes in good for being able to write platform neutral Mojos. <div class="example"><a name="N10449"></a><p class="title"><b>Example 19. Sample Profile Configuration</b></p><div class="example-contents"><pre class="programlisting">
<profiles>
<profile>
<id>org.eclipse.swt.win32</id>
@@ -1193,15 +1193,15 @@
</profile>
</profiles>
</pre></div></div><br class="example-break">
- </p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N1043E"></a>Using it all together</h2></div></div></div><p>Just to round things off, the following is a brief description of the development process for Eclipse binary and source
+ </p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N10450"></a>Using it all together</h2></div></div></div><p>Just to round things off, the following is a brief description of the development process for Eclipse binary and source
plugins. The descriptions below assume that all configuration/installation specified in the previous section has been done and
- that all the projects sit in a hierarchy.</p><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N10444"></a>Developing binary plugins</h3></div></div></div><p>You can begin by creating a Maven 2 project by using the archetype for creating projects. Do this under the project that
+ that all the projects sit in a hierarchy.</p><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N10456"></a>Developing binary plugins</h3></div></div></div><p>You can begin by creating a Maven 2 project by using the archetype for creating projects. Do this under the project that
contains the POM with all the configuration described in the previous section.
<pre class="programlisting"><code class="code">mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-binary-plugin</code></pre>
This should give you the basic template for your project. </p><p>Now once you do a <pre class="programlisting"><code class="code">mvn eclipse:eclipse</code></pre> you will be able to import the project
into Eclipse. Open up the POM file (<code class="code">pom.xml</code>) in Eclipse and change the <code class="code"><packaging></code>
element to <code class="code"><packaging>binary-plugin</packaging></code>. Also add all the dependencies that you want the
- binary plugin to expose right into the pom file. It may look like the example below when you are done: <div class="example"><a name="N1045D"></a><p class="title"><b>Example 20. Example binary plugin POM</b></p><div class="example-contents"><pre class="programlisting">
+ binary plugin to expose right into the pom file. It may look like the example below when you are done: <div class="example"><a name="N10471"></a><p class="title"><b>Example 20. Example binary plugin POM</b></p><div class="example-contents"><pre class="programlisting">
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
@@ -1230,16 +1230,16 @@
dependencies, defined in the POM, into a <code class="code">lib</code> directory and generate an OSGi manifest file
(<code class="code">MANIFEST.MF</code>) in <code class="code">META-INF</code>. Before Eclipse knows what PDE artifacts to export and make available to
other plugins you must open the manifest file in Eclipse's PDE manifest editor and select the "Update the classpath and the
- compiler compliance settings" link on the editor's "Overview" tab.</p><div class="figure"><a name="N10471"></a><p class="title"><b>Figure 3. Eclipse PDE manifest editor</b></p><div class="figure-contents"><div class="mediaobject"><img src="images/pde-update-classpath.png" alt="Eclipse PDE manifest editor"></div></div></div><br class="figure-break"><div class="note" style="margin-left: 0.38in; margin-right: 0.38in;"><table class="note-table"><tr><td><img alt="[Note]" src="images/note.gif"></td><td><p>Whenever you change the POM for a binary plugin, the above steps must be executed again, in order to copy the correct
+ compiler compliance settings" link on the editor's "Overview" tab.</p><div class="figure"><a name="N10487"></a><p class="title"><b>Figure 3. Eclipse PDE manifest editor</b></p><div class="figure-contents"><div class="mediaobject"><img src="images/pde-update-classpath.png" alt="Eclipse PDE manifest editor"></div></div></div><br class="figure-break"><div class="note" style="margin-left: 0.38in; margin-right: 0.38in;"><table class="note-table"><tr><td><img alt="[Note]" src="images/note.gif"></td><td><p>Whenever you change the POM for a binary plugin, the above steps must be executed again, in order to copy the correct
dependent artifacts; create the manifest and update the classpath and compiler compliance settings.</p></td></tr></table></div><div class="note" style="margin-left: 0.38in; margin-right: 0.38in;"><table class="note-table"><tr><td><img alt="[Note]" src="images/note.gif"></td><td><p>The PDE test Mojo, described earlier, leverages this exact same mechanism when deploying the dependent plugins for a
source plugin being tested, but rather than creating the PDE artifacts in your project directory, it creates them
directly in the <code class="code">plugins/</code> directory in your test Eclipse instance.</p></td></tr></table></div><p>When doing a Maven 2 build of a binary plugin, the behavior seen is that of a "pom" packaging type. What this means, is
that no actual compilation, packaging or testing is performed, but all dependencies are resolved and provided to the
- dependent plugins.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N10484"></a>Developing source plugins</h3></div></div></div><p>Creating a source plugin essentially is similar to creating a binary one. Simply do
+ dependent plugins.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N1049B"></a>Developing source plugins</h3></div></div></div><p>Creating a source plugin essentially is similar to creating a binary one. Simply do
<pre class="programlisting"><code class="code">mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-source-plugin</code></pre>
and do a <pre class="programlisting"><code class="code">mvn eclipse:eclipse</code></pre></p><p>As with the binary plugin, import the project into Eclipse and change the packaging. However since this is a source plugin
you must change the packaging to <code class="code">source-plugin</code>. Your source plugin POM will end up looking something like the
- following: <div class="example"><a name="N10496"></a><p class="title"><b>Example 21. Example source plugin POM</b></p><div class="example-contents"><pre class="programlisting">
+ following: <div class="example"><a name="N104AF"></a><p class="title"><b>Example 21. Example source plugin POM</b></p><div class="example-contents"><pre class="programlisting">
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
@@ -1261,9 +1261,9 @@
build.</p></td></tr></table></div><p>From now on you simply develop and test your Eclipse plugin in PDE as per usual. When building the plugin using Maven 2,
the normal build lifecycle comes into effect. For example, to do a clean install of your plugin, do
<pre class="programlisting"><code class="code">mvn clean install</code></pre> and to get a Cobertura code coverage report, do
- <pre class="programlisting"><code class="code">mvn cobertura:cobertura</code></pre></p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N104A7"></a>Acknowledgements</h2></div></div></div><p>Based on the excellent <a href="http://www.eclipse.org/articles/Article-Authoring-With-Eclipse/AuthoringWithEclipse.html" target="_new">article</a> by Chris Aniszczyk and Lawrence Mandel, from IBM, we decided to write this article in DocBook. We took the
+ <pre class="programlisting"><code class="code">mvn cobertura:cobertura</code></pre></p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N104C3"></a>Acknowledgements</h2></div></div></div><p>Based on the excellent <a href="http://www.eclipse.org/articles/Article-Authoring-With-Eclipse/AuthoringWithEclipse.html" target="_new">article</a> by Chris Aniszczyk and Lawrence Mandel, from IBM, we decided to write this article in DocBook. We took the
liberty of further refining their kindly donated XSL stylesheet to include the "Eclipse Corner Article" banner and image. Please
- find the stylesheet <a href="article.xsl" target="_new">here</a>.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N104B5"></a>External Links</h2></div></div></div><p>
+ find the stylesheet <a href="article.xsl" target="_new">here</a>.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N104D1"></a>External Links</h2></div></div></div><p>
<div class="itemizedlist"><ul type="disc"><li><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=158653" target="_new">Bugzilla Bug 15863</a> at
Eclipse</li><li><a href="http://maven.apache.org/" target="_new">Maven 2</a> at Apache</li><li><a href="http://mojo.codehaus.org/" target="_new">Mojos</a> at Codehaus</li><li><a href="http://maven.apache.org/continuum/" target="_new">Continuum</a> at Apache</li></ul></div>
</p></div><div class="notices"><h3>Legal Notices</h3><p>Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or
