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: [email protected] [mailto:[email protected]] 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
Bundle-Activator:
> Activator
Bundle-RequiredExecutionEnvironment:
> JavaSE-1.6
Import-Package:
> org.osgi.framework;version="1.5",org.eclipse.osgi.framework.console
Bundle-Name:
> test
Manifest-Version: 1.0
Build-Jdk:
> 1.6.0_07
Bundle-SymbolicName: test
Bundle-Version: 1.0.2 

> </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: [email protected] [mailto:[email protected]] 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
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/p2-dev
>
> _______________________________________________
> p2-dev mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/p2-dev
>
> _______________________________________________
> p2-dev mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/p2-dev
