Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] Change Request Debugging 
On 2011-01-20, at 11:43 AM, Kevin McIntire wrote:

> Hi,
> 
> We are continuing to build an app on a headless equinox container that provides p2 installation facilities over an http interface and are running into issues with installing certain bundles.  We can install many features into the container and apply changes and start the bundles, but certain features are installing bundles that cause p2 to restart the already running servlets, and the http client never gets a response.
> 
> We've run across a generalized discussion of why this happens (http://dev.eclipse.org/mhonarc/lists/p2-dev/msg02006.html) but is there a good way to actually debug/diagnose this behaviour?
	At this point you would have to debug the Slicer code which given an IU will compute a "slice" (aka the transitive closure of this IU). The interesting method to see when an IU is added to the slice is org.eclipse.equinox.internal.p2.director.Slicer#consider(...) and why. Note though that the slicing proceed in a BFS so it may be a bit of pain to see exactly why something gets in.

>  Or, better yet, is there a way to exclude certain bundles from being considered as part of the installation plan?
	First, if the problem is caused by some IUs being updated, then be sure to lock (meaning specify a precise version) the IUs referred to from the feature.
	If this is not the case, then you have two possibilities.
		1) Specify negative requirements on the IProfileChangeRequest using the IProfileChangeRequest#addExtraRequirements
			Note though that the extra requirements are *not* persisted in the profile, so these extra requirements will have to be re-added every time a profile change request is emitted.
		2) Specify negative requirements in one / several IUs that represent the "core" of your system. This is equivalent to the "idea" of locking but except that you are locking things out. The aspect that is not optimal about that solution is that we currently have no support in the p2.inf to add negative requirements. So you either have to write a little utility to serialize the IU to disk, or provide a patch :)

At this point, I think that solution 2 is probably best because it allows you to control through metadata specified in a repository rather than having to have the negation be expressed in code.

Here is a snippet that shows how to create a negative requirement, the relevant values are the min and max card that need to both be set to 0.
IRequirement req1 = MetadataFactory.createRequirement(IInstallableUnit.NAMESPACE_IU_ID, iu.getId(), new VersionRange(iu.getVersion(), true, iu.getVersion(), true), null, 0, 0, false, null);

HTH
	


>  The servlet and it's supporting middle tier bundles are a bootstrap mechanism that we want running no matter what.
> 
> Thanks!
> 
> Kevin
> _______________________________________________
> p2-dev mailing list
> p2-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/p2-dev

Back to the top