[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] Bundle start configuration


On 2011-12-14, at 5:23 AM, Todorova, Katya wrote:

Thank you for the time and the answer.  It helped a lot to resolve the emerged conflicts in my understanding of CUs.
 
Since this fix probably wouldn’t be of community interest in short term, I would like to summarize the problem and your comments in order to be available and easily accessible in future.  Should I open a new bug?
Please do open a bug with the [engine] tag and capture the mentioned solution.

Btw it is not a good practice  to include in the IU the configuration information since it makes for your IU to be less reusable since it is now bound to the context of a particular deployment (in your example set to start level 3) and as such you would have to create a completely new IU if you wanted to now deploy this IU at start level 5.

This issue made me think that it would be useful to have a central p2 architecture wiki capturing p2 components and their responsibilities. There’s plenty of information on that (community presentations, discussions, bugs, etc) but it’s difficult to find and put these pieces together.
I don’t know if Eclipse provides some guidelines how to document that, but if you think it would be useful and have an idea how to organize that, I could try gathering what’s available (please advice how to proceed if this is the case).
I don't know of any guidelines. I agree this would be useful. Go ahead, the wiki is all yours.

 
Kind regards,
Katya
 
From: p2-dev-bounces@xxxxxxxxxxx [mailto:p2-dev-bounces@xxxxxxxxxxx] On Behalf Of Pascal Rapicault
Sent: mercredi 14 décembre 2011 04:25
To: P2 developer discussions
Subject: Re: [p2-dev] Bundle start configuration
 
Took me a long time to understand what you were getting at, as at first I thought you had an IU and a CU.
 
I agree that in the case you describe, where an IU carries touchpoint data and there is also a CU attached to it, the behaviour is bogus.
This is slightly different than the bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=263087 I was talking about but is a friend of it.
 
As for right fix (which does not require the previous bug to be fixed), I don't think the attachment logic is the right place and for two reasons:
            - The attachment logic should only deal with matching a CU to an IU. The touchpoint data is the business of the engine. Fixing this in here would mean coding in the resolver some specific knowledge about the shape of the metadata for a bundle (in this case the fact that there is manifest, etc) and would not work for any other case.
            - Dropping the default CU or any CU when there is something in the main IU would not be very flexible, and I can see how someone would be able to complement someone's data through a CU.
 
IMO, a more appropriate solution would consists in enhancing the engine and the touchpoint data to allow each instructions section to declare the expected behaviour when the situation arises. At this point I could see several keys: before, after, override, delegate that would control this (as I'm writing this I'm sure we can find better wording in the AspectJ literature). For example, override would say that the value in the CU would override what is specified in the IU; delegate would mean run whatever is in the IU and ignore what is in me the CU; before and after meaning run the CU in addition to the other instructions.
 
HTH
 
On 2011-12-09, at 9:30 AM, Todorova, Katya wrote:


I can’t think of more specific requirement than the one belowJ
It seems my idea of CUs is not consistent so I would appreciate a little help here.
 
Having touchpoint data doesn’t lead to creation of CU, right?  On the other hand, instruction parser merges info coming from touchpointdata and attached CU.
So from my point of view having touchpoint instructions and applicable fragment is the only currently possible case where two “fragments” are attached. So, they get merged and the result is bizarre.
Isn’t it local touchpoint data the most specific case?  Is there a conceptual difference between CU and touchpoint data?
 
Until the bug you mention is fixed, isn’t it better not to attach any CUs if there’s other touchpoint data than manifest details?
 
Thank you,
Katya
 
 
    <unit id='test' version='1.0.2' singleton='false'>
      <update id=' test ' range='[0.0.0,1.0.2)' severity='0'/>
      <properties size='2'>
        <property name='org.eclipse.equinox.p2.name' value='test'/>
      </properties>
      <provides size='3'>
        <provided namespace='org.eclipse.equinox.p2.iu' name='test' version='1.0.2'/>
        <provided namespace='osgi.bundle' name='test' version='1.0.2'/>
        <provided namespace='org.eclipse.equinox.p2.eclipse.type' name='bundle' version='1.0.0'/>
      </provides>
      <requires size='2'>
        <required namespace='java.package' name='org.osgi.framework' range='1.5.0'/>
        <required namespace='java.package' name='org.eclipse.osgi.framework.console' range='0.0.0'/>
      </requires>
      <artifacts size='1'>
        <artifact classifier='osgi.bundle' id='test' version='1.0.2'/>
      </artifacts>
      <touchpoint id='org.eclipse.equinox.p2.osgi' version='1.0.0'/>
      <touchpointData size='1'>
        <instructions size='3'>
          <instruction key='manifest'>
            Bundle-ManifestVersion: 2&#xA;Bundle-Activator: Activator&#xA;Bundle-RequiredExecutionEnvironment: JavaSE-1.6&#xA;Import-Package: org.osgi.framework;version=&quot;1.5&quot;,org.eclipse.osgi.framework.console&#xA;Bundle-Name: test&#xA;Manifest-Version: 1.0&#xA;Build-Jdk: 1.6.0_07&#xA;Bundle-SymbolicName: test&#xA;Bundle-Version: 1.0.2 &#xA;
          </instruction>
          <instruction key='unconfigure'>
            org.eclipse.equinox.p2.touchpoint.eclipse.setStartLevel(startLevel:-1);org.eclipse.equinox.p2.touchpoint.eclipse.markStarted(started:false);
          </instruction>
          <instruction key='configure'>
            org.eclipse.equinox.p2.touchpoint.eclipse.setStartLevel(startLevel:3);org.eclipse.equinox.p2.touchpoint.eclipse.markStarted(started:true);
          </instruction>
        </instructions>
      </touchpointData>
    </unit>
 
 
From: p2-dev-bounces@xxxxxxxxxxx [mailto:p2-dev-bounces@xxxxxxxxxxx] On Behalf Of Pascal Rapicault
Sent: vendredi 9 décembre 2011 14:56
To: P2 developer discussions
Subject: Re: [p2-dev] Bundle start configuration
 
My guess is that this is because the CU requirements on the IU are not specific enough and this causes the fragment to not be attached. The code is in the director AttachmentHelper.
This is likely a friend of https://bugs.eclipse.org/bugs/show_bug.cgi?id=263087 which we've discussed before.
 
On 2011-12-08, at 10:41 AM, Todorova, Katya wrote:



Hi guys,
 
I’m trying to install in Eclipse a bundle  published with  touchpoint instructions for start level = 3 & start = true (I use p2.inf in bundle META-INF to describe these).
As a result I get a strange mix of the local configuration and default bundle tooling presented in Eclipse – start level is 4 and start flag is true in the final bundles.info.
 
I assumed that local configuration would be preferred over the default one but it seems it’s not the case. What would be the correct behavior according to you?
 
Thank you,
Katya
 
 
_______________________________________________
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