[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [cross-project-issues-dev] P2 and feature dependencies
|
Hi all,
I appreciate all your offers to help remedy our situation
with
plugin vs. feature dependencies!
Unfortunately I cannot respond personally, since what
I've
done today was invest the first day of my vacation into
a desperate effort getting this fixed (in vain,
unfortunately).
I'll be out of office for the next two weeks, and from
what
Andrew said on the bug, I could indeed imagine
hand-crafting
group IU's in the end, unless a better solution is found
in
the meantime.
It looks like WTP and Mylyn have found their own
way
of workaround by means of feature dependencies,
but
what I'm really wondering is : doesn't this affect
anyone
else? What about the "BIRT / TPTP" integration,
this
would be a prime candidate that cannot have hard
feature dependencies into either BIRT or
TPTP...
doesn't that cause any issues when selected
by
itself as the only item to install?
Cheers,
--
Martin Oberhuber, Senior Member of Technical
Staff, Wind River
Target Management Project
Lead, DSDP PMC Member
If you are trying to create features that refer to several other features
to simply resolve the problem in the context of ganymede site, then I don't
see the need to generate source features.
You could create those features
after the fact and build them with pde build in another invocation of
pde.
As for the hair, I'm now almost bald :)
"Oberhuber, Martin" ---06/10/2008 10:01:05
AM---Hi,
 From: |
 "Oberhuber, Martin"
<Martin.Oberhuber@xxxxxxxxxxxxx> |
 To: |
 "Cross project issues"
<cross-project-issues-dev@xxxxxxxxxxx> |
 Date: |
 06/10/2008 10:01 AM |
 Subject: |
 RE: [cross-project-issues-dev] P2 and
feature dependencies |
Hi,
I need to give up on the
"wrapper feature" idea. After fighting PDE
Build for approx 16 hours now, I
do not find a way of having the
wrapper features generated, and still getting source plugins
generated.
It looks like I will have to
introduce some feature dependencies,
although this limits the flexibility in which products can
be
created.
I must say, this
"specification update" of P2 has cost me
several grey hairs.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=231453
Cheers,
--
Martin
Oberhuber, Senior Member of
Technical Staff, Wind
River
Target Management Project
Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
From:
cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Oberhuber, Martin
Sent: Tuesday, June 10, 2008 9:53
AM
To: Cross
project issues
Subject: 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.
See also https://bugs.eclipse.org/bugs/show_bug.cgi?id=231453#c20
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
http://www.eclipse.org/dsdp/tm
From:
cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Steffen Pingel
Sent: Tuesday, June 10, 2008 8:45
AM
To: Cross
project issues
Subject: Re: [cross-project-issues-dev] P2 and feature
dependencies
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_______________________________________________
cross-project-issues-dev
mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev