[
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