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

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

Yes, JDT does need to know what jars
to put on the classpath for compilation but this is part of the JRE definition
(where JRE = VM + JCL).  My only point here is that we cannot define
a generic .ee for say Foundation 1.0.  We can define one for the J9
2.3 configured to run a particular set of JARs that happens to constitute
a Foundation 1.0 compliant JRE.  That .ee would not be relevant for
say the Sun Foundation 1.0 setup.

Jeff

Thomas Watson <tjwatson@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

04/25/2007 09:16 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

The J9 vm has a class library called jclRM that implements the OSGi-min
1.x execution environments. 

I thought the .ee files also indicated what jars should be placed on the
boot classpath.  Doesn't JDT use this information to construct the
classpath for an installed JRE? 

Tom

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

04/24/2007 08:50 PM

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

There should be .ee files for all relevant JRE configurations.  The
long term hope is that JRE vendors will eventually include these files
in their distributions.  In the mean time we can provide the definitions
that users/developers can add to the JREs for dev and execution time.  Note
that .ee files are not for defining profiles but rather describe how a
particular VM can be run/compiled against with a particular classlib.  So
with J9 for example, there would be a whole set of .ee files since the
same VM can be used to run many different class library configurations.
 To date I don't know of a JRE configuration that would correspond
to OSGi-min 1.x. 

Jeff

Thomas Watson <tjwatson@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

04/23/2007 08:48 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

+1 

I think this is a fine direction to explore.  Would we still what
to define some .ee files for the foundation and osgi-min EEs?

Tom

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

04/20/2007 08:51 PM

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

Hmmm, would it make sense to basically manage the "extras" only?
 That is, say in bundle Foo we use Foundation 1.0 or J2SE-1.3 for
the most part.  We would set the B-REE accordingly.  Assume that
we want to be able to use java.nio.FileChannel (whatever from 1.4).  We
could create a shell JAR that contains just that class (and transitively
required classes).  This JAR would go in the Foo project and be placed
on the buid path using something like the build.properties extra.jars (whatever
it is) property.   

These extra JARs would in general be specific to particular bundles though
it seems likely that there might be some common sets classes that are frequently
used in such scenarios.  It is not clear that manage this duplication
would be worth it.  For exmaple, it may be better to just let the
project developers expliciitly spec what they need in one JAR and not worry
about duplication. 

Jeff

Thomas Watson <tjwatson@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

04/16/2007 09:34 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

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
_______________________________________________
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
_______________________________________________
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
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev