[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [cross-project-issues-dev] P2 and feature dependencies
|
Hi Steffen,
what I'm currently investigating is
this:
-
Keep all original features exactly as they would have been with classig
UM.
For instance, if features are CAPITALS, and bundles are
lowercase:
A depends on b,c,d where b,c are
in fearure C and d,e are in feature D
B dependes on
b,d,e
-
Now UM's "select required" would have selected features C, D in this
case.
-
In order to satisfy P2, I'm adding a 2nd level of features on top of
the original ones, which "include" original features and do a "feature
dependency" on what UM would have selected:
-
A* includes A, depends on C, D
-
B* includes B, depends on C, D
My thinking is, that by keeping original features untouched
there is little risk of breaking existing
(commercial) product configurations
or the "Check for Updates" behavior. On the other hand,
I'm modeling the feature dependencies that UM would have
detected austomatically by mans
of the explicit additional wrapper
features.
The dilemma that I had see is, when I modifiy existing
feature A to have feature
dependencies, then I'm limiting the flexibility of
commercial products including
A: In order to have a valid configuration, such products
must include features
C, D wherease usually they could live with a subset if the
product designer
wanted it that way. That's why original features are
untouchable in my opinion.
I'm currently testing this approach and cannot yet say if
it'll be successful.
Of cours, my personal favorite would be if P2 added a
"Select Required"
feature like UM had, thus saving all us projects the effort
of tweaking our
features to make it work in a mixed UM / P2 environment...
not having
feature granularity dependencies any more is a regression
in my opinion.
Cheers,
--
Martin Oberhuber, Senior Member of Technical
Staff, Wind River
Target Management Project
Lead, DSDP PMC Member
On Mon, Jun 9, 2008 at 11:22 AM, Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx>
wrote:
To be really clear here. When you say: "if you rely on plug-in
dependencies alone users can end up with partial updates."
I assume you
meant to say "the user will only get what you specified and its closure, but
not see any runtime problem".
FWIW, I have been installing *only* the
Mylyn Bugzilla integration feature from the Ganymede update site and it
worked fine, so I'm not sure if the problem you are referring to is only one
about missing doc?
The difference in behavior I have observed when dependencies are
specified on a plug-in level rathern than a feature level is that P2 can fail
late, i.e. when it's already download plug-ins. This is the scenario: A user
downloads the Ganymede Java distribution that does not include PDE and chooses
to install the Mylyn PDE integration feature.
(1) Mylyn specifies
dependencies on a plug-in level: P2 will start downloading plug-ins and fail
with an error that is can not resolve a number org.eclipse.pde* plug-ins. This
is different to the behavior of UM which checks the plug-in dependencies at
the time when the feature is selected for installation and does not continue
with the download before dependencies are satisfied.
(2) Mylyn
specifies feature dependencies: P2 finds the PDE feature on some update site
and prompts the user to accept the license for PDE. The plug-ins are
downloaded to the plugins directory but the installation still fails with an
error that plug-ins could not be resolved.
At this point I
am not sure how to proceed since the install fail for me in both cases.
Suggestions how we can specify dependencies in a way that works for both UM
and P2 and improves the user experience are greatly
appreciated:
236357: P2 fails during install
https://bugs.eclipse.org/bugs/show_bug.cgi?id=236357
Thanks.
Steffen