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 _______________________________________________ nebula-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/nebula-dev
