Community
Participate
Working Groups
Created attachment 88344 [details] patch to registration helper It appears that the fragment IU for tooling.plugins.default was getting added as a fragment to the a.jre. When I looked through the content.xml, it looks like the tooling.plugins.default is specifying a required capability of IUs with type "bundle". Since a.jre does not expose any type, or the type bundle, it appears that resolution helper is incorrectly determining that tools.plugins.default can be a fragment for a.jre. Later, when the install stage is happening, the action installBundle is not able to be found for the native touchpoint (as that's the touchpoint defined on a.jre). Two ways come to mind on how to fix this issue. First, we should only allow fragment IUs to be hosted to things with the same touchpoint type, or we can't re-use the touchpoint instructions from the fragment IUs that don't have the same touchpoint. Or second, I believe that RegistrationHelper should be smarter about only allowing fragments to be associated to hosts that meet the given requirements (assuming that's how RequiredCapability is supposed to be used on IU fragments). If this is indeed the case, I've created a patch, attached, that appears to allow provisioning to work correctly by not allowing a fragment to be connected to something that does not meet appropriate required capabilities.
I have seen this happening before, but I can't find an existing bug about it. Presumably the extra checking in your patch only needs to happen for the case of binding the default fragment. I.e., if a fragment explicitly identifies the host it wants to attach to, it seems reasonable to assume its touchpoint data is applicable to that host. How can I reproduce the problem you're seeing? The Generator currently does produce a configuration unit for a.jre, so it should not end up getting bound to the default CU (the default CU is only used if there is no more applicable CU available).
Correct, this patch only needs to do this extra checking in the case where the host ID on the fragment is null (default). To cause this issue: 1) I generated a standand artifact and metadata repository from an Eclipse 3.3 SDK 2) Create a test case that installs using a single group-type IU instead of using the standard SDK one. I have that IU constructed with a few required capabilities for the software I want as well as to the different tooling...default objects as needed for the fragments to be included. I have this currently as part of a larger system and haven't yet separated out my logic into a single standalone test case, though the flow into p2 is through a provision() request so I would imagine you can reproduce it that way.
See related discussion in bug 217173.
Created attachment 88764 [details] patch to resolution helper Here's an updated patch that only checks required capabilities of fragments matching the host if the host ID is indeed null.
This looks reasonable to me - Pascal, can you also review? Since attachment of fragments uses the framework resolver, we are presumably only looking at fragments that require a capability provided by the host. I think this patch just ensures that the host satisfies *all* of the required capabilities of the fragment.
*** Bug 219695 has been marked as a duplicate of this bug. ***
The example attached in bug 219695 allowed me to reproduce and understand why this was working in the SDK and not in Tim's and Andrew's scenario. It goes as follows: - in the case of the SDK (generated from the root IU), the a.jre IU gets bound to another a fragment called "confg.a.jre". This fragment is properly attched to the jre IU because it is referred from the SDK root IU - in the case of a proper produdct. The jre is brought in by following the dependencies but the fragment is not brought in since no one depends on it. Therefore because the fragment attachment code not doing a lot of checks we ended up attaching as a CU to the jre the tooling.plugin.default IU which then causes the pb. I'm releasing a modified version of Tim's patch where instead of ensuring that all requirements are satisfied, I stop after only one is satisfied.
