Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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

Back to the top