See comment embedded.
[...]
(b) Alternatively, when a user logs in, the application contacts a provisioning server and obtains a list of Features/Versions that the user is permitted to use. We then call Update Manager and install/update ONLY those Features/Versions and appropriate dependencies.
So we'd love to have feedback/input from the community.
Detail:
We've got (a) above tackled using P2. We're struggling a bit with the API to implement (b).
The API that implements (b) is:
public boolean update(URL[] updateSiteURLs, File downloadRootDir, Set<FeatureVersionedIdentifier> featuresRequested) throws InstallError
In P2 terms, updateSiteURLs wind up being consolidated into a compoundQueryable.
This is correct
I'm not sure what P2 terms are yet for downloadRootDir, but I'm guessing that this has something to do with P2 Profiles? In Update Manager, this specified a root directory where we would create your install site(s). The purpose is to enable installations on Citrix or *nixes where the installation directory might not be writable; this we have to support putting updates somewhere else.
p2 hides any concept of location except on creation of the installation. You should dump this parameter.
featuresRequested is the set of Features that the current user is allowed to use. It obviously must be a subset of the features on updateSiteURLs.
[[A FeatureVersionedIdentifier simply is a (String, String) pair where the first String is the Feature ID and the second is either the exact version, a version number without the qualifier, or "0.0.0" to specify the latest version. (IFeatureReference doesn't implement equals/hashCode, so we needed something that would be usable in collections. Plus we wanted to be independent of Update Manager so we could later move to P2.) This class is very similar to an InstallableUnitDescription, but just for Features; maybe there's another even closer match in P2?]]
See class VersionedId.
featuresRequested is basically our query API.
[...] What are you trying to achieve by doing the traversal ? Why do you want to create this synthetic IU for the things that you are installing? This implies that only the code that we are looking at will be able to update the product unless you start having builds that produces an IU rightly named.
|
