[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [equinox-dev] managing "extra" classes
|
How about enforcing the use of fragments and override "dispatchers"
depending on EE capabilities? IIRC, fragments are enabled at runtime
depending on their required EE so that process would be semi-automatic.
Example:
Bundle X requires Foundation-1.0 and contains dispatch classes (ending
in a UnsupportedOperationException) for functionality normally found in
J2SE 1.3 and 1.4
Fragment Xa requires J2SE-1.3 and overrides some of the dispatch classes.
Fragment Xb requires J2SE-1.4 and overrides the remaining dispatch classes.
The author of X would be forced to comply with Foundation-1.0 and create
explicit dispatchers going beyond that. A bit tedious perhaps but
there's no muddiness and no confusion of metadata.
I wasn't aware that a bundle could require more then one execution
environment. I find that concept rather confusing, especially since the
environments often overlap. Should the list be interpreted using
operator AND or OR?
Regards,
Thomas Hallgren
Jeff McAffer wrote:
In a few (and seemingly growing number of) places we have bundles that
need to compile against say J2SE 1.4 but in practice we want them to
run against Foundation. This is cool because it allows us to run in
small places but take advantage of function when it is available. We
currently have a mixed approach to this however. For example in
org.eclipse.osgi we have a set of JARs that contain shell apis for the
OSGi ee.minimum 1.1 and we compile against these. We also have a set
of "exception" (extra) jars that similarly just contain class
signatures for us during compilation. In other bundles we do things like
Bundle-RequiredExecutionEnvironment:
J2SE-1.4,CDC-1.0/Foundation-1.0,J2SE-1.3
This uses an intentional quirk of PDE that uses the first EE on the
list as the compilation base for the project. That's pretty cool and
useful for getting going but it has some downsides:
- it muddies the waters by confusing the metadata
- it allows people to use any 1.4 classes/methods thus opening the
doors to mistakes
So I wonder if we should apply the first technique more broadly and
seek to eliminate instances of the second in our bundle set? It seems
that we just need a mechanism for easily creating/managing these shell
jars and then we can have very detailed control over what we use in
our bundles.
Thoughts?
Jeff
------------------------------------------------------------------------
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
