[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [hyades-dev] Hyades Features restructuring
|
I can see this is being driven off the IBM packaging requirement, but I think
we should articulate to a wider audience who won't understand the subtleties
of what is being proposed (I'm not sure I do) what the implications of structuring
are on the products that can get built.
How indeed does this relate to the three projects plus core currently being
proposed for the new PMC?
There is an idea floating round for a "Monitoring Project" package to pass
out through the volume linux distributions. This would contain log, statistical
viewers and agents, not trace, not test inside RCP. Can we do this?
MIke
Curtis D'Entremont wrote:
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
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
