Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [hyades-dev] Hyades Features restructuring


I had made a few suggestions to Qiyan earlier on about features that I wanted to share. Some of this goes counter to what Richard mentioned; specifically the part about feature number. I wasn't aware that we had people requesting different packaging; we should definitely try to accomodate this by splitting our features to match this, so ignore my previous comments about this.

As for the includes -vs- requires, these have fundamentally different meanings that shouldn't be confused. Includes means it is "part of" the feature, while requires means a dependency. So a "Hyades" feature would include, say, the probekit, and would require the jdt. It's important to get this right because we eventually should move our build system to use the PDE.

------------------------------------------------------------------------------------------------------------------------------------------------

I did a bit of research on features and updated the hyades features. Here's what I did and why.

- Reorganized the features to reflect the way the plugins are being distributed and packaged. I justify this using the example of the jdt. The jdt has many components in itself; the launchers, editors, builders, refactoring, junit, etc. which could all be separated. But the individual jdt pieces are never delivered separately; they are always bundled together. So there is only one feature for the jdt (plus the source feature). One could take the other extreme and nit pick down to the smallest pieces that can be separated and create a feature for each. But there is nothing gained from doing this, and the features are hard to maintain. So I propose the simplest solution for hyades, the same as the jdt's and other components. So I removed the models, logging, probekit, and test.examples features because they are never distributed by themselves and are always part of other "bundles". The way I see it, we have 4 features - core, test, examples, and source. This is much more consistent with the features from other projects. I also have one 'root' feature - hyades, which encapsulates all the hyades features, much like the org.eclipse.sdk feature for the eclipse+jdt+pde platform. The benefit to having this is can be seen in how I set a dependency on the eclipse platform. I just reference the org.eclipse.sdk feature; which we know includes everything we need. We could instead take the long way and list each part (platform, jdt, pde, etc) but this is simpler. So higher products' features would either include or require our hyades feature, which in turn includes core, and optionally includes the others.
- Removed about.html from features. None of the other features have this (all of their plugins do). Also removed from build.properties.
- Updated license.html file to a new version.
- Updated license string in .properties file.
- Using feature dependencies (emf, platform). I couldn't find anything anywhere that says you shouldn't use feature dependencies, so I'm using them. I still don't know why the other features refer to the plugins instead of the features. If you prefer, you can switch these to plugin dependencies.
-Reordered some of the jars in build.properties for some plugins that have two src dirs. the PDE is sensitive to which one is built first. If they are in the wrong order, you get compile errors. Although this only seems to happen when exporting jars, and not when building from source in eclipse while developing.

Things that I didn't do and that should be done:

- Set the correct version numbers for the features and plugins depending on the release.
- Specify the update site that is used to update these plugins. Right now, Hyades is basically not update-able unless you do some magic in the update manager. EMF has its own update site on eclipse.org, so I can't see why we can't have our own. GEF, on the other hand, is bundled with the platform's update site.

The features should now build and package properly (almost) in the PDE when you do an export -> feature. I tried deploying and running and it seems fine. So if you wanted to generate the runtime jar (like on hoplite4), you'd just export the core feature. It seems to have a lot of difficulty dealing with the already-built org.apache.jakarta-commons-logging plugin, so I have it listed now as a requirement instead of a part of the core feature. I suppose you could just drop this plugin in the zip afterwards for the build when you move to the PDE build system.

Here's the collection of patches (I was using 3.1 but they should be more/less ok for 3.0.1 too).



Curtis d'Entremont
Problem Determination Tools
IBM Toronto Lab

Phone: (905) 413-5754
E-Mail: curtispd@xxxxxxxxxx




Richard Duggan/Toronto/IBM@IBMCA
Sent by: hyades-dev-admin@xxxxxxxxxxx

07/22/2004 02:48 PM

Please respond to
hyades-dev

To
hyades-dev@xxxxxxxxxxx
cc
Subject
[hyades-dev] Hyades Features restructuring










Currently, there are a total of nine features in Hyades: source, hyades,
logging, models, core, porbekit, test, examples, and test.examples.
Currently, <includes> have been used to create bigger features, but this
has and with continue to cause serviceability problems.  The solution is
use <requires> instead.  The list below is the dependencies among the
existing features

     Feature           Requires
     source            nothing
     logging           emf
     models            logging
     core        models
     probekit    core
     test        core
     example     core
     test.examples     test
     hyades            everything except source


Furthermore, I would like to break the features into a more fine grained
list so that Hyades can be consumed at a more granular level.  Several
products which have committed to consuming hyades, and others that have
expressed an interest, do not wish to pick up the entire Hyades content.
Today is it possible to break apart our existing features into the
following additional features.
     Feature                 Requires
     test.manual       test
     test.junit              test
     test.http               test.junit
     test.examples.manual    test.manual
     test.example.junit      test.junit
     test.examples.http      test.http
     probekit.examples probekit
     profiling               core
     profiling.examples      profiling
     logging.examples  logging
     gla               core


One of the biggest unknowns yet is how do we handle NL content.  Do these
plugin fragments get packaged as part of the feature or as a separate
feature?  If they are a separate feature, they need to correspond 1-1 with
a functional feature.  I will see what I can find out about how the base
handles this.

I would appreciate any feedback on this before we move forward.

Richard K. Duggan
Problem Determination Enablement
IBM Toronto Laboratory
External: 905-413-2396
Internal: 969-2396

_______________________________________________
hyades-dev mailing list
hyades-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/hyades-dev

Attachment: patches.zip
Description: Zip archive


Back to the top