[nebula-dev] Nebula Build

["Peter Centgraf" <peter@xxxxxxxxxxxx>]

Nebula-devs,

Since it seems likely that I will soon become a CDateTime committer, I've
taken a deeper look at the current build process, and I'd like to move
forward with the work that Chris has already done.  Overall, I'd like to
bring the Nebula builds in line with the overall Eclipse build
infrastructure, so we can participate in the next moon-of-Jupiter release.

1. Consistent Naming

A consensus seems to have evolved for package/bundle naming, where each
widget gets a package like "org.eclipse.nebula.widgets.XYZ" and higher-level
controller code goes in "org.eclipse.nebula.jface.XYZ".  However, snippets
and tests still use the old "org.eclipse.swt.nebula.ABC" convention.  I'd
like to make these "org.eclipse.nebula.snippets",
"org.eclipse.nebula.examples", etc.

2. Consistent Versioning

Each of the widgets in Nebula has an individual version number and its own
release schedule.  This is all for the good.  However, I'd like to bring the
versioning _scheme_ in line with Eclipse conventions.  This means using the
four-part major.minor.service.qualifier system.  If a widget is in a true
"alpha" state, in which no guarantees of API compatibility whatsoever are
maintained, I propose that we specify the major version number as zero.  If
we follow these conventions, it will be easier for other Eclipse projects to
use our widgets.

http://wiki.eclipse.org/Version_Numbering

3. Update Site / Features

Chris has already started a feature project to package all of the Nebula
widgets into a single item for an update site.  I recommend that we create
separate features for each widget, instead.  Features are intended to be
single units of functionality that are versioned and deployed as a set, but
the Nebula widgets are all versioned and used independently.  Since a
feature must increment its version whenever an included plugin version is
incremented, the feature version is likely to spin out of control very
quickly.  If we still want to have a central compound feature, we can
accomplish this with the "required features" mechanism.  Separate features
also would allow us to create individual descriptions for each widget that
would be visible in the update manager.

4. Source and Binary Builds

The current build process creates a ZIP file containing source, Javadoc,
snippets, and the binary-only jar.  This is fairly convenient, but I think
we can do better.  If we use the PDE build support, we can create two jars,
both of which are working, deployable binary jars.  One of them would
contain only the class binaries and required license files and would be
suitable for deployment to end user machines.  The other would contain those
files plus source, javadoc, and snippets and would be suitable for use
within the Eclipse IDE.  Eclipse will automatically detect the presence of
source and javadoc within a plugin jar and will use them for hyperlinking
and tooltips.  A developer must only drop the jar into the Eclipse plugins
directory -- no unpacking required.  Better yet, the plugin can be delivered
via the Update Manager with source and docs already linked.

Supporting this style of packaging would be relatively easy, since the PDE
build already creates the binary jar.  Setting up the source build requires
a few tweaks to the build.properties using the PDE editor.  As a side
effect, this would take care of the issues we have now with version
numbering, since the PDE outputs jars with the full version number appended
to the file name.  The only tricky part would be to pull in the snippets for
each widget.  I think we can accomplish this with a custom build callback.
Personally, I would prefer to move the snippets into the widget plugins to
which they belong and simply exclude them from the binary build.

5. Signing and Processing Jars

The last requirement for participation in a moon-of-Jupiter release is to
sign and pack the plugin jars using the PDE jarprocessor tool.  Setting this
up is also relatively straightforward.  However, we need an Eclipse.org
certificate to sign the jars.  Do we have access to such a certificate?  How
would we get it?


If we make all of the incremental changes I've laid out, Nebula would be
ready for inclusion in next summer's major release.  It would also make
Nebula widgets much easier to consume for other Eclipse projects and RCP
developers in general.  If the committers agree that this is a worthwhile
goal and approve my strategy for getting there, I'll get started setting up
the builds.  I will submit patches to each plugin, so that the maintainers
for each widget can approve or veto the details of each change.  If there
any adjustments you think should be made, please let me know and I'll do my
best to include them.

--
Peter