Grouping sounds good to me. It should probably be more general than
handling a special case for JREs. There might be a case for other
artifacts as well.
Maybe one could do quite a bit with just a group field. If IUs belong to
the same group then they provide equivalent type functionality and can be
considered (it might still not resolve). For my example:
- IU request jclDesktop but J2SE is installed.
- grouping is allowed
- both are identified as members of same equivalent group.
- allow J2SE to remain.
The governor could also play a part in accepting or declining a choice.
If we need a group IU then hopefully we don't have to know ahead of time
which JRE IUs might be capable of attaching. The JRE IU should be able to
declare itself a match.
David R
Stevenson/Redmond
/[EMAIL PROTECTED]
To
Sent by: Equinox development mailing list
equinox-dev-bounc <[email protected]>
[EMAIL PROTECTED] cc
Subject
10/11/2007 01:01 [equinox-dev][prov] JRE versioning
PM
Please respond to
Equinox
development
mailing list
<[EMAIL PROTECTED]
pse.org>
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/[EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
To
[EMAIL PROTECTED]
10/11/2007 09:30 AM lipse.org
cc
Please respond to Subject
Equinox development mailing list [equinox-dev][
<[email protected]> 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
[email protected]
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/equinox-dev
<<inline: graycol.gif>>
<<inline: pic00525.gif>>
<<inline: ecblank.gif>>
_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
