[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [nebula-dev] Nebula Build
|
Hi Peter,
Comments inline.
Regards,
-Chris
Peter Centgraf wrote:
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.
Yup, we haven't been good about cleaning up these spots. The tests
project should really be deleted. Following our new paradigm, each
plugin should manage their own tests (or have their own tests plugin).
Regarding snippets, we'd also have to make sure we change the
referencing web pages. I would be happy for them to be updated.
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
I don't have a strong opinion here but I don't know that using 0 as the
major ver is a good idea. When developing a set of inter-related
plugins you want to be able to specify plugin dependencies as you
develop. That is, I want to say plugin A requires plugin B 1.0. If
plugin b is 0.7 then that won't work.
Also, is this an Eclipse convention? I haven't seen other plugins start
at 0.x when developing.
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.
I created the feature when I started the build work but in the end I did
not use it. It could also be deleted. I don't think we ever expect all
the widgets to be updated as a group. I don't even think most people
will want to use the update manager to update individual widgets. Most
end-users probably don't want to think about downloading individual
widgets. I'm not sure if the ROI is there for any work on Nebula features.
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.
Yes I agree. This would be better than what we have now. I remember
thinking about this during the initial build work but I don't remember
why we didn't just do this.
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?
I'm not sure. I believe there is information about how to obtain the
certificate is either on eclipse.org or buried somewhere in the various
Eclipse mailing lists. We'll have to investigate.
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
I would definitely appreciate work on these things. Nebula suffers a
bit because none of the committers have much time. None of us work on
Nebula full-time. If you make these changes, submit patches then we
have no excuse :)
One last thought on the moon-of-Jupiter release, its of course necessary
that each plugin actually prepare a release for next summer. Individual
plugins may decide to release earlier or later. So I'm not sure how
easy it would be for us to jump on those releases. I don't think
they'll know how to handle us.
Regards,
-Chris
