[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] p2 is greedy enough to be broken

You are correct. The unpack works correctly. I will continue testing. I do like this if it can work for us.

Inactive hide details for Pascal Rapicault ---05/05/2009 08:19:55 PM---This is a change in behaviour in comparison to update maPascal Rapicault ---05/05/2009 08:19:55 PM---This is a change in behaviour in comparison to update manager. However the exact same behaviour was implemented in 3.4.


From:

Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx>

To:

P2 developer discussions <p2-dev@xxxxxxxxxxx>

Cc:

P2 developer discussions <p2-dev@xxxxxxxxxxx>, p2-dev-bounces@xxxxxxxxxxx

Date:

05/05/2009 08:19 PM

Subject:

Re: [p2-dev] p2 is greedy enough to be broken




This is a change in behaviour in comparison to update manager. However the exact same behaviour was implemented in 3.4.
The p2 behaviour is an improvement over the old UM behaviour which would always end up picking a random feature depending on your context and would eventually bring down too much.

As for the shape of the plug-in (to unzip it or not) the p2 metadata now puts the information where it belongs, in the plug-in metadata and no longer in the container like it was in UM.

PaScaL

Inactive hide details for James D Miles ---05/05/2009 05:32:12 PM---I believe this is a change in behavior. Even in the old updJames D Miles ---05/05/2009 05:32:12 PM---I believe this is a change in behavior. Even in the old update manager if you selected "Add required dependencies" it will add

From:

James D Miles <jdmiles@xxxxxxxxxx>

To:

P2 developer discussions <p2-dev@xxxxxxxxxxx>

Date:

05/05/2009 05:32 PM

Subject:

Re: [p2-dev] p2 is greedy enough to be broken




I believe this is a change in behavior. Even in the old update manager if you selected "Add required dependencies" it will add features and not plugins. While the scheme you suggest might work I don't think it is backward compatible.

Don't get me wrong I like the ability to only install the plugin if that is all that is required. It seems like we are making no real distinction between the feature element <plugin> and <requires>. The other thing that is wrong with installing from the <requires>. element is that we don't convey enough information. For instance we don't know if it should be upacked.

Inactive hide details for John Arthorne ---05/05/2009 03:47:59 PM---There is no greediness problem here. p2 is following the deJohn Arthorne ---05/05/2009 03:47:59 PM---There is no greediness problem here. p2 is following the dependencies as specified (there is no concept of an IU "managing" ano

From:

John Arthorne <John_Arthorne@xxxxxxxxxx>

To:

P2 developer discussions <p2-dev@xxxxxxxxxxx>

Date:

05/05/2009 03:47 PM

Subject:

Re: [p2-dev] p2 is greedy enough to be broken





There is no greediness problem here. p2 is following the dependencies as specified (there is no concept of an IU "managing" another IU). Since there is no dependency from Feature B to Feature A, so there is no reason to install feature A. If you want this kind of granularity, you can specify your dependencies accordingly (have features only reference other features). This is what we call "right-grained provisioning" in p2 - provisioning can occur at any granularity depending on how you configure your metadata.


John

James D Miles <jdmiles@xxxxxxxxxx>
Sent by: p2-dev-bounces@xxxxxxxxxxx

05/05/2009 11:48 AM



Please respond to
P2 developer discussions <p2-dev@xxxxxxxxxxx>
To
p2-dev@xxxxxxxxxxx
cc
Subject
[p2-dev] p2 is greedy enough to be broken




I am describing the default behavior of 3.5M7. I there another mode?

How dependencies are handled is a little different than what we are use to. For instance with managed only we only have plugins enabled if they are managed by a feature.

With p2 that is not the case. If I have a site
Site A
- Feature A that references plugin A. Both are on this site

Site B
- Feature B that requires plugin A. Only feature B is here.

Then I setup preferences so that both sites are visible or I could merge all of this into one site.

If I install featureB it will pull in pluginA from siteA but it won't pull in featureA.

- This will break our concept of install handlers totally.
- Since the touchpoint data is metadata for the IU it should break that also.

I think the answer is if a plugin needs to be installed we must install the IU that manages it.
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/p2-dev

_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/p2-dev

_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev


GIF image

GIF image