Community
Participate
Working Groups
Pascal and I had a long discussion about repo reference following in a provisioning context. What should it do (which is really bug 305226) and how do we make use of it in the UI to ensure that real problems are being solved? The real-world problems we see are these: 1 - a metadata repository has a reference to an artifact repository which is not co-located. For example bug 278191. If you are pointing, for example, to another eclipse, you should not have to "contact all sites" to find the artifacts for that metadata repository. If a metadata repository knows where its artifacts are, we should always honor this rather than always assume colocation. 2 - a metadata repository A has a reference to another metadata repository B because an IU in A has a requirement on something in B. Today, you have to "contact all sites" to find that repo. So what we have decided is this: CORE behavior - ProvisioningContext should *always* follow artifact repository references as part of doing its work. This does not require use of a special property. This fixes problems like #1. - ProvisioningContext should *not* follow metadata repository references as its normal course of doing work. However the FOLLOW_REPOSITORY_REFERENCES flag can be used to direct it to follow (recursively) enabled repository references from the repositories that are set into the context. Specifically, enabled means either: - known by the manager and enabled from a user point of view - not known by the manager (because the referring repo had never been loaded, for example), but the repo reference itself is enabled. - we will never follow references if the manager knows about them and they are disabled. There is room in the future for prompting the user, but this is covered in bug 303258 On the UI side, here is what we do: For install operations: - Determine the initial provisioning context as we do today. It's either all enabled sites (when the "contact all sites" checkbox is checked), or else it's a specific set of repos dictated by the combo box. - Try to resolve. - If the resolution fails due to missing requirements, then try again with repo referencing set to true. The second try will solve problems like #2. In practice the second try will make a bigger difference when "contact all sites" is not checked. Note that the checkbox says "Contact all sites when looking for required software" so I think we are good with redefining the "unchecked" state. We never said, "only check the site that is selected." By using repository referencing, we are broadening the meaning of the unchecked state to look for requirements in any repositories explicitly referenced by the user's selection.
fixed in HEAD >20100422. The one thing I'm not really happy with is having to reach into director/planner internals to detect a missing requirement. In order to evolve bugs like 261928, we'll want better API for this. For now I've hidden this code in the method InstallOperation.missingRequirement(IProvisioningPlan failedPlan)
opened bug 310212 to further discuss the explanation API.
I was looking for a good user scenario to show how our life is better with repo referencing. This scenario is contrived, and a little weird, but shows the improvement. In 3.5.2, I added the site http://download.jboss.org/jbosstools/updates/development/ I had [ ] Contact all sites unchecked. I selected Maven Support->JBoss Maven Integration When I try to resolve, I immediately fail with Missing requirement: JBoss Maven Integration 1.0.0.v201003050540R-H56-GA (org.jboss.tools.maven.feature.feature.group 1.0.0.v201003050540R-H56-GA) requires 'org.maven.ide.eclipse.feature.feature.group 0.10.0' but it could not be found The maven code is not found. (Yes, I realize that one should probably already have maven installed if they are trying to install JBoss Maven Integration. It's like the Mylyn Connector case. ) In I20100426-0852, I can get further. I end up failing in the end due to a different missing requirement (wst). But at least this scenario proves that the reference following is working. If the WST repo were referenced by JBoss then possibly the whole thing would succeed.
