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 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
http://www.eclipse.org/dsdp/tm
 
 


From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Pascal Rapicault
Sent: Tuesday, June 10, 2008 4:54 PM
To: Cross project issues
Cc: Cross project issues; cross-project-issues-dev-bounces@xxxxxxxxxxx
Subject: RE: [cross-project-issues-dev] P2 and feature dependencies

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 :)

Inactive hide details for "Oberhuber, Martin" ---06/10/2008 10:01:05 AM---Hi,"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



Back to the top