Re: [equinox-dev] managing "extra" classes

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

Fragments can be used in some cases
but often there is just some small bit of funciton that one wants to use
and sometimes it is quite embedded in the refering classes.  It also
results in more stuff to manage/ship.  In any event, that approach
can be considered in some cases.

As for multiple EEs, their contents
are AND'd (ie., intersected).  For example, it is quite common for
a bundle to spec Foundation 1.0 and J2SE 1.3.  While Foundation 1.0
is based on SE 1.3, it is not a proper subset.  It includes some additional
things.  So if you spec both, the bundle should run on either and
so logically can only use classed that are in both.

Jeff

Thomas Hallgren <thomas@xxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

04/14/2007 09:46 AM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

To	Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc
Subject	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
>   

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev