[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[equinox-dev][prov] JRE versioning
|
Another possibility for handing the
multiple variants of JREs is to have a JRE (or java execution environment)
group with selectable content so that the actual variant and version can
be chosen via filters. You can think of this approach as corresponding
to the way that arch, os, and ws are currently handled
by eclipse. A bunch of details on exactly how to represent the myriad JREs
and their relationships would have to be worked out. Similarly we
would have to craft very carefully the leaf IUs for jres to meet the use
cases we imagine.
If we did this, then our eclipse generator
could use the execution environment information from the manifest to construct
required capabilities on the appropriate jre - currently we ignore the
execution environment and don't generate dependencies.
-
Dave
James D Miles/Austin/IBM@IBMUS
Sent by: equinox-dev-bounces@xxxxxxxxxxx
10/11/2007 09:30 AM
Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx> |
|
To
| equinox-dev@xxxxxxxxxxx
|
cc
|
|
Subject
| [equinox-dev][prov] |
|
From Questions for M3
"Should versions be pluggable (the current version
does not properly reason about the version of the JRE"
JRE versions do go past the version definition that currently exists. I
will only give you our experience using versions with the current update.
Translate to the new terminology as needed.
We used the major number to create a hierarchy of different types of JREs.
For instance we used 2.0.0 for j2se and 1.0.0 for jclDesktop. These were
used for a parent feature. The child feature contained the actual JVM feature.
This allowed us to provision JVMs like any other artifact. It allowed us
to treat JVMs as equivalent from the ID perspective.
However it does not properly encapsulate the policy decisions that are
necessary. If a platform initially specifies jcldesktop, version 1.0.0,
then the user changes the JRE to J2SE, version 2.0.0, what gets done on
an upgrade that specifies jclDesktop. So there likely needs to be another
parameter/policy that specifies a user or platform choice (assuming either
choice will resolve). In general updates only occur on versions. However
IU with ID for jclDesktop does not equate to an ID for J2SE. The problem
is how to know that they can replace each other.
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev