Community
Participate
Working Groups
Build ID: I20080513-0817 Steps To Reproduce: 1. Create a feature to contain the following URL <url> <update label="my update site" url="http://tpftoolkit.torolab.ibm.com/tpftoolkit/updates34/"/> <discovery label="updateSiteName" url="http://download.eclipse.org/eclipse/updates/3.4"/> <discovery label="secondaryUpdateSiteName" url="http://download.eclipse.org/releases/ganymede"/> </url> 2. Create a update site to include the above feature and build the update site 3. Load the update site to an http server 4. Install the above feature from the update site 5. Restart workbench 6. The above urls are not displayed on the Available Software view More information:
To avoid presenting the user with too many sites that he never heard of, they are made available in the "manage sites" dialog for the user to add at wish.
I think this actually doesn't work for this particular case - installing a feature from a legacy update site. Support was added in M7 for installing from a p2 repository (bug 228046), and for features unzipped in plugins/dropins, but not for update site repositories. We could implement this fairly easily in UpdateSiteMetadataRepository.
Samuel, were you using the p2 UI or the old update manager UI?
All the steps were done with P2 driver. Another little thing to remind before it's too late if this function needs to be implemented. The update site URL of the included features should honor the setting on the parent feature. If the parent feature handles the update for the children features, the URL of the childrean features shouldn't appear.
Created attachment 100635 [details] Fix
Note that you won't get the exact same semantics with p2 as you did with Update Manager, but this is intentional. In UM, each feature specified its update URL. This is problematic because different providers might want to control updates differently for the same feature. Some may want updates for feature F to come from server X, and another may want them to come from server Y. This was difficult in UM because the update server URLs were hard-wired directly into the feature.xml. You had to use the complicated update policy support to redirect users to a different server. In p2, we explicitly do *not* tie the update servers to the units being installed (features, bundles, etc). Instead, the servers are specified at the repository/site level. Each repository can list a different set of repository references for controlling where updates come from. This makes the features easier to reuse for providers who want to control where updates come from. For backwards compatibility we try to convert update URL references in feature.xml to repository references, but there are some semantic differences. For example the mechanism of parent features overriding the update URL for child features doesn't make sense in the p2 way of doing things. Instead you can craft the set of repository references listed in your p2 repository content.xml to control where updates come from. Note for myself: we need to document differences like this in the porting guide or somewhere similar.
A product may depend on specific version of the common component. That's why it needs a way to control the update of all the common components. The parent/including feature mechanism is the way provided by the UM to handle the global update and it works fine. I'm not saying that p2 has to do exactly the same thing to provide this function. I don't mind that p2 provides a complete new way of doing this. I haven't seen any p2 guide in this area and what I was told was to use p2 as UM. That's the story behind this bug. What we need is a predefined repository site shipped by the product. What the customers need to do is just a button to click, which will start the product update.
+1
Fix released.
Test failed with Build id: I20080605-1300
Created attachment 104351 [details] zipped test update site 1. Unzipped the attached update site 2. Install the feature Parent feature 3. Parent feature contains the following URL <url> <update label="my update site" url="http://tpftoolkit.torolab.ibm.com/tpftoolkit/updates34p2/"/> </url> 4. Child feature contains the following URL <url> <update label="my update site" url="http://tpftoolkit.torolab.ibm.com/tpftoolkit/updates34/"/> <discovery label="updateSiteName" url="http://download.eclipse.org/eclipse/updates/3.4"/> <discovery label="secondaryUpdateSiteName" url="http://download.eclipse.org/releases/ganymede"/> </url> 5. Expected behavior: the update site URL in parent feature shows in the available software site and the ones of the child feature don't 6. Result: none of them shows
This is target milestone 3.4 RC2 which is long gone. Please correct milestone.
Created attachment 104377 [details] Screen shot This works for me in 3.4 RC4 build. Note the site is not enabled by default for performance reasons. If you open the "Manage Sites" dialog you can see these repositories and enable them.
Closing. Please enter a new bug report for any new issues. This problem was fixed and verified.
