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

[Thomas Watson <tjwatson@xxxxxxxxxx>]

The problem with the first approach
is that it we duplicate the shell jars across many different projects and
have to maintain them separately.  We could define a common project
that contains several .ee profile definitions for development time.  The
.ee profiles would configure the shell jars for compilation.  Then
developers only need to checkout the common .ee project and install each
.ee profile that is needed.  The project could contain many of the
common J2ME .ee profiles (CDC-1.0/Foundation-1.0, CDC-1.1/Foundation/1.1,
OSGi/Minimum etc).  We could also define some of the hybrid .ee file
like the one that org.eclipse.osgi is currently compiling against at development
time, something like OSGi/Minimum+extensions.

We would still need specify to PDE which
EE we want to compile against.  For example, org.eclipse.osgi will
need to define the hybrid ee to compile against.  This makes some
sense because we are explicit in the compilation needs.  But I think
this idea has a major flaw because nww we will be in the business of defining
EEs.  In the end they are not real EEs, only EEs we need to compile
against, but I think many will confuse them with EEs that they can execute
against.

Tom

Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

04/14/2007 06:54 AM

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

To	equinox-dev@xxxxxxxxxxx
cc
Subject	[equinox-dev] managing "extra" classes

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